Redux-Store Best practice: как лучше в store разделять данные от состояния UI?

Question

[sapl]

Есть ли какие-то Best Practices как лучше организовывать Store в redux проектах?
Как именовать и как хранить в дереве флаги касаемо UI и сами данные?

Конкретно как разделять в сторе данные бизнеслогики от состояния интерфейса:
- показать/скрыть тот или иной компонент
- поменять вид компонента
- показать скрыть диалог,
- экраны в связке с роутингом
- и т.д.

как это хранить в сторе?

Answer 1

[alvvi]

Если это глобальные состояния, которые влияют на несколько компонентов сразу, можете хранить их например так

store: {
  ui: {
    sidebar:  true   
  }
  entitites: {
     //...
  }
}

если же это состояние компонента, типа

- показать/скрыть тот или иной компонент
- поменять вид компонента
- показать скрыть диалог,

лучше использовать нативный реактовский стейт.
А так в целом, структура Store зависит от приложения, строгих правил кроме рекомендаций типа "сущности лучше хранить в нормализованном виде", я лично не встречал.

Answer 2

[Максим]

Состояние интерфейса обычно хранится в state компонента.
- экраны в связке с роутингом (тут и состояние хранить обычно не нужно дополнительно, так как оно уже хранится в роуте (объект location))

Comments

[sapl]

Ну как же..
Мы же получаем информацию об обновлении ui через actions (которые обычно дергают API), а значит через redusers и store, т.е должны как то записать эти изменения в store.
- показать тот или иной диалог на действия пользователя (в том числе в результате ответа api)
- показать блок с ошибкой
- показать следующий блок ввода формы, после заполнения предыдущего
- и т.д

[Максим]

sapl, не все нужно прокидывать через actions. У Илья Ростопка хороший ответ, я с ним согласен (про глобальные состояние, которые влияют на несколько компонентов сразу, либо просто какой-то компонент "уведомлений", например, который как раз таки нужно прокинуть через reducer)

[Максим]

sapl, по вашему вопросу (не вижу всего, тем не менее)
- показать тот или иной диалог на действия пользователя (state), (в том числе в результате ответа api - reducer)
- показать блок с ошибкой (ошибка валидации формы, например? - state, серверная ошибка валидации формы - reducer), просто блок с ошибкой (типа уведомления - reducer)
- показать следующий блок ввода формы, после заполнения предыдущего (state, зачем тут reducer? только если у вас "следующий блок" как-то завязан на основе предыдущего + запрос на сервер)

Answer 3

[sapl]

Спасибо, за ответы Максим и Илья Ростопка
Думаю я плохо сам вопрос сформулировал.
Когда использовать state и когда store - более менее понятно.
Вопрос скорее по именованию полей и структуре самого дерева (даже если это все хранится в state - вопрос также актуален).

У меня проблема такая: сами компоненты при рендеринге изобилируют
во такими конструкциями:

{entityA!=null ? <EntityA name={entitiA.name}/>:null}

<Input error={error!=null?error.message:""}

{isDialogAOpen?<Dialog/>:null}

Это все приходит в props (redux) или как-то хранится в state.
Порядка не получается, разобраться потом проблематично.
Мне кажется не хватает каких-то гайдлайнов по именованию как props значений так и структур store/state. Вот я и хотел найти ссылочки на подобное

Comments

[Максим]

sapl предлагаю не сильно переживать, стиль выработается. Гайдлайнов особо нет. Мне из ваших примеров, не понравилось только:
<Input error={error!=null?error.message:""}
Можно же просто:

<Input error={error} // так как если пустая строка / null, то ошибка не должна быть отрисована в норм компоненте, проверка избыточна.

Мне, например, нравится стиль, когда я большие логические куски рендера, выношу, например:

...
          </div>
          { this._renderTable() }
          { this._renderModalWindow() }
          { this._renderPagination() }
          { this._renderBundleFooter() }
        </div>
      </BaseLayout>

и там уже внутри, например

_renderBundleFooter = () => {
    let template = null;

    if (какая_то_переменная_состояния) {
      template = (
        <MyComp пропсы... />
      )
    }

    return template;
  }

Если условие подходит под switch, то switch...

А кто-то любит писать (или если маленькое условие) сразу:
{isLoading && <Loading center />}