Очень распространенным требованием при написании одностраничных приложений является выполнение асинхронного HTTP-запроса к какому-либо API. Возможно, вы захотите получить некоторые данные с сервера. Или вы можете захотеть выполнить какое-то действие на сервере (например, RPC).
В любом случае это асинхронное действие. И если вы только начинаете с Redux и / или интерфейсной разработки, вы гуглите, как другие разработчики в Интернете делают эти асинхронные вещи. И вы сталкиваетесь с redux-observable, redux-saga, redux-thunk или какой-нибудь другой библиотекой «побочных эффектов» для Redux.
Redux-observable использует реактивное программирование, redux-saga использует генераторы. Оба являются чрезвычайно интересными и полезными концепциями. Но нужно ли вам изучить что-либо из этого, чтобы выполнить этот запрос API?
Одним словом, нет.
Чтобы пояснить свою точку зрения, давайте кратко рассмотрим самую суть того, для чего мы используем Redux.
Мне нравится Redux, потому что он позволяет мне абстрагироваться от визуального пользовательского интерфейса и позволяет мне представлять состояние моего приложения в простом (JavaScript) объекте. Тогда пользовательский интерфейс по большей части является просто визуальной проекцией этого объекта. Это так просто.
Итак, нужно выполнить асинхронный запрос? Сначала задайте себе этот вопрос: Влияет ли запрос вообще на глобальное состояние приложения?
- Нет, это не так. Это вполне допустимый вариант использования. Забудьте о Redux и просто вызовите его axios (или HTTP-клиент по вашему выбору).
- Да. Тогда почему бы просто не обновить состояние самостоятельно? Одна отправка до запроса и одна отправка после запроса.
Любой, у кого есть хотя бы базовые знания Javascript и Redux, поймет, как работает приведенный выше код. Не приглашайте посредника к вам, пока не убедитесь, что он принесет вам больше, чем стоит.
Еще одна прелесть этого подхода «JavaScript 101» в том, что вы получаете обратно Promise (или Observable, если хотите)! Вы когда-нибудь хотели показать вращающееся колесо после нажатия кнопки без ломающего голову цикла через диспетчер, редуктор, селектор, соединение и реквизиты? Что ж, теперь вы можете! :)
Кстати, если вы более опытный пользователь Redux, вы можете заметить, что это совсем не отличается от redux-thunk. Основное отличие - внедрение зависимостей. Redux-thunk внедряет для вас dispatch и getState, но, поскольку вы все равно должны сначала передать действие в dispatch, это почти не спасает вас. нажатия клавиш. С другой стороны, это делает вещи немного менее прозрачными и даже изменяет подпись метода dispatch для возврата обещания (попробуйте объяснить это TypeScript).
Заворачивать
Моя личная борьба с этими библиотеками побочных эффектов заключалась в том, что они добавляли много сложности к чему-то, что само по себе вовсе не обязательно должно быть сложным.
Я не понимал, что то, что делает Redux действительно ценным для меня, - это не условности или «использование современных веб-технологий». Это факт, что я могу рассуждать о приложении без нагрузки на пользовательский интерфейс. И что я могу легко писать тесты, которые не должны полагаться на какие-то сумасшедшие фреймворки.
Итак, в конце дня, моя конечная цель состоит в том, чтобы иметь возможность обновлять состояние, когда мне нужно, до любого состояния, которое мне нужно. Если сторонняя библиотека может мне в этом помочь, отлично! Если нет, то зачем это нужно?
Вам решать, подойдет ли вам эта модель. Но пока это для меня.
