Спасибо большое. Добавить про tree shaking в целом хорошая идея. Но думаю, что можно оставить на еще одну статью. У нас была мысль написать статью про рефлексию, и то как Angular работает с декоратором Injectable. Там, мне кажется, инфу про tree shaking было бы отлично видеть
Спасибо большое за лестный отзыв о статье. Рад, что вам понравилось.
Согласен, что Angular не особо пытается донести людям, что необязательно делать только синглтоны. Тут вы правы.
С 17ой версии можно смотреть дерево инжекторов в Angular DevTools, это очень помогает, крайне советую. Еще можно отметить, что мы следуем заложенной архитектуре, и таким образом внезапных зависимостей не появляется. Как то так.
Сори за долгий ответ. OlegTar ответил верно ниже. Попробую немного подробнее ответить. Если у нас есть observeOn в пайпе, то он как бы свитчит поток в scheduler в моменте, где он добавлен. А subscribeOn оборачивает весь Observable в выбранный scheduler.
.pipe(
... // синхронной работы остается синхронной
observeOn(asyncScheduler)
... // все остальное будет выполняться ассинхронно
)
.pipe(
... // синхронная работа будет выполнена ассинхронно
subscribeOn(asyncScheduler)
... // все остальное будет выполняться ассинхронно
)
Я создал StackBlitz, где можно наглядно посмотреть, как это работает
Вы правы насчет ngIf и ngFor. У нас используется tuiLet, когда в этих структурных директивах нет необходимости.
Идея статьи была в том, что бы рассказать про AsyncPipe и как он работает изнутри, потому что в начале моего пути это казалось какой-то магией.
А так, когда нет возможности использовать AsyncPipe, мы подписываемся и отписываемся внутри, как вы и сказали. Еще у нас есть TuiDestroyService, что позволяет не создавать сабжект каждый раз руками.
Но в большинстве случаев у нас используется AsyncPipe и проблем не наблюдаем.
О, я понял. Почитал немного про RxJava. Там оказывается есть отдельная сущность Flowable для backpressure. Круто!
Нашел интересную дисскусию о backpressure story в RxJS, открытую еще в 2015 году. Вроде как по ходу дисскусии, мейнтейнеры библиотеки решили что имплементировать слишком дорого, а use кейсов не прям много.
В вашем случае должны помочь loss-less операторы — bufferCount, windowCount, bufferTime и т.д.
Я не знаком с тем, как выбирается backpressure стратегия в Java, но в RxJS этим можно управлять через операторы.
Вы можете подробнее об этом прочитать в старой документации.
Если у нас только подписка, то, наверное, ничего страшного. Но иногда мы можем рассчитывать на определенный контекст выполнения кода по подписке.
Попробую пояснить на примере, возможно, не очень реалистичном, но главное суть.
У нас есть функция getUser() получения конкретного юзера. get() это функция из статьи, которая сначала возвращает асинхронно данные, а на второй раз синхронно.
И мы подумали, что на время получения юзера, нужно зачем-то обнулить его данные, может быть там какая логика связанная с этим, решив что get() всегда выполняется в контексте макрозадач.
В первый раз, при вызове getUser() все будет нормально. Во второй раз, сначала выполнится код в subscribe, а потом присвоение null. И это явно не то, чего мы хотели.
Интересная информация. Я не знал, что теряется контекст. Спасибо вам.
Насчет содержимого по дефолту согласен. Пару раз очень бы пригодилось.
Мы используем ng-content в основном для layout компонентов. Например, у нас есть хедер, в котором должны быть разные компоненты в зависимости от страницы, но позиция у них одинаковая. И тут идеально подходит ng-content для нас. Так что по поводу «ущебрный» я с вами не совсем согласен.
Спасибо большое. Добавить про tree shaking в целом хорошая идея. Но думаю, что можно оставить на еще одну статью.
У нас была мысль написать статью про рефлексию, и то как Angular работает с декоратором Injectable. Там, мне кажется, инфу про tree shaking было бы отлично видеть
Спасибо большое за лестный отзыв о статье. Рад, что вам понравилось.
Согласен, что Angular не особо пытается донести людям, что необязательно делать только синглтоны. Тут вы правы.
С 17ой версии можно смотреть дерево инжекторов в Angular DevTools, это очень помогает, крайне советую. Еще можно отметить, что мы следуем заложенной архитектуре, и таким образом внезапных зависимостей не появляется. Как то так.
Сори за долгий ответ. OlegTar ответил верно ниже. Попробую немного подробнее ответить. Если у нас есть observeOn в пайпе, то он как бы свитчит поток в scheduler в моменте, где он добавлен. А subscribeOn оборачивает весь Observable в выбранный scheduler.
Я создал StackBlitz, где можно наглядно посмотреть, как это работает
Это правда, но в таком случае создается дополнительный объект в памяти. Рома Седов вот тут ответил подробнее.
Вы правы насчет ngIf и ngFor. У нас используется tuiLet, когда в этих структурных директивах нет необходимости.
Идея статьи была в том, что бы рассказать про AsyncPipe и как он работает изнутри, потому что в начале моего пути это казалось какой-то магией.
А так, когда нет возможности использовать AsyncPipe, мы подписываемся и отписываемся внутри, как вы и сказали. Еще у нас есть TuiDestroyService, что позволяет не создавать сабжект каждый раз руками.
Но в большинстве случаев у нас используется AsyncPipe и проблем не наблюдаем.
Нашел интересную дисскусию о backpressure story в RxJS, открытую еще в 2015 году. Вроде как по ходу дисскусии, мейнтейнеры библиотеки решили что имплементировать слишком дорого, а use кейсов не прям много.
Я не знаком с тем, как выбирается backpressure стратегия в Java, но в RxJS этим можно управлять через операторы.
Вы можете подробнее об этом прочитать в старой документации.
Попробую пояснить на примере, возможно, не очень реалистичном, но главное суть.
У нас есть функция getUser() получения конкретного юзера. get() это функция из статьи, которая сначала возвращает асинхронно данные, а на второй раз синхронно.
И мы подумали, что на время получения юзера, нужно зачем-то обнулить его данные, может быть там какая логика связанная с этим, решив что get() всегда выполняется в контексте макрозадач.
В первый раз, при вызове getUser() все будет нормально. Во второй раз, сначала выполнится код в subscribe, а потом присвоение null. И это явно не то, чего мы хотели.
Насчет содержимого по дефолту согласен. Пару раз очень бы пригодилось.
Мы используем ng-content в основном для layout компонентов. Например, у нас есть хедер, в котором должны быть разные компоненты в зависимости от страницы, но позиция у них одинаковая. И тут идеально подходит ng-content для нас. Так что по поводу «ущебрный» я с вами не совсем согласен.