Нет конечно, я использовал аналоги интерфейсов на основе абстрактных классов, для этого был ещё доп. декоратор использован 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

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

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

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

Почему бы просто не разделить букву М в MVC на две составляющие — данные и сервисные методы: Post и PostQuery

И сейчас не сложно их разделить, и будет автокомплит в ИДЕ работать ( подменить метод ActiveRecord::createQuery создать дополнительный класс, подменить возвращаемый тип у find и findBySql для ИДЕ ):

...
/**
 * @method static \app\models\PostActiveQuery find( $q = null )
 * @method static \app\models\PostActiveQuery findBySql( $sql, $params = array() )
 */
class Post extends \yii\db\ActiveRecord {
...
	/**
	 * @return PostActiveQuery
	 */
	public static function createQuery() 	{
		return new PostActiveQuery( array(
			'modelClass' => get_called_class(),
		) );
	}
}

class PostActiveQuery extends ActiveQuery {
	/**
	 * @param $title
	 * @return PostActiveQuery
	 */
	public function byTitle( $title ) {
		$this->andWhere( 'title = :title', array( 'title' => $title ) );
		return $this;
	}
}

Так оно и планируется, только еще один пункт:

3. замена всех клиентских window.location на MU.location

Возможно на странице яндекса устаревшая информация, но написано так:

Использование <iframe>. Для корректного ранжирования документа не рекомендуется использовать тег <iframe>, так как поисковый робот Яндекса не индексирует документы, подгружаемые в него.

Год назад пытался сделать что-то подобное, дальше песочницы статья не прошла (, однако сам vdi файлик вполне можно скачивать и использовать )

Еще фееричный момент mail.ru:
сочетание ">0<" заменяется на полный текст письма. Правится заменой на "> 0 <".
Пример: «Скидка: 0 руб.» в интерфейсе mail.ru отображается как
«Скидка: Скидка: 0 руб. руб.»

Спасибо! Поправили.

Имею отношение к разработке этого проекта. Буду благодарен за любые сообщение о багах, глюках. Постараюсь ответить на любые вопросы.

http://www.kuzpress.ru/data_url.html

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