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.
Yes I have looked at that but I feel it is still very little information. Basically just says to use containers instead of mixinsā¦ I feel itās still way too open
Take a look at the react branch of the todo example on Meteorās GitHub. Not a perfect implementation of the guide, but should get you most of the way there!
If you are talking about āfuture proofā and ātrendā, yes, for now containers are the way to go, mixins will not be supported by React in the near future.
However, the guide is an attempt to document best practices and community conventions, so we hope that the majority of the Meteor community will benefit from adopting the practices documented here.
So, I think itās better to follow itās instructions when possible. Youāll probably have to search stuff outside of it as well, keep posting questions and suggestions so it can be improved.
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):
Oh, and BTW about Redux - if we think Redux is a good idea for React, I think it would be good for Blaze and Angular as well. I donāt think it should be a React-specific thing.
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?
@sashko By āRedux patternsā I mean UI communication via events with payloads. In Redux the term is āActionā. The pattern is loosely described in Mantra state management section https://kadirahq.github.io/mantra/#sec-State-Management which is great, but itās not obvious how to actually implement it.
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.
Minimongo and Redux definitely bring their own advantages to the table. For data, Iām using 100% Mongo/Minimongo. For my projects, Redux is solely in charge of:
UI state
Form states
Maintaining state for sets of actions that are committable (e.g. with a āapplyā or āsaveā button, which then saves to MongoDB)
Not sure about a whole redux, but at least, putting all actions(db calls, sessions, etc) in one action folder with index, as it does redux, seems as a really good pattern.
