After some tries and plays with ReactiveVar and ReactiveDict and trying to have a global state between client and server without Session or Collections, I came up with some approach heavily inspired by Redux.
Yes, I thought that makes sense a reducer be a Meteor.method, so it can interact over the persistence layer.
I made a update just now to reduce de Meteor.call boilerplate and make de API looks even more like Redux.
@SkinnyGeek1010, one of the things that I’ve noticed is how the reducer always needs to return a copy of the entire state (not a mutated one, according to the docs). What if your state object is humongously complex, and you’re just modifying one teeny tiny part of the state, wouldn’t it be a bit inefficient to have to re-copy the state just to reflect that tiny state modification you’ve made?
Is there a way to break up the state without having to create another store?
And is there a more efficient way to update the app state, especially huge ones?
@leocavalcante so I have tried implementing this and I am getting stuck on whether I should use this pattern for logging in or signup. I don’t know what the initial state would be and how that would work. Do you have a better example besides a simple counter?
Hi guys, my final thoughts about Redux/Flux on Meteor after these studies was just… don’t use it! LOL.
I think Meteor already has its own way of architecture things using pub/sub and collections. I haven’t found a satisfiable solution of using Redux on Meteor yet, I’ll keep looking @SkinnyGeek1010 projects and meanwhile using what Meteor offers out-of-the-box.
I agree with @leocavalcante, using Flux within Meteor is kinda missing the point of why Flux was created. We already have the unidirectional flow with the subscriptions on Meteor. It is pointless to use Redux unless you REALLY want the time travel and action log. As much as I love Redux, it is a pretty high price to pay in complexity.
I played around with the Redux dev tools and honestly, it was nice getting it to work, but only played with it for like 2 minutes before I got bored with it . It is not that great. I have more fun using Mongol/Constellation.
There is one thing I took away from Redux and it’s the way they connect the data to the component. So I took that connect concept and made it so that you can connect Meteor data to a component and it seems to work quite well:
Essentially, ReactiveComponent is a function that takes a function as first parameter that returns Meteor reactive data, and the second argument is a React component you want to wrap. It returns a new component that is able to access the Meteor data using this.props instead of this.data.
Wat? lol. Time travel and seeing the state tree change over time is super nice. You can also make commits and reset instead of reloading the entire app when debugging (using it while debugging is much more useful).
If anyone wants to try it out (devtools) here’s a repo (redux branch)
I didn’t get a chance to play with the time-traveling, commit and reset features. I think I was annoyed that the action log was sorted in ascending order because it made me have to scroll down when a new action was logged, so I think I moved on lol.