Инверсия зависимостей и 'import' в JS

Карма меньше -30 накладывает ограничение на количество комментариев в сутки, а не на количество букв в комментарии. Могли бы и раскрыть свою мысль, если она у вас вдруг возникла.

Зависимости на уровне исходников (кто кого подключает) и зависимости на уровне компонентов (кто кого использует) – разное.

Первое решается import'ами, второе – конструкторами с параметрами, сеттерами, DI-контейнерами и так далее.

И вполне обычная практика для выбора зависимости компонента – подключить (в использующем компонент модуле) несколько модулей и выбрать по каким-то условиям.

Согласен. Однако, я имел ввиду именно обычный класс, не абстрактный. Как по мне, абстракция - это все-таки о дизайне класса/модуля. Обычный класс вполне может быть замечательной абстракцией. В пример могу привести репозиторий, внутри методов которого реализуется кэширование. Когда мы вызываем какой-нибудь метод, нам главное то, что он сохраняет/возвращает сущность. Мы не должны знать о том, что помимо БД, он обращается и в кэш. И совсем не обязательно, чтобы этот репозиторий имплементил интерфейс или абстрактный класс.

Неймспейсы:

В коде, мы объявляем неймспейс, для краткости используем в качестве имени `$`.
Внутри него экспортируем функцию, класс, переменную и т.п.

namespace $ {
  export function $log( this: $, ... params: unknown[] ) {
    console.log( ... params )
  }
}

В рантайме, у будет объект $ , а в нем функция $.$log

То есть тайпскирпт скомпилирует код выше, в такой JS:

var $;
(function ($) {
    function $log(...params) {
        console.log(...params);
    }
    $.$log = $log;
})($ || ($ = {}));

Получается, что $ это контейнер(или контекст), хранящий все наши сущности. Для того что бы в него что-то положить, это что-то надо экспортировать из неймспейса.

Заметьте, у функции $log типизирован this это значит, что тайпскирт не даст нам вызвать эту функцию так: $log() , а необходимо вызывать ее в контексте контейнера $.$log()

Также нам нужен механизм для переопределния сущностей. Вот один из варинтов:

namespace $ {
  export function $ambient(this: $ , overrides: Partial<$>): $ {
    return Object.setPrototypeOf(overrides, this)
  }
}

В статье по ссылке, более сложное переопределение, покрывающее большее количество кейсов

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

namespace $ {
  export function $hello(this: $) {
    this.$log('Hello user!')
  }
}

Мы пишем тест, проверяющий что эта функция выводит именно строку "Hello user!"

namespace $ {
  export function $test() {
    const logs:string[] = []
    // функция $ambiet получает текущий объект-контейнер в this
    // мержит в него переданный нами объект
    // в котором подменена функция $log
    const ctx =  $.$ambient({
      $log: (str) => { logs.push(str) },
    })
    ctx.$hello() // Вызывает $hello в измененом контексте
    if (logs[0] !== 'Hello user!') throw new Error('Wrong message')
  }
}

Для классов история примерно такая же. Только дополнительно нужен базовый класс реализующий работу с контекстом(контейнером) и от него необходимо наследовать классы.

Авторегистрация:
1) мы просто экспортируем сущность из неймспейса, тайпскрипт положит ее в глобальный объект. В функциях обращаемся к другим сущностям через this.$имя или $.$имя . В классах обращаемся через this.$.$имя .
2) Нам не нужно знать про "property based injection", "constructor based injection" и т.п. Просто обращаемся к сущностям как описано в пункте 1, у всех зависимостей, автоматически, всегда, будет значение по умолчанию. А где нужно, переопределяем нужные сущности в объекте-контейнере перед вызовом функции или при инстанцировании класса. И конечно, нет необходимости везде безусловно использовать обращения к сущностям через контекст, обычно только там где код образается к базе данных, к local storage, или что-то пишет в консоль / файл и т.п.

