Каждый раз, когда приложение React ведет себя некорректно, первый твит — это вариант «React — отстой». Нет, это не так (ладно, кого я шучу, может быть, немного), но что действительно ломается, так это ваша ментальная модель состояния.
Разработчики продолжают тянуться к новым библиотекам управления состоянием так же, как люди с похмелья тянутся к жирной пище: надеясь, что это исправит то, что, по сути, было причинено им самим. Zustand, Jotai, Recoil, Valtio — все они отличные инструменты.
Но ни один из них не сможет спасти вас от хаоса, если вы не понимаете, как данные перемещаются через ваше приложение. React не ваш козел отпущения: главный виновник здесь — ваша государственная архитектура.
Пристрастие к блестящим решениям для управления состоянием
Экосистема React порождает новые библиотеки управления состоянием и работает быстрее, чем npm может предупредить вас об уязвимостях. Каждые несколько месяцев на X появляется новый, обещающий простоту, производительность и конец шаблонному подходу. Разработчики спешат установить его, убежденные, что на этот раз они нашли то самое. Медовый месяц длится до первого конфликта при сверлении винта или ошибки синхронизации. Затем снова приходится обвинять React.
Но эти библиотеки не решают основную проблему: неясный поток данных. Разработчики накладывают глобальные хранилища, контексты и перехватчики, даже не задаваясь вопросом, почему данные находятся там, где они есть. Они прикрепляют логику к фреймворку вместо того, чтобы проектировать архитектуру. Когда все обновляет все остальное, вы создаете минное поле, а не пользовательский интерфейс.
Вы не сможете создать ясность, передав мышление новейшей библиотеке.
Что React дает вам, так это возможность компоновки. От того, что вы с ним делаете, зависит, будет ли ваше приложение выглядеть элегантным или хрупким. Вы не сможете создать ясность, передав мышление новейшей библиотеке. Вы делаете это, понимая однонаправленный поток данных — основной принцип React — и придерживаясь его.
Понимание перегрузки контекста и пирамиды поставщиков
Если ваше дерево компонентов выглядит как внутренняя часть матрешки, вы не одиноки. «Пирамида поставщиков», в которой половина вашего приложения находится в перекрывающихся контекстах, — это новый ад обратного вызова. Все гонятся за удобством глобального государства, но контекст не является панацеей. Это скальпель: мощный при точном использовании и губительный при чрезмерном применении.
Разработчики часто оборачивают все в контекст, потому что это похоже на нирвану общего состояния. Но каждый провайдер вносит сложности. Отладка вложенных контекстов становится археологической раскопкой с помощью вызовов useContext. Производительность страдает, поскольку повторные рендеринги проходят каскадно по иерархии.
Правда в том, что большинство данных не обязательно должны быть глобальными.
И нет, переход на Зустанд волшебным образом это не исправит. Вы все еще синхронизируете состояние с неправильной степенью детализации. Не говоря уже о том, что если вы используете экземпляры, то безопасность контейнера — это еще одна вещь, о которой вам следует беспокоиться и относиться к ней серьезно. Можно с уверенностью сказать, что это не самая легкая суматоха, в которой я оказался.
Правда в том, что большинство данных не обязательно должны быть глобальными. Корзина для покупок? Конечно. Тематические предпочтения? Может быть. Но это состояние «выбранная в данный момент вкладка» или «временный фильтр»? Держите это локально. В тот момент, когда вы все глобализируете, вы теряете контроль над своей ментальной моделью. React поощряет локальное мышление — соблюдайте эту границу.
Почему Redux не был тем злодеем, о котором вы думали
Redux стал боксерской грушей усталости от React; но, оглядываясь назад, это был не злодей. Это просто сделало вашу архитектуру честной. Redux заставил разработчиков задуматься о потоке данных, семантике действий и неизменности. Эта дисциплина была болезненной, но она выявила, где на самом деле живет логика. Настоящая проблема заключалась не в Redux; именно так команды злоупотребляли этим.
Многие использовали Redux как свалку для каждой переменной — от аутентификации до открытия модального окна. Результатом стала глобальная миска спагетти с действиями и редукторами, которые никто не понимал. Затем пришла волна аналитических статей «Redux слишком сложен», в которых удобно игнорировать тот факт, что сложность возникает из-за того, что Redux рассматривается как база данных, а не как координационный уровень.
Современные инструменты абстрагируют шаблонность, но не устраняют необходимости в умственной дисциплине.
Современные инструменты абстрагируют шаблонность, но не устраняют необходимости в умственной дисциплине. Независимо от того, используете ли вы Zustand, MobX или React Query, применяется один и тот же принцип: состояние принадлежит там, где оно наиболее значимо. Глобальное состояние должно быть исключением, а не значением по умолчанию. Вам не нужно меньше библиотек; вам нужно меньше оправданий.
Мираж простоты в React Hooks
Хуки React должны были упрощать вещи. Вместо этого они стали новым прибежищем для архитектурных грехов. Пользовательские крючки отлично подходят для абстракции, но когда вы начинаете вкладывать их, как матрешек, вы создаете невидимую связь. Каждое использование скрывает зависимости и проблемы синхронизации, которые проявляются только в производстве — когда ваше дерево компонентов начинает действовать как одержимое.
Самое привлекательное в крючках то, что их можно составить. Но композиция без дисциплины — это просто хаос слоев. Ментальные затраты на понимание того, откуда происходят изменения состояния, быстро умножаются. В итоге вы получаете дюжину хуков, которые разделяют состояние немного по-разному — каждый повторный рендеринг запускает другие, как домино.
Простота заключается не в меньшем количестве строк кода; речь идет о предсказуемости. Чем меньше мысленных прыжков между причиной и следствием, тем разумнее будет ваше приложение. Прежде чем писать еще одно useGlobalStore, спросите, действительно ли ваш хук должен существовать. В большинстве случаев вы можете решить эту проблему с помощью реквизита и четкой иерархии.
Как масштабировать приложение React, не теряя рассудка
Каждый проект React начинается с чистого листа. Затем наступает реальность: больше функций, больше компонентов, больше разработчиков. Внезапно штат потек, как нерегулируемая река. Именно тогда команды паникуют и приносят новую библиотеку. Но масштабирование — это не инструменты, а шаблоны.
Совместите состояние с компонентами, которые его используют. Передавайте данные намеренно, а не рефлекторно. Используйте производное состояние вместо дублирования источников истины. Разделяйте поставщиков контекста по домену, а не по удобству. Эти принципы не модны; они вне времени. Вы можете масштабировать приложение React, не превращая его в лабиринт зависимостей, если относитесь к архитектуре как к живой системе, а не как к лоскутному одеялу.
Даже в масштабе большая часть хаоса в React возникает из-за пренебрежения фундаментальными принципами.
Даже в масштабе большая часть хаоса в React возникает из-за пренебрежения фундаментальными принципами. Не стремитесь к сложности, когда достаточно ясности. Фреймворки развиваются, синтаксис меняется, но законы чистой архитектуры никогда не выходят из моды. React не требует совершенства — просто последовательность.
Проблема не в фреймворке, а в вашей архитектуре
Обвинять React в головных болях с состоянием — это все равно, что обвинять свою машину в плохом вождении: почему бы просто не сменить машину и не перестать жаловаться? Фреймворк делает именно то, что вы ему говорите. Если ваши компоненты трясутся, ваши контекстные слои переросли или ваши хуки неотличимы от черной магии, это ваша вина.
React упрям в одном: данные текут вниз. Все остальное — побочные эффекты, синхронизация и кеширование — ваша ответственность. Это не ошибка; это особенность. Это заставляет вас строить намеренно. Когда вы отказываетесь от этой ответственности за все, что происходит на GitHub, вы обмениваете понимание на временное облегчение.
Фреймворки не создают хаос; разработчики делают.
Вам не нужно переписывать свое приложение в Solid, Svelte или Vue. Вам нужно перестать приклеивать абстракции к архитектуре, которую вы так и не разработали полностью. Фреймворки не создают хаос; разработчики делают. Как только вы это примете, React перестанет быть проблемой и станет партнером.
Заключение
React не сломан. Ваша архитектура. Бесконечный цикл замены библиотек, переосмысления шаблонов и обвинений в инфраструктуре только скрывает правду: управлять состоянием сложно, потому что сложно ясно мыслить.
Решением является не еще один хук или глобальное хранилище; это смирение и дисциплина. Поймите, как движутся ваши данные, намеренно спроектируйте свое состояние, и React перестанет чувствовать себя противником. Перестаньте винить React в своем похмелье. Ты налила напитки.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Александр Уильямс — полнофункциональный разработчик и технический писатель, имеющий опыт работы независимым ИТ-консультантом и помогающий новым владельцам бизнеса настраивать свои веб-сайты. Узнайте больше от Александра Т. Уильямса
