That’s a great idea. I think the packages we are offering would let someone build another package that uses react-templates to compile templates and then integrate with Meteor by creating a build plugin. So I encourage you to try making your own build plugin for this!
If a lot of people ask for it, we might also make a more supported version.
Hello everyone,
I made a simple react template for loading blaze template but i don’t know what implication it can produce.
Here is my code:
/**
* params: template - name of template, data - context for template
*/
RcBlaze = React.createClass({
render: function() {
return <div />;
},
componentDidMount: function(){
var node = this.getDOMNode();
var tempName = this.props.template;
var data = this.props.data || {};
if(!tempName || !Template[tempName]){
console.error("Missing template name or template doesn't exists!", tempName);
return;
}
this.setState({_blazeView: Blaze.renderWithData(Template[tempName], data, node)});
},
componentWillUnmount: function(){
if(this.state._blazeView){
Blaze.remove(this.state._blazeView);
this.setState({_blazeView: undefined});
}
}
});
Great work guys…Thumbs up
ok. So I am new to Meteor and new to React and just had the time to go through the tutorials and docs using my Ubuntu instance. Did I say I am trying to also ween myself off the MS teet? Well, I gotta say this is sweet. Meteor and React. Sweet. Buy man do I feel old. Heck, I am old.
A big part of what got me interested in Meteor was it’s amazing templating system. It was the first one to ever really click with me immediatel. Ember, Angular, Backbone, none of these ever felt right. But Meteor did almost instantly.
Seeing this React support come through is kind of off putting. A year ago Famous was all over social media as the next big thing - the right way to do UI - no more bugs - etc. Where is it today? Not even a cliffnote on a wiki page.
My question is: Will we have to use React? Will Spacebars be deprecated? How much time will be invested by the core team into React support?
That’s awesome that spacebars clicked with you. Why does that mean that Meteor should only support one templating system? Did you see that Meteor is adding Angular support, along with React?
At the end of the day, Meteor boils down to the command line tools, isomorphic packages and DDP. The rest of the technology stack will always have a hint of flavour-of-the-month about it, whether that’s Spacebars, Famo.us, React, Angular etc.
No. Meteor is a platform, you can choose which packages and templating engines to use.
No official word from MDG, some people have different opinions about it. Let's talk about deprecating spacebars
I think you’re asking the wrong question. You should be asking - How many more people will React bring to the Meteor ecosystem?
With proper support for React - Meteor can now reach a broader audience. An audience that will be contributing new packages, updates to core packages, and supporting MDG by buying Galaxy/ Developer Subscriptions.
So, if the MDG & the Meteor Community continue to thrive - we can continue benefiting from the excellent open source software they’ve released.
Oh - and as for famo.us - they just re-wrote their engine to fix a bunch of performance issues (which stopped their initial adoption). Check it out.
large apps it has bitten me several times. I didn’t fully realize this until after using React and contrasting the two
Sure. To preface, these things can be fixed by mimicking React best practices in Blaze. However it’s not the default path/setup that most people use.
The typical Blaze template setup and execution flow is also hard to reason when you have child and parent templates calling each other, router data contexts, and jQuery plugins changing the DOM from beneath you. Add in a few more devs, a couple hundred templates, and lots of state that needs to be maintained and it gets hairy quickly.
I don’t want to flood this thread with off topic posts but feel free to PM me for more detail. This Quora post explains it well in general terms.
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?
Yes, read the documentation for ‘cosmos:browserify’
@sashko Am I missing something or is there not really an easy way to import CSS from a React Package?
Random (and possibly silly) question:
Why is Meteor data accessed thru this.data instead of this.state? Just curious.
Gerard
Hi guys! I have a preview of the new official React and Meteor tutorial here: Request for feedback about new official React tutorial
Please check it out and leave comments!
This is covered partially in the guide: http://react-in-meteor.readthedocs.org/en/latest/meteor-data/#design-notes
did you get past this? I’m getting the same problem
This is currently a known bug: https://github.com/meteor/react-packages/issues/39
We are working on fixing it ASAP.
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:
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.
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:
https://github.com/petehunt/minimongo-cache#working-with-react
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.
Facebook Parse also uses this.data, FWIW.
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.