Внедрение зависимостей (dependency injection) через свойства-функции в JavaScript

[@AxisPod]

Я бы посоветовал полноценно понять, что же такое IoC (Inversion of Control) и IoC контейнеры. И после этого пересмотреть свои взгляды. Да, в списке библиотек у вас смешались в кучу кони, люди. Там есть IoC контейнеры, есть просто свободное видение IoC. Ваше же решение, это просто обилие бойлерплейт кода, всё это можно автоматизировать, но у вас надо делать ручками. IoC контейнеры автоматизируют внедрение зависимостей.

Ну и собственно в вашем велосипеде я не увидел самого главного — внедрения зависимостей. Чем ваше решение отличается от простой фабрики?

IoC контейнеры решают множество проблем. Автоматическое внедрение. Во время разработки вы просто меняете сигнатуру конструктора или список публичных параметров (возможно помеченных), и вуаля, ни строчки лишнего кода и там у вас уже будут нужные объекты.

Я конечно понимаю, вы не называли свою статью «IoC контейнеры для упрощения работы DI», но абсолютно не вижу смысла как-то частично автоматизировать внедрение зависимостей.

В общем советую полноценно разобраться с IoC контейнерами и возможно более не будете изобретать подобные велосипеды. При этом на хабре уже есть тьма статей про это. Не смотрите в срезе JS, смотрите теорию, она применима куда угодно. Я реализовывал свои решения на C++ и JS и они в общем-то работают без проблем и выполняют свои задачи. Хотя вроде как языки и не очень хорошо подходят для этого.

P.S. TS преимуществ тут никак не даст, ибо в рантайме есть только JS.

[@kraut]

AxisPod, спасибо за ваш комментарий!

Я бы посоветовал полноценно понять, что же такое IoC (Inversion of Control) и IoC контейнеры. И после этого пересмотреть свои взгляды.

IoC нигде в статье не упоминал.

Да, в списке библиотек у вас смешались в кучу кони, люди. Там есть IoC контейнеры, есть просто свободное видение IoC.

Это действительно так, я в статье указал как я нашел эти библиотеки «Сделал небольшой парсер, разбирающий попадание сочетания “di” в npm. Пакетов по этой теме ~1400. Все рассмотреть невозможно. Рассмотрел в порядке уменьшения количества npm dependents.». Тут моя ошибка в подзаголовке «Популярные dependency injection вспомогательные библиотеки javascript/typescript», правильнее «Библиотеки npm, содержащие в keywords сочетание di»

Ваше же решение, это просто обилие бойлерплейт кода, всё это можно автоматизировать, но у вас надо делать ручками. IoC контейнеры автоматизируют внедрение зависимостей.

Действительно можно, но у меня было скорее желание донести мысль из темы: «Внедрение зависимостей (dependency injection) через свойства-функции в JavaScript», свое решение скорее как видение как эту тему можно красиво реализовать именно в прототипной модели. Но на самом деле есть и дополнительные преимущества, например если это скрипт для браузера, то размер с моим решением ~11КБ (для сравнения inversify 63КБ, колонка bundle size в таблице) будет аргументом в пользу использования, отказавшись от преиуществ IoC.

Ну и собственно в вашем велосипеде я не увидел самого главного — внедрения зависимостей. Чем ваше решение отличается от простой фабрики?

Да, по сути фабрика с контекстом, хранящим зависимости. Да, наверное оно выглядит слишком просто. Но я считаю это скорее преимуществом, чем недостатком.

IoC контейнеры решают множество проблем. Автоматическое внедрение. Во время разработки вы просто меняете сигнатуру конструктора или список публичных параметров (возможно помеченных), и вуаля, ни строчки лишнего кода и там у вас уже будут нужные объекты.

Да, согласен, у меня не IoC контейнер. И по сравнению с ним, в моем решении надо будет делать дополнительную работу. Я скорее пытался освятить другую проблему. Долгое время в JavaScript и общепризнанной реализации классов не было. И можно найти много готовых и очень популярных библиотек, которые очень сложно допилить под себя. Я предлагаю один из вариантов, с минимальным дополнительным кодом можно писать более гибкий ООП код.

Я конечно понимаю, вы не называли свою статью «IoC контейнеры для упрощения работы DI», но абсолютно не вижу смысла как-то частично автоматизировать внедрение зависимостей.

Думаю уже ответил выше.

В общем советую полноценно разобраться с IoC контейнерами и возможно более не будете изобретать подобные велосипеды. При этом на хабре уже есть тьма статей про это. Не смотрите в срезе JS, смотрите теорию, она применима куда угодно. Я реализовывал свои решения на C++ и JS и они в общем-то работают без проблем и выполняют свои задачи. Хотя вроде как языки и не очень хорошо подходят для этого.

Подскажите, в своем JS варианте вы использовали какую-то библиотеку? Если да то какую?

[@AxisPod]

Подскажите, в своем JS варианте вы использовали какую-то библиотеку? Если да то какую?

Никаких не использовал, только ES6. Метаинформацию описывал используя декораторы. Внедрить можно было в любой класс, даже незарегистрированный, полям, куда внедрять надо указать внедряемый объект через декоратор inject, для конструкторов привязка шла декоратором на класс. Работает строго для классах.

P.S. Ответил не туда.

[@kraut]

Никаких не использовал, только ES6. Метаинформацию описывал используя декораторы. Внедрить можно было в любой класс, даже незарегистрированный, полям, куда внедрять надо указать внедряемый объект через декоратор inject, для конструкторов привязка шла декоратором на класс. Работает строго для классах.

Правильно ли я понимаю, что inject декоратору аргументом нужно передать готовый внедряемый объект? Не токен, не ключ?
Но тогда где вызывается new? Вне системы dependency injection? А что если этому внедряемому объекту потребуется своя зависимость?

[@AxisPod]

Правильно ли я понимаю, что inject декоратору аргументом нужно передать готовый внедряемый объект?

Нет конечно, я использовал аналоги интерфейсов на основе абстрактных классов, для этого был ещё доп. декоратор использован abstract, все методы помечались как абстрактные, правда кидали исключение только в рантайме. Совместить с compile-time позволит TS, если это необходимо. Моя реализация похожа на оные для строго типизированных языков, где сервис регистрируется в контейнере по интерфейсу.

[@kraut]

Нет конечно, я использовал аналоги интерфейсов на основе абстрактных классов, для этого был ещё доп. декоратор использован abstract, все методы помечались как абстрактные, правда кидали исключение только в рантайме. Совместить с compile-time позволит TS, если это необходимо. Моя реализация похожа на оные для строго типизированных языков, где сервис регистрируется в контейнере по интерфейсу.

Понятно, но если сложить саму реализацию Inject, декораторы abstract, сами абстрактные классы, то в конечном счете для IoC много дополнительного кода.
Моя альтернатива в том, что мы заведомо принимаем решение, что можем прописать все зависимости вручную, без IoC преимуществ, но взамен имеем простой, расширяемый способ писать в ООП стиле. Аналогами интерфейсов для ES6 в моем случае являются типы () => IService, т.е. функции, которая возвращает определенный тип. Сами интерфейсы в ts стиле можно прописывать или нет, в любом случае они не отразятся на конечном коде. IDE будет помогать выявлять потенциальные ошибки:



См. пример — codesandbox.io/s/github/kraut-dps/di-box/tree/0.2.2/examples/?file=/example-js.js