Что можно положить в механизм Dependency Injection в Angular?

[atomic1989]

Спасибо за статью! Раньше думал, что закинуть побольше вещей в DI, круто и правильно, то сейчас скажу нет. Стандартные вещи как window, document — считаю излишеством закидывать в DI. Ваша зависимость либо эмулирует поведение стандартной фичи, либо возвращает null(undefined). В целом сказал бы бесполезная процедура. Да и лишние затраты на создание провайдеров. Из опыта SSR, также добавлю, что в node.js чаще всего придется эмулировать браузерные объекты. Редко проекты обходятся без плагинов, которые заточены только под браузер

[MarsiBarsi]

Привет!

У нас как раз наоборот получилось — раньше опирались на глобальные объекты, использовали isBrowser (например, в библиотеке шаренных компонентов, которые могут быть использованы в любом контекте). Потом перешли на токены — тестировать полностью независимые сущности всегда проще, не надо думать о контексте исполнения

Обычно нужны не сами window и document, а их преобразования в различные location / performance / userAgent, их уже мокаем в тестах или стабаем в SSR. Даже вот опенсорсную либу накрутили, чтобы в SSR можно было подставлять объекты вроде UserAgent github.com/ng-web-apis/universal

[stantum]

Возможно, это локальная проблема, но при открытии этой статьи процессор загружается на 100%. На мобильной версии сайт пару раз перегружается, после чего выскакивает "проблема с открытием этой страницы". Возникает только на этом посте.

[mayorovp]

Ну ещё бы. Тут же в статью встроена полноценная IDE, притом аж в 4х независимых экземплярах...

[Waterplea]

Столько лет на Хабре нельзя было встроить стэкблитц и спустя всё это время они не утрудились даже сделать, чтобы он загружал их только при доскролле. Даже в спойлере грузит сразу и плевать хотел на аргументы стэкблица «запускать по клику»… :(

[Argnist88]

У меня, к тому же, все 4 экземпляра открывают один и тот же пример…

[MarsiBarsi]

Перепроверил примеры — все на местах, странно. Похоже, что эксперимент со Stackblitz'ами на Хабре вышел неудачный :(

У меня основной блог на медиуме на английском, там такие штуки на радость заходят и хорошо работают, вот и здесь пробую

[AndyGrom]

Чтобы уж полностью проникнуться, без всякой магии Angular, то вот: inversify.io — годный контейнер. Давно пользуюсь и на бэке и на фронте.

[BaZzing0]

Почитал, посмотрел на примеры. Просто вот вопросы:
1. Вы считаете что зависимость от расположение файла это повод для создания DI. Соврменная IDE может запросто поменять все пути к этому файлу во всех местах, где он использутеся. Я не понимаю профита от DI в этом случае
2. В последнем примере вы точно так же можете поменять расположение pressed-key.ts файла и всё сломается если не делать этого через IDE.
Для себя я понял, DI очень крут когда нужно мокать сервисы во время тестирования. В остальных случаях я не особо понимаю профита, я не знаю может это прийдёт с опытом, но я уже какой раз пытаюсь найти какой то полезный кейс для себя, и не вижу его.

[MarsiBarsi]

Добрый день!

Нет, я не считаю, что зависимость от расположения обязательно повод для создания DI. Тот псевокласс показывал, какие есть зависимости и что нам не всегда их легко подметить. Он ни к чему не призывал, так что извиняюсь, что смутил этим :)

[LastDragon]

прийдёт с опытом

На самом деле чем больше опыта, тем больше осознание что DI тут какой-то ущербный :( В статье например не сказано что все зависимости по сути синглтоны (пусть и в пределах модуля), даже фабрика и та создает синглтоны (кмк несколько неочевидно), хотя это по-моему упоминается в документации. Если синглтон не нужен приходиться явно добавлять сервис в компонент и писать @Self() — очень раздражает и легко ошибиться (особенно когда компоненты наследуются). Надеюсь что когда-нибудь они добавят providedIn: 'component' или что-то подобное ...

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