I will soon be starting a rather large project and I spent the last few days looking through most of the Meteor/React related stuff.
As many of you know there are a ton of different architectural styles that can be used in combination with React and Meteor.
I worked through the Meteor + React 2.0 example from Ken Rogers which embraces Mantra.
I also looked at the 1.3 version of the Meteor Guide but it seems like the React sections still needs a bit of working on.
Mixins seem to be gone with 1.3 (unfortunately they are still used in the react tutorial which is the most official Meteor documentation besides the guide it seems…but its for 1.2 so makes sense i guess…)
I also looked at github discussion between Meteor devs, Mantra enthusiasts, redux, flux etc. which don’t seem to point in a particular direction…
I know that Meteor wants to give its devs as many choices as possible, but with the release of 1.3 will it be likely that they recommend a certain architecture style for react/meteor apps? Basically something to replace their mixins…it does not have to be as detailed as for example Mantra spec is.
Ya…It would be nice if Meteor would “endorse” certain architectures (and it could be more than one)…similar to what they did with React/Angular/Blaze official support.
For example, and this is purely meant as an example, MDG say follow the Mantra spec then people starting larger projects who have to make decisions about the structure of their app could state a path with more confidence because it is officially backed.
Right now its more like use containers (which is the react way these days anyways) and do whatever you want architecture wise.
I guess this goes back to “Too opinionated vs too much freedom”
If anyone starting a larger project (with Meteor 1.3 / React) could comment on their architecture that would be helpful.
Primarily how much confidence can you put into something like Mantra at this point, do you think meteor will ever endorse it or provide their own official alternative?
The React article in the Meteor 1.3 guide is just one small part! It’s specifically just about React integration. When it comes to architecture, you should look at some of the other articles (note that these are still drafts, and will be finalized soon):
I do think a specific guide for how to integrate architectural choices such as redux (probably the most popular choice with react currently) with Meteor are very appropriate to be included in the guide.
Sure redux does not have any ties to Meteor but I do not think that excludes it of being part of the Meteor guide.
Just saw this post
Seems to confirm that people really really want these kind of examples / documentation and if it were part of the official guide (even if it is treated as an addon) that’d be just a really valuable resource
I totally agree with that. It seems like some sort of state management tool is a must for more complex apps, and it seems like Redux is the one at the moment. Working out how, and particularly what, of Meteor to integrate with Redux is a bit of a head-scratcher though, some official guidance there would probably save a lot of people a lot of time.
The traffic stats on the simple CRM repo appear to confirm that:
I hope we can get Simple CRM to a standard where it can be good enough to be one of the main examples for Meteor/React/Redux. I tried to follow the Guide when writing it, but obviously there is no officially blessed approach for Redux as yet.
@sashko mentioned the need for thorough tests to be included in example apps on the most recent Transmission which I totally agree with, that’s next on the agenda for Simple CRM.
The Redux store does a lot of the same things as Minimongo so I tried an experiment which removes the use of Minimongo entirely. It works great if you don’t need optimistic UI. If you do need optimistic UI then it’s a terrible idea.
I think you want to give devs a patterns they can follow. Which does not mean it has to be the only one of course.
For example if you include a section in the guide detailing a React/Meteor/Redux architecture and maybe include a sample app that implements it (including tests) its easy for devs who want to follow the pattern.
Does everyone who uses Meter/React have to follow that pattern? Of course not.
Sample apps that are not really built out and do not have support from Meteor are just going to add to the endless array of options.
Out of interest @sashko what are your arguments against this?
While MVVM has the popular View Model package, Redux-style Meteor apps haven’t seen a clear winner emerge ( that I’m aware of ). But, that could also be due to React changing a lot, it might just be too soon.
I think the benefit is that Redux scales up well and there are lots of examples out there. So if people adopt that architecture, then their apps should be more manageable and maintainable as they grow and when they hit questions they have the wider JS community to refer to, not just the Guide. I might have misunderstood the question though.
Edit: agree with @looshi, maybe it’s too soon. It does feel like Flux (i.e. action, payload, etc) is the new MVW though.