We'd like to unify our Router on both client and server and do away with the dispatcher.
When we started this project there wasn't a clear winner in the Flux Framework race, but the community and its underlying tech have matured to the point where we might want to reconsider. The benefits of going with a maintained framework are many -- including documentation and lack of a need to decide on a ton of standards.
In this case we need to ask what this will look like. Danny's been thinking about this a lot, and I've got a stale PR with a new Router system in place. The main subquestions then would be:
- What would our router look like?
- a functional Express style router (like mine)?
- or a more declarative one (like react-router)?
- How should we be declaring data dependencies?
- in the router?
- in the component files (using something like Relay or Connect)?
- and how do we maintain the ability to 404 on certain missing data?
- What are the advantages/disadvantages to the dispatcher?
- Redux recommends that you dont have your action creators call the dispatcher, but I'm not totally sure what the advantage to that is.
We decided to stick with our own framework with the following action items:
- Declare data dependencies in top level components and have these components take care of most of the logic that gets lumped in the router/server files.
- If we do this, the form our actual router takes doesn't matter. It will be very thin.
- Dependencies will be actions (not one-off requests).
- All actions will take a store or context and call directly into the store's main dispatch/reduce method.