Checkout the React-ive Meteor app/repo and the readme for a more complicated app.
The Flux leaderboard shows how to use flux for more complex apps.
(looking to create a flux branch for Reactive Meteor soon)
These are distilled out of my production apps that i’ve made recently. I’ve written several thousand lines of production React code and have ironed out a lot of Meteor specific issues. I’m migrating all of my other apps gradually as bugs pop up, they get replaced with React + flux.
I love the sound of React but im still put off by JSX.
It mangles HTML and javascript together in a way which often looks like a mess.
For example in manuel’s post in the react example we see this.state.text.length === 0 Why are we running javascript inside a template? Isn’t that unmaintainable? Doesn’t this go against everything templating/views stand for?
In the same example the blaze helper buttonDisabled makes the template a lot easier to manage. I don’t need to rely on the implementation details of why the button should be disabled.
Blaze just looks closer to separating design and logic. You can write documentation for helpers etc and then hand it to a designer who only has to touch the templates.
@ahref I am at the tail end of a huge project that uses Blaze + Meteor. I just started a new one with React + Meteor. JSX is awesome! My code never looks mangled or like a mess. In React you break everything down into small components and it makes your app much easier to test and reason about. Every time I have to work in the app I’m just finishing I wish I would have done it in React. Yes, you can use React without JSX but it makes markup more complex
I just read a well-written overview of React on Tuts+, and it gave me a good (though very high-level) view of how it works and why people find it so compelling:
I agree that people (like myself, until I read that first tutorial I linked to) who are put off by the thought of mixing presentation layer (HTML) and code may be jumping to conclusions too quickly without giving it five minutes to learn a bit about it first.
But I disagree with the notion that separation of the two is no longer relevant. I think the Tuts+ author put it well when he said (I’m summarizing) a strict separation of those concerns (a la MVC) is (still) appropriate for small- to medium-sized apps, but for huge, sprawling & distributed web apps (e.g. Facebook), it makes a lot of sense (at least, in client-side code) to think in terms of individual components (like a Tweet box, or a playlist, or an email inbox, or a form) and to keep the HTML template and the DOM-manipulation code together, the way React does. (I still think separation of code and HTML, like most MVC frameworks enforce, is still the way to go with server-side frameworks, like Yii, Django and Rails. I can’t think of any good reason to mix HTML and PHP together, for example).
Then maybe I’m not understanding React as well as I thought I did (I’m at the beginning of the tutorial). And, if it doesn’t do that stuff automatically, why is it called “React?” I thought one of its major selling points was that it automagically managed DOM updates without you, as the developer, having to manually write event handlers (like in Backbone) or data bindings (like in Angular), similar to the way Meteor is so awesome with reactive updates behind the scenes.
I’m all about using the best tool for the job. React sounds very cool, and I’m sure all the people talking about it can’t be wrong, but my main priority with React is figuring out how it could be most useful to me, today. I have no plans to build anything as large as Facebook anytime soon, so if doesn’t have quite as many compelling benefits for small/medium-sized apps, then I’m not sure I want to invest the time to learn it.
I’m completely sold on Meteor as an upgrade to the way I’ve been building server-side and client-side web apps for the past decade+. But what I REALLY want to know about React is, how can it be used with Meteor (in specific use cases; I’m aware of the meteor-react package, but I don’t know much about it)?
And what compelling features does React offer that Meteor doesn’t? Can they both be used together without having to jump through too many hoops to get them to integrate play nicely with each other? If I would have to go back to manually writing data-binding code to use React, when Meteor manages that for me, I’m not sure how interested I’d be.
@ahref
JSX is optional and is there mostly as a convenience for developers. You don’t have to use it. (from what I can tell - I haven’t used React yet. I’m still investigating whether its worth the effort to learn or not, like you all).
Please, someone correct me if I’m wrong here. I’m just trying to see if I’m understanding React’s design philosophy.
From what I can tell, the reason they couple the JSX template together with the JavaScript that controls it is that, in React, the primary entity is the Component, which represents a UI component, like an inbox, or a playlist, or a login form (and this is partially what people mean when they talk about creating custom components in React).
Also from what I can tell, the React framework authors’ reasoning for coupling the view code (JSX) and the Component that renders it together is that, in a giant web application (they created React for Facebook, after all), there are so many different little UI components, that the MVC model doesn’t make sense anymore - keeping the templates separated from the controllers and models starts to become more of a hindrance than a beneficial design pattern in such a large front-end application, right? If that’s correct, I can see how that might make sense for large front-end applications.
If I’m way off or if I’ve gotten any part of this wrong, please steer me in the right direction. I don’t want to invest weeks learning React if it’s not right for me, but I don’t want to miss out either, if it is.
It’s most likely my lack of a better explanation! It does automatically update but only when calling setState or force rendering.
Since it’s just the view layer it doesn’t include or force you to use a reactive/observable data source. Instead it uses normal Javascript objects, arrays, etc…
For instance to make a counter increase with local state here’s what would happen
In React
set initial state : {count: 0}
setup template/render: Counter: {this.state.count}
on button click handler: this.setState({count: this.state.count + 1})
view automatically updates
With both Blaze and React you’re declaratively describing how the view should look instead of imperatively saying how to do it (like jQuery). With the React example the state is locked into just that component (unless it passes it down to a child).
When you want to auto render with database collections you need to use the mixin so that it will auto render on change (you could do this manually but it’s verbose).
Does this help answer your question?
It’s really about simplicity and easier maintainability. Blaze is great too but is easier to make a mess with. It doesn’t force you to use good habits.
Also the React community focuses a lot on making things maintainable… not so much here in the Meteor community (more is focused on finishing faster or less keystrokes).
Meteor offers a lot more than React, as Meteor is the server, client, etc… using React just swaps out Blaze for React. Once you learn how data flows through React they play together really nicely!
Ok, yeah - I think I get it now. When you said that, I remembered reading in that Tuts+ overview article that React.js creates some sort of virtual DOM, and that Components are organized into a top-down, tree-like hierarchy, and that when you have a piece of your UI that you want to be updated dynamically, you just (declaratively) tell the top-level Component to re-render, and it takes care of updating all the dynamic, data-driven pieces of your template by recursively telling all of it’s child Components to re-render. That makes sense.
It also makes sense that, like you said, being a client-side only framework, it’s not typically accessing data that’s external to JavaScript (even data received through an API would likely be in JSON, or accessed through JavaScript’s XML API, at worst [does JavaScript have an XML API? I’m not sure]).
I really like the declarative approach better when it makes sense.
Yeah, I realized early into the Discover Meteor book (I’m only like half-way through it) that the choice not to impose “convention over configuration,” like some frameworks do, would be nice in some ways, but that it would require that you impose your own structure on your applications. And that requires a lot of discipline. But there’s always a trade-off. Frameworks that impose a lot of conventions on you do free you from having to make decisions about everything, but then they also take away your freedom to make choices about some things you might want to make your own decisions about (but that’s what plugins are for ).
That sounds good. It might work well for me, too, because I’m just now learning the most basic fundamentals of Meteor. I haven’t even begun to read through all the Blaze documentation yet.
But, how well do they interact, Meteor and React? I hear what you’re saying about replacing Blaze with React, but is it an actual drop-in replacement? Or do you have to make tweaks to Meteor’s configuration, or adjustments to your workflow to integrate them together into an app?
It’s essentially a drop in. You just add it with meteor add react and then create a .jsx file. If you’re not using a router then you’ll have to mount the topmost component with React.render into a div and from there on it takes care of itself.
Session pretty much doesn’t get used as you’ll typically use the component state instead. In order to use the database/minimongo you can use the mixin and getMeteorData to auto-update/render. For large apps you can even use flux… but that’s another post
Reaktor is a great facade on top of FlowRouter for easy React routing.
You can even render Blaze templates into React and vice versa (I do this for certain packages like DataTables which is a lifesaver). If you don’t want any Blaze you’ll be able to drop it easier in Meteor 1.2 (I don’t think that’s released currently)
I’ve also open sourced a React + Meteor boilerplate that you could use to clone and get started. It might have a little too much for day 1 but you could always just edit the both/pages/Home.jsx page and then explore when things make more sense.
This also has browserify setup so you can include NPM packages/components easily.
Particularily I’m interested in why this.state.text.length == 0 floating inside HTML is suddenly OK because react is involved.
I get that it is a simple example but it resembles the old days of PHP where you’d drop in and out of the language with <? ?> and use echo statements.
I know its not the same because react tracks state etc but readabilty / code wise it looks the same.
Would you use such a style in a full application?
Ultimately it just appears to be a mix of concerns. Logic within templates should be a minimum right?
As for JSX it looks like it would get unwieldy with a larger component. For example a product information card. I’ll look through some examples but I guess I want the HTML in a different file away from the JavaScript to allow designers an easier time?
Whoa, this thread really blew up! I’m glad it sparked such a discussion, and I appreciate the time everyone took to reply. I’ll have to revisit this when I have some spare time, hit the links, and post a response. Thanks!
Can we bind a react view state directly to a document and have it update when the document updates?
Yes we can! There’s a mixin you can call within your react objects.
The executive summary here is:
Reactivity isn’t gone. Documents and their properties still updated on the fly.
Client-side functionality is modified by changing the state.
See this example. Now, obviously this isn’t using React but the principle applies. If you don’t use React, you would need to use a ReactiveVar or even worse, a Session variable to move things around client-side.
I guess I need to look into some of the open source react + meteor projects provided here and try running some of them. Which will probably answer some of my queries with examples but probably cause more
[quote=“SkinnyGeek1010, post:30, topic:8100”]
It’s essentially a drop in. You just add it with meteor add react and then create a .jsx file.[/quote]
That’s great - that’s what I was hoping to hear. Thanks for explaining all this, btw. You’ve done a better job of explaining React.js (in a way I could understand, at any rate) than their own introduction did.
Please don’t take offense to this – I am not criticizing you at all, but Facebook (I’m not the biggest FB fan, in general, but they do make good software). But I think one of the biggest turn-offs about React and certain other frameworks (e.g. Rails) is the way they invent new language to describe their technology in a way that needlessly increases the slope of the learning curve. Mount the component, really? It just feels so … I don’t know - corporarish (that’s not a word, I know). I get that people need to explain their design philosophy, and metaphors are a useful way to do that, and I realize there’s a need to differentiate your product from the rest, but I just think some organizations overdo it.
Sorry, rant over. I shouldn’t pick on Facebook or React.js. They’re not even the worst corporarish offenders.
By mixin, do you mean the react package in Meteor, or is that a React.js thing?
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? And if it is just a set of guidelines for workflow, how strictly is it enforced? Is it just a matter of experiencing less pain if you conform your app’s structure/workflow to the Flux guidelines and/or rules?
All things considered, I must say that React does look pretty useful. If it’s really true that they’ve come up with a better way of thinking about the front-end development process (as people have said), then that’s enough reason alone to try it. But if you hadn’t explained it so well, I think I might have dismissed it, so thanks for that.
it is not only React, also Polymer etc…
Simple little components maintaining their own state.
But without something like flux to define single point of truth for state, it ends up quite messy.
If you worked with Angluler 2way data binding or Polymers, you would know .
Or that facebook message notifier example showing nicely how is code becoming impossible to maintain when few different component need to have state in sync without central store.
Still if there is nicely defined flux state design above blaze components it could be interesting. There is not much to use atm, mby ReactiveDict if we want to use it meteor documentation way. And these are not exactly how flux should be handled.
@ahref I assume that the reason developers viewed putting logic in a view as bad practice is because it can turn into an unmaintainable mess super fast. This isn’t the case with JSX (if you’re doing it right). Every page in your app is comprised of smaller components. If a component is getting unwieldy it is a sign that you should break it up into smaller components. For instance, a form would be some sort of form container component and then each of the form input fields would likely be it’s own component. I do this in my apps and it makes it super easy to build the equivalent of something like AutoForm with all the bells and whistles that come with it. Here is an example login page:
I don’t know about you, but this definitely doesn’t seem unwieldy to me.
With regard to the {this.state.text.length === 0} example, I don’t find it to be a problem. Although I would destructure this.state so that I was using just text in the code.
I’ve actually found mixing the JSX and JS in the same file to be quite refreshing. I don’t have to bounce back and forth between files to set everything up. I set an onChange attribute on some element and then a few lines above that I declare the handleChange method. I think that this style also forces you to think very carefully about the architecture of your app.
I would most definitely use React in a full application (I assume that is what you were asking). As to whether it’s hard for designers I can’t answer that. I usually turn designs into html and css anyways so I haven’t had to deal with that problem.
