Sure. I like flux because of its unidirectional data flow. Here I think flux is is too much for meteor.
-
we need most of the apps to be router specific. We build web apps which has more activities in the router. It’s a good idea if we can create a route for every case. Chat is a different example. So, router tends to be a good dispatcher.
-
Stores. We have minimongo and reactive queries. That’s a better place for stores.
-
I got confused with their action implementation. May be guys at fb may like to write more codes. It just a single event to me.
What they basically build an even emitter pattern with some more stuff to It which is specific to how fb architect their apps.
They later release another UI architecture, I don’t remember the name. So, it’s like they just throw out different stuff. But should not use all of them. But I like react.
Okay, then what’s the issue with meteor. If we designed a router based app normally, that’s tend to be with unidirectional data flow.
But with IR we re-run stuff in the router layer, with or without our concern. We need to stop that. We did it with flow-router.
In meteor stores get updated automatically. Then the UI also gets updated using reactive queries. Yes, now we don’t have a better control over that. But I couldn’t find a patter which works best for us.
Other things is template is meteor and there is no place to maintain the app state and the logic. We solves this using flow-components. It enforces single direction data flow and prevent talking to parent components.