Take the case of reseting a password. The user is presented with a form asking them to enter their email. They submit the form so that they'll be sent a reset link in an email. The submit triggers an action, the action makes a POST to /api/password/reset
and will return success or failure.
Obviously i want to update the UI so the user knows what is going on. The Flux way is to have actions dispatch a constant e.g. PASSWORD_RESET_SUCCESS
and stores listen to the dispatcher so they can change the state. Components listen to the stores so they change the UI when the store state changes.
In the case of the password reset, i can't really see a sensible way to have this run through a store (and it seems verbose to do so). The only changing of state seems to be directly related to that form/component. Nothing that needs to be preserved once the user has left that page.
- Is it "flux-y" to have components listen directly to the dispatcher?
- Is there a sensible design for a store that allows me to handle generic events like this that don't directly link to models in the app?
Many thanks!
(This relates to working on https://github.com/mwillmott/techbikers in case anyone is interested)
Flux architecture obviously can seem too strict and complex for the simple app — and it is. But it was not designed for simple apps in mind, it was designed for the complicated UI with lots of components — as complicated as the get. That's why stores, actions and components need to be separated from themselves as much as possible.
If you think that your application is quite simple, you can always take shortcuts, like passing a changeState callback directly to the action as a param — but if some other component will need to react to the PASSWORD_RESET_SUCCESS event, you've got yourself a problem. You can always think about it when it happens though. The project architecture is always about trade-offs, flexibility vs development speed vs performance.
The most important skill of developer is to know about this trade-offs, their value and know where to make them — and where not.
Good luck!