Отличная статья. Я бы еще докинул Self декоратор при инжекте destroy$ сервиса, чтобы он случайно не стянулся с родительского компонента в случае, если разработчик забыл указать сервис в провайдерах компонента.
Прошу прощения, но причем тут перегрузка? For of это отличный пример полиморфизма, а не перегрузки. В каком месте for of перегружается? For of конструкция работает только с итерируемыми объектами.
Юнит тесты — видимо у вас очень удачный подбор компаний, потому что я за свою практику встречал всего пару компаний, где фронтенд приложения покрывают юнит тестами.
А по поводу бездумности — как много новичков вы знаете, которые начинают приступать к проекту только после чтения всей документации и просмотра ее исходников? Лично я ни одного такого человека не встречал. Доки обычно смотрятся вскользь, а возвращаются к ним в моменты, когда что-то идет не так, или спустя время, когда менеджер не стоит над душой с новым багом или фичей.
От одной отписки, перегруженным код не станет(а все подписки внутри сервиса или компонента всегда можно свести к одной строчке отписки). А вот то что он станет более безопасным и менее подверженным ошибкам — это более серьезный довод в эту сторону.
Спасибо, но исходники я видел. Мой посыл вы однако не поняли. Зачем мне вообще в них заглядывать, если я использую простой контракт: «подписка = отписка»? Это первое.
Ну и конечно же второе: сегодня у них одна реализация, а завтра они ее меняют. Какой код более устойчив к изменениям реализации того или иного Observable?
Ну и конечно же третий довод: От отписки еще ни одной утечки/нежелательных последствий в коде не было, а вот от их избегания…
И чисто от себя: я всегда делаю отписку, будь то EventListener, паттерн Observable или его реализация ввиде Rxjs. Я даже в сервисах всегда ставлю отписку, потому что сегодня он у меня синглтон, а завтра я начну провайдить его в компоненты и он уже не синглтон.
А вы не подменяете понятий? Причем тут «преждевременная оптимизация» и безопасный код? С кодом работать гораздо проще, когда ты знаешь, что при модификации потока у тебя точно будет происходить отписка, а не сидеть и не изучать исходники либ/сорсов из которых этот поток тянется. Что проще, потратить минуту на написание одной строчки с unsubscribe/switchMap/takeUntil, чем каждый раз смотреть исходники или вставлять ненужный «отладочный» код и проверять его работу?
Мой пример изначально был немного сложнее, с показом ошибки и выводом сообщения о том, что результат пустой. Но тогда статья очень сильно разрастается. Я же хотел максимально доступно объяснить как работают эти операторы, и немного показать это на практике.
Но за идею спасибо! Думаю это можно будет показать в отдельной статье.
Зацикливания вполне можно создать, но не в вашем примере. Переменная a зависит от некоего источника b, который еще не был создан. Данный пример просто не заработает.
Но зацикливание можно получить, если подписаться на источник, и изменять его значение в ответ на изменение. Например, у вас есть некий буфер сообщений, который представляет собой поток. Вы подписываетесь на него. И в случае, когда вам придет новое сообщение, пытаетесь запушить новое. С обычным Observable это сложно провернуть, но вот используя Subject вполне.
Код не надо вызывать по разному, нужно лишь увидеть различия в поведении. Можно сказать, что второй пример это и есть некий «псевдкокод», а не реальный вариант. В pull стретегии, чтобы узнать значение sum, нам нужно будет заново его посчитать: sum = a + b; В push оно посчитается само. Приведу аналогию с excel. У вас есть две ячейки: a(2), b(3). В третьей ячейке вы описываете формулу =A1+B1; Когда вы поменяете a, то значение в 3 ячейке посчитается само. Это и будет push стратегия.
Спасибо за конструктив.
В следующих статьях я буду использовать примеры на rxjs. Поэтому и добавил его в название.
С остальным согласен. Думаю, что сделаю на этом акцент в будущем.
Да никак) если вы его выполните, то он выдаст одинаковый результат. Я хотел показать, как бы он «мог работать», если бы использовалась push стратегия, а не pull. Если бы я сразу привел код с использованием rxjs, то это усложнило бы его. А так я постарался оъяснить разницу на привычном всем императивном подходе.
Да, все верно. Я хотел показать, как код будет вести себя при реактивном подходе(в комментариях в коде показано различие). Сам же пример далек от реальности и был приведен с целью упростить понимание.
Отличная статья. Я бы еще докинул Self декоратор при инжекте destroy$ сервиса, чтобы он случайно не стянулся с родительского компонента в случае, если разработчик забыл указать сервис в провайдерах компонента.
А по поводу бездумности — как много новичков вы знаете, которые начинают приступать к проекту только после чтения всей документации и просмотра ее исходников? Лично я ни одного такого человека не встречал. Доки обычно смотрятся вскользь, а возвращаются к ним в моменты, когда что-то идет не так, или спустя время, когда менеджер не стоит над душой с новым багом или фичей.
Ну и конечно же второе: сегодня у них одна реализация, а завтра они ее меняют. Какой код более устойчив к изменениям реализации того или иного Observable?
Ну и конечно же третий довод: От отписки еще ни одной утечки/нежелательных последствий в коде не было, а вот от их избегания…
И чисто от себя: я всегда делаю отписку, будь то EventListener, паттерн Observable или его реализация ввиде Rxjs. Я даже в сервисах всегда ставлю отписку, потому что сегодня он у меня синглтон, а завтра я начну провайдить его в компоненты и он уже не синглтон.
Но за идею спасибо! Думаю это можно будет показать в отдельной статье.
Но зацикливание можно получить, если подписаться на источник, и изменять его значение в ответ на изменение. Например, у вас есть некий буфер сообщений, который представляет собой поток. Вы подписываетесь на него. И в случае, когда вам придет новое сообщение, пытаетесь запушить новое. С обычным Observable это сложно провернуть, но вот используя Subject вполне.
В следующих статьях я буду использовать примеры на rxjs. Поэтому и добавил его в название.
С остальным согласен. Думаю, что сделаю на этом акцент в будущем.
Извиняюсь, промахнулся с комментарием. Ниже дал ответ.