Зеркальное отображение частей редукционного состояния в локальной базе данных - PullRequest
Новая
       5

Зеркальное отображение частей редукционного состояния в локальной базе данных

0 голосов
/ 26 января 2020

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

Какой шаблон лучше всего соответствует этим требованиям?

A - Создайте два редукционных действия, одно для простого обновления локального состояния приложения (например, AddItem), а второе с использованием thunk (например, CreateItem), отвечающего за обновление состояния приложения до загрузки, асинхронный доступ к базе данных, отправка AddItem и повторное переключение состояния загрузки

B - Для каждой операции CRUD обновляйте только локальное состояние и зеркалирование его в базу данных всякий раз, когда жизненный цикл приложения заканчивается.

Я знаю, что вариант B подразумевает множество возможных проблем, но вариант A выглядит не очень хорошо для меня, поскольку он предполагает концептуальное дублирование некоторые действия. Какой вариант лучше? Есть ли другой подход, который я не рассматриваю?

Так заранее

1 Ответ

1 голос
/ 26 января 2020

Мне нравится использовать 3 действия: ACTION_NAME {REQUEST / RESPONSE / ERROR} (хороший пример: https://redux.js.org/advanced/async-actions). Итак, ваш базовый c поток:

выполнить thunk -> запрос отправлен (изменить локальное состояние на загрузку) -> вызвать BE API -> api Finishes -> refre sh локальное хранилище в зависимости от успеха или ошибка. Вы можете написать создатель пользовательских действий или промежуточное программное обеспечение, которое будет автоматически отправлять действия REQUEST / RESPONSE / ERROR при вызове API BE (это отличный пример: https://blog.logrocket.com/data-fetching-in-redux-apps-a-100-correct-approach-4d26e21750fc/).

Большая проблема с решением B, если у вас есть более 1 пользователя. Поскольку изменения сохраняются только в конце приложения, пользователь A не увидит никаких изменений пользователя B, пока пользователь B не выйдет из системы. Если это не проблема, тогда для сохранения состояния я рекомендую что-то вроде: https://github.com/rt2zz/redux-persist.

Надеюсь, это поможет.

...