У меня есть приложение, которое использует «поток перенаправления» Oauth2 для аутентификации пользователей, то есть пользователи перенаправляются на другой веб-сайт для входа в систему, а затем перенаправляются обратно на мой сайт.
Документация и другие источники, похоже, утверждают, что бизнес-логика должна идти либо в создателях действий, либо в редукторе. Однако у меня есть функция login()
, которая никоим образом не меняет состояние, она сохраняет текущее состояние приложения как простой объект в localStorage, а затем перенаправляет пользователя на сервер авторизации. Когда пользователь вошел в систему и был перенаправлен обратно, состояние восстанавливается (другим фрагментом кода) и передается в качестве начального состояния моей функции создателя магазина.
Мой вопрос: логика функции login
просто извлекает состояние, но никоим образом не меняет его, поэтому оно не принадлежит редуктору. Он также не возвращает действие, которое является определением создателя действия. Где в структуре моего приложения я должен его разместить?
"Нормально" иметь создателя действия, который на самом деле не создает действие? Я делаю это прямо сейчас с помощью redux-thunk (потому что мне нужно getState()
), и он работает без каких-либо проблем, но это кажется неправильным, потому что на самом деле это не «создатель действий», с другой стороны, у меня также есть logout()
функция, которая действительно возвращает действие, поэтому кажется, что они должны жить в одном месте. Я предполагаю, что это своего рода угловой случай, но не совсем потому, что я могу придумать множество причин, чтобы сохранить состояние таким образом и перенаправить посетителей на другие сайты (или даже просто сохранить состояние без перенаправления).
PS. Я знаю, что есть библиотеки для автоматической синхронизации моего хранилища redux с localStorage, но вопрос не в этом.
РЕДАКТИРОВАТЬ: Некоторые пояснения:
Из документации Redux, где разместить бизнес-логику: Нет однозначного ответа на вопрос, какие именно элементы логики должны входить в редюсер или создатель действий.
Читая дальше, становится ясно, что есть только два места, куда я должен поместить бизнес-логику: либо в редьюсере, либо в создателе действий. Теперь, поскольку то, что я хочу сделать, не влияет на состояние, а редуктор по определению влияет на состояние, я склоняюсь к тому, чтобы поместить эту логику в создатель действий.
Документация по создателям действий: Создатели действий - это именно те функции, которые создают действия. Термины «действие» и «создатель действия» легко объединить, поэтому постарайтесь использовать правильный термин. [...] В Redux создатели действий просто возвращают действие
Документация по действиям: Действия - это простые объекты JavaScript.
Псевдокод для моего примера входа в систему:
function login() {
// retrieving and serializing the state, then:
localStorage.set('my_app_id_state', my_serialized_state);
window.location = url_to_authorization_service;
}
Очевидно, этому коду нет места в создателе действия, потому что я не возвращаю действие, что является целью создателя действия. Однако мне все еще нужно получить состояние, поэтому я тоже не могу сделать его полностью независимым.
Итак, опять же, вопрос в том, где мне поместить этот фрагмент кода в структуру моего приложения?
Опять же, код работает, и все в порядке, так что я думаю, это скорее академический вопрос, но меня очень беспокоит то, что я здесь явно нарушаю основные правила Redux. Может это просто исключение?