FQN:
1) FQN стоит рассматривать как альтернативу импортам/экспортам. Вместо того, что бы импортировать какой-то модуль/функцию/класс, мы просто обращаемся к нему по имени, а имя его состоит из пути до него в файловой системе. Например, у нас по пути app/user/model лежит модель юзера. В коде, который ее использует, мы обращаемся к ней "напрямую" $app_user_model без предварительных импортов. Т.е. когда мы что-то объявляем, в имени этой сущности указывается путь до нее. Директории разделяются знаком подчеркивания, а знак доллара - это маркер, говорящий о том, что это FQN имя.
2) Как можно заметить в этом "di на неймспейсах", у нас все сущности свалены в один объект, нужны какие-то ограничения на имена, что бы небыло случайных переопределий, конфликтов, или чего-то еще, что там может случится. FQN с этой задачей полностью справляется.
3) Хоть это и альтернатива импортам/экспортам, но используется слово "export", т.к. мы ограничены реалиями, в данном случае тайпскриптом. Кажется в PHP есть похожая концепция.
4) Можно сказать еще про личный опыт, в виде погружения в достаточно большую кодовую базу. При использовании FQN это легче, потому что с одного взгляда понятно откуда какая зависимость и где ее искать.
5) Еще чуть-чуть: если имя слишком длинное, то можно использовать локальный алиас, где-нибудь вверху, так же как импорт `const model = $app_user_model`; длинные имена заставляют больше задумывать над именованием и расположением файлов в фс (привет DDD). Есть обратная сторона: для сокращения имени, могут использовать не общепринятые слова, а их более короткие синонимы, не всегда понятно что означает слово.

Минусы:

1) При использовании такого подхода на фронте(если мы заботимся о размере бандла) - в каждом файле с неймспейсом нужно писать специальную директиву для тайпскрипта, что бы он знал, что этот файл тоже надо включать в бандл. Иначе можо сбилдить только весь код целиком, что не всегда нужно. Это может стать проблемой например, если используется модульная система типа MAM, где рядом может лежать много проектов использующих общие модули или друг друга в качестве зависимостей, и мы не хотим класть в бандл вообще все. Или когда бандлы собираются постранично. Придется мириться с директивами, либо настраивать вебпак / свой сборщик / тришейкер. В MAM свой сборщик.
2)Еще, что бы перевести какой-то существующий проект на такой подход, нужно досаточно много усилий, с точки зрения переписывания кода. Хотя в теории и перевод проекта на другие подходы, тоже может быть затратен.
3) А также не просто ощутить / понять / объяснить преимущества этого на другими подходами. Т.к. все привыкли к чему-то "Inversify"подобному подходу, который скопирован с подхода в java, где других вариантов не было.(тут могу ошибаться, мб поправит кто-нибудь)
4) NPM-пакеты подключаются сложнее, т.к. они заточены на импорты/экспорты.

Итог:
Этот подход в описаном выше виде используется в $mol , думаю его можно реализовать и как-то по другому. Если интересно подробнее разобраться, то наверно лучше в телеге , там больше людей и лучше, чем я смогут помочь, т.к. я сам во всем этом еще разбираюсь.
Еще есть краткое сравнение разных подходов

И вообще, замечаю проблему с объяснением каких то идей из этого фреймворка, который нельзя называть, с тем что практически любая из-них связана с еще несколькими, и что бы объяснить одну, нужно какое-то понимание других и так по кругу. В довесок к этому, сами идеи / концепции мало где используются и не привычные, и первое что хочется - это просто отвергнуть и не тратить время, на какие странные вещи.

Трудно понять эту боль, когда давно используешь TypeScript + TypeDI

Да, потому что, второе очень часто работает в контексте первого. Высокоуровневые компоненты декларируют контракты (это инверсия), а что-то должно этим контрактам сопоставлять реальные объекты (это внедрение). Второе базируется на первом (но может и не базироваться, если в приложении внедрение зависимостей есть, а инверсии нет).

Инверсия зависимостей стала популярной благодаря SOLID. Но частота ее упоминаний довольно слабо кореллирует с частотой использования конкретно в программировании. Это точно не самый распространенный программистский прием на практике (впрочем, как и весь солид).

Пример зависимости без инверсии из реальной жизни это, например, прокат автомобилей (ну или любой другой сервис из сферы массового обслуживания). Тысячи клиентов, скрипя зубами, подписывают типовые контракты в том виде, в котором их предлагает провайдер услуги, покорно соглашаясь на все их драконовские условия.

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

Если же вы относитесь к тем немногим счастливчикам, для кого деньги не главное, то инверсия нередко приводит к появлению на стыке каких-то адаптеров - фирм-прокладок, берущих на себя ответственность за <strike>распил бабла</strike> поддержание должного уровня абстракции, согласованность контрактов, обеспечение специфических индивидуальных гарантий и нивелирование рисков.

Я скорее про опрос, потому что он звучит ультимативно

Разница в трактовке модулей хорошо видна на примере первого Angular.js (где, если вы помните, этот термин был использован в реализации собственного DI контейнера). Несколько лет тому назад на stackoverflow был популярен вопрос в чем разница между модулями Angular.js и ESM модулями и как их скрестить. Во второй версии они переименовали свои модули в компоненты и все на этом успокоились.