Using redux for data doesn’t make much sense to me as that overlaps too much with minimongo. However using it just for ephemeral state + action dispatch seems like a nice separation of concerns.
If any data is coming through a subscription then I wouldn’t touch that with redux.
I wrote a blog post series here:
That goes over how we use redux at workpop inc.
I was just about to post a link to this - we’ve just been working through it, it’s an excellent set of posts, thank you for taking the time to write it.
@yinghao , that seems like a good structure to me. For the sake of discussion and learning I made this example that uses DDP directly instead of minimongo and tracker.
It’s really easy to update the store from the incoming DDP messages. I think this is still very ‘meteoric’, even though it may sidestep some of the meteor front-end features.
We had some discussion about it here :
https://forums.meteor.com/t/redux-ddp-no-minimongo/?source_topic_id=15649
Great article, thanks for posting this. Is workpop fully transferred to React now? I saw the job posting for recat /full stack front end guy. You guys are doing awesome stuff there. I’m working on building my skillsets to working for a company like yours someday 
It ends right when it gets to actions 
- Is that where you draw the line? Make the mutations through actions otherwise the rootReducer will pick up the dispatch message? So for mutations you dispatch a function, and for UI state you dispatch a TYPE?
Do you guys use one file for all actions or actions per a module?
edit: nvm there’s more (blog post 3 doesn’t link to the next one fyi)
Whoa! What!?! WOW!
I really wanted to do that, and it was my original aim-- what about optimistic methods through Meteor.call()?
We’re headed in that direction!
Hahah my bad. Anything that effects domain state is dispatched as a mutation. Anything client side is done via reducers
@yinghao optimistic method calls are hard. I implemented a fairly “low budget” way to do it in the example app. @mattkrick made this : https://github.com/mattkrick/redux-optimistic-ui .
Will redux still be relevant now that the mdg are transitioning to a Relay / graphQLbased approach? From my understanding relay provides a client side single state atom as per redux and minimongo. People are already asking this same question to Dan Abramov here:
https://github.com/rackt/redux/issues/775
See @sashko’s response to lai, where he confirms mdg’s plan to use Relay
https://forums.meteor.com/t/reactive-graphql/17048/53?u=dcworldwide&source_topic_id=15649I’d love to hear people’s advice on this matter for those of us who are transitioning to React, but have not yet adopted Redux. Should we skip Redux and wait for the graphQL package to land?
I guess people were starting to put their server-side state in Redux, but that doesn’t make sense to me. I think state that comes from the server should be separate from client-side state, so it makes sense to use Minimongo + Redux like in the Workpop blog posts, or, analogously, Meteor Data + Redux.
Of course, in this case Redux only solves a small problem, so it might not be that necessary. But that’s up to you to decide.
Thanks Sashko. This is the conclusion I’ve been leading towards over the last few weeks of reading.
Bingo! Client State is specific to each client. Data client cache is not specific to each client (i.e., is a cache of some shared data). Don’t mix, please.
What do you mean with client state? If you want to save app state so a user can switch between devices for example, I don’t see a difference between that or the list of blog posts. Client state could be only small things like if the user is scrolling, or changing the UI, like with dragging things and you don’t want to save that (user is dragging Z and is at position XY).
Not related to Meteor, I used to store client state in localStorage, nice for syncing between tabs etc. but it’s limited if you switch browsers or devices. So (to me anyway) I think there’s not a big difference between site/app data and client state/data.
What am I missing? Of course this could depend on the kind of website/app you’re making.
Yeah client side for redux, and meteor data for collections.
The thing that does seem appealing about redux is just for the dispatch system. That way the views are only sending messages and not handling any logic other than dispatches regardless of client side or server side state.
exactly you got it right.
When you setup your redux reducers do you have it per a module, or is it all centralized in one location?
per module.
As our app is refactoring to Redux, we actually have a couple stores for the short term. We have a huge app, so every “piece” is essentially an independent system.
I’m a bit confused by this. I thought that Redux action functions normally returned an action object that would then be passed to dispatch(). I understand that the CollectionActions.viewChanged function will get called reactively whenever the collection changes, but where is dispatch() called? Inside the action function?