Reading the various Blaze vs React threads here, it seems like one of the most common concerns preventing people from switching to React is the way it mixes HTML and JS in the same file. This is bad from a separation of concerns point of view (if you care about such things), but more practically speaking also makes it a bit more risky for non-programmers (i.e. front-end designers) to modify your component code.
So I had this idea for a Meteor package to enable getting rid of this boilerplate, and making React components more compatible with designer/developer workflows. I’m not sure if it’s a good idea or not, so I would love some feedback from both the React and Blaze crowd. Here’s more details:
I added React to a two year old Rails project we have. Having stateless components was good for us, because we grabbed that data from our controllers, as opposed to using something like Ajax calls within the components themselves. We just passed in pure strings, numbers and arrays.
However, I believe that Meteor being reactive by default, it makes sense to use that reactivity and avoid having having a wrapping container in charge of getting the data unless you really understand why you’re adding a container.
I agree, having stateless components -does- make it easier for designers to create components in a vacuum! That’s a major win.
For our projects, we’re moving towards containers because it allows my brother to design components using raw data. Then I can just plug in the actual data, and there you go, all done. ReactMeteorData detects a change, and re-runs the render() down into my stateless component and presto.
To be honest I’ve just been following the best practices recommended by Mantra. I agree not every single app will require you to split components into smart/dumb sub-components, but overall I think it does make your app more flexible, and potentially even less dependant on React itself.
a) How are functional stateless components better than BlazeReact?
b) How can BlazeReact be improved using functional stateless components?
Not having side effects is a good thing. Yay! Stateless. No side effects. But compared to having a library that supports Spacebars syntax vs having a library that has no side effects, we’ll take the Spacebars syntax any day of the week. We deal with side-effects all the time, and know how to manage it. The Spacebars syntax however… represents tens of thousands of lines of codes and many dozens of packages and apps.
Well I feel like supporting Spacebars syntax is a whole other debate, and the React community as a whole seems pretty anti-template. I mean, there are existing React templating solutions out there but I don’t think they’ve been adopted by React leaders.
So this would be more of a way to meet people halfway and get some of the benefits of templates (separate files, easier syntax highlighting, minimal logic in components, etc.) without actually adding a templating language.
Regarding separation of concerns I like and use the idea of creating stateless React components that just handle the concerns of rendering data and notifying the app code about user interactions. Those react components are easy to test and can be better reused in other contexts.
@sacha like the idea, I had a similar thought. I personally prefer less boilerplate. I don’t always see the value of splitting up containers/components into separate files, but I think this could be a good solution for Mantra.
I feel like I must not be doing a great job of explaining my idea, as my proposal is specifically to use pure JSX, and not a templating language. I guess I shouldn’t have mentioned the word “templates” at all, but I wasn’t sure how else to describe it…