This is totally normal. I think the 5 stages of grief apply here 
Once you start to get used to the look it tends to look very neat and orderly. Oddly enough I now feel that my older apps with templates/javascript helpers look/feel like a mess.
So actually if anything itās using a markup (JSX) in JavaScript not the other way around. The React component is all JS except for whatās returned in the render method. You can use all of JS above the return to add as much logic as needed.
JSX is just a convenience for designers and for developers because itās easier to think about markup than function calls. This is an example from my react login buttons project that doesnāt use JSX (iām doing this because so people might not have JSX installed).
So personally I wouldnāt quite write it that way in production. Itās shorter but less clear whats happening at glance. The component will re-render every time setState is called so here, every time text is entered in the textarea. On this re-render pass itās checking to see if length is truthy and returns a boolean. If itās > 1 then it will be visible.
Worth noting, the entire render block will be rendered, in Blaze only the bit that is reactive will change if itās data changed.
Hereās a slightly more readable version. notice that this.isDisabled is getting called right away as opposed to the this.handleChange which is just the func. reference. Youāre looking at the render method and can now declaratively setup how it will look at any state, as opposed to imperatively setting it up with PHP.
var TweetBox = React.createClass({
getInitialState() {
return { text: "" };
},
handleChange(event) {
this.setState({ text: event.target.value });
},
isDisabled() {
return this.state.text.length === 0;
},
render() {
return (
<div>
<textarea onChange={this.handleChange}></textarea>
<button disabled={this.isDisabled()}>Tweet</button>
</div>
);
}
});
Itās used frequently. Using this.setState in larger apps is only used if no other component wants to know about the state. If it does itās either pushed up higher so both can receive that state or something like flux is used to globally share it in a sane way.
Hereās an example of declaring if a user should see the ādelete postā button.
This explains it far better than I could, itās even queued up to answer why FB does this 
https://youtu.be/DgVS-zXgMTk?t=113
I though this as well at first. However this is because I was making large templates. I donāt know what the product card looks like but it could prob. be broken down into 4-5+ components, stored in a product_card/ folder. You can also render a blaze template right into the JSX so itās possible to do that to.
Hehe, yea this is prob. half and half fault. They have a method called componentDidMount that fires after the itās inserted into the DOM and I had that in my head. I just meant that it needs to be inserted into the DOM. 
Itās an optional package that comes with the Meteor react package by default. Itās made by MDG. Itās in the Meteor tutorial I linked to
[quote="thebionicman, post:38, topic:8100"] I haven't had a chance yet to read beyond the first page of the overview on the Flux site. It said that it is more of a process than a framework, though. Is it like a set of guidelines? Or does it involve some sort of API at all? [/quote]
Ah yea donāt let flux ruin the simplicity of React 
So flux is just a spec they released on how you can do this. They do provide a dispatcher but nothing else. This led to a flurry of flux libraries that do the same thing, but with different APIs. My favorite is Alt.
Itās pretty much the wild west. Most stick to the pattern. Some like Reflux remove constants and the dispatcher which breaks the point of flux. Alt will hide these as implementation details and instead uses some convention to generate them for you, providing a nice simple API and still sticking to the pattern.
The gist is that it allows you to decouple your view and share state across the app in a sane way.
- View calls an action (w/ optional payload) and itās job is done
- Action method takes payload and could modify it and then dispatches it
- Data store (state obj) handles action and can use payload to update itself and fires āchangedā event
- Views receive changed message and re-render
If youāre interested in how this works this is a great article.
do you typically grab data from subscriptions for a template and store them in templateVars as well to keep all template state in templateVars, or just data thatās not from a subscription? Iām deciding between Blaze and React and although I really like Blazeās simplicity and syntax I love how React maintains state for each component. Iād prefer to explicitly state each Blaze templateās state variables rather than assume everything required is present from a subscription