0

We're using React and Flux (via the Alt implementation).

The state is maintained on the stores and is passed to the view components as props, which is nice for data.

I found myself, however, maintaining state such as isOnHover and similar UI states in the store as well, which seems cumbersome (creating action and store handlers for each UI state).

Is maintaining UI state directly on the component itself considered a bad practice, and if so, why?

Thanks.

Shahar
  • 478
  • 5
  • 17
  • 1
    There is a rule I try to follow these days (not exclusively, but in general it works fine): it's only data comes to the store that can be rendered on server. – zerkms Oct 07 '15 at 05:06
  • @zerkms which means you use view componets' state to maintain other data such as UI state? – Shahar Oct 07 '15 at 05:07
  • 1
    Yep. Something like "isOnHover" would belong to the component state as per my classification. – zerkms Oct 07 '15 at 05:08
  • I find it useful to have an app.store for app state that impacts more than one component. I also use it for app.config data. – J. Mark Stevens Oct 07 '15 at 20:55

1 Answers1

1

Maintaining anything other than the data which the store provides in the respective store is bad practice in my opinion. One store for each piece of data. A components state should stay in the component.

Setting values like isOnHover should be stored and updated in the component, and initially set using getInitialState.

It's good to think of things like this in terms of using components across projects, you want to be able to essentially plug and play with minimal of fuss and code tangle for each component part.

AndyD
  • 875
  • 7
  • 18
  • "Maintaining anything other than the data which the store provides in the respective store is bad practice " --- "Setting values like isOnHover should be stored and updated in the component, and initially set using getInitialState." --- these 2 statements are controversial. You either store them in a store or in a component state. – zerkms Oct 07 '15 at 10:19