Preview of official React support

react
21

@arunoda one way to get around this is to create a container component that just handles data fetching and passes the data into a single child. This child can then use shouldComponentUpdate and others as the child component has it’s data in props. It also ends up making the FeedList more re-usable too.

I have an example of a FeedData and FeedList that uses this. However in this case I haven’t been able to really use === to prevent re-renders (looking into this though, perhaps putting in an ImmutableJS dictionary?)


Checkout this issue on React SSR. Basic React SSR works but once you add in data fetching it gets complicated.

22

So what are the main reasons you guys want to use react? Personally, I love the simplicity and lightweight nature of the blaze templating system, after coming from angular I found it to be hugely simplified.

I haven’t spent enough time with react to know what it’s advantages are, but I’m curious what the main advantages of using it with meteor would be.

4 Likes
23

Any details on what this means for Blaze? I know awhile back there was talk of a Blaze 2.0, and now with official react support, I’m just plain curious. Will Meteor be officially supporting 2 entire front ends or is there a sunset in the future?

4 Likes
24

I like this example here, but I feel as if it doesn’t address my concern. In order to use what you have here, there is somewhat of a learning curve in getting it all to play nicely together.

Now, Im not trying to say I am not willing to go after that learning curve, but if I was ever to try and introduce Meteor + React into a team setting (say at a startup), I would be shot down in favor of something more streamlined.

Obviously this is just a preview, so I still have hopes going forward. But in order for React to be “Officially Supported” in my mind, it would have to be treated as a first class citizen like Blaze is and be just as easy to work with.

1 Like
25

I don’t want to sound like a broken record but for me:

React has a very elegant way of dealing with state and sharing that state with other components. Ideally the state will be stored in one single point and is then passed down to children components.

If you step back and look at this, the component is like a pure function. It takes in params (props) and returns a value (HTML string) based on the values of the params. This makes it very easy to debug, since a component can only change based on those params passed in.

React components (ideally) don’t create side effects (unlike many jQuery plugins).

Because of this one way data flow and thinking of components as pure functions, it makes React really easy to use once you’re used to it. way easier than Angular in my experience.

Blaze is great for small apps but the typical Meteor app doesn’t have any way to manage state and in large apps it has bitten me several times. I didn’t fully realize this until after using React and contrasting the two.


I agree that this example is not the most ideal for a React 101. It was more less something to test out non-trivial data subscriptions. Also it’s not using 100% React (some Blaze) which may change soon.
What would you suggest change in order to make it play nicely together?

There’s some PRs in progress that will allow you to remove Blaze all together and send down a static HTML page that React-Router could mount to. This should help with that.

1 Like
26

Would you be so kind an share your experience?

27

What makes it harder to work with than Blaze?

28

In Blaze, it’s really easy to attach a route to a Blaze template I.e. (This is using Iron Router)

Router.route("/", {
  name: "dashboard",
  action: function() {
    return this.render("home");
  }
});

This obviously just references the home template.

At least from what I found, this type of simplicity of getting a React template rendered is not as simple.

1 Like
29

Thanks.
I got it.

But I am looking for why we can’t just use states? If we simply use states that makes things pretty simple. I’ve a implementation in mind with our experiments with Flow Components. May be I should wrap it to a package.

30

Hey guys! Thanks for all of the feedback so far, keep it coming. We released this thing at such an early stage so that we could collect feedback continuously while working on it. I’m going to try to summarize some of the issues that have come up so far, and move discussion for them off of the thread:

  1. @nightstrike789 expressed a desire for a simple way to get a React component rendered on the page with a router. I’m going to write up a short guide for this, discuss on the following GitHub issue: https://github.com/meteor/react-packages/issues/29
  2. @gabrielhpugliese mentioned having an easy way to remove Blaze entirely from an app. I’m working on that in a PR, please discuss further here: https://github.com/meteor/react-packages/issues/30
  3. @gevalia and @tdhz77 noticed that stuff doesn’t work on Windows. I’ll investigate further, let’s discuss here: https://github.com/meteor/react-packages/issues/31
  4. @buduguru asked about server-side rendering. Please discuss here: https://github.com/meteor/react-packages/issues/15
  5. @SkinnyGeek1010 and @arunoda have been discussing data loading; there is a thread for that here: https://github.com/meteor/react-packages/issues/19

Hopefully I have covered all of the main issues - please put any further discussion on the above GitHub threads, and I’ll close them there when they are resolved.

If you have more new thoughts, please keep bringing them up in this thread!

Very exciting stuff.
Sashko

1 Like
31

One big thing missing on ReactJS imho is the clear separation of the HTML template and the JS logic on a class.

I’ve seen some people agreeing with this “problem” at the Proposal for Blaze 2 discussion.

Would you guys consider having something like http://wix.github.io/react-templates/ on the building tool?

Something like this would make it much easier for people to migrate from Blaze to ReactJS.

1 Like
32

@gabrielengel. Watch a few talks by Pete Hunt about react to get a better idea of it’s philosophy of separation of concerns. They want the HTML and JS together to keep everything about a single concern in one component’s code. Also, another thing he touts about React is it is specifically built to work within your current framework, and it can also contain your favorite framework. This made it easy to transitionto react at facebook. I haven’t attempted to put Blaze into React, but I bet it can be done. I suppose this would be handy for rendering a packages pre made templates.

33

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.

2 Likes
34

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});
        }
    }
});
4 Likes
36

Great work guys…Thumbs up

37

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.

3 Likes
38

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?

4 Likes
39

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.

1 Like
40

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.

41

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.

3 Likes