I’ve been using Meteor daily now for a couple of weeks and I thoroughly love what the community has done.
I first learned about Meteor when I seen an example of how data changes in a Mongo collection updated in the UI with very little effort. That blew me away. The accounts features were the icing on the cake. Documentation is easy to read, and I was able to get up and running quickly.
As a React developer I didn’t quite understand how React fitted in. And then I learned about withTracker. I could now subscribe to record sets and pass that data down as props to container components.
Like seriously, this blew me backwards when I first did this with React.
I then tried to fit Redux into Meteor and I managed to do it in a very clean way.
To do this I got rid of withTracker and used Tracker.autorun which subscribes to methods and dispatches actions when the data changes. I use connect and mapStateToProps to pass data to components instead of withTracker.
It seems that a lot of people are migrating from Blaze to using React and I see a lot of questions on using Redux but any guides or tutorials are either dated, or of little help.
I would like to write a section on using React and Redux in the documentation if I may. Is this something that would be welcomed if I was to submit a pull request?
Thank you @fullstax for coming forward to enhance the documentation. For me, a section about Redux in Meteor would be helpful a lot!
Maybe it is better to open an issue instead of waiting for an answer on the forum for a healthier communication with MDG.
State management is very opinionated, I don’t think it’ll reach Meteor Guide, but it can reach Meteor Blog, so you should try there.
I personally think Redux is an absolute over-engineering for most web-apps. With routes, authentication, lists, forms, and few simple step flows, it makes things much harder to follow, hard to find your actions and reducers, I worked with Redux and Meteor I actually understand it in depth, worked with thunks, all sorts of middlewares, but ultimately you have to use the right tool for the right job, and in my opinion redux solves the problems for a small (very small) niche of apps, I prefer the original flux pattern used with MobX
It’s not just that state management is opinionated. It’s that the state management really defines different types of apps. It’s very much in the realm of the various cookbooks. It would be great to get some writeup and analysis of the pros/cons of different state management approaches.
Regardless, to the OP… write some text up, post it for consideration, and submit a pull request.
I also this Redux is over engineering. It solves for many-many components communication which was very rare for us, and when we needed it we used Meteor session/tracker with a wrapper.
Furthermore, React is moving toward having the component themselves fetch the data async they call it react suspense, we are currently doing this with Meteor methods and having the component owns the fetching of data.
Thus, I think it’s an opinionated approach that is for a subset of react apps and I’m not sure why it should be in the Meteor Guide, however a blog or tutorial would be good to have.
Redux is very simple. There’s nothing difficult about it, but people tend to struggle because it requires a change in thinking. I don’t see how it’s over engineering. Requires a fair bit of boilerplate is my only gripe. Following the data flow isn’t difficult either. Finding actions and reducers is easy if you use feature folders (actual actions themselves are in shared directory as they’re required in many parts of the app) …
I’ve hit a snag in the road that I hadn’t even considered until now. Duplication of data.
With the way I have it setup data is stored in both minimongo and the store. A subset of the minimingo data is duplicated in the state. It’s starting to feel a bit messy.
I apologies. Redux in Meteor is definitely over engineering when you have to start thinking about how to not end up with duplicate data and double the memory requirements.
