React with meteor was painful for me. It’s been so bad I’ve abandoned meteor 3 months into a startup project in favor react/node front end a rails api backend. I’m currently rebuilding the whole thing while already having a client wanting to start adding his users to it… That’s how bad meteor and react was for me.
At first it was ok, after some minor hiccups it was working. Then I ran into a lot of trouble trying to use react community packages. A vast majority of the react community assumes we are using webpack/browserify to bundle our project. I haven’t found a good solution to this in Meteor. So I can’t use non-meteor community packages like react drag-n-drop, etc. Ok, that sucks but I could live with that.
But it gets much deeper than that the further I went along. Eventually I found they are actually at odds with each other conceptually.
We have react which promotes self contained isolated immutable little functions that represent the UI at any given time. It is optimized for ease of understanding what the code is doing when you have to add a feature 2 months in the future. A component only knows about itself and what props it was handed. That’s it, that is all there really is to react. A parent component gets some data and populates child components passing in data that they need. Those children have no knowledge of the parent or anything else in the system. I love this. Using a build tool like webpack further enforces this, I can only use the files I explicitly require.
Blaze is the opposite, purposely optimized for speed at development time. Every template can call any other template instance and do stuff to it. Working with an external API like stripe is just ugly. Session variables (ReactiveVar is better but still has issues) to check if a user interaction is active… Helpers in separate files that create really tight coupling between logic and the display of UI. So much of it is in direct conflict with react at the core, and I personally like the react concepts more. I really don’t want to start flames here, just stating my personal opinion from building out a SaaS project first in rails, then in meteor, then in react. If you love blaze and feel the need to correct me, please move along.
But ok, let’s try abandoning blaze completely and use just 1 template with react. First, we’ll need to replace the routes, there’s react-router. Awesome router concept btw, nested layouts of visual components is brilliant (thanks ember). But how do you use react-router? var Router = require('react-router'); When I try to include it all the files and dependences it relies on break. Bummer.
Looks like there might be some progress on getting this to work, but not there yet. Well, ok, we can use the meteor router and just render react components inside empty blaze templates. Works decently, and there’s some pretty cool features like startMeteorSubscriptions to reactively render collections, awesome.
Now getting pretty deep into nested child templates that passing along data is getting out of hand, and if I change one I have to change the whole tree of child components. So what’s this Flux stuff about? Actions, dispatcher, and stores make sure I can only have one source of logic (stores) and one source of manipulating the state of the app (actions). That sounds like it could solve some of my complexity problems. How do I use it? var Dispatcher = require('flux').Dispatcher; Uhhhhgggg…
So, that’s what it was like for me to use React with Meteor. Believe me, I would LOOOOVE to have this figured out. I really enjoyed Meteor, but have a distaste for Blaze (any template engine really, like handlebars, rails mvc, etc) when compared to isolated components. I would be so happy to use Meteor for my server api and webpack with react for my frontend, all on one deployed server.
I could imagine the Meteor server files acting like Flux stores and the client folder holding the components and actions would be a brilliant way to work. Helps enforce security since I can never manipualte state from the front end, I can only create actions and the server updates the collections and creates new actions to dispatch the results, and in some cases wouldn’t even need to, the collection would just reactively update in the view, react diffing efficiently blowing away the old content with the new data.
The closest thing I could find was Asteroid, but in my initial tests I was unable to get it to work on two separate deployed servers, likely due to some CORS stuff. I didn’t investigate too far since I realized that if I am running two servers and separating the client and server, I might as well just use a rails API that I am familiar with, or even Firebase would do almost everything a separated Meteor api could.
