3

Flux documentation states that state should be stored in Stores. Should then the loading, saving, error messages related a entity be stored in Stores. Since View is going to get its initial State from Store hence only way to know whether its loading/saving comes from a Store.

Also when editing a form user decides to cancel editing hence these intermediate form values should be stored in Views states rather then sent to Store?

pra
  • 343
  • 1
  • 3
  • 16

2 Answers2

2

I use React in a very functional way, as all my data is stored outside of React as a global JSON object, and that data is injected to a top-level component. Thus React is just a clever templating engine for me: a transformation of JSON to Virtual DOM, and then application of Virtual DOM to the real DOM. Rendering always trigger from the main component and is optimized thanks to immutability. Read more here

I don't agree with Rygu, the errors are part of the state. Stores may be comparable to databases, but what does that mean? That stores should only contain something that is not "temporary" or something that may be considered as meaningless?

For me, if you want to embrace functional programming with React, anything that is displayed as DOM should rather be in the first place passed as props of your components, including errors. If you don't, then you rely on side effects to manage the DOM, and it will be harder to reason about all these side effects over time.

Community
  • 1
  • 1
Sebastien Lorber
  • 89,644
  • 67
  • 288
  • 419
  • atom-react and react-cursor are similar? I would like more documentation/examples on how to use atom-react. – pra Sep 25 '14 at 10:28
  • I didn't know react-cursors before. Yes it is very similar except that react-cursors seems highly coupled to React and it seems to put the whole app state inside the root component state, while atom-react has a decoupled atom/cursor implementation. Atom-React is the glue that permits to wire the atom state to the React rendering pipeline + an event bus + an opiniated way to manage state. I'll write documentation and exemples soon but we are currently in a startup rush :) – Sebastien Lorber Sep 25 '14 at 13:06
  • I like your idea. Will look forward for more documentation. – pra Sep 25 '14 at 14:02
0

Your input fields should have their own memory. That means that Store state (source of truth) is immutably decoupled from any changes that happen in components. Through actions, those changes are communicated to the Stores. Whether they become the new truth or fail with errors, the Store state will again be immutably copied to the component input state. Errors, I would also move to the component as they apply to the input state, not the Stored state.

Stores are like databases, you rarely put any temporary records or errors there either. Unless you're writing a text editor where input history is tracked...

  • 1
    But the errors/loading need to be stored in Store correct since the View listens on Store updates. Is there any other way for the action error result to communicate back to View? – pra Sep 20 '14 at 12:29
  • Does your Store have the ability to trigger with additional parameters? Reflux.js has that ability, so no storage of errors is required, they're just passed along when triggering. –  Sep 21 '14 at 10:47
  • I am using the default flux implementation. Emitting a different event for errors is workable. I would then need to ensure the error belongs to a particular component. – pra Sep 22 '14 at 06:50
  • If your models support errors, then you won't have to worry about which components get which errors. The *models* get errors. Basically I would do it like that. –  Sep 22 '14 at 07:18
  • Model is a json object. So i would be just adding a errors attribute. Thanks for the help. I would be going that way unless i encounter any issue later. – pra Sep 22 '14 at 07:30