Нативная инверсия зависимостей в TypeScript и React

Да, в этом идея constructor injection. Передавать все сервисы по одному будет более накладно — суть моего подхода в том, чтобы свести эти накладные издержки синтаксиса к минимуму. Впрочем, там выше mayorovp предложил отличный вариант:

export interface AnotherComponentProps {
    services: $Logger & SomeComponentProps['services'];
}

Нативная инверсия зависимостей в TypeScript и React

Допустим, дочернему компоненту 1 нужен сервис Logger:

services: $Logger; // props дочернего компонента 1

дочернему компоненту 2 сервис LocalStorage:

services: $LocalStorage; // props дочернего компонента 2

Родительский компонент должен получить оба сервиса, чтобы передать их в дочерние компоненты. Соответственно, он объявляет свой services следующим образом:

services: $Logger & $LocalStorage; // props родительского компонента

Соответственно, этот объект services он сможет передать обоим дочерним компонентам, т.к. тип $Logger & $LocalStorage совместим и с $Logger и c $LocalStorage.

Нативная инверсия зависимостей в TypeScript и React

Объявление класса после строчек "Объявляем наш компонент, которому требуются зависимости Logger и LocalStorage." в статье.

Вложенным компонентам сервисы можно передавать двумя способами:

1. Правильно — передавать services родительского компонента. При этом, родительский компонент должен объявить свой интерфейс services так, чтобы включать все сервисы, необходимые ему и вложенным компонентам.
2. Использовать какой-то обходной путь, и получать необходимые сервисы из вне.

В этом суть constructor injection — все зависимости спускаются вниз по дереву простым и очевидным образом.

Как работает JS: сервис-воркеры

Angular умеет работать в веб-воркере, думаю, при желании, им не трудно было бы адаптировать то же для сервис-воркера. Если только в этом есть какой-то смысл.

Не вебпаком единым

Hotreload возможен и для SystemJS, и гугл показывает кучу реализаций, включая стандартную реализацию в JSPM. Я просто правда очень скептически отношусь к этой теме, может напрасно.

Не вебпаком единым

А в SystemJS как это возможно? Там вообще всё в памяти.

Вы имеете ввиду загрузчик TypeScript для SystemJS, который компилирует на лету. В моем варианте компиляция происходит отдельно от SystemJS, она работает уже с готовым JS.

IDE-зависимая сборка

Ну разумеется отдельная галп-таска для компиляции. Плагины IDE только во время разработки.

изменения я увижу автоматически, когда они будут готовы

Всегда интересовало, как Вы определяете, что изменения уже применились? Допустим, если они визуально не заметны.

Не вебпаком единым

Видимо зависит от проекта.

Не вебпаком единым

Вы пробовали отлаживать TypeScript по source map? Вот попробуйте.

Вжух и готово — генерируем документацию из TypeScript кода с Typedoc

Есть еще отдельная документация, это чисто справочник по API. В .NET тоже всю документацию можно посмотреть в IDE, и тем не менее часто удобно зайти на MSDN и посмотреть описание конкретного класса. Здесь подразумевается, что ты уже знаешь название класса, например, и нужно просто посмотреть его API. Ну и разумеется, все это в IDE тоже доступно.

Конечно, хочется сделать структурированное содержание, чтобы все было не таким вот сплошным списком, а в виде дерева. Например, в соответствии со структурой директорий в исходниках. Но из коробки такое не поддерживается, а сделать пока руки не доходят.

Вжух и готово — генерируем документацию из TypeScript кода с Typedoc

Можно, наверное, попробовать сделать плагин для typedoc.

Вжух и готово — генерируем документацию из TypeScript кода с Typedoc

Не очень понял, что там можно линтить. Поясните, пожалуйста.

Вжух и готово — генерируем документацию из TypeScript кода с Typedoc

Это Вы о returns? Там да, пожалуй упоминание типа лишнее. В целом, информацию о типе typedoc берет из кода, дублировать ничего не нужно.

Вред маленьких функций

Каждая функция — абстракция. Собственно, мысль автора — если мы принудительно ограничиваем размер функций, то это порождает массу плохих (непродуманных) абстракций.

Промисы в ES6: паттерны и анти-паттерны

async/await делают последовательное выполнение промисов сказочно простым

Внутренние механизмы V8 и быстрая работа со свойствами объектов

Было бы хорошо сделать более практичные выводы — что нам как разработчикам стоит делать, а что наоборот не стоит, чтобы помочь движку в оптимизации.

Для себя вынес — частое изменение свойств объекта плохо, массивы целых чисел — хорошо, разреженные массивы — плохо.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

И вместо того, чтобы как было заявлено «читать сверху вниз» мы бегаем по файлу, а то и файлам, а то и папкам с файлами.

Здесь соглашусь. Поэтому я пишу в статье, что для компонентов приложения SOLID зачастую даже вреден. Нарушается целостность кода, он становится трудно читаемым. Но для повторно используемых компонентов это жизненно необходимо.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Интересно, как вообще arg.name был ассоциирован с Data.name? Просто по имени поля?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Не верю, что IDE сможет найти все ссылки без типизации. Вот допустим:

function foo(arg) { arg.name = "punks not dead"; }

function bar(arg) { arg.name = "all you need is love"; }

Как IDE поймет, что name в обоих случаях один и тот же?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Да, все верно, это то, чем приходится расплачиваться за стабильность. Просто нужно выбирать, что важнее — стабильность или возможность менять все приложение одной строчкой. Если последнее делается специально — это хорошо. Но чаще это делается не специально — хотел поменять только в данном сценарии, а поломал все приложение.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

А еще превосходный тулинг — findAllReferences, rename, autocmplete...