I completely agree with this statement. I tried Angular and Backbone before coming to Meteor. The way Meteor implemented templates with Blaze just felt right. I was able to get productive SO MUCH FASTER than with Angular in particular. With Angular I spent weeks training myself and building demo type applications. In the same amount of time with Meteor, I was able to build twice as much. At least with Angular 1.* (I have not tried 2.*) I think Meteor’s template system is head and shoulders ahead in terms of productivity.
I agree with this. React doesn’t seem like a real advantage over Blaze from what I’ve seen and read. Ok, there’s a lot of mindshare around it right now, and people keep saying it’s great, but the demos I’ve seen and the articles I’ve read have not impressed.
If this is all about trying to get Meteor adoption, and it’s at the expense of Blaze, then this is just wrong in my opinion.
Please don’t depreciate Blaze for any other front end framework at this point, none complete in terms of simplicity or productivity so far.
is there a way to wrap the npm modules like in the material-ui-leaderboard to a package, such that those modules can accessed within the same package or other packages?
First, I think this is awesome and really appreciate the work to provide first-class support for React for the view layer. But I share the concerns mentioned here.
I haven’t seen this addressed yet. I have more experience with React than with meteor, and I think introducing this new concept of this.data is very un-react-like. Components should be composed of props and state. In our own non-meteor flux implementations, we typically attach fetched data to state in the component.
Sometimes we’ll use the component as simply a data fetcher, but in this case the data still gets assigned to this.state, and then passed into a child component as a prop. I haven’t yet dug into the mixin code to see if there is a reason this is necessary (will try to do so), but offhand I don’t see why we couldn’t be using getInitialState and this.state for the reactive meteor data. As mentioned it means we cannot use shouldComponentUpdate as intended, nor can we use pureRenderMixin. And I think in general it adds significant complexity to the React side of the equation.
Pete Hunt also uses this.data for his Minimongo cache implementation. I’m curious why as well but it might be because it gives them more control over when it will render? example:
[quote="rralian, post:50, topic:6150"]
As mentioned it means we cannot use shouldComponentUpdate as intended, nor can we use pureRenderMixin. And I think in general it adds significant complexity to the React side of the equation.
[/quote]
You can still use the Meteor mixin in a ‘container’ component and then pass the data to the child. For example the ‘FeedListContainer’ component would fetch data and render FeedList while passing this.data as it’s props. This also makes FeedList more re-useable.
You can still use the Meteor mixin in a ‘container’ component and then pass the data to the child.
Yep, I recognize that. My point is that the container component in most flux implementations still generally uses setState as the mechanism to trigger a re-render (upon observing changes from a store). That is at least how I am used to working in React. And I’m not sure why we wouldn’t use the same general approach here, particularly as it seems more in line with how React is meant to work.
Fair enough, I hadn’t seen that before, but I would suspect you’re correct about the reasoning. Maybe we have a similar reasoning for using this.data in this meteor-react mixin, but I’m not yet understanding it.
IMO it doesn’t make sense to use state because if you want the data you are loading to be able to take state as an input, you end up with a circular dependency on state itself, and a potentially infinite loop of loading new data.
I think that using transient state (regular array) with an event emitter and observing a live data stream are going to be fundamentally different. Also the circular dep that Sashko mentioned makes sense.
Disclaimer: I’m writing this without having written a single line of React.
This, from what I can tell, is merely an implementation limitation that you are talking about. Or we could frame it as a UX issue like: Meteor/React should be able to “just do the right thing” with this.state, i.e. differentiate itself what parts of the state come from the regular React side of things and what properties I have (in the previous autorun cycles) added on in my Meteor-related code, and so there should never be a circular dependency issue that prevents the ideal UX in the first place.
(EDIT: Implementation-wise it seems to me no trouble to remember what parts of state came/come from where and as such not pass “Meteor-side” parts (what is in this.data now) back into the function/method that is supposed to create them, not consume them.)
I might be missing something here, but wanted to share this, just in case I don’t. Because even without having any practical experience with React it’s clear that “excellent UX” and “keep deviations from well-known workflows as minimal as possible” (especially for “external” tools like React; and this basically also ties in with ideal dev UX) is a big part of what Meteor is all about and (most) anything that brings us closer to those ideals is a good thing.
I might be wrong but my impression is that state should be reserved for keeping track of the state of your UI while data is simply data. Not sure why you’d couple the two together? Then again, I’ve never done React outside of the basic tutorials.
I think that’s exactly what we are doing, by following the trends in future React development for the observe API, and popular packages like Parse. Also, AFAIK people who use Flux definitely don’t put their server-side data on this.state.
Call for community React related packages to put in guide
Hi everyone who has been posting in this thread! I want to compile a list of useful React+Meteor projects that have popped up since the initial release of these packages, and add them to the guide so that people don’t have to read all of the github issues to find this stuff.
I’m going to go through the conversations on GitHub looking for those projects, but if you have others that I should mention, let me know!