Comments 11
У нас как раз наоборот получилось — раньше опирались на глобальные объекты, использовали isBrowser (например, в библиотеке шаренных компонентов, которые могут быть использованы в любом контекте). Потом перешли на токены — тестировать полностью независимые сущности всегда проще, не надо думать о контексте исполнения
Обычно нужны не сами window и document, а их преобразования в различные location / performance / userAgent, их уже мокаем в тестах или стабаем в SSR. Даже вот опенсорсную либу накрутили, чтобы в SSR можно было подставлять объекты вроде UserAgent github.com/ng-web-apis/universal
Возможно, это локальная проблема, но при открытии этой статьи процессор загружается на 100%. На мобильной версии сайт пару раз перегружается, после чего выскакивает "проблема с открытием этой страницы". Возникает только на этом посте.
Ну ещё бы. Тут же в статью встроена полноценная IDE, притом аж в 4х независимых экземплярах...
1. Вы считаете что зависимость от расположение файла это повод для создания DI. Соврменная IDE может запросто поменять все пути к этому файлу во всех местах, где он использутеся. Я не понимаю профита от DI в этом случае
2. В последнем примере вы точно так же можете поменять расположение pressed-key.ts файла и всё сломается если не делать этого через IDE.
Для себя я понял, DI очень крут когда нужно мокать сервисы во время тестирования. В остальных случаях я не особо понимаю профита, я не знаю может это прийдёт с опытом, но я уже какой раз пытаюсь найти какой то полезный кейс для себя, и не вижу его.
Нет, я не считаю, что зависимость от расположения обязательно повод для создания DI. Тот псевокласс показывал, какие есть зависимости и что нам не всегда их легко подметить. Он ни к чему не призывал, так что извиняюсь, что смутил этим :)
прийдёт с опытом
На самом деле чем больше опыта, тем больше осознание что DI тут какой-то ущербный :( В статье например не сказано что все зависимости по сути синглтоны (пусть и в пределах модуля), даже фабрика и та создает синглтоны (кмк несколько неочевидно), хотя это по-моему упоминается в документации. Если синглтон не нужен приходиться явно добавлять сервис в компонент и писать @Self()
— очень раздражает и легко ошибиться (особенно когда компоненты наследуются). Надеюсь что когда-нибудь они добавят providedIn: 'component'
или что-то подобное ...
Ничего не сказано и об иерархии, которая иногда создает проблемы при переопределении провайдеров, про невозможность собрать все провайдеры из всех модулей и т.д.
Что можно положить в механизм Dependency Injection в Angular?