Комментарии 8
1) С учётом того что EventEmitter наследуется от Observable outputToObservable выглядит бесполезно
2) Что такое @UntilDestroy(), откуда он импортирован?
3) "В этом примере вместо обработки асинхронных подписок и ручного управления состоянием Signal обновляется синхронно при поступлении новых данных. Это делает компонент проще, понятнее и легче в обслуживании. "
Что стало проще? Что понятнее? можно было просто написать <li *ngFor="let item of data$ | async">{{ item.name }}</li>
и не плодить лишний код.
4)
get data() { return this._dataSignal(); }
Какой смысл так писать? Что мешает вызывать сигнал напрямую в шаблоне? callstack короче будет и меньше лишнего кода.
5)
>import { createSignal } from '@angular/core';
В angular 18 нет импорта по этому пути, есть "import {createSignal} from '@angular/core/primitives/signals';" но у него нет метода pipe.
google так же ничего не знает про метод pipe у сигналов.
Статья мусорная, содержит не рабочий код.
Ну что Вы хотите. Джипити наше все!
Дело в том что я писал статью с помощью Chat GPT Canvas и в какой то момент мои вставки кода превратились в что-то совершенно иное, чем были раньше. Видимо мои комментарии по правкам в статью Chat GPT воспринимал как руководство к тому что он может похозяйничать и в коде.
Сейчас статья содержит верный код и верные факты.
Спасибо за критику! Исходя из ваших разумных замечаний, я переписал статью и весь код + добавил ссылку на Live Demo.
Что касается импорта декоратора UntilDestroy, импорт из библиотеки @ngneat/until-destroy
Пожалуйста, ознакомьтесь с новой версией статьи. Теперь код 100% рабочий.
@ngneat/until-destroy
Ангуляр имеет свою реализацию уже (не декоратором, а rxjs оператором), в примеры точно не стоит тянуть лишние внешние либы.
Честно говоря, удивился, увидев в статье про RxJS Interop применение '@ngneat/until-destroy'. Почему не takeUntilDestroyed() из того же '@angular/core/rxjs-interop'?
RxJS Interop в Angular 18: основные изменения и преимущества