Cloning the content of the subscribed collections means 2x memory usage ?

[yched]

The reducer in the redux example clones the entire content of the tracked minimongo collections into the store. That seems like a sad memory hog, wondering if there's any other way ?

[AdamBrodzinski]

@yched yep that's one of the downsides. For most collections though won't be an issue. The alternative is to not use minimongo for that collection but that has big drawbacks.

The main reason to use it would be to de-couple from Meteor at the cost of some memory usage. On mobile this would be an issue. On desktop, most likely worth it. For example in this app you could switch over to Phoenix, Rails, etc.. with two lines of code (the collection dispatch).

You can still use the mixin of course and leave redux for local transient state and use the mixin for db state.

[yched]

Thanks for the answer, makes sense.

I continued playing with your approach (and with https://www.npmjs.com/package/meteoredux, which takes a similar approach, but automates the handling of the "collection changed" actions).

I guess the main drawback I see, other than memory duplication, is that when you use Meteor methods rather than direct Mongo writes on the client, you have to leak knowledge of which Meteor action affects which collection into the client code, which kind of hinders the abstraction of Meteor methods.

As you said, there's always the possibility to handle collections out of the redux store with the "official" mixin, and keep the store for local UI state and such.