В Storyly у нас есть два очень разных проекта React; один — «приборная панель», а другой — «студия».

Эти два проекта различаются как по назначению, так и по техническим задачам. Панель инструментов — это проект CMS, где наши пользователи управляют своими приложениями, экземплярами, группами историй, настройками и интеграциями и видят свою аналитику. Проект Studio, с другой стороны, является инструментом дизайна; это позволяет нашим пользователям создавать свои истории на пустом холсте, используя наши предопределенные элементы.

На техническом уровне, как вы также догадываетесь, информационная панель в значительной степени представляет собой данные на стороне сервера, а студия — это в основном данные на стороне клиента. Итак, при категоризации я ориентируюсь на цели проектов, а не только на технические аспекты.

Мы, как фронтенд-разработчики, не должны принимать технические решения исключительно по техническим аспектам. Есть так много других аспектов, которые необходимо учитывать, включая команду, текущих и возможных пользователей, предполагаемое будущее проекта и корпоративную культуру. Все это существенно повлияет на ваши технические решения в процессе принятия решений.

Допустим, ваша задача — выбрать решение по управлению состоянием для вашего проекта. Их очень МНОГО, с разными минусами и плюсами. Можно с уверенностью сказать, что тема управления состоянием в экосистеме внешнего интерфейса имеет наибольшее количество решений после темы «фреймворки».

Если вы рассматриваете только технические плюсы и минусы, показатели производительности, простоту использования решения и, возможно, количество коммитов, звезд и проблем решения будут тем, что вы проверяете. И это все важные моменты при выборе библиотеки.

Когда я смотрю на решения по управлению состоянием для использования в обеих кодовых базах с технической точки зрения, я склоняюсь к использованию Zustand или Jotai. Они в хорошем состоянии, невероятно просты в использовании и производительны. Это было легкое решение, верно?

Ну, мы использовали всемогущий Redux в обеих наших кодовых базах для управления его состоянием, и мне нужно было упростить эту часть проекта, потому что она стала более обширной, чем нужно. Это был основной источник многих наших ошибок. Я сразу подумал: «О, отлично, мы должны использовать Zustand для обоих проектов, потому что это потрясающе!» но потом я сделал шаг назад и еще немного задумался над этим.

Процесс миграции

Как я объяснил в начале, наши две кодовые базы очень разные.

Панель инструментов показывает данные на стороне сервера пользователю с очень тонкими изменениями и обновлениями данных на стороне сервера. Есть много страниц с данными аналитики, списками и расчетной статистикой. Будущее этого проекта также будет таким же; панель инструментов, похожая на CMS, со множеством статистических данных и списков. Поэтому мне нужно было рассмотреть кеширование данных, аннулирование кеша, сетевые водопады, обновления данных в реальном времени, оптимистичные обновления и т. д. Помня об этих темах, я решил, что нам не нужно менять наше решение для управления состоянием (Redux). ); нам просто нужно было удалить его с панели инструментов, потому что нам не нужно «управлять» каким-либо состоянием.

Затем я рассмотрел решения для извлечения данных, такие как SWR , TanStack Query и RTK Query .

У SWR нет стабильного потока мутаций, а RTK Query слишком связан с Redux Toolkit, поэтому я продвинулся вперед с TanStack Query.

TanStack Query устраняет накладные расходы на управление данными на стороне сервера с помощью потоков кэширования, аннулирования и изменения. Всегда есть состояние, которым нужно управлять, но вам не всегда нужно управлять им самостоятельно. Мы возложили эту тяжелую работу на TanStack Query и не оглядывались назад. Мы используем Redux и TanStack Query параллельно и перемещаем состояние Redux по частям в запрос TanStack до тех пор, пока в состоянии Redux ничего не останется, и мы сможем безопасно yarn removeего использовать.

React Hooks позволяет нам использовать их параллельно и постепенно перемещать логику между ними:

Однако в студии для отправки на сервер создается много чисто клиентских данных. Вы можете полностью создать историю с предопределенными элементами; вы можете перемещать их на холсте, изменять их размер, изменять их содержимое в соответствии с вашими потребностями, изменять фоновое изображение истории или даже размещать видео на заднем плане. И возможности безграничны, прежде чем вы отправите окончательные данные на сервер для их сохранения. Все эти функции являются данными на стороне клиента, пока вы их не сохраните. И после того, как вы сохраните их и вернетесь, чтобы отредактировать их, они снова будут данными на стороне клиента, полученными из данных на стороне сервера.

Нам также нужно подумать о возможных функциях — возможность отменять изменения, создавать рисунки от руки, проектировать переходы между историями… Возможности безграничны, но все возможные функции — это тяжелые данные на стороне клиента. Поэтому нам нужно «управлять» нашим состоянием здесь для максимальной гибкости.

Для Studio мы уже использовали решение для управления состоянием Redux. Итак, я задал своим товарищам по команде вопрос: «Что мы должны использовать, чтобы исправить наше управление состоянием?»

После всех ответов путь был ясен: будем использовать Redux Toolkit .

RTK (Redux Toolkit) — это набор инструментов от команды Redux для улучшения качества жизни разработчиков. Это упрощает настройку магазина и управление несколькими магазинами с помощью слайсов . Итак, мы перенесли наше старое состояние Redux на новую архитектуру RTK. Мы одновременно запускаем и старую, и новую архитектуру и перемещаем части состояний в новую архитектуру при ее рефакторинге. Все это позволяет нам двигаться быстро и поэтапно, не блокируя рабочий процесс продукта.

Мы запускаем эту старую и новую архитектуру параллельно, передавая пользовательский React Context поставщикам Redux :

Имейте в виду, что когда вы передаете пользовательский контекст Redux Provider, вам необходимо создать все связанные Redux-хуки с предоставленными генераторами и использовать их в своем коде вместо прямого импорта из пакета react-redux:

Наша долгосрочная цель — полностью удалить Redux из проекта Dashboard и удалить «старый» Redux из проекта Studio. Мы движемся к этой цели, рефакторинг каждого файла, который мы должны коснуться, разрабатывая новые функции и исправляя ошибки.

Эти важные технические переходы должны быть плавными и поэтапными в основном по двум причинам: во-первых, вы перестраиваете повседневную работу своей команды. Они должны с удовольствием работать с этими изменениями, иначе их производительность существенно снизится. С другой стороны, если им нравятся инструменты, которые они используют для создания, и эти инструменты помогают им, а не блокируют их, их производительность существенно возрастет. А во-вторых, продукт должен продолжать создаваться . Шоу должно продолжаться. Должны быть новые функции. Нужно двигаться вперед. Поэтому технические переходы не должны блокировать развитие продукта. Каждое изменение должно быть постепенным.

Резюме

Принимая технические решения как разработчики, мы должны учитывать каждый аспект проекта, над которым мы работаем, и потребности команды, с которой мы работаем. Просто потому, что эти технические решения влияют на команду и всех, кто работает над проектом, а не только на разработчиков.

Технические изменения должны быть постепенными любой ценой. Эти изменения не должны блокировать конвейер продукта и, следовательно, его успех.

И всегда помните, чтобы разработчик был продуктивным, вы должны предоставить ему инструменты, которые делают его счастливым.