I come from a Meteor/blaze background so I’m very familiar with using reactiveVar/reactiveDict and the Session objects to maintain reactivity for components that need to re-render on changes.
I’m writing a new React app with Meteor and want to get your opinions on the pro’s/con’s of continuing to use reactive variables vs using redux to manage state and reactive re-rendering.
I’d say that I’m equally familiar with both paradigms, so my main concerns are:
Performance / overhead. Some of the variables will be updated every second or even 2-10 times/sec. So if one takes significantly less client CPU that would be preferable.
Specific limitations of one or the other that I should be aware of in terms of using them to make components automatically re-render when data changes.
Anything else I should know from people who’ve done this before
Note, I’m planning on using Meteor’s pub/sub to get any rapidly changing data from the server (along with methods and regular API CRUD calls for static data), and also probably tying some data to local collections defined in minimongo (which IMHO is much easier than using redux as a data store). So the question is mainly about using one or the other to enable reactive updates of various components in the UI. I do have a slight bias toward using redux only because that’s something every React developer is already familiar with, while most would require some time to get familiar with Tracker.autorun and reactive variables. But if reactiveVar is a better solution for other reasons, that’s fine.
When I was looking at this quite some time ago, the options I had were
A. Redux (or other state management package)
B. Meteor Sessions
C. React Context + Portal
We decided to go with C for simplicity but we ended up not using portals. Whenever we need a reactive result that is not in the current dom tree, we ended up using Meteor Sessions (because it is so simple to use)
The only thing I hate about Meteor Session is its “global” nature. I’m recently thinking of adding a namespace in Meteor Session to remedy this.
I’m using state and it’s super fast and lightweight. Couple of lines you good to go. I didn’t notice any overhead with using state - actually the opposite - it’s so darn fast I have to throttle it client side from updating state in places or it’d be just too fast and create a high load from to many updates from user input whilst typing for instance. I just learned about debouncing in underscore so that’s what I’m planning to do for that now.
Never got into redux, already was using mongo and redux just seemed like a janky fb afterthought. React is king though. Love it
If I am not wrong, if you use a lot of pub/sub within Redux you get a duplication of your data “tree” as you replicate Minimongo into Redux. I don’t know what is your use case but look at this comparison: for a wall with feeds, say you get 5 feeds in a page and add 5 & skip 5 for the next page. In Minimongo with subs you always have 5 cards, in Redux (with methods) you can keep adding cards while you skip 5 every time and get the next batch of 5 while the browser memory eats all that data. When you back-page or scroll up, all your cards are already in Redux. With Redux it would be “normal” to have hundreds of objects (with 0 impact to your server).
You can indeed subscribe to things like user online, new message but as is the case with any Meteor app, reactivity can be disguised using logic in the UI + methods.
Redux is amazing when you have a lot of data dependencies from nth child to a parent component or in async dependencies (e.g. wait for the file to upload and then close “that” window from another component.
I feel Redux + Minimongo is not a good play. For pub/subs I’d use the React data containers. Another option is to use Redux for app states (e.g side bars, modal windows) and containers for Mongo data but I would not run Minimongo data over Redux (no Tracker.autorun in Redux Action)
If you are debating between reactive vars and redux, there’s an alternative you might want to consider: simpler state:
This is a fairly new project. We were using Redux, switched to Simpler State, and got rid of a lot of code and unnecessary complexity in the process. For our use cases, Simpler State worked much better:
Having said that: do not duplicate domain state (like from pub/sub, graphql, rest, or whatever) into local state libraries, but use dedicated tools for that:
meteor pub/sub → minimongo (you can the useTracker hook)
For me redux is a good exemple of over-engineering. At the end it works, but i will crash your productivity.
If your application is simple, you can get away with react state (=> hooks).
I like Mobx which has been inspired by Meteor reactivity system.
