Яндекс corporate blog
Ajax
Open source
JavaScript
Interfaces
Comments 8
+1
Я для себя вывел такое правило: если объект не имеет состояния, то его нужно инжектить через конструктор. Это позволяет не кэшировать зависимости и избежать проблем с таким кэшированием связанных.
+9
1. Как у вас достигается типобезопасность, если все зависимости в строковых ключах описаны. DI же популярен в Java, C#, PHP и применяется для больших архитектур, а там без типов никак. А для небольших проектов и DI не нужен. Хорошие DI это Ninject C#, InversifyJS, AngularDI, там все на типах как раз.

2. Как во время рефакторинга узнать, что за реализация стоит за тем или иным строковым ключем-зависимостью? В какой папке искать Salad? Как при написании кода а не в run-time, узнать, что существует класс, который пытается резолвить DI?

3. Как в большом проекте вы решаете проблему дублирующихся имен классов? Есть какие-то составные имена, соглашения по именованию, неймспейсы?

4. Задача подгрузки кусков кода в DI не очень понятное решение. Разве подгрузка чанков бандла такая частая задача, что ее надо добавлять в ядро DI, задача которого собирать код, а не загружать из сети? К примеру, можно разделять приложение на несколько микросервисов или явно прописать загрузку в странице через роутинг и фетч, это же обычно достаточно в одном месте приложения сделать.

5. Добавили асинхронность, как обрабатывать ошибки загрузки, делать тот же retry, рисовать loading, пока код подгружается, отменять загрузку, если во время загрузки первой страницы перешли на вторую?

6. Конвенций для создания инстансов придумывать не надо, достаточно начать использовать typescript или flow+babel и генерить метаданные из аргументов в конструкторе, а через new внутри DI создавать инстансы, как делает Inversify или angular.di, разве нет? Зачем портянки невалидируемых конфигураций (в Java/Spring или PHP/Symfony для этого есть мощные плагины для idea), если можно метаданные вытаскивать из типов/интерфейсов?

7. Как вашу реализацию заставить работать с компонентами, тем же реактом? В Inversify есть хотя бы inversify-react.

8. При применении DI к компонентам вылезает проблема контроля времени жизни зависимостей. Например, есть компонент User и его зависимость UserSettings. Что будет если отобразить User, поменять что-то в UserSettings, и закрыть и снова открыть User?

9. Также есть проблема контроля разделяемости инстансов. Что будет, если есть список User, изменения в UserSettings затронут все User или только один? Поэтому в ангуларе придумали hierarchical-dependency-injection.
+2
0

Больше всего понравилось слово "бандлирование".Занёс в словарик. Если флеш не считать фронтендом, то название статьи корректно.

+1
const будет конечно лучше, но это не спасет от изменения самого объекта. Лишь запретит изменнии ссылки на текущую перменную.
0
Инверсия контроля это IoC, а не DI (Внедрение зависимости). Ту ссылку, что вы привели, это DIP принцип инверсии зависимости.
Only those users with full accounts are able to leave comments. , please.