Redux: conventions / recommendations for UI state?

Created on 21 Aug 2015  路  12Comments  路  Source: reduxjs/redux

From: http://rackt.github.io/redux/docs/basics/Reducers.html#designing-the-state-shape

You鈥檒l often find that you need to store some data, as well as some UI state, in the state tree. This is fine, but try to keep the data separate from the UI state.

I've just started with Redux, I've done some React and Polymer, and I've spent a fair bit of time with Angular. So for my benefit, it would be great to be specific about why this separation is a good idea. Reasons I can think of:

  • if you're going to serialise state to the server, it's handy to be able to omit UI state
  • reducers / actions that operate purely on non-UI state can be used (and tested) isomorphically in both the browser and Node.js
  • different UIs (e.g. browser vs native vs Node.js CLI) can share the same non-UI behaviour

Am I completely off-base here? Are there more compelling reasons to follow the documented suggestion?

I was toying with the idea of just nesting all UI state beneath a top-level "ui" property:

{
  ui: { /* ... */ },
  /* ... */
}

How are other people separating UI state from other state? Property prefixes, e.g. "ui..." ? Visual property order, e.g. UI state properties first, other state properties last (or vice versa) ?

discussion question

Most helpful comment

@gaearon Know you're busy, but could you give a quick explanation of how you typically handle UI concerns (especially with list items), or point to a resource on it? Thanks!

All 12 comments

Oh, interesting topic to discuss.

I want persist UI in state too. It's very handy, we can save entire state to LS and in next app launch rehydrate it, so, for example, modal windows will be opened too, not just data in modal windows.

But how we can make it? Just change this.setState() in each component to this.props.actions.ui.setState()? Little bit weird. Wrote middleware or store enhancer? I don't know but I definitely want to store UI in one state.

I opted for having a really naive separation a la:

const myState = Immutable.Map({
  ui: Immutable.Map({
    selectedItems: Immutable.Set(),
    searchText: ''
  }),
  data: Immutable.Map({
    events: Immutable.List()
  })
});

Since my application is very small it works out good so far. It is purely frontend though, at the moment.

@ojung
Why not keep it simple with:

const myState = Immutable.fromJS({
  ui: {
    selectedItems: [],
    searchText: ''
  },
  data: {
    events: []
  }
};

Ah, sure. My example was purely artificial. But now that you mention it I actuall found a spot where I could use Immutable.fromJS. Just not too sure if I not actually prefer it explicit. Immutable.fromJS will propably make the selectedItems: [] a List by default.

Closing, as Redux has no opinion on this: you're free to structure your state any way that makes sense for your app, just like you're free to implement any server API you like.

@gaearon Know you're busy, but could you give a quick explanation of how you typically handle UI concerns (especially with list items), or point to a resource on it? Thanks!

My 2 cents: almost always, UI states are either derived from data states or mutated by events, so you can either computed it on-the-fly from data, or if it's some temporary state (like reaction to an event) just store it in the plain ol' react component's this.state, why not? since you're losing it any way.

I am also in the same dilemma with splitting the UI and Data states. Thanks to Mark Erikson for helping me out. I like how he structured his store based on his tutorial series specifically:

const rootReducer = combineReducers({
entities : entitiesReducer,
unitInfo : unitInfoReducer,
tabs : tabReducer,
});

Wherein the tabs would basically be UI state while the Data will be on entities and unitInfo. I would probably be nesting all the UI states under another top-level slice like ui too as per @jokeyrhyme example but if there isn't much UI state to keep track of then going Mark's example would be good enough for my use case.

redux-ui offers also an interesting and easy to use approach:
https://github.com/tonyhb/redux-ui

There is something I don't like of redux-ui it hasn't been maintained for almost a year and is currently failing its own tests. (https://circleci.com/gh/tonyhb/redux-ui).

Does someone knows an alternative ?

hello , i am new to redux and i like it too much , i just have a question about the UI state of the component :
- can we manipulate the UI state of a component locally without dispatching actions , for example i have a login component and when the user submit the form i fire an action tsend an api to the server using redux-thunk middle ware , and i want to pop up a spinner , can i do it locally .... sorry for my bad English

@chenineazeddine : Yes, you can absolutely use local component state in a Redux app. See http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state .

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cloudfroster picture cloudfroster  路  3Comments

vraa picture vraa  路  3Comments

benoneal picture benoneal  路  3Comments

amorphius picture amorphius  路  3Comments

ilearnio picture ilearnio  路  3Comments