Миграция с AngularJS на современный Angular в Дубае: что ломается и как спланировать переход

Поддержка AngularJS закончилась в январе 2022 года, согласно собственной документации AngularJS, а значит бизнес, всё ещё работающий на приложении на AngularJS, не имеет официального источника патчей безопасности для самого фреймворка. Практичный ответ, это спланированная, обычно поэтапная миграция с AngularJS на современный Angular для бизнеса в Дубае, а не игнорирование риска и не обязательство переписать всё с нуля до того, как выйдет что-то новое. То, что на самом деле ломается, это обычно двусторонняя привязка данных, собственные директивы и связывание внедрения зависимостей, а не простой синтаксис.

Это руководство рассказывает, что на самом деле означает окончание поддержки AngularJS, что обычно ломается при миграции на современный Angular для бизнеса в Дубае, как переходить поэтапно вместо одного большого переписывания, и как правильно протестировать результат до того, как он дойдёт до пользователей.

Что на самом деле означает окончание поддержки AngularJS для бизнеса в Дубае

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

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

Почему AngularJS и Angular, это не один и тот же фреймворк

Название действительно вводит в заблуждение. AngularJS, также называемый Angular 1, это фреймворк на JavaScript, построенный вокруг двусторонней привязки данных и собственной системы внедрения зависимостей. Angular, версии 2 и выше, это полное переписывание: другая архитектура, TypeScript по умолчанию вместо обычного JavaScript, и компонентная модель, которая не отображается один в один на контроллеры и директивы AngularJS. Автоматического пути обновления от одного к другому не существует, поэтому переход между ними правильно называть миграцией, а не обновлением.

Это важно для планирования, потому что исключает простой ответ в виде повышения номера версии. Миграция с AngularJS по объёму ближе к переносу приложения на новый фреймворк, чем к обычному обновлению зависимости, и с самого начала её стоит оценивать и закладывать в бюджет именно так.

AngularJS и Angular разделяют название и почти ничего больше. Планируйте переход как миграцию, а не как обновление.

Что обычно ломается при миграции с AngularJS в Дубае

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

Четвёртая область, которую легко упустить, это сторонние библиотеки AngularJS без поддерживаемого аналога для Angular. Проверка на раннем этапе, от каких внешних библиотек зависит приложение и есть ли у каждой из них поддерживаемая замена для Angular, помогает не обнаружить блокирующую проблему на середине миграции, а не на этапе первоначальной оценки.

Поэтапная миграция с AngularJS в Дубае вместо переписывания всего сразу

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

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

1. Проведите аудит существующего приложения на AngularJS

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

2. Настройте гибридное окружение

   Запустите AngularJS и Angular бок о бок в одной сборке, чтобы перенесённые и ещё не перенесённые разделы приложения могли сосуществовать во время проекта.

3. Переносите в порядке риска и ценности

   Сначала перенесите более простые самостоятельные экраны, чтобы проверить подход, а затем проработайте общие сервисы и самые тяжёлые собственные директивы.

4. Удалите AngularJS, когда от него больше ничего не зависит

   Убедитесь, что ни один маршрут, сервис или компонент больше не обращается к AngularJS, прежде чем полностью удалить его из сборки, окончательно закрыв незащищённость неподдерживаемого кода.

Как правильно протестировать миграцию с AngularJS на Angular в Дубае

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

Там, где у существующего приложения на AngularJS мало автоматических тестов или их нет вовсе, написать тесты под его текущее поведение перед миграцией раздела стоит дополнительного времени, потому что это превращает вопрос «работает ли это по-прежнему» в вопрос с чётким ответом, а не в субъективное суждение под давлением сроков.

Частые ошибки при миграции с AngularJS в Дубае

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

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

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

Чем может помочь Digital Marketing Dubai

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

Если вы всё ещё решаете, переносить приложение на месте или перестраивать заново, наше руководство как выбрать CMS для бизнеса в ОАЭ и материал чек-лист запуска сайта для бизнеса в Дубае будут полезны вместе с этим материалом.