Я работал над своим первым проектом с Redux последние несколько недель. Интерфейс администратора для управления и создания анкет о сборе данных о пациентах.

При написании небольшого приложения все кажется простым и понятным, если приложение начинает расти и добавляются новые функции, возникают препятствия. У меня было ощущение, что я пишу один и тот же код снова и снова. В основном для операций CRUD.

Первая проблема заключалась в денормализации всего состояния (использование библиотеки normalizr поощряется документами redux, я не знал об этом, когда начинал, и делал это вручную) таким образом, чтобы разбить его на небольшие части. , каждая с редуктором. Это упрощает обработку состояния, но ручная обработка отношений через идентификаторы усложняет редукторы, особенно при удалении записей.

Во время разработки мне пришлось как минимум трижды реорганизовать структуру, чтобы она соответствовала новым требуемым функциям. Рефакторинг был тяжелой работой с redux, поскольку каждое действие и редукторы (и связанные тесты) должны быть переписаны вручную, чтобы адаптировать изменения. Я не нашел ничего, что могло бы автоматизировать эти задачи, и мне очень не хватало некоего фреймворка.

Еще одна вещь, которая меня расстраивает, - это необходимость создавать разные действия для каждого изменения атрибута состояния. Чтобы решить эту проблему, я, наконец, написал более общие действия, которые могут служить для разных атрибутов.

Разработка через тестирование с использованием redux меня приятно удивила. Это полезно и значительно ускоряет процесс разработки.

Демо

Резюме моих плюсов и минусов

Плюсы

  • Разработка через тестирование упрощается благодаря чистым функциям и повышает продуктивность разработки.
  • К редуктору подключен только корневой компонент (я называю его контейнером), все действия и состояние передаются через props. Это упрощает использование компонентной композиции и запись компонентов без состояния.
  • Линейность кода, все просто и не сильно отличается от проекта к проекту.
  • Неизменяемость: принуждение к сохранению неизменяемого состояния во многом помогает избежать странных ошибок.
  • Промежуточное ПО Log в режиме разработки, показывающее все различные состояния до и после отправки действия, очень помогает.

Минусы

  • Сложно поддерживать отношения, и нет официальной библиотеки с документацией и поддержкой, которая могла бы помочь вам в этом.
  • Избыточный код, каждое действие пишется вручную, даже самое обычное, например, изменение атрибута состояния.
  • Нормализация сложного состояния с множеством уровней вложенных объектов не всегда кажется лучшим подходом.

Мои лучшие практики

  • Структура каталогов по модулям, а не по области видимости. Пример:

foo /

… .Actions.js

… .Reducer.js

… .Tests __ /

… .Constants.js

бар/

… .Actions.js

… .Reducer.js

… .__ тесты __ /

… .Constants.js

  • Разделите логику между сервером и клиентом. Моя ошибка заключалась в том, чтобы реализовать всю логику на стороне клиента. Лучшим подходом могло бы быть получение нового состояния с сервера, когда это необходимо, и обработка отношений состояний на уровне базы данных.
  • TDD на редукторах, тесты на редукторах не только ускоряют разработку, но и содержат информацию о возможных «тихих» ошибках в состоянии.
  • Делайте компоненты простыми и используйте компонентный состав.
  • Нормализовать состояние с помощью библиотеки Reselect

Управление сложными отношениями с магазинами (# 386)

Записка Дэна Абрамова

Удаление всегда сложно, потому что не существует первоклассного понятия схемы. Мы не знаем, какие части состояния на самом деле являются ссылками на идентификаторы и нуждаются в обновлении.

Я вижу три решения:

Для объектов, которые удаляются редко, перезагрузите страницу. Не так уж плохо, если это случается редко (например, выбор чего-то вроде группы в Facebook или публикации в блоге, ведущей к обновлению, - это нормально, IMO, вы не делаете это каждый день).

Для объектов, которые могут часто удаляться, вы можете рассмотреть поле статуса. Например, удаление может установить isDeleted на модели. Таким образом, он все еще там, но пользовательский интерфейс должен отфильтровать удаленные элементы.

Вы можете сделать схему первоклассной концепцией, точно так же, как это первый класс в normalizr. Если у вас есть схема, вы можете написать фабрику редукторов, которая создает редукторы, придерживающиеся этой схемы. Эти редукторы будут знать, когда удалять идентификаторы из полей внешнего ключа, потому что они знают, как выглядит схема.

Зависимости я учту в будущих проектах

Redux-форма

Идеально подходит для управления состоянием сложной формы

Redux-orm

Небольшая, простая и неизменяемая ORM для управления реляционными данными в вашем магазине Redux.

Было бы здорово, если бы операции CRUD управлялись с помощью объявления модели без необходимости писать действия вручную.

Redux UI

Хорошее решение для отделения состояния пользовательского интерфейса от состояния приложения.

Нормализр

Библиотека, предложенная в официальной документации redux для нормализации состояния приложения.

Основные зависимости для этого проекта

  • Реагировать
  • Redux
  • React router v2
  • Redux Thunk
  • React DnD
  • Выбрать повторно
  • Стилизованные компоненты
  • React Bootstrap
  • Bootstrap Материальный Дизайн
  • Шутка

Вывод

Redux - хорошее решение для работы со сложным интерфейсом, он очень похож на архитектуру потока, но если мне придется переписывать приложение, я бы сделал это по-другому.

Я бы избегал указывать всю логику на клиенте, перемещая часть на стороне сервера.

Хороший подход, который я видел в некоторых проектах, - это отправка действий на сервер и уведомление всех подключенных клиентов о внесенных изменениях при подключении через веб-сокеты.

Таким образом, клиент отвечает только за денормализацию и нормализацию состояния, полученного сервером, обработку состояния пользовательского интерфейса и представление данных.

На стороне сервера намного проще обрабатывать отношения с ORM, предоставляемым веб-фреймворком.

Этот проект очень помог мне понять все предостережения, которые Redux может сделать для приложения среднего размера. Когда я только начинал, я не думал о том, что потребуется столько работы, так как большинство примеров redux, доступных в Интернете, относятся к простым спискам задач и чат-приложению, где состояние и логика минимальны.

Ссылки на документацию