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

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 варианте вы использовали какую-то библиотеку? Если да то какую?

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

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