Если вы только что зашли сюда и не слышали о ScandiPWA, позвольте представить вам: ScandiPWA — это первая полная тема PWA для Magento 2, разработанная в Scandiweb. Это быстрое, готовое к работе в автономном режиме решение Progressive Web App. Тема основана на React и Redux с использованием таких технологий, как GraphQL, Varnish и Redis, для повышения производительности вашего сайта.
Фаза 2: Основное развитие
ScandiPWA поддерживается основной командой, которая в апреле 2022 года решила, что пришло время приступить к реализации второго этапа основной разработки продукта. Проследив дорожную карту, наши разработчики приступили к рефакторингу и совершенствованию кода, стремясь обеспечить бесперебойную работу и высокую производительность, а также переключившись на более новые технологии, такие как Typescript.
Сегодня мы расскажем о преимуществах перехода на Typescript и опишем некоторые неожиданные открытия, из-за которых потребовалось больше времени, чем предполагалось вначале.
Преимущества перехода на Typescript
- Typescript предлагает лучшие предложения IntelliSense, которые значительно улучшают работу разработчиков и производительность. С правильными предложениями мы знаем, какие именно данные у нас есть, что мы должны передать функциям и что мы получим взамен.
- Это помогает при обновлении до следующей версии, рефакторинге и т. д. Со строгими типами мы точно знаем, что именно было обновлено, а что нет, что может привести к проблемам.
- Использование Typescript может предотвратить многие возможные проблемы и сделать код проекта более стабильным и предсказуемым.
Погружение в процесс разработки
Ниже мы подробно описываем процесс разработки миграции кода с Javascript на TypeScript (TS), а также проблемы, с которыми мы столкнулись, надеясь, что это поможет и другим разработчикам.
В процессе миграции наша команда столкнулась с рядом проблем. Во-первых, мы решили получить нашу внутреннюю схему GraphQL и сгенерировать из нее тип TS. Это должно было помочь нам повторно использовать структуры данных, которые мы получаем от API. Проблема в том, что схема GraphQL представляет собой дерево. Вы можете разделить его на подтипы и сделать из него большой древовидный тип. Это работает хорошо, пока у вас нет псевдонимов в ваших запросах. С псевдонимами у вас есть тип данных из схемы, который не соответствует запрошенному типу данных. Из-за этого нам пришлось отказаться от этой идеи и добавлять типизации во все наши запросы вручную.
Затем команда решила начать миграцию TS с небольших примитивных функций и постепенно переходить к более сложным функциям и классам. Идея была в том, что более простые функции легче типизировать и они бы уже показывали, что именно они принимают и что возвращают. Когда мы поняли, что этот результат не соответствует ожиданиям, мы решили пойти противоположным путем. Мы знали точную структуру данных, которую получаем от API (мы делаем запросы от родительских классов, диспетчеров и т.д.). Вот с этого мы и начнем, а затем углубимся.
Попутно были обнаружены новые проблемы:
1. Способ написания кода в JS и TS сильно отличается. В то время как JS гибок и позволяет нам делать все, что угодно, TS будет спорить, пока мы не найдем единственно приемлемый способ.
2. Нам не разрешено рефакторить код для обеспечения обратной совместимости с предыдущим выпуском. Таким образом, мы могли внести лишь незначительные изменения в соответствие типам, и больше ничего.
3. Мы хотели повторно использовать одни и те же типы во всем проекте. Это невозможно, потому что существует много преобразований данных. Итак, вы получаете данные и передаете их функции. Функция преобразует данные в другую структуру и возвращает те же данные, но другого типа.
4. Существует много динамического кода, в котором мы не можем знать, какие данные у нас есть в определенный момент.
5. В коде много запасных вариантов. Когда мы не получали значение, мы присваивали пустую строку, пустой объект, пустой массив или вместо этого получали значение из другого источника.
6. Существует много отверстий для винтов, но мы не можем быть уверены, сколько типов этих винтов может быть на самом деле. Так как часть свойств объекта одинакова, а часть отличается, резервный вариант сработает, и компонент все равно будет отображаться.
7. Если вы передаете строку или массив строк, у JS не возникнет проблем при объединении такого значения с другой строкой. Пока ТС об этом предупредит. То же и с другими типами.
8. Наличие повторно используемых компонентов, повторно используемых типов, преобразований данных между компонентами и глубокого детализации пропсов привело к тому, что когда вы настраиваете тип для одного компонента, он сразу ломает другой.
9. Типы React TS плохо работают с компонентами общего класса. Поскольку в ScandiPWA все компоненты должны быть расширяемыми, эту проблему еще предстоит решить.
Оценки и сложность работы
По оценкам, переход на TypeScript займет чуть больше месяца, и мы закончим его к концу мая.
Сейчас мы находимся в начале июля, так что получается, что оценка превышена примерно в 2 раза. Это потому, что мы сильно недооценили объем работы и ее сложность. Одна только миграция продукта заняла 3-4 недели, что очень много. Код ScandiPWA никогда не предназначался для ввода, поэтому он вызывал много проблем.
Круто то, что если раньше мы работали со всеми одинаковыми продуктами, то теперь мы знаем, что, несмотря на то, что это одна и та же переменная, каждый продукт отличается, будь то настраиваемый тип, простой тип и т. д. Это значительно упрощает работу. отныне, но для реализации потребуется много времени.
Мы также наткнулись на общую сложность классов React для типизации. Они просто не хотели легко расширяться! Потребовалось некоторое время, чтобы обеспечить дополнительные типизации для containerProps, containerFunctions и всех второстепенных вещей, которые нам нужны тут и там :)
В общем, миграция почти готова, и ScandiPWA увидит интересные обновления в ближайших релизах!
Хотите знать больше?
Если вам интересно узнать об этом больше, посмотрите наши демонстрационные видеоролики, которые еженедельно записываются сопровождающими ScandiPWA: Демонстрационные видеоролики.
