3

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)

Michael Willmott
  • 529
  • 1
  • 8
  • 21

1 Answers1

0
  • No, it isn't. The architecture of the Flux should always follow the same scenario — Component calls actionCreator, ActionCreator dispatches actions to the stores, store emits change to all subscribed components. That is how Flux works, explained here.
  • I think the best way to do it is to have the general ResultStore, which simply accepts key/value defined in the action and writes them to hash. This way you can get away with one handler, with the name onResultWrite or something like this. Flux Stores were never meant to be a direct representation of your models — they are more a representation of your whole app state.

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!

opportunato
  • 417
  • 4
  • 14