Мы падаем на них ради нашего же блага, но как долго?
Redux взял нас штурмом, когда вся дискуссия об архитектуре Flux была яркой. Я помню, что было много реализаций общей архитектуры с множеством отличительных характеристик, сильно различающихся как в интерпретации самой структуры, так и во мнении о том, насколько далеко должен быть досягаемость менеджера состояния. На какие вопросы эта абстракция должна ответить?
Предсказуемый менеджер состояний для приложений JavaScript
Потом получаем Redux. У него было несколько фундаментальных предпосылок, исходящих непосредственно из функционального программирования. У него была мертвая простая реализация, которую мог понять любой, наряду с мертвенно-простым API, который каждый мог понять с первого взгляда. Сам по себе он отвечал на очень немногие из открытых вопросов, но был достаточно гибким, чтобы сообщество могло ответить на недостающие вопросы самостоятельно.
Сразу же все другие реализации Flux показались запутанными и сложными. Чистота редуктора действительно сделала программное обеспечение более предсказуемым, особенно те проекты игрушек, путешествующих во времени, которые использовались для продажи, что концепция того стоила. Вскоре произошла интеграция с постоянно растущей библиотекой рендеринга React, и она отлично сочеталась с ее функциональной стороной, а также ответила на беспокойство по поводу того, что представление слишком много знает о чем-либо.
На тот момент все были Redux или, по крайней мере, фреймворк управления состоянием, вдохновленный Redux, созданный для вашей библиотеки рендеринга, отличной от React. Сообщество немедленно должно было ответить на эти вопросы, оставшиеся без ответа. Хотите что-нибудь сделать? Для этого есть промежуточное ПО. Не согласны с тем, как это делает промежуточное ПО? Для этого будет промежуточное программное обеспечение, для которого вы только что создали репозиторий и уже имеете девяносто звезд, чтобы похвастаться.
Но какой ценой?
Вот и мы сегодня, а о чем эта статья? В свободное время я изучаю Elm, а также читаю о GraphQL и Apollo. Я также работал с Redux над несколькими проектами и ежедневно использую его на своей обычной работе в нескольких проектах.
Заглянув вовнутрь, я вижу, что эти нерешительности оставили след на образе и реальности использования библиотеки, и, вероятно, именно поэтому мы отходим от нее, когда дело доходит до нее. Эта статья не о критике, а о том, чтобы указать на эти пробелы, как мы можем на них ответить и как мы должны ответить на них, как влияет на нашу жизнь и семью (хорошо, немного увлеклись этим).
Я думаю, что важно отметить, что это всего лишь мои мнения по этому поводу, и, как и все мои мнения по любому вопросу, я полностью ожидаю, что они ошибочны. Единственная переменная между моим согласием и несогласием с этими словами - это время. Убирая это с пути, давайте начнем.
Семантика действий расплывчата
В Redux действия - это полезные данные, отправляемые из вашего приложения в ваш магазин. Это единственный способ изменить состояние приложения и, следовательно, единственный способ обновить представление. Они представлены как примитивный объект со специальным свойством, указывающим, что это за действие.
Это звучит идеально, простая концепция с сильным подтекстом. Действие сообщает о чем-то Store, чтобы он мог соответствующим образом изменить свое состояние. Итак, если у вас есть два действия, которые сокращаются с похожими или перекрывающимися функциями, как сохранить ваш код сухим и извлечь аналогичную обработку, чтобы ее можно было совместно использовать?
Это очень распространенный вопрос, на который есть два принципиально разных ответа, которые в конечном итоге говорят о семантике ваших действий и о том, что вы понимаете под приложением. Вы могли подумать, что общие функции можно выделить в отдельное действие, или вы могли подумать, что отдельные функции можно выделить в служебную функцию.
Первый подход рассматривает действие как блок обработки, совпадающий с концепцией универсальной функции. Второй отделяет функцию от действия, которое представляет, приближая семантику действий к сообщениям.
Я видел оба подхода на практике и продолжаю видеть эту путаницу. Я считаю, что если вы рассматриваете действия как просто функции, у вас неправильное представление о семантике.
Я могу быть прав или неправ в этом, но, возможно, двойной интерпретации можно было бы избежать с помощью более строгого определения этой фундаментальной части предлагаемой абстракции, если что-либо уменьшит количество решений по ней, которые должен принять пользователь.
combReducers вводит в заблуждение
У вас есть вся концепция редуктора: может быть только один, и вся ваша логика входит в него (надеюсь). Неизбежно вы захотите разделить эту логику на множество небольших блоков, чтобы упростить тестирование и лучше организовать ваш проект. Если вы действительно прилежны, вы, вероятно, выберете утиный подход и используете прилагаемый служебный инструмент, который поставляется с redux, для объединения всех ваших редукторов.
Дело в том, что разбить логику на блоки не так просто. Одна из замечательных особенностей redux заключается в том, что редуктор - это просто функция, и вы можете делать все, что хотите, чтобы разделить ее логику. Вы можете обратиться к помощникам, к различным редукторам с доступом к любой части состояния, как вы ее называете.
Если вы действительно уверены, что какая-то часть логики полностью изолирована, вы можете полностью изолировать ее от остальной части испытаний, используя combReducers. Следует отметить, что это один из самых строгих возможных случаев. Это исключение, а не правило.
Если вы сойдете с ума, разделяя каждый бит имеющейся у вас логики и инкапсулируя каждую часть данных в редуктор, вы в конечном итоге задаетесь вопросом, как передавать редукторы. В конечном итоге вы переместите данные за пределы своего магазина, чтобы получить их через другой редуктор, и вы даже можете использовать некоторую глобальную выборку состояния, чтобы не платить за связь.
Конечно, речь идет о плохом моделировании, и опытным разработчикам удастся избежать всего этого, но открытый подход redux вместе с наиболее ограничительным помощником по умолчанию кажется мне немного вводящим в заблуждение, по крайней мере, для новичков. .
Чтение данных становится беспорядочным
Одно государство управляет всем приложением. Есть только одна правда, и это правда магазина. Эта концепция является центром редукции и одной из самых удивительных концепций, которые мы получили во фронтенд-разработке.
Дело в том, что у вас есть одна цель, и все. Даже для огромного приложения с множеством действий, редукторов, логики и любви вы получаете всего один объект. Это потрясающе, но в то же время довольно страшно. Объект имеет тенденцию становиться огромным, с различными ветвями и условиями, известными только из глубины редуктора.
Поэтому, когда вы, наконец, прочтете его и покажете на странице, вы должны быть осторожны. Что допускает значение NULL и когда? Можно ли установить эти две переменные одновременно? Где мне написать необходимую мне предварительную обработку этого массива перед отправкой его в представление? Должен ли вид делать это?
У Redux нет ответа. Это твоя логика, ты с этим справишься. Только не дублируйте бизнес-логику в представлении, чтобы отображать нужное всплывающее окно в нужное время. К счастью, эта проблема прекрасно решается некоторыми замечательными библиотеками, такими как reselect, которые добавляют к удивительным, а также к входному барьеру всего этого.
О побочных эффектах мы думаем позже
Функциональное программирование - это круто, но все мы знаем, что побочные эффекты буквально заставляют ваше приложение что-либо делать. Вам нужны побочные эффекты, но ваш редуктор не должен иметь побочных эффектов. Должен быть какой-то самоуверенный способ избежать побочных эффектов, не нарушая архитектуры, верно?
Сам по себе Redux на это не отвечает. Он не говорит, где побочный эффект круто, он просто говорит, где его нет. Итак, мы должны предположить, что везде все в порядке, не так ли? Итак, мы начинаем запускать запросы из обработчиков компонентов, как в старые времена, или, может быть, мы перемещаем их в создатель действий? Но тогда мне нужно, чтобы создание действия было асинхронным, как я могу это сделать?
Я думаю, что это может быть самый большой пробел в сокращении. Побочные эффекты - это то, что заставляет ваш стартап работать, и они вам нужны, но когда вы начинаете изучать redux, вас наводняют совершенно разные взгляды на то, как они вписываются в ваше приложение. Вы даже не знаете, нравится ли вам redux, и вам нужно выбирать от thunks до sagas, от cycles до loops.
Более того, преобразователи являются одним из самых популярных промежуточных программ с побочными эффектами, но они даже не пытаются смоделировать проблему. Они были закодированы как доказательство концепции промежуточного программного обеспечения побочного эффекта, но сообщество так отчаянно нуждалось в официальном решении, что мы быстро выбрали преобразователи, хотя это вообще не решение.
Интеграция маршрутизации… нет?
Если случайно вы изучаете redux для управления состоянием своего одностраничного приложения, скорее всего, вы собираетесь использовать что-то вроде react-router , чтобы позаботиться о маршрутизации на стороне клиента.
Библиотека на самом деле довольно хороша. Он аккуратный, и документация хороша. Наконец-то мы набрали темп в мире React / Redux, а? У вас есть единственный источник правды, поэтому вы полагаете, что состояние маршрута должно быть сохранено на нем.
Тогда вы видите, что вам не хочется делать это. Redux не предлагает официального решения по этому поводу, а маршрутизатор по умолчанию для React побуждает вас нарушить единую предпосылку истины. Вы сбиты с толку и решаете продолжить интеграцию только для того, чтобы понять, почему вас вообще обескуражили.
Конечно, интеграция маршрутизатора выходит за рамки проблемы redux, и было бы несправедливо возложить на него недостающий уровень интеграции. Тем не менее, маршрутизация является важной частью одностраничного приложения, и пользователи redux неизбежно будут разочарованы по этому поводу.
Может Redux плохой?
Выше у нас был небольшой сеанс разглагольствования и указаний, но теперь он закончился. Вы можете подумать, что если в redux не хватает всего этого, может быть, это плохой путь? Может быть, моя энергия должна быть куда-то более… зрелой и разумной?
Да, все выглядит немного сумасшедшим, но это не на redux. Сообщество JavaScript должно быть одним огромным гигантом страсти, и все, что его волнует, - это будущее. В мире нет другого сообщества программистов, которое было бы настолько готово и стремиться к изменениям, экспериментам, предварительной обработке, добавлению и объединению и, в конечном итоге, к выяснению того, что работает.
Redux не плох, на самом деле, это потрясающе. Потребовалось мужество, чтобы предложить смену парадигмы от того, к чему мы привыкли в государственном управлении. Тем более, чтобы не отвечать на вопросы, на которые еще не было ответа.
Одна вещь, которую мы можем извлечь из всех умерших реализаций Flux, заключается в том, что плохой ответ хуже, чем его отсутствие, по крайней мере, в этом сообществе. Мы хотим иметь возможность экспериментировать, исследовать и разгадывать вещи. Мы сделаем это через промежуточное ПО и через посредник, и даже через промежуточный усилитель более высокого порядка (патент заявлен), если это необходимо.
Redux заложил основу и использовал замечательное сообщество, чтобы построить то, что у нас есть сегодня.
Куда мы отправимся отсюда?
Конечно, на этот кликбайтный подзаголовок нет однозначного ответа. Я имею ввиду, кто ты?
Вы впервые изучаете redux и искали, того стоило оно того или нет? Это того стоит, присоединяйтесь и узнавайте что-то новое, внося свой вклад.
Вы ищете подтверждения своих сомнений по поводу того, что должна охватывать библиотека, а чего нет? Иди сюда, обними меня. Мы в этом вместе, и это ужасно круто, что это дает нам возможность думать самостоятельно.
Вы не согласны со всем, что я сказал, и не упустил ли я весь смысл JavaScript? Ты классный и, наверное, прав! Напишите мне сообщение, чтобы я тоже его увидел и у меня было чем заняться после работы.
Вы читаете это просто потому, что вы мой друг и ничего не понимаете, но все равно будете хлопать в ладоши? Эй, эта статья была длиннее, чем обычно, вам не нужно было ее изучать. Наша дружба крепкая, позаботьтесь прежде всего о себе. Хотя люблю тебя!
Вы Redux?
Если да, то прежде всего должен вас поблагодарить. Вы сломали мой повелительный разум и подсадили на функциональную мысль. Более того, вы дали мне возможность попрактиковаться, поговорить и узнать об иностранных концепциях и поделиться ими с моими друзьями, даже в обычное рабочее время.
Я абсолютно уверен, что эти пробелы и подводные камни позволяли и поощряли потрясающие эксперименты. Сколько людей на самом деле понимают и используют саги в своем интерфейсе, как будто это ничего, сколько людей узнали о мемоизации и о том, что такое чертов thunk. Это действительно потрясающе.
Но, возможно, Redux все еще слишком сырой. Может быть, то, что он поощрял в экспериментах, также затрудняет обучение. Может быть, микробиблиотеки делают так, что люди, которые не знают об их существовании, застревают в решенных проблемах. Возможно, это неправильное использование из-за расплывчатой абстракции затуманивает его имидж и прогресс, достигнутый во всех этих исследованиях.
Возможно, нам нужно сделать трудный выбор, чтобы расти еще дальше.
