Как стать автором
Обновить

Комментарии 9

export default class TeqFw_Http2_Back_Server {
    constructor(spec) {
        // EXTRACT DEPS
        /** @type {Function|TeqFw_Http2_Back_Server_Stream.action} */
        const process = spec['TeqFw_Http2_Back_Server_Stream$'];
        /** @type {TeqFw_Web_Back_Handler_Registry} */
        const registryHndl = spec['TeqFw_Web_Back_Handler_Registry$'];

зачем все это, когда есть TypeScript?

А как на TS будет выглядеть аналогичный фрагмент с учётом того, что:

  • функция-конструктор для функции-обработчика action находится в файле ./src/Back/Server/Stream.ts в npm-пакете @teqfw/http2

  • класс реестра обработчиков находится в файле ./src/Back/Handler/Registry.ts в npm-пакете @teqfw/web

  • зависимости (функция-обработчик и реестр) в конструктор сервера инжектятся в виде singleton'ов?

Как будет выглядеть код конструктора для сервера?

Вот так бы я написал ваш фрагмент на TS - три строчки
типы не нужно указывать - они автоматически определятся по типам полей в интерфейсе входящих параметров

константы можно сразу пакетом получить за счет деструктуризации (3 строчка)

export default class TeqFw_Http2_Back_Server {
    constructor(spec: IServerConfig) {
        const {process, registryHndl} = spec;

PS: это без учета импортов, работу по которым из-за хоткеев в IDE я вообще не вижу

нет разницы, где именно в папках лежат импортируемые пакеты - если они в src, IDE их найдет. Если в node_modules - то может быть понадобится вводить вручную

если захочется, то можно еще строчку сэкономить за счет той же деструктуризации

export default class TeqFw_Http2_Back_Server {
constructor({spec, registryHndl}:IServerConfig)

В том-то и дело, что без import'а никак. То, что вы их не видите, роли не играет. Особенно при рефакторинге. А межпакетный импорт несовместим для nodejs и браузеров (браузеры вообще не понимают межпакетный импорт - только с явным указанием пути). Да, за вас всю механическую работу делают IDE и сборщики, а в моём им этого делать не надо. Я не призываю вас использовать моё "кун-фу", я просто сравниваю стили.

Спасибо, что подтвердили мои догадки.

Похоже, на TypeScript аналогичный фрагмент отобразить - это не дело 5 минут. Я TS не знаю, поэтому помочь не могу. Может кто-то ещё может соорудить аналогичный код на TS?

@teqfw/diбыл создан для загрузки исходных кодов es-модулей, создания и инъекции зависимостей в "мультимодульных монолитах" (единая кодовая база, состоящая из npm-пакетов) с возможностью одновременного использования es-модулей в браузерах и nodejs и без применения транспиляции к модулям.

Зачем? Сначала из любопытства, а потом пошло-поехало. Так получилось, в общем.

Ванильный JS, Apache, сурово :)

Но, для изучения однозначно круто

Для меня веским аргументом для перехода на TypeScript стало как раз сокращение работы по указанию типов через JSDoc - во многих случаях компилятор прекрасно стал определять их сам, а там, где их надо указывать - все равно получалась более компактная запись.

Я указываю типы в конструкторе и в большинстве случаев IDE далее в коде способна разобрать что-куда и помочь autocomplete'ом. Ну и в сигнатурах функций/методов, само собой, нужно ставить. В общем-то, как и в TS, только в JSDoc.

Если бы в JS были аналоги PHP'шного namespace, то аннотации можно было сделать ещё короче. Наверное :)

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