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

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

Моя команда и я в OPLOG сейчас находимся в процессе модернизации. Кодовая база приложения была создана в 2018 году, и по какой-то причине основная структура с тех пор не изменилась. Мы стремимся адаптировать наши приложения к последним разработкам во внешнем интерфейсе и повысить удобство работы для разработчиков и конечных пользователей. Кому это может быть интересно, наши технические стеки: TypeScript, ReactJS, Redux, Jest - Enzyme, Styled System (CSS-in-Props), Atomic Design.

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

1) Преобразование классовых компонентов в функциональные компоненты

В React 16.8 мы встретили React Hooks. До этого для использования методов жизненного цикла мы использовали классовые компоненты. С помощью хуков мы можем получить все возможности, которые есть у компонентов класса для функциональных.

Учитывая характер базового механизма ввода-вывода и мощь хуков, сообщество React предлагает использовать функциональные компоненты в каждом приложении масштабирования. Кроме того, в большинстве популярных библиотек были установлены специальные хуки, чтобы избавиться от внедрения реквизита с помощью HOC.

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

2) Измените структуру файлов и разбейте компоненты на более мелкие части.

Файловая структура - один из самых важных моментов, когда мы говорим о масштабируемости и ремонтопригодности.

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

Как команда, нам очень нравится эта методология. Он выглядит очень организованным, и очень легко определить, какие компоненты куда идут. Благодаря программированию в области WMS (Warehouse Management System) в течение почти двух лет, она также зарекомендовала себя с точки зрения масштабируемости. Очень удобно находить блок кода, который вы ищете, и манипулировать им.

Несмотря на эти положительные отзывы, возникла проблема с размерами компонентов. В связи с бизнес-логикой или требованиями к дизайну количество строк кода компонентов может увеличиться более чем на 1000.

Чтобы решить эту проблему, мы добавили в систему еще одну папку, которую назвали «костями». У нас ограниченная длина компонентов - 300 строк кода. Если компоненту требуется более 300 строк кода, мы разделяем их на кости, которые представляют собой более мелкие фрагменты основных компонентов, в которых у них есть своя собственная логика. Эти компоненты относятся к основным компонентам, которые делятся на кости. Их нельзя использовать ни в каких других компонентах.

Вы можете увидеть изображение выше, чтобы увидеть, как мы разделили компонент OrderDetails на кости. Мы также разместили нашу папку «tests», которая включает файлы спецификаций, параллельно нашим компонентам.

Мы поняли, что 300 - это хороший психологический предел для более чистых и легко читаемых атомарных компонентов.

3) Используйте Webpack 5

С Webpack 5 мы получили много необычных и значительных улучшений в webpack и webpack-dev-server. Мы также продвинулись на шаг дальше к инфраструктуре микро-интерфейсов (см. Микро-интерфейсы с федерацией модулей Webpack).

Преобразование подробных конфигураций webpack 4 в webpack 5 было довольно сложной задачей. Есть много критических изменений. К счастью, команда webpack поделилась руководством по миграции, которому нужно следовать. После кропотливой работы мы обновили нашу версию webpack до 5 и webpack-dev-server до 4.

Я подробно поделился своим опытом при обновлении webpack до v5 в отдельном сообщении в блоге. Блог ведется на турецком языке, поэтому говорящие по-турецки могут прочитать его и применить в своих проектах. Для остальных вы можете проверить следующие ссылки, чтобы получить лучшее представление о webpack 5 и переходе на него:

Https://webpack.js.org/blog/2020-10-10-webpack-5-release/
https://webpack.js.org/migrate/5/
Https://frontend-digest.com/whats-new-in-webpack-5-ef619bb74fae

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

На графиках вы можете увидеть почти 100% улучшения. Кроме того, webpack 5 готовит основу для более серьезных улучшений.

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

4) Обновите React и TypeScript до последних версий

