В этой статье рассказывается о первом опыте работы с новым Angular и о проблемах, с которыми я столкнулся.
Я помню те времена, когда я разрабатывал приложения на нашем старом AngularJS. Иногда было действительно сложно делать то, что вы хотели с ним делать. Неважно, время прошло, и я недавно начал работать с новеньким Angular.
Первое, что мне не нравится, это название. Проблема в том, что когда вы вводите его в Google, чтобы искать какие-то вещи, а Google не понимал, что у вас на уме новый Angular, он показывает вам много результатов, связанных с AngularJS, и вам нужно пройти через все этот беспорядок, чтобы найти свои вещи в новом Angular. Это действительно раздражает, и я думаю, что ребята из Google были правы, заметив это, прежде чем выбрали это имя. Может быть, какое-нибудь другое расширение, такое как TS (TypeScript), решит проблему.
Когда я впервые увидел код Angular, он выглядел великолепно. Приложения написаны (я думаю, что это необязательно) на TypeScript, поэтому в Angular есть все новые горячие вещи из ES6, такие как классы, распространение объектов / массивов, стрелочные функции и даже некоторые вещи из будущего ES7, такие как свойства классов. И в качестве бонуса он имеет безопасность типов, обеспечиваемую TypeScript. Но самым захватывающим для меня было то, что Angular использует RxJS Observables, которые я хотел изучить и много использовать.
Итак, у меня есть билет на перезагрузку данных, когда вы нажимаете кнопку Назад и параметры запроса меняются на предыдущие. Первое, что пришло мне в голову, это то, что мне нужно будет прослушивать нажатие кнопки Назад, также известное как событие popstate. Итак, я обнаружил, что в Angular есть служба под названием Location, которая выполняет именно эту задачу. Я проверил документацию и обнаружил, что в ней есть метод subscribe. Отлично, я могу использовать его и комбинировать с другими операторами Observable. Я также обнаружил, что вам нужно отказаться от подписки на службу Location, когда вы покидаете текущий маршрут. Недавно меня интересовали звонки для отказа от подписки, и я нашел действительно хороший шаблон, как отказаться от подписки на Observables, которые действуют после того, как вы покинете маршрут. Основным преимуществом обнаруженного шаблона было то, что вам не нужно хранить все свои подписки в переменных экземпляра класса, вам просто нужно декларативно вызвать один метод для ваших Observables. Вы можете найти шаблон здесь. Идея состоит в том, что вы создаете новый объект Subject, а затем вызываете метод takeUntil для Observables, из которого вы хотите (необходимо) отказаться от подписки и передать эту тему в вызовы takeUntil. А затем, когда компонент собирается уничтожить, вы генерируете событие по теме (и завершаете его), что уничтожает подписки. Этот шаблон рекомендован непосредственно разработчиком ядра Angular, и он мне очень понравился.
Еще одна проблема заключалась в том, что было действительно сложно определить, от каких Angular Observables вам нужно отказаться от подписки до изменения маршрута. Найти эту информацию даже в официальной документации непросто. Вам нужно погуглить и посмотреть видео с конференций, чтобы понять это, что отнимает у вас много времени.
Когда я вернулся в службу Location, я захотел использовать с ней этот недавно обнаруженный шаблон, проявить смекалку и очень хорошо отказаться от подписки. Но один сюрприз пришел ко мне сразу. Location не является Observable, хотя напоминает об этом! Он имеет метод subscribe, который имеет точно такой же контракт, что и подписаться из Observables ,, что действительно сбивает с толку. Так что я не смог использовать этот недавно обнаруженный паттерн. Это меня действительно разозлило. Возможно, я не понимаю его концепцию, но когда что-то выглядит как Observable, оно должно быть Observable, а не сбивать с толку клиентов. Хорошо, поэтому мне придется обрабатывать этот «особый» случай иначе, как и все другие случаи в моем компоненте. Мне нужно будет сохранить подписку, а затем в ловушке жизненного цикла ngOnDestroy я вызову для нее unsubscribe. Это действительно некрасиво. Я не могу смириться с этим фактом, но мне нужно идти вперед и закончить свой билет.
Но самым интересным с моей точки зрения в отношении службы Location было то, что внутренний метод subscribe преобразует переданные обратные вызовы в RxJS Observable! Было так сложно подумать об этом и вместо этого предоставить какой-то метод (например, сервис Http), который возвращает Observable, на который вы можете подписаться и использовать все наблюдаемые операторы на нем? Это вызвало у меня много эмоций.
Итак, мой обработчик next передан методу Location subscribe. Мне нужно прочитать текущие параметры запроса. Как это сделать? Отлично, есть служба ActivatedRoute, которая хранит эту информацию. Поэтому я ввел его и попытался получить доступ к этим параметрам. Но, как нетрудно догадаться, еще один сюрприз. Этот сервис хранит параметры из предыдущего маршрута, а не текущего, который я хотел. Я сам пытался объяснить это, и история, которую я придумал, заключалась в том, что новый маршрут еще не был активирован. Итак, как я могу прочитать эти параметры? Я должен спросить Google, и история продолжается ...
Позже я обнаружил, что обработчик next вызывается два раза, сначала со старыми параметрами запроса, а второй с текущими параметрами маршрута, хранящимися в службе ActivatedRoute, поэтому вам нужно пропустить первый вызов, если вас интересуют только правильные. Это связано с используемым под капотом BehaviorSubject. В одном из ответов была прямая ссылка на исходный код документации Angular и RxJS. Так что каждый раз, когда я буду использовать какой-нибудь Observable в Angular, мне придется проверять его исходный код, чтобы убедиться, как он работает? Эта информация должна быть доступна в документации, верно?
И подобные проблемы очень хорошо напомнили мне о моих чувствах и разочаровании, которые я испытал со старым AngularJS. Я новичок в новом Angular и все еще учусь на нем кодировать, но для разработчика очень неприятно, что все работает не так, как вы ожидаете. И если разработчикам приходится решать подобные вещи большую часть своего рабочего времени, они никогда не станут продуктивными.
Из-за всех вышеупомянутых проблем мне больше нравится React, и в основном потому, что когда вы кодируете в нем, это похоже на веселье, а не на борьбу с ним. В React все имеет смысл и ведет себя так, как вы от них ожидаете.
Но я не хочу рассказывать только о плохих вещах о новом Angular. Он действительно изменился, и в нем есть действительно классные вещи, такие как ES6, CLI и т. Д. Когда вы пишете компоненты, это тоже очень весело. Все гораздо более продвинуто, чем в старом AngularJS. И, наконец, он принял модульную систему ES. Итак, теперь мы можем требовать пакеты NPM, как и все остальные в сообществе JS.
Помните, это мой первый опыт работы с новым Angular, поэтому могут быть некоторые ошибки и недопонимания.
Большое спасибо за чтение.
И извините за мой английский ☺
