От автора: последний год мы работаем с крупным корпоративным клиентом с 20+ веб-приложениями, написанными в AngularJS (точнее, Angular версии 1.5). Но учитывая анонс Google в начале этого года, похоже, клиенту потребуется обновить все эти приложения.
Основная причина этого заключалась в том, что Google завершит поддержку старой версии 30 июня 2021 года. Любые дыры в безопасности, обнаруженные после этого момента, оставят нашего клиента уязвимым, если он самостоятельно не возьмется за развертывание патчей в самом фреймворке. Мы знали, что нам нужен новый фреймворк, но первая, большая проблема заключалась в том, чтобы решить, какой из них выбрать и как это сделать.
«Большая тройка» front-end в 2018 году
Мы могли бы легко выбрать последнюю версию Angular (v6.2 на момент написания), но чувствовали себя обязанными исследовать все возможные варианты. Двумя другими соперниками, которых мы рассматривали, были Vue и React.
Несмотря на то, что он стартовал в развитии, как Али-Баба, Vue мы перестали рассматривать довольно рано. Его популярность увеличивается с впечатляющей скоростью, однако сообщество относительно невелико, что представляет собой риск. Это был риск, на который стоило пойти только в том случае, если Vue предложил бы функции, которые были бы важны для того, что мы делали. Но это было не так.
Несмотря на огромную популярность, мы также сняли с гонки и React. Это скорее библиотека, а не полный фреймворк, который был бы прекрасен, если бы не тот факт, что нам нужно было убедиться, что ни одна часть фреймворка AngularJS не останется неохваченной, когда мы закончим.
Выбор React означал бы необходимость искать другие библиотеки для обработки маршрутизации и хранения данных, а также разрабатывать нашу собственную архитектуру, что было просто не нужно, когда Angular 2.0+ предлагал все эти функции «из коробки».
Замена front-end фреймворка — это трудоемкая задача сама по себе, и мы хотели минимизировать затраты времени. По той же причине мы решили не вносить изменения ни в один из инструментов, которые мы использовали для развертывания или автоматического тестирования.
Реальным решением был модуль ngUpgrade, предлагаемый Angular. Он не только официально поддерживается Google как «способ обновления», но также для него доступно много реальных примеров, которым мы могли бы следовать. Существует даже целый курс, построенный исключительно вокруг этого предмета, который объясняет процесс шаг за шагом.
Хотя мы хотели изменить как можно меньше, было несколько ситуаций, когда у нас просто не было выбора. Некоторые модули Node.js, используемые нашим приложением AngularJS, совместимы только с версией 6.0 и ниже, а для Angular 2.0+ требуется как минимум v8.0. Нам также пришлось добавить компилятор, поскольку мы вводили TypeScript, но это не было проблемой, потому что мы выбрали Webpack.
«Бонусные» преимущества
Новые технологии создаются в результате работы сообществ, которые поддерживают их и улучшают в процессе поиска новых решений. Таким образом, только факт модернизации дал нам преимущества, которые мы специально не искали, но все равно получили.
Webpack включает поддержку отложенной загрузки, то есть браузер загружает только те ресурсы, которые необходимы для визуализации того, что видно в окне просмотра. Это здорово для производительности, потому что это уменьшает количество анализируемых Javascript. Также сюда можно отнести отпечаток пальца загрузки, который является существенным для крупного международного бренда, когда вы не можете гарантировать условия сети на разных рынках.
Хотя большое количество нашего кода AngularJS можно было перенести только с незначительными изменениями, были области, требующие значительного рефакторинга. Мы восприняли это как возможность оптимизировать код другими способами, включая некоторые изменения в модели данных, которые уменьшали количество вызовов служб.
Необходимость рефакторинга в основном обусловлена тем, что Angular 2.0+ ориентирован в значительной степени на архитектуру на основе компонентов (по сравнению с Модель-Представление-Контроллер для AngularJS), и на то есть основания; это делает ваш код более модульным, что также отлично подходит для повторного использования и проверки.
Наш подход
Модуль ngUpgrade позволяет загружать AngularJS в Angular 2.0+, поэтому компоненты могут создаваться в обеих средах и работать в одном приложении при совместном использовании данных и сервисов. Эти два фреймворка могут сосуществовать, сохраняя при этом возможность продолжать вводить обновления для производства. Это позволяет выполнять инкрементное обновление, начиная с наименьшего компонента.
Альтернативой мог быть подход более близкий к водопаду, который мог бы привести к зависанию сервера до тех пор, пока обновление не было бы «полным»: абсолютный анти-шаблон для больших сложных приложений, в которых этот процесс может занять годы.
Команда разработчиков программного обеспечения постоянно жонглирует приоритетами. Идея отказаться от всего, чтобы реализовать полное обновление, была бы совершенно неприемлема для наших клиентов и нашего руководства, особенно если после этой работы конечный продукт выглядел бы точно так же, без каких-либо дополнительных функций.
Это были еще не все подводные камни… Упор Angular на TypeScript мог быть потенциально неприятным сюрпризом для разработчиков интерфейсов, которые не знали ничего, кроме Javascript. Это надмножество Javascript, поэтому многие дополнительные функции были необязательными, но по-прежнему кривая обучения была очень крутой. Тем не менее, для большого проекта с несколькими командами, работающими над одним и тем же кодом, TypeScript упростил для всех понимание нового кода, когда они работали над незнакомыми частями базы кода.
Мысли напоследок…
Мы были очень довольны решением, к которому пришли в конце концов, хотя, очевидно, было бы проще, если бы Google никогда не раскалывал AngularJS / Angular.
Также не было никаких гарантий, что подобная ситуация не возникнет в будущем, хотя Google, должно быть, осознал боль, которую они причинили многим разработчикам, когда-то использовавшим AngularJS в качестве основного фреймворка, но в результате перешедшим на React.
Это предполагает, что в будущем они будут избегать ошибок в отношении дополнительных инкрементных обновлений. С этой точки зрения, модернизация — это процесс, который стоит реализовать для нашего клиента.
Автор: Simba Sagwete
Источник: https://medium.com/
Редакция: Команда webformyself.
