Комментарии 76
Рассмотренные здесь модули без импортов вполне соответствуют DI, и так кодить правильно, имхо. Насчёт SOLID - его 4 и 5 принципы к JS вообще никак не относятся: нет интерфейсов, говорить не о чем.
JS - "живой" язык, начиная с 2015 года обновления идут каждый год. Возможно, эта красота закончится через год или раньше, но пока так. Думаю, что некоторую имплементацию интерфейсов в него реально встроить в ближайшие год-два, если спрос на интерфейсы будет, разумеется.
Хотя даже на нынешнем уровне развития языка возможно использование интерфейсов в виде классов с пустыми методами:
/**
* @interface
*/
class IPerson {
/**
* @return {string}
*/
getFullName() {}
}
/**
* @implements IPerson
*/
class Person {
}
По Ctrl+I с курсором на 15-й строке IDEA выдает подсказку, какие методы нужно добавить для класса Person
, имплементирующего IPerson
:
Я бы не стал списывать со счетов 4-й и 5-й принципы SOLID даже для JS :)
Спасибо, что высказались за возможность существования es6-модулей с зависимостями, но без импортов.
4 и 5 принципы solid не имеют ни какого отношения к интерфейсам
Карма меньше -30 накладывает ограничение на количество комментариев в сутки, а не на количество букв в комментарии. Могли бы и раскрыть свою мысль, если она у вас вдруг возникла.
Могли бы и раскрыть свою мысль
Так а что тут раскрывать? Просто в формулировке Interface segregation и Dependency inversion самого Мартина ни чего нет про интерфейсы (сразу примечание: конечно же, "interface" в "interface segregation" это не те интерфейсы, которые в условной джаве, т.е. это не языковой механизм). Оно прекрасно работает как в языке с интерфейсами, так и в языке без них - это принципы объектно-ориентированного программирования.
Спасибо (y) esm_loaders
очень напоминает spl_autoload_register из PHP. Пусть пока и экспериментальный функционал, но само направление движения мне нравится. С import-map, похоже, frontend-only функционал. На Хабре есть статья - "Контролируем JavaScript импорты с помощью Import maps"
А наличие в коде es6-модулей импортов конкретных имплементаций "убивают" принцип инверсии зависимостей.
Как мне кажется, DI не обязательно должен использовать интерфейсы и абстракции. Ключевой принцип — что зависимости передаются снаружи:
let a = new A(x, y, z);
let b = new B(a);
В этом примере мы не используем интерфейсы (и не можем передать в new B()
что-то, кроме A
), но DI все равно нужно, так как позволяет нам произвольно сконфигурировать объект a
перед передачей в new B()
. Мы сами выбираем, что указать в x, y, z. Мы можем даже создать несколько объектов B с разной конфигурацией A.
В случае же с импортом объект сам находит и создает свои зависимости. И повлиять на их конфигурацию мы не можем. Без DI пример выше выглядит как:
let b = new B(); // B сам создает A и непонятно откуда берет x, y, z
Я вообще не очень понимаю, как можно обойтись без DI и как тут помогут импорты. Вот у вас объект B импортирует и создает объект A. А откуда возьмутся настройки для объекта A (то есть x, y, z)?
Это не значит, что импорты вообще не нужны. Они могут пригодиться для импорта функций-утилит.
Ключевой принцип — что зависимости передаются снаружи:
Совершенно верно.
Вот у вас объект B импортирует и создает объект A. А откуда возьмутся настройки для объекта A (то есть x, y, z)?
Если продолжить аналогию с B, который импортирует и создаёт A, то A также импортирует и создаёт x, y, z. Но в случае с импортами такая связь получается жёсткой - всегда импортируются одни и те же модули для A, x, y, z.
Если только не применяются механизмы esm_loader и import-maps, на которые дал ссылки коллега @dynamicult чуть выше. В этом случае сам JS-движок выступает своего рода DI-контейнером и способен подменять одни es6-модули другими на уровне импортов.
Но что-то мне кажется, что такой подход (с подменой на уровне импортов) нарушает "правило наименьшего удивления", потому что одного исходного кода es6-модуля с импортами становится недостаточно для понимания логики работы - нужна ещё карта импортов или стандартизация логики работы esm_loader'а (как это сделали в PHP). В общем, esm_loader и import-maps - это заявка на переход от физической адресации es6-модулей к логической (движение в сторону появления namespace'ов в JS).
Они могут пригодиться для импорта функций-утилит.
Совершенно верно, в PHP остались include и require и иногда их даже используют.
Зависимости на уровне исходников (кто кого подключает) и зависимости на уровне компонентов (кто кого использует) – разное.
Первое решается import'ами, второе – конструкторами с параметрами, сеттерами, DI-контейнерами и так далее.
И вполне обычная практика для выбора зависимости компонента – подключить (в использующем компонент модуле) несколько модулей и выбрать по каким-то условиям.
Правильно. И если на уровне используемого компонента решение о том, какие зависимости подключать, не принимается, то никаких импортов в нём и не требуется. Остаётся голый конструктор с возможностью запихнуть нужные зависимости:
// file './scr/DiCompatible.js
export class DiCompatible {
constructor(dep1, dep2, dep3) {...}
...
}
Т.е., у нас есть es6-модуль с зависимостями и без импортов. Потому что это зависимости уровня выполнения (компонентов), а не зависимости уровня сборки (исходников). Каким образом в него внедряются зависимости (через DI-контейнер или вручную) - за то разработчик ./DiCompatible.js
волноваться не должен.
И если на уровне используемого компонента решение о том, какие зависимости подключать, не принимается, то никаких импортов в нём и не требуется.
Угу. За возможным исключением типов данных для зависимостей (актуально для ts, но в js-то нет статической типизации). Например, интерфейс IFooer описан в модуле A, несколько его реализаций в модулях C и D, а используется он в E и F – так подключить его придётся во все четыре. А в js модуля A может вообще не быть.
ЗЫ: лично я, конечно, предпочту иметь статическую типизацию, я в своей жизни наелся такого, что кто-то из коллег что-то чуть-чуть поменял, и сломалось в неочевидном месте.
В JS есть возможность использовать JSDoc annotations для описания типов ожидаемых параметров. Не совсем то же самое, что стат. типизация, но кое-что похожее. Мне хватает, у меня IDEA.
export class DiCompatible {
/**
* @param {SimpleClass} dep1
* @param {Namespace.NestedClass} dep2
* @param {InterfaceFromJSDoc} dep3
*/
constructor(dep1, dep2, dep3) {...}
}
актуально для ts ... так подключить его придётся во все четыре. А в js модуля A может вообще не быть.
Да, но я-то на JS пишу, у меня такой проблемы нет. Нет модуля А - нет проблемы.
Всё-таки абстракции - это не только интерфейс ы. Почему класс не может быть абстракцией?
Может. Это лишь вопрос восприятия и терминологии. "Интерфейс" - абстрактен по своей сути. Встречая в разговоре слово "интерфейс" мы сразу же понимаем, что речь идёт о некотором уровне абстракции. В случае с классом нам нужно добавлять "абстрактный", чтобы понять то же самое. В Java есть abstract class и interface, там терминология закреплена на уровне языка. В JS такого нет, приходится вводить собственные, внутрипроектные договорённости. Например, класс IPerson
- полностью абстрактный класс (интерфейс), а APerson
- класс с частичной абстракцией на уровне методов. Но лучше использовать JSDoc-аннотации для этого или TypeScript (там интерфейсы и абстрактные классы тоже есть на уровне языка).
Согласен. Однако, я имел ввиду именно обычный класс, не абстрактный. Как по мне, абстракция - это все-таки о дизайне класса/модуля. Обычный класс вполне может быть замечательной абстракцией. В пример могу привести репозиторий, внутри методов которого реализуется кэширование. Когда мы вызываем какой-нибудь метод, нам главное то, что он сохраняет/возвращает сущность. Мы не должны знать о том, что помимо БД, он обращается и в кэш. И совсем не обязательно, чтобы этот репозиторий имплементил интерфейс или абстрактный класс.
Возможно вас заинтересует эта статья: https://habr.com/ru/post/541800/. Кратко суть:
- вместо импортов/экспортов используются неймспейсы
- по сути в данном случае, неймспейс - это способ авторегистрации объявляемой сущности в глобальном объекте - контейнере
- с помощью небольшого хелпера, мы можем переопределять сущности в этом контейнере, т.е.
- функции вызываются в контексте этого глобального_объекта-контейнера (если нужно с переопределенными сущностями), т.е. через this
.
- для классов создается базовый класс, от которого надо наследоваться. В методах класса обращаемся к сущностям через this.$.*
- this.$.log()
- там еще используется именование через подчеркивания, это отчасти другая история не связанная с темой (суть: что бы в html/css/js сущности имели одинаковое имя, для поиска / реплейса и т.д.)
- второй момент с подчеркиванием, там юзается Fully Qualified Names . Опять же кратко: в названиее сущности отражается ее местоположение в файловой системе проекта. FQN имя начинается с доллара
Мне очень понравилась ваша "краткая суть" (namespaces, FQN, авторегистрация, местоположение в файловой системе) - это как раз то, чего мне не хватало в JS. Но, оказывается, я уже читал эту статью. Я просмотрел её ещё раз, но так и не понял, в какой момент происходит загрузка es6-модулей (преобразование FQN объекта в путь к файлу с исходником для него). Возможно, это из-за того, что там TS, а я его не понимаю на достаточном уровне, а возможно, она просто несколько не о том.
Неймспейсы:
В коде, мы объявляем неймспейс, для краткости используем в качестве имени `$`.
Внутри него экспортируем функцию, класс, переменную и т.п.
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 , думаю его можно реализовать и как-то по другому. Если интересно подробнее разобраться, то наверно лучше в телеге , там больше людей и лучше, чем я смогут помочь, т.к. я сам во всем этом еще разбираюсь.
Еще есть краткое сравнение разных подходов
И вообще, замечаю проблему с объяснением каких то идей из этого фреймворка, который нельзя называть, с тем что практически любая из-них связана с еще несколькими, и что бы объяснить одну, нужно какое-то понимание других и так по кругу. В довесок к этому, сами идеи / концепции мало где используются и не привычные, и первое что хочется - это просто отвергнуть и не тратить время, на какие странные вещи.
мы просто экспортируем сущность из неймспейса, тайпскрипт положит ее в глобальный объект.
Да, теперь понятно, как устанавливаются связи.
Иначе можно сбилдить только весь код целиком, что не всегда нужно
Вот у меня как раз другой подход - разбивать код на отдельные es6-модули и затягивать на фронт только те, что используются по факту (на бэке это и так есть). Тут другой минус: много мелких модулей - много обращений к серверу. Можно кэшировать, это смягчает проблему. Или "инсталлировать" - при старте приложения закачивать все модули в кэш браузера (аналог "сбилдить весь код целиком").
Спасибо за подробное объяснение, но для меня у $mol есть фатальный значимый недостаток - он на TS. Я очень плохо перевариваю транспиляторы (включая бандлеры), даже аппетит пропадает. К тому же у вас $mol заточен, насколько я понял, под фронт (на бандлы), а мне же больше видится единое "фронт-бэк" решение, с кодом, разделяемым между сервером и браузером (те же DTO).
Я не стремлюсь сделать популярное решение, я стремлюсь сделать решение, удобное прежде всего для меня. А мне удобно иметь код, который я могу использовать без изменений как в браузере, так и на сервере.
Ещё раз спасибо за подробный коммент и ваше время.
а мне же больше видится единое "фронт-бэк" решение, с кодом, разделяемым между сервером и браузером
Полностью разделяю такой подход
К тому же у вас $mol заточен, насколько я понял, под фронт (на бандлы)
Да бандлы есть, но сам он - это просто набор маленьких изоморфных модулей, хорошо состыкованых друг с другом, которые можно использовать и на сервере, и на фронте. Выделеное ядро отсутствует.
Спасибо за ответы.
Я несколько раз перечитал вашу статью, но так и не смог понять, в чем ваша боль. Могут ли быть модули без импортов? Да, конечно.
В браузере возможно обойтись без импортов вообще, если зависимости берутся из глобальных объектов (если используются только методы из стандартной библиотеки). Но если используются библиотеки/фреймворки, нужен бандлер, а он будет собирать приложение, ориентируясь как раз при помощи импортов.
На Node.js вообще без импортов (или require) вряд ли получится, потому что здесь стандартная библиотека на модулях (в отличии от браузеров).
Если используется TS, то импорты нужны еще и для передачи типов. Так что если даже сама зависимость инжектируется, все еще нужно в модуль пробросить ее тип (иначе зачем TS?), для этого тоже нужен import.
Но, в итоге, система модулей (и import/export) это удобный способ структурирования кода, и зачем с этим бороться я не очень понимаю.
Моя "боль" - вот:
А наличие в коде es6-модулей импортов конкретных имплементаций "убивают" принцип инверсии зависимостей.
Но мне её "полечил" коллега @dynamicult своим esm_loader.
Я не борюсь с import'ом, в конце-концов, в JS нет другого механизма для загрузки модулей. Я просто проверяю свои наработки. В моих es6-модулях, не завязанных на nodejs, нет импортов и тем не менее, они подгружаются и связываются друг с другом как на фронте, так и на бэке. Мне комфортно программировать на JS (я дал в начале публикации ссылку на объяснение, почему так) и без import'ов. Вам - на TS и с import'ами.
Ну и опрос, опять же :)
Трудно понять эту боль, когда давно используешь TypeScript + TypeDI
Попробую объяснить. У вас есть интерфейс IPerson:
export default interface IPerson {
getFullName(): string;
}
и две имплементации:
export default class Fbi implements IPerson {
firstName: string;
lastName: string;
constructor(first: string, last: string) {
this.firstName = first;
this.lastName = last;
}
getFullName(): string {
return `${this.firstName} ${this.lastName}`;
}
}
export default class Kgb implements IPerson {
firstName: string;
lastName: string;
constructor(first: string, last: string) {
this.firstName = first;
this.lastName = last;
}
getFullName(): string {
return `${this.lastName} ${this.firstName}`;
}
}
Вся разница у них, что первая для getFullName()
выводит имя как "Alex Gusev", а вторая - как "Gusev Alex".
Есть учётная карточка персонала с именем и званием:
export default class Card {
person: IPerson;
rank: string;
constructor(person: IPerson, rank: string) {
this.person = person;
this.rank = rank;
}
getName(): string {
return `${this.person.getFullName()}: ${this.rank}`;
}
}
В соответствии с принципом инверсии зависимостей Card
зависит от абстракции (интерфейс IPerson
), а не от деталей (Fbi
или Kgb
). И решение о том, какую имплементацию подключать в каком случае, принимается не на уровне Card
.
На уровне Card
нет импорта ни Fbi
, ни Kgb
.
Окей, но в точке (т.е. в модуле) где создается Card
и принимается решение о том, какую имплементацию использовать - Fbi
или Kgb
- уже будет импорт трёх данных сущностей. Или мы должны пойти дальше, и импотировать все классы (а также функции, константы, внешние зависимости из npm-пакетов, svg на фронтенде и пр.) в некий клобальный entity-локатор, и оттуда раздавать по требованию?
А наличие в коде es6-модулей импортов конкретных имплементаций "убивают" принцип инверсии зависимостей.
Если импорт Fbi
и Kgb
будет внутри Card
, то да. Но если в точке, где создается Card
, то нет. Или вы предлагаете возвести инверсию в абсолют, и принимать решение обо всех деталях реализации на самом верхнет уровне - то есть, в конфигурации вне приложения, которая поключается к нему на лету во время запуска?
В таком случае будет нарушен основополагающий принцип инженерной деятельности - инкапсуляция. Не говоря уже о том, что понять как работает приложение, будет невозможно из-за динамичности абсолютно всех деталей.
уже будет импорт трёх данных сущностей.
Или двух, если решение "захардкожено". Например, на уровне KgbCardsFactory
.
Или мы должны пойти дальше, и импотировать все классы (а также функции, константы, внешние зависимости из npm-пакетов, svg на фронтенде и пр.) в некий клобальный entity-локатор, и оттуда раздавать по требованию?
Примерно так и работают Dependency Injection контейнеры. Тот же TypeDI. Вы в своей реплике слегка драматизировали, загнав в "некий глобальный entity-локатор" совсем всё, но "кое-что нужное" DI-контейнер импортирует и раздаёт по требованию. Всё верно.
Если импорт Fbi и Kgb будет внутри Card , то да.
Вот за этот случай я и говорю.
Или вы предлагаете возвести инверсию в абсолют
Нет.
Не говоря уже о том, что понять как работает приложение, будет невозможно из-за динамичности абсолютно всех деталей.
В других языках как-то справляются.
В других языках как-то справляются.
Вряд ли стоит апеллировать к другим языкам, поскольку в разных экосистемах принято по-разному решать разные проблемы. К примеру, в некоторых языках есть опционалы, а в некоторых - перегружаемые операторы. Но вы почему-то не топите за их включение в JS, вам не нравится именно модульная система в JS.
Но ваш подход - вне сомнения - имеет полное право на жизнь (как и любой другой подход). Единственное, использовать его в проде - вряд ли обдуманное решение, поскольку такой код будет трудно ревьювить; плюс, если с проекта уйдут ключевые разработчики (т.е. вы и те кто знаком с подходом), то новоприбывшим будет очень трудно разобраться как все устроено.
Ну и простите моё любопытство, но вот, если мы к примеру пишем приложение в чисто функциональном стиле (функции высшего порядка, каррирование и декорирование функций, никаких классов) - то как в данном случае распространять зависимости (импортированные в DI контейнер) по приложению? Можно небольшой пример, или хотя бы концептуально на словах? Спасибо.
Я не силён в функциональном программировании, но попробую.
DI-контейнер оперирует es6-модулями и export
'ами внутри этих модулей. Я сделал ветку для демо, каким образом инжектить функции внутрь других функций. Все es6-модули внутри этой демки находятся в пространстве имён Demo
. Основной файл (./src/main.mjs
) импортирует контейнер и настраивает маппинг имён на файлы. Это единственный файл проекта, в котором используется import
, все остальные es6-модули загружаются через DI.
default export
модуля имеет идентификатор Vnd_Mod#
(#
в конце). Для такого идентификатора контейнер вернёт саму функцию, которая соответствует default export
'у. Если указать идентификатор Vnd_Mod$$
($$
в конце), то контейнер вернёт результат выполнения default export
'а, предоставив функции соответствующие зависимости, запрошенные через входной аргумент spec
. Так получаются фабричные функции, которые создают другие функции, которые сами могут быть зависимостями:
export default function Factory(spec) {
/** @type {Function|Demo_Other_Card.fnCard} */
const card = spec['Demo_Other_Card#Builder$'];
// ...
return function() { /* use 'card()' inside */ };
}
Если в конце стоит один $
, то контейнер при помощи фабрики создаст функцию при первом запросе соответствующего depId, а затем будет всегда возвращать этот же экземпляр (singleton).
Если у нас в es6-модуле экспортируется просто функция, а не фабричная функция, то её depId будет примерно такой 'Demo_Stuff_Lib#getRank
' . Контейнер просто вернёт соответствующий экспорт, как будто был применён статический импорт:
// внутрипакетный
import {getRank} from './Stuff/Lib.mjs'
// из других пакетов
import {getRank} from '@flancer64/habr_di_demo/src/Stuff/Lib.mjs'
Ну а дальше всё просто - у нас есть es6-модули с простыми функциями, эти функции мы используем в качестве зависимостей в фабриках для получения составных функций (использующих простые). И так по цепочке, пока не дойдём до начала.
Я ничего не понимаю в функциональном программировании (каррирование монады и всё такое), но это пример того, как в JS (ES6+) можно связывать простые функции в составные при помощи DI-контейнера.
Вполне возможно, что DI в функциональном программировании - это нонсенс. Но вы спросили - я ответил :)
Да нет, я понимаю что такое DI в обеих расшифровках, и для чего оно нужно. Боль в том, что в JavaScript нет интерфейсов?
Скорее, нет устоявшейся системы адресации кода без привязки к файловой системе (package в Java и namespace в PHP).
Но и это не боль. Задача данной статьи - получить отклик от коллег, насколько для них допустима мысль, что зависимости между различными es6-модулями не связаны напрямую с используемыми в них импортами. На данный момент 45% допускают подобный вариант, а 55% считают, что "если в es6-модуле есть зависимости, то должны быть и import'ы".
Просто в моём коде мало импортов, но много зависимостей и это может показаться кому-то странным. Но на самом деле это совершенно нормально. Как тут чуть ниже отметил коллега @funca это код "позднего связывания" - динамического, а не статического. Так что эта статья для них - тех, кому не хватает импортов в моём коде.
В начале статьи вы упомянули, что не стоит путать архитектурный принцип Dependency Inversion из SOLID с техникой программирования Dependency Injection (которая суть частный случай техники Inversion of Control). Но вся статья как будто бы про второе.
Здравый смысл говорит нам о том, что слои более низкого уровня не должны ни чего знать о слоях более высокого. База данных ни чего не знает про бизнес логику, бизнес логика не имеет понятия о UI и т.п. Когда вы заказываете пиццу, то повар который её готовит, не имеет ни малейшего представления ни о вашем существовании, ни о ваших вкусовых пристрастиях (равно как и тысяч других каких же как вы клиентов). Следование этому принципу позволяет повторно использовать низкоуровневые компоненты в абсолютно разных задачах. Но с другой стороны, в таком случае, высокоуровневые компоненты вынуждены подстраиваться под все условия низкоуровневых, что делает их практически незаменимыми. А ведь часто хочется пиццу, приготовленную на свой вкус. Чтобы этого избежать, можно сделать все наоборот: высокоуровневая система абстрактно описывает свои требования (в виде договора на своих условиях, регламента, контракта, критериев, интерфейса и т.п) и предлагает низкоуровневой системе его реализовать. В таком случае заменить низкоуровневую систему не составит проблем, ведь контракт был на стороне высокоуровневой и он остался прежним. Так появляется та самая инверсия в направлении зависимостей (Dependency Inversion). На практике используются в основном прямые зависимости внутри, а инвертированные лишь на границах систем, иначе дополнительные издержки, связанные с разработкой и поддержкой такой бюрократии себя не окупают.
Внедрение зависимостей (Dependency Injection) решает другую проблему, а именно разделение ответственности за жизненный цикл объекта (создание, хранение, удаление) и его использование. Обычно клиент хочет только использовать, а остальные такие заморочки ему ни к чему. Все техники сводится к разным вариантам позднего связывания, когда клиент получает свои зависимости только в рантайме, а управляет жизненным циклом кто-то другой.
Основная идея, во круг которой строилась спецификация для ESM модулей, была напротив возможность выражать связи в коде статически - чтобы все зависимости можно было проследить чисто по тексту, без запуска программы. Благодаря этому, например, довольно правдоподобно работает автокомплит в ide, линтеры могут сообщать об ошибках непосредственно при редактировании, а сборщики - исключать из бандлов неиспользуемый код. Позднее связывание тоже поддерживается (функция import), но в целом ее использование идёт в разрез основной идее.
Думаю отказываться от импорта, означает лишать себя многих полезных вещей, связанных со статическим анализом кода. Однако пренебрегать поздним связыванием тоже не стоит. Хотя, управление жизненным циклом объектов это вряд-ли та задача, которую стоит решать на уровне ESM. Решение инженерных задач всегда содержит в себе компромиссы. PHP и JS идут немного разными путями потому, что их создатели по-разному ставят приоритеты. Но в целом, пробовать таскать разные идеи туда-сюда, может быть даже если и не полезно, то крайне увлекательно
Но вся статья как будто бы про второе.
Да, потому что, второе очень часто работает в контексте первого. Высокоуровневые компоненты декларируют контракты (это инверсия), а что-то должно этим контрактам сопоставлять реальные объекты (это внедрение). Второе базируется на первом (но может и не базироваться, если в приложении внедрение зависимостей есть, а инверсии нет).
Основная идея, вокруг которой строилась спецификация для ESM модулей, была напротив возможность выражать связи в коде статически
Вот! Поэтому и возникает конфликт статических import'ов с динамическим "поздним связыванием". А у динамического import'а с динамическим "поздним связыванием" такого конфликта нет. И esm_loader & import maps как раз и пытаются добавить динамики (а заодно и порушить автокомплит в IDE и стат. анализаторы кода). В общем, тут пришили, там отвалилось.
PHP и JS идут немного разными путями
Но к очень похожим целям. PHP всегда был "серверным" языком, а на JS очень сильно влияет "браузерность". composer появился позже npm (2012 vs 2010), но "пакеты" в PHP были с 1999-го года (PEAR), так что у PHP community более богатый опыт в "групповой" разработке. В той же Magento 2, написанной на PHP, порядка 3.4 млн. строк кода (32% - комменты) и 590 тыс. классов. И это только сама платформа, без зависимостей и расширений (я в курсе размеров node_modules, но в нём разные проекты, а не один). В общем, сопоставляя опыт одних и других, действительно приходишь к выводу, что:
пробовать таскать разные идеи туда-сюда, может быть даже если и не полезно, то крайне увлекательно
Да, потому что, второе очень часто работает в контексте первого. Высокоуровневые компоненты декларируют контракты (это инверсия), а что-то должно этим контрактам сопоставлять реальные объекты (это внедрение). Второе базируется на первом (но может и не базироваться, если в приложении внедрение зависимостей есть, а инверсии нет).
Инверсия зависимостей стала популярной благодаря SOLID. Но частота ее упоминаний довольно слабо кореллирует с частотой использования конкретно в программировании. Это точно не самый распространенный программистский прием на практике (впрочем, как и весь солид).
Пример зависимости без инверсии из реальной жизни это, например, прокат автомобилей (ну или любой другой сервис из сферы массового обслуживания). Тысячи клиентов, скрипя зубами, подписывают типовые контракты в том виде, в котором их предлагает провайдер услуги, покорно соглашаясь на все их драконовские условия.
Инверсия выглядит как решение, но если вдуматься, то она требует индивидуального подхода, тщательной проработки юридических, экономических, технических и т.п. вопросов недешевыми специалистами. В общем будет крайне затратна для обоих сторон, что может свести всю экономику такой затеи глубоко в минуса.
Если же вы относитесь к тем немногим счастливчикам, для кого деньги не главное, то инверсия нередко приводит к появлению на стыке каких-то адаптеров - фирм-прокладок, берущих на себя ответственность за <strike>распил бабла</strike> поддержание должного уровня абстракции, согласованность контрактов, обеспечение специфических индивидуальных гарантий и нивелирование рисков.
Пример зависимости без инверсии из реальной жизни это, например, прокат автомобилей (ну или любой другой сервис из сферы массового обслуживания).
Вообще-то как раз наоборот - это хороший пример инверсии зависимости)
Т.к. требование к конфигурациии сервиса предъявляет его потребитель, а не: "ну дайте мне что-нибудь, что получилось".
Здорово вы всё расписали, больше бы таких комментариев на Хабре!
А как же KISS? Если есть необходимость подменять зависимости (в зависимости от настроек или для тестирования), то делаем DI, иначе не оверинженирим.
Я очень уважаю KISS. Эта статья как раз про первый случай.
Я скорее про опрос, потому что он звучит ультимативно
Вы меня озадачили :) Что ультимативного в вопросе "Допустимы ли es6-модули с зависимостями, но без импортов?" Даже если предположить варианты ответов "да" и "нет"?
Да, допустимы
Нет, не допустимы
Какой третий вариант ответа здесь мог бы быть? "Иногда допустимы" или "иногда не допустимы"? Мне кажется, они все покрываются первым вариантом - "да, допустимы". Поясните, пожалуйста, в чём вы видите ультимативность.
В том, что вопрос безусловный. То есть либо можно использовать импорты, либо нельзя совсем ни при каких условиях. Из вопроса не понятно, что речь идёт только про использование импортов в контексте DI.
Я не вижу этой ультимативности в вопросе: "Допустимы ли es6-модули с зависимостями, но без импортов?"
"Допустимый" как раз и означает "разрешённый, позволительный, приемлемый, терпимый". Тут прямо веет компромиссом.
IMHO, ультимативный вопрос звучал бы так: "Обязаны ли es6-модули с зависимостями иметь импорты?"
Полагаю, что ответ с отрицанием допустимости звучит несколько категорично "если в es6-модуле есть зависимости, то должны быть и import'ы". Но отрицание компромисса не может само быть компромиссом.
Полагаю, что KISS поддерживает как раз первый ответ - "es6-модуль без import'ов вполне себе рабочее решение"
Я не топлю за отказ от импортов. В JS это невозможно в принципе (если у нас больше одного файла в приложении). Я показываю вариант, когда можно (и нужно!) обходиться без статических импортов. Просто некоторые в комментах к статье, ссылку на которую я дал в начале, назвали подобный подход глупостью. Нет, это не глупость.
Что такое оправданная необходимость?
Тут просто - когда в JS-приложении связываются более одного es6-модуля или используются библиотеки nodejs, то без import'а не обойтись. А использовать статический или динамический import - то на выбор разработчиков. Я стараюсь использовать динамический, где это возможно.
Как видно уже из нескольких ваших статей и комментариев к ним, сообщество тяготеет к одному трактованию, вы — к кардинально отличному.
Возможно, я просто криво выражаю свои мысли.
Я недавно встретил такую расшифровку правила KISS - "Keep It Stupidly Simple". Она слегка меняет акценты в правиле, не меняя его сути. Не stupid делай simple, а делай stupidly simple. Я считаю, что убрать import'ы для es6-модулей, связываемых через DI-контейнер, как раз и есть случай "keep it stupidly simple". По крайней мере, некоторые коллеги глупостью это уже называли ;)
может быть, вы и правы, и ваш подход жизнеспособен.
Но отказываясь от индустриальных стандартов, вы добровольно отключаете себе ряд возможностей. Включая то, как люди, привыкшие к индустриальным стандартам, будут относиться к вашему стилю.
Мне кажется - проблема в том, что понятие модуля в разных языках разное. В es модулем является файл, но один файл далеко не всегда (скорее, почти никогда) представляется реализацией целого слоя приложения. Если, скажем, разделить приложение на несколько базовых уровней вроде транспортного, бизнес-логики и хранилища, то связи между ними как раз удобно и правильно реализовывать в виде абстракций и инверсии зависимостей. Но в рамках одного слоя, если требуется работа с конкретной базой данных, скажем, то инверсия уже не требуется - используем прямые импорты. При этом бизнес-логика будет работать с любыми видами хранилища через обобщенный интерфейс.
Это не какое-то строгое правило, и подход применим и к более мелким частям приложения, можно ограничить их пространствами имен или макро-модулями (называйте как хотите), вопрос лишь в потребности. Если есть необходимость использовать различные реализации - используем инверсию, и, как правило, инъекцию. Если же такое потребности нет, то зачем усложнять жизнь себе и тем, кто будет читать код? Собственно, мой вопрос состоит в том - почему вы хотите отделить один прием от другого, если они не противоречат друг-другу? Или я неверно вас понял?
Я не противопоставляю. Я показываю вариант, когда es6-модуль без импортов, но с зависимостями не является такой уж глупостью. Вы правы, что оба варианта имеют право на существование в рамках одного приложения.
Разница в трактовке модулей хорошо видна на примере первого Angular.js (где, если вы помните, этот термин был использован в реализации собственного DI контейнера). Несколько лет тому назад на stackoverflow был популярен вопрос в чем разница между модулями Angular.js и ESM модулями и как их скрестить. Во второй версии они переименовали свои модули в компоненты и все на этом успокоились.
я прихожу к выводу, что при декларации классов/функций, зависящих от абстракций, в es6-модулях не должны использоваться import'ы, т.к. они привязаны к конкретным имплементациям (файлам — es6-модулям). Поэтому в приложениях, в которых соблюдается принцип инверсии зависимостей, допустимы es6-модули в которых полностью отсутствуют импорты,
Я так и не понял, к какому конкретно выводу вы пришли. Процитированное выше позволяет два толкования:
- модули без импортов — обязательны, т.е. все модули должны получать абсолютно все зависимости исключительно через DI. Используешь внутри
JSON.stringify()
? Это зависимость, получи её через DI, вдруг кто-то замокать захочет; - модули без импортов — просто допустимы, т.е. если модуль хочет абстракций — использует DI, если ему нужна конкретная имплементация — использует
import
илиglobal
, получилось без них — молодец.
Однако со вторым никто вроде и не спорит, никто никого не обязывает использовать импорты под пистолетом. Если это ваш главный вывод, то статья и опрос ни о чём.
Вот видите, какой вы молодец! Для вас очевидно, что импорты в es6-модулях не обязательны. А вот по результатам опроса 60% считают наоборот.
Так что насчёт "не должны использоваться import'ы"? Вообще никогда не должны, или когда-то можно?
Ну, скажем, возьмём какой-нибудь первый попавшийся пакет вроде uuid
. Этот пакет зависит от ГСЧ, который в браузере берётся из global.crypto
, а в ноде — через import "crypto"
. Как по-вашему, должен ли был автор делать ГСЧ абстрактной зависимостью, чтобы пользователи сами искали и подсовывали нужный ГСЧ через DI?
при декларации классов/функций, зависящих от абстракций, в es6-модулях не должны использоваться import'ы
Я ответил на ваш вопрос?
ГСЧ, используемый для генерации UUIDов — это абстракция?
А что там в коде? По коду же обычно видно - абстракция или конкретика.
В модуле uuid
нету своего кода ГСЧ, берётся внешний — значит это вроде абстракция, нужно передавать через конструктор? В другом модуле нет своего кода JSON.parse()
, берётся внешний — значит это тоже абстракция, тоже передавать через конструктор?
значит это вроде абстракция
Вроде или абстракция? Не всякая внешняя зависимость - абстракция. Некоторые вполне себе конкретные имплементации. Вы сталкивались когда-нибудь с интерфейсами и абстрактными классами?
Вроде или абстракция?
Я же не знаю, что вы лично называете абстракцией. Термин "абстракция" — это абстракция :) Он зависит от того, где проведена граница, при этом каждый проводит границу сам, и границы, проведенные разными людьми, могут не совпасть. Например, я могу назвать абстракцией любой компонент, исходный код которого контролирую не я. Тогда абсолютно любая функция, определённая вне модуля — это абстракция, со своим абстрактным интерфейсом вызова.
Не всякая внешняя зависимость — абстракция. Некоторые вполне себе конкретные имплементации.
Я и пытаюсь добиться от вас ответа, где провести границу, и насколько далеко вы хотите зайти в отказе от импортов и использования глобальных API. Вы пока что предпочитаете от ответа уходить, отвечая вопросами на вопросы.
Мне кажется, вы упустили, что статья называется "Инверсия зависимостей и 'import' в JS". Если вы определили в качестве зависимости некий интерфейс и не предполагаете, что за имплементация к вам попадёт (в этом и есть суть "Инверсии зависимостей"), то у вас, в общем случае, в принципе нет понимания, что за модуль этот интерфейс будет имплементировать и как он попадёт в ваш код. Всё, что от вас требуется - предоставить механизм внедрения (конструктор или сеттер).
и использования глобальных API
А это-то тут причём? Это ваша собственная придумка с JSON.parse() и она отношения к инверсии зависимостей не имеет.
Я и пытаюсь добиться от вас ответа, где провести границу,
Где удобно лично вам в соответствии с особенностями вашего проекта.
и насколько далеко вы хотите зайти в отказе от импортов
В своем коде я отказался от импортов своих собственных es6-модулей на 99%. Импортируется только DI-контейнер, всё остальное тянется через него. Разумеется, импорты в nodejs-части кода остаются (nodejs API и прочие npm-пакеты), в браузерной части кода импортов нет (за исключением DI-контейнера, опять же), т.к. мои модули тянутся через DI, а внешние библиотеки подключаются в globals в HTML:
<script type="application/javascript" src="./src/vue/vue.global.prod.js"></script>
и доступны в DI-контейнере через соответствующий класс-обёртку.
Но это совсем не значит, что вы тоже должны так делать. Если вы не понимаете суть принципа инверсии зависимостей, то отказ от import'ов нанесёт вам больше вреда, чем вы получите пользы. Более того, используя мой подход, вы не сможете создавать "классические" web-приложения и писать на TypeScript. Он подходит только для PWA и ESNext. У моего подхода достаточно специфическая область применимости и, чтобы его использовать, нужно осознавать границы этой области.
export default class Fl64_Habr_Vue_Front_App {
constructor(spec) {
this.#config = spec['TeqFw_Web_Front_Model_Config$'];
this.#container = spec['TeqFw_Di_Shared_Container$'];
...
}
}
Откуда пользователь узнает строки вроде "Fl64_Habr_Vue_Front_App$" или "TeqFw_Web_Front_Model_Config$", не заглядывая в имплементацию, в справочник по синтаксису, и без подсказки IDE?
Что будет, если класс переименовать/переместить? Бегать менять строки везде?
Как я понимаю, суффиксы вроде "#", "$" и "$$" указывают на способ получения зависимости из контейнера — т.е. это фактически неявный интерфейс доступа к контейнеру, закодированный в строках. По сути скрытый ServiceLocator.
По ссылке на прошлый пост прочитал про этот spec
:
Прокси-объект, через который DI-контейнер определяет, какую зависимость запрашивает конструктор. Контейнер по идентификатору находит исходник для зависимости и импортирует модуль
Ну так я и думал — это 100% ServiceLocator, с прокидыванием локатора в каждый конструктор, только вместо явного require("./путь/к/компоненте")
или container.get("путь_к_компоненте")
у вас неявный, через геттер. Т.е. каждый класс теперь имеет одну-единственную зависимость — от вашего прокси, — и сигнатура конструктора никак не раскрывает истинные зависимости. А то, что вызов конструктора может запустить цепочку долгих загрузок недостающих модулей — это вообще полный мрак.
Совершенно непонятно, почему нельзя использовать нормальный человеческий DI без этих странных телодвижений:
constructor(config, ...) {
this.#config = config;
...
}
Тоже никаких импортов, зато полная языковая поддержка при рефакторинге, и никаких скрытых локаторов. Даже с TypeScript импорты не нужны, если прописать типы в ambient declarations.
Откуда пользователь узнает строки вроде "Fl64_Habr_Vue_Front_App$" или "TeqFw_Web_Front_Model_Config$"
Вы абсолютно правы, пользователь должен знать, где находится код, который он собирается использовать в качестве зависимостей. И от способа наименования кода эта ситуация не меняется:
new com.sun.net.ssl.internal.ssl.Provider(); // java
new My_Long_NestedComponent_ClassName(); // PHP 5-
new \My\Long\NestedComponent\ClassName(); // PHP 5+
import ClassName from 'package/src/My/Long/NestedComponent/ClassName.js'; // js
Что будет, если класс переименовать/переместить? Бегать менять строки везде?
Именно так. То, что за вас это делает IDE не значит, что не нужно "менять строки везде". К тому же при замене подобных длинных имён замечательно работает Find/Replace. У меня нет проблем с рефакторингом, если вы об этом.
Как я понимаю, суффиксы вроде "#", "$" и "$$" указывают на способ получения зависимости из контейнера — т.е. это фактически неявный интерфейс доступа к контейнеру, закодированный в строках. По сути скрытый ServiceLocator.
Не совсем так. Вам никто не запрещает создавать объекты вручную:
import App from '@flancer64/habr_teqfw_vue/src/Front/App.mjs';
const config ={};
const app = new App({
['TeqFw_Web_Front_Model_Config$']: config,
...
}) ;
ну и где тут сервис-локатор? К тому же лично я не вижу ничего плохого в самом сервис-локаторе. Просто не употребляйте его там, где не нужно.
Т.е. каждый класс теперь имеет одну-единственную зависимость — от вашего прокси
Неверно. Выше я привёл код, который позволяет создавать объект вручную без всяких прокси.
и сигнатура конструктора никак не раскрывает истинные зависимости.
Кто понимает правила, тот видит зависимости. DI-контейнер, например, справлется.
А то, что вызов конструктора может запустить цепочку долгих загрузок недостающих модулей — это вообще полный мрак.
Так работает любой DI-контейнер.
Совершенно непонятно, почему нельзя использовать нормальный человеческий DI
Потому что в JS нет "нормальной человеческой рефлексии".
Даже с TypeScript импорты не нужны, если прописать типы в ambient declarations.
Я не пишу на TypeScript, т.к. я не использую транспиляторы и бандлеры.
Пользователь должен знать, где находится код, который он собирается использовать в качестве зависимостей.
Нет, класс Widget
, являющийся пользователем сервиса Logger
, совершенно не обязан знать, где находится код класса, реализующего этот сервис. Это должен знать DI-контейнер и только он. Widget
должен знать только публичный интерфейс логгера.
У меня нет проблем с рефакторингом, если вы об этом.
А с минификацией?
Вам никто не запрещает создавать объекты вручную… ну и где тут сервис-локатор?
То, что сервис-локатор имеет интерфейс хэшмапа не отменяет его присутствия. Вызов конструктора всё равно способен оказаться неожиданно долгим, с нетривиальнымы результатами.
Так работает любой DI-контейнер.
Вовсе нет, так работает только сервис-локатор (и SL не является DI, потому что он ничего никуда активно не "инжектирует", он пассивно выполняет запрос, в нем нет IoC).
Есть несколько причин почему SL считается мягко говоря спорной практикой:
- у всех появляется зависимость от SL. Как минимум, ваш SL накладывает ограничение на параметры конструктора, требуя передавать
spec
и толькоspec
; объекты которые не следуют паттерну (например, из чужих пакетов или встроенные), не могут пользоваться вашим механизмом. В DI такой проблемы нет — контейнер принципиально может сконструировать любой объект и скормить ему любой другой, no strings attached. - из-за SL конструктор внезапно получает дополнительную скрытую ответственность. В коде конструктора мы видим простую легковесную инициализацию членов, и ожидаем, что конструктор дёшев для вызова, что он может бросать только ошибки валидации. И в тестах с ручными хэшмапами оно так и есть — можно беззаботно создавать миллионы объектов в секунду.
В продакшине же вдруг внезапно оказывается, что там ещё появляется асинхронное общение с сетью, и конструктор может бросать ошибки сети, ошибки сервера, ошибки сериализации и чёрта лысого. И вызов тривиального конструктора может вылиться в целое приключение. Счастливой отладки.
В DI здорового человека вся чёрная и долгая работа — в контейнере — он загружает модули, обрабатывает ошибки. И только после того как всё необходимое загружено и готово — начинает строить граф зависимостей, вызывая конструкторы и фабрики в нужном порядке, и инжектируя в них нужные зависимости, уже готовые к использованию. Конструкторы же никогда в жизни не бросают ошибки, которые они не должны бросать, нарушая контракт (да-да, список исключений — это тоже часть контракта).
Потому что в JS нет "нормальной человеческой рефлексии".
А без неё совсем никак? В любом DI-контейнере есть стадия регистрации, где вы можете связать одни типы с другими, указать их жизненный цикл и проч. Рефлексия там не обязательна, хотя может помогать. Без неё будет чуть больше ручной работы, но всё это хотя бы будет локализовано в одном месте, а не навязано и распылено по всему коду. Как бонус, ваш composition root будет единственным источником истины. Разные композиции можно сохранять в файлах и выборочно загружать для разных условий.
Я не пишу на TypeScript
Ну вы в предыдущей статье спрашивали про возможность написать конструктор без import'ов. Так как любой код JS — это валидный код TS, то если это можно сделать в JS, то можно и в TS. Только информацию о типа нужно откуда-то взять, если не хочется получить any
на всё.
Нет, класс
Widget
, являющийся пользователем сервисаLogger
, совершенно не обязан знать...
ОК, я не так выразился. Я имел в виду местоположение класса в пространстве имён всех возможных классов проекта, что и продемонстрировал примером (в трёх из 4 вариантов используется как раз "логическая" адресация), но вы поняли по-своему (4-й вариант, но в JS нет namespace'ов, поэтому так). Пользователь должен знать, что собственно он собирается использовать в качестве зависимости - у меня это называется "идентификатор зависимости" и выглядит примерно так: TeqFw_Core_Shared_Logger$
. Вы совершенно правы, что потребитель зависимости не знает, где находится имплементация, поиск соответствующего файла делает DI-контейнер в соответствии со своими настройками.
А с минификацией?
А какое отношение имеет минификация к вашему начальному вопросу, на который я отвечал?
Что будет, если класс переименовать/переместить? Бегать менять строки везде?
У меня нет проблем с рефакторингом. И у меня нет минификации. Меня в первую очередь заботит, удобен ли код для отладки в браузере, и лишь затем - сколько места он там занимает и как долго он туда закачивается. Когда меня начнёт заботить минификация, я сделаю её на уровне раздачи статики web-сервером приложения при переводе его в production mode. Инструменты для этого есть - тот же uglify-js. Я использую кэширование на уровне Service Worker'ов, поэтому понадобится только однократная закачка нового кода на клиента (аналог инсталляции в десктопных приложениях). Но мне нравится, что вы расширяете охват оценки решения и выходите за рамки статьи.
То, что сервис-локатор имеет интерфейс хэшмапа не отменяет его присутствия.
Вы не поняли. При ручной сборке нет никакого DI-контейнера и сервис-локатора. Я оформляю свой код так, что он 100% совместим с обычным ручным импортом, созданием зависимостей и их внедрением. Да, в моих приложениях есть DI-контейнер (некоторые разделяют понятия DI-контейнер и сервис-локатор, но по сути любой DI-контейнер можно использовать как сервис-локатор, если заинжектить его в качестве зависимости), но 99% моего кода можно использовать без DI-контейнера. Правда вы замучаетесь вручную создавать и инжектить зависимости. Этим я ещё раз подчёркиваю, что у моих es6-модулей нет настоящей зависимости от моего контейнера. Да, вам будет неудобно использовать мои модули без моего контейнера, но с точки зрения архитектуры у меня всё ОК. Вы можете написать свой собственный "true" DI-контейнер, заложить в него граф зависимостей и он точно так же сможет использовать мои es6-модули без их переделки. Это должно быть понятно по коду модулей и я не буду больше повторять эту мысль.
Как минимум, ваш SL накладывает ограничение на параметры конструктора
Да, моё "вытягивание зависимостей" (если вам больше нравится точность формулировок) основано на определённом формате аргумента конструктора. Вы совершенно правы. Не любой объект может быть сконструирован моим контейнером.
из-за SL конструктор внезапно получает дополнительную скрытую ответственность.
Точно так. Но если вы о ней знаете, то она уже не скрытая.
В коде конструктора мы видим ..., и ожидаем ...
Да, мой подход не совпадает с вашим видением и ожиданием.
И вызов тривиального конструктора может вылиться в целое приключение.
Может. Вопрос, что вы получаете за эту плату.
В DI здорового человека вся чёрная и долгая работа — в контейнере — он загружает модули, обрабатывает ошибки. И только после того как всё необходимое загружено и готово — начинает строить граф зависимостей,
Получается, что для того, чтобы нарисовать в SPA логин-форму DI-контейнер "здорового человека" должен распарсить зависимости на всё приложение? А как быть с правами, которые выясняются уже после авторизации? Ведь по ним может оказаться, что у пользователя нет доступа к части функционала. Или DI-контейнер должен создаваться на каждый route в SPA?
Для backend'а такой DI подойдёт, а на фронте с ним будут проблемы.
А без неё совсем никак?
А без неё вот так - приходится вводить spec и отталкиваться от названий атрибутов spec'а.
В любом DI-контейнере есть стадия регистрации, где вы можете связать одни типы с другими, указать их жизненный цикл и проч.
Вы можете взять "любой DI-контейнер" и он сможет работать с моими es6-модулями. Нужно будет только "связать одни типы с другими, указать их жизненный цикл и проч." Вы же сами говорите, что "true" DI-контейнеры могут работать с любыми классами, значит смогут и с моими.
Свой контейнер я сделал под себя, мне с ним удобно вот так. И во многом потому, что мне не нравится делать "чуть больше ручной работы".
а не навязано и распылено по всему коду.
У меня как раз другая цель - размазать функционал по плагинам (npm-пакетам) и сделать их переиспользуемыми.
Ну вы в предыдущей статье спрашивали про возможность написать конструктор без import'ов.
Да, это были "размышления вслух". Я на днях опять попробовал TS и там всё ещё есть транспиляция. Поэтому я пока что останусь на JS.
А какое отношение имеет минификация к вашему начальному вопросу, на который я отвечал?
Минификаторы могут менять имена компонентов. Если ваш локатор парсит строки для поиска компонент по имени класса, то это может поломать его — как и при рефакторинге. Поиск/замена тут не помогут.
Получается, что для того, чтобы нарисовать в SPA логин-форму DI-контейнер "здорового человека" должен распарсить зависимости на всё приложение?
Распарсить зависимости на приложение он должен, чтобы запустить собственно приложение. Форма же не в воздухе висит? А когда придёт очередь формы — он распарсит зависимости для этой формы.
Минификаторы могут менять имена компонентов.
Очень сильно подозреваю, что могут и не менять - в зависимости от настроек. Вряд ли они меняют строковые константы и имена экспортов - а это всё, что нужно.
А когда придёт очередь ...
ну, значит я неправильно понял ваше
И только после того как всё необходимое загружено и готово — начинает строить граф зависимостей, вызывая конструкторы и фабрики в нужном порядке, и инжектируя в них нужные зависимости, уже готовые к использованию.
А-а, походу я понял, куда вы клоните. Типа, если в es6-модуле есть хотя бы одна абстрактная зависимость, то импорты в этом модуле не должны использоваться вовсе? Разумеется, нет - импорты конкретных зависимостей остаются. Отсутствуют только импорты для абстрактных зависимостей, тех, что в TS оформляются в виде интерфейсов.
Ну, скажем, возьмём какой-нибудь первый попавшийся пакет вроде
uuid
. Этот пакет зависит от ГСЧ, который в браузере берётся изglobal.crypto
, а в ноде — черезimport "crypto"
. Как по-вашему, должен ли был автор делать ГСЧ абстрактной зависимостью, чтобы пользователи сами искали и подсовывали нужный ГСЧ через DI?
import { v4 } from 'uuid';
const id = v4({
rng: myFunc
});
myFunc уже решает, откуда взять рандомайзер. То есть автор uuid сделал это абстрактной зависимостью (хотя и предусмотрел некое дефолтное разрешение этой зависимости). Собственно, вот он DI в чистом виде.
Меня интересует, до какого уровня абстракции автор предлагает дойти. Нужно ли просовывать через DI вообще всё, что хоть как-то используется модулем — JSON.parse()/stringify()
, atob()
, URI
и т.п., или где-то можно остановиться?
Хороший вопрос, кстати. Выскажу своё мнение: тут не обойтись без чутья и чувства меры. Стандартные, встроенные в язык штуки вроде бы тащить в DI не надо. А вот всякие модули среды исполнения вполне могут (но не обязательно) понадобиться там, где их нет, при переиспользовании клиентского кода на сервере или наоборот, или в каких иных ситуациях. Или, к примеру, fetch - зашили его напрямую, а потом понадобилось в запросы что-то добавлять. Короче, зависит от ситуации.
Инверсия зависимостей и 'import' в JS