I’ve been reading up and thinking about architecture for the latter part of the week. And as I was just writing something:
export function addPerson(person) {
Meteor.call('people.addPerson', person, (error, result) => {
});
return {
type: ADD_PERSON,
person
}
}
…a question hit me: why would I want to maintain Redux state about a list of people, when I have that exact same list in Mongo? I can see Redux being useful for maintaining state for other things, like if an info pane is expanded or not—more impermanent conditions. Redux would also be useful if you wanted to build a list of things but not have it actually save until you hit the “save” button (then you just grab the current state, dump it into a DB).
But for the usual use case in Meteor, where you want real-time data, I’m not seeing the value anymore. I had a misconception earlier that Flux/Redux architecture provided the advantage of dispatching actions from anywhere in your component tree, but I was wrong (as you’re supposed to have a single container that passes props to its children).
It’s very likely my brain is just fried from staring at code and reading docs for the past several days. Maybe someone could get me back on track.
Yeah, that’s what I’ve been thinking as I’m sitting here writing this code! So I’m wondering why Meteor devs use Redux, then. Unless they’re just using it for the reasons I mentioned above.
honestly speaking I couldn’t identify why we are using all this fluxy tech and started a thread like yours
a lot of good pints came up. Some saying they don’t see a point, other saying though it is very similar to meteor, it just helps them think unidirectionally.
My take on this is, the redux way works good for node apps, but for meteor, its just adding complexity. Same goes for a lot of other tech thats emerging. I think meteor has already partly achieved what these techs are trying to achieve and they are just different take on solving similar problems. A lot of overlap thats what we have in our hands
Yep. Redux seems great for an app that doesn’t have client-side state. I’m all for breaking things down into testable units, and keeping code clean and easy to debug, but I’m also for simplicity. I don’t want to add something under the hood unless it really brings a lot to the table. And I don’t see Redux doing that in the context of Meteor.
With redux your data walks in one way only. With minimongo you don’t have that. That’s the goodness of Flux: if your app is huge, you can identify problems very easily, just follow the path.
Redux also offers undoable actions, but that’s not a big thing if you don’t need it.
Maybe someone could get me back on track.