Всегда хорошо иметь последнюю основную версию для основных библиотек. Хотя в React 17 и TypeScript 4 нет критических изменений, они предложили некоторые приятные функции и совместимость с другими недавно обновленными библиотеками.

В процессе модернизации мы обновили наши библиотеки React (до v17) и TypeScript (до v4).

Обновление версии TypeScript оказалось простой задачей. В кодовой базе не было конфликтов или разрывов. Однако во время обновления React возникли конфликты зависимостей между узлами, которые возникли с некоторыми библиотеками с устаревшими версиями.

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

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

React 17: https://betterprogramming.pub/whats-new-in-react-v17-68b7e15576e1
TypeScript 4: https://javascript.plainenglish.io/features-and-breaking-changes- in-typescript-4-111e6551cd7

В частности, функция мгновенной горячей перезагрузки и устраненная необходимость импорта библиотеки реагирования в компоненты - два основных улучшения, которые нам нравятся в React 17.

5) Обновите response-router и используйте его новые функции на основе хуков для навигации

Мы использовали withRouter HOC для внедрения свойств маршрутизатора в наш компонент и чтения состояний маршрутизатора из свойств компонента. Как и react-router v5.1, теперь мы можем использовать ловушки для доступа к состояниям маршрутизатора и функциям навигатора внутри компонентов.

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

useHistory, useLocation и useParams - самые популярные крючки.

Хук useHistory дает вам доступ к экземпляру history, который вы можете использовать для навигации. Ловушка useLocation возвращает объект location, представляющий текущий URL. useParams возвращает объект пар ключ / значение параметров URL.

6) Замените или обновите вашу библиотеку i18n, чтобы использовать функцию перевода на основе хуков.

Библиотека i18n, которую мы использовали, была react-intl. Нам нужно обновить две основные его версии, чтобы иметь настраиваемую функцию перехвата для достижения состояния intl внутри компонента. Было так много критических изменений, которые необходимо настроить. Поэтому, несмотря на то, что у него достаточно возможностей в отношении простоты использования и поддержки сообщества, мы решили перенести нашу библиотеку i18n на i18next и react-i18next.

Процесс миграции прошел очень гладко. Мы использовали точно такие же файлы переводов в i18next и настроили их в соответствии с нашими потребностями.

Чтобы освободиться от injectIntl HOC, необходимо изменить каждый компонент в приложении. Мы удалили injectIntl HOC и использовали useTranslation() ловушку для доступа к функции перевода.

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

7) Используйте хуки для диспетчеров и селекторов Redux

Я всегда имел тенденцию забывать о структуре mapStateToProps, mapDispatchToProps и connect HOC для обертывания компонента. Если вы работаете с TypeScript, это может быть намного сложнее, когда вам всегда нужно копировать из других компонентов. Кроме того, когда мы смотрим на то, что нам нужно, явно возникает избыточная сложность.

С react-redux v7.1.0, хуки useSelector и useDispatch присоединились к нашей жизни. С их помощью мы были освобождены от написания двух отдельных функций (mapStateToProps и mapDispatchToProps) и HOC-оболочки для вставки свойств redux в компонент. Этих хуков достаточно, чтобы подписаться на хранилище Redux и отправлять действия.

Как говорят документы react-redux;

«Мы рекомендуем использовать API перехватчиков React-Redux в качестве подхода по умолчанию в ваших компонентах React.

Существующий connect API по-прежнему работает и будет поддерживаться, но API хуков проще и лучше работает с TypeScript ».

Вы можете узнать больше об использовании хуков в приложении React Redux в документации.

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

Выше вы четко видите влияние этого изменения.

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

Две нижеследующие сущности имеют одинаковый результат. Вы можете увидеть, насколько укорочен компонент.

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

Очень важно быть в настроении непрерывного развития, особенно для мира веб-интерфейса.

Я хотел бы поблагодарить моих товарищей по команде Эмре Кескин и Огулкан Давран за то, что они вдохновили нас своим высоким уровнем видения и опыта.

Оставайся на связи!

Больше контента на plainenglish.io