Many people are interested to the Meteor + React combo for many reasons, but currently I see many options to build the “initial puzzle”, so I start this thread to hear your opinion.
Some “moving parts” come from Meteor some other come from React, however it would be more difficult to share a generic high level component (e.g meteor-react-account-ui) if we use completly different “bricks”.
NOTE: I didn’t mention all the possible combination of the ingredients you can use to cook your Meteor + React soup. So feel free to add yours
ES2015 import/export modules
WHY: to control the load order of your js files in your app
The upcoming Meteor 1.2 will support ES2015 by default via Babel but not the modules.
Don’t forget timbrandin:sideburns. It’s maybe the best integration of React and Meteor with Blaze so far. For anybody who has an existing Blaze application that they want to refactor towards React, Sideburns is going to potentially allow them to add React without rewriting all their templates.
rocket:module is becoming super stable. The only problem is Meteor’s build servers always time out before they can successfully publish rocket:module. I’m using rocket:module in a real project to bring React into Meteor instead of using MDG’s react package (for now at least) and MDG’s react-meteor-data to use the mixin to make components reactive. The example app will show how to use rocket:module to bring React into the app, but it’s not quite ready. Check back on the example app soon.
Hmmm, sideburns is neat! Maybe I can help refactor sideburns to use rocket:module to pull in the React dependency so it works with NPM packages that depend on React from NPM.
Also worth mentioning, if one likes having JSX in the same file, you can still add-in/refactor React in a Blaze project (doing that now actually, as we change/update that section of the code).
sideburns is great though! I think it’s an awesome thing to use if you like the markup separated out.
It’s less of an issue of ‘like’ the markup being separated out, as opposed to ‘have to because the client says so’ or ‘burdened with an existing code base’ or ‘thats just the way the app(s) are currently written’. It’s really much more an issue of backwards compatibility and refactor/upgrade paths than personal preferences.
Sideburns is the React integration that is 100% painless from the Blaze perspective; is backwards-compatible with Blaze, and can forward-migrate basically any existing Blaze applications into a React application. It lets people who want to do pure React stuff do their pure React stuff; and it lets Blaze folks migrate towards React as they’re able. There’s almost no down side to it.
No, it’s the other way around. You change the extension of your HTML template from foo.html to foo.html.jsx, and instead of compiling the HTML to Blaze, it compiles it to React instead.
It takes this:
<template name="Page">
<div class="page">
Hello world
</div>
</template>
```
And turns it into this:
```js
Page = React.createClass({
render: function() {
return (<div className="page">
Hello world
</div>);
}
});
```
So, if you've written an application in Blaze already with Spacebar HTML templates; it allows you to migrate to React without having to rewrite all of your templates. You can write new stuff in whatever React patterns you want; and migrate the old stuff as you have time.
As far as backwards compatibility goes and upgrading existing apps; this is what existing Blaze users will consider a seamless integration, an effortless upgrade, and a backwards-compatible architecture. If the React community is serious about getting the existing Blaze community to buy into this new-fangled React approach and migrate apps; this is the way to do it.
(The only thing I'm not 100% crazy about is the branding. ``Sideburns`` is okay; but it wound be nice to go back to a space or fire theme. ``Inferno``, maybe? But it's better than `jsx-templating`, so whatevs.)
I haven’t planned for building bidirectional support, it might be a direction we could go if people want to go the other direction. But I think it’s harder going from react to blaze.
The current version I’m working on will support handlebars/spacebars flavor in React yes, and I’m working on removing the requirement of changing filenames.
Basically I think it should be seamless for Blaze developers to test out their stuff in either React or Angular2 and be allowed to mix and match with Blaze if that feels right.
My personal end goal is to be able to use all the brilliant packages for Blaze with React or Angular2. And also I’m learning both as I’m working on the package.
