Comments 16
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 и сборщики, а в моём им этого делать не надо. Я не призываю вас использовать моё "кун-фу", я просто сравниваю стили.
Спасибо, что подтвердили мои догадки.
я не учу вас жить, просто призываю подумать - зачем тратить время на то, что могут делать машины лучше?
Машины не могут править мой код вместо меня. С этим нужно управляться мне. Я ищу способ кодировать на JS, который бы меня устраивал. Когда Google анонсировал dart, я начал погружаться в dart, но когда я увидел, что dart нативно не будет поддерживаться всеми браузерами, я перестал погружаться. Как только TS начнёт поддерживаться всеми браузерами, я сразу же переключусь на TS, а пока же я вижу, как JS и TS плавно мигрируют друг к другу. И я вместе с ними.
Кстати, я не трачу время, я изучаю возможности языка :)
я так понял, что вас парит лишняя работа по созданию import
но одновременно вас не парит обильное многословие, к которому вынуждает типизация через JSDoc - при этом крайне ненадежная типизация, кстати. TS при ошибке типов остановит вас дважды - в IDE и при сборке. JS Doc остановит вас только в IDE, сборщик проекта отлично проглотит все ошибки и несовместимости типов.
Важно то, что мне кажется, что у вас гораздо больше работы по вводу символов, чем у меня. Я могу писать двухстрочники, однострочники, не указывать типы (при этом они будут соблюдаться). Работы стало на порядок меньше.
Мне кажется, это уже не вопрос программированния, а вопрос управления личным настроением, личным отношением.
Тут никто помочь не может, но вы можете попробовать увидеть выигрыш, который важен для вас. Я так понял, что вам важен выигрыш в наборе символов. Так вот, TypeScript даже с import - значительно мог бы уменьшить объемы символов, которые нужно набирать для вашего кода.
Меня не парит набор симовлов, я искал возможность писать JS-код, который бы без изменений запускался в браузере и nodejs. Оказалось, что межпакетный импорт этому мешает. И я нашёл для себя способ, который позволяет писать код, который бы без изменений запускался в браузере и nodejs.
В каком-то роде вам проще, вы пишите на TS, который затем транспилируется под среду выполнения. Я так уже делал на GWT, мне не понравилось.
// который бы меня устраивал
У вас есть измеримые численные параметры для этого критерия, или вы опираетесь исключительно на внутреннее ощущение "от сердца"?
может быть, составим таблица Pro et Contra с числовыми параметрами и еще проставим коэффициенты, какой из них имеет наибольший вес?
по набору символов я привел примеры и уже сказал - что по численному параметру TypeScript тут намного лучше и по строчкам, и по символам.
Похоже, на TypeScript аналогичный фрагмент отобразить - это не дело 5 минут. Я TS не знаю, поэтому помочь не могу. Может кто-то ещё может соорудить аналогичный код на TS?
@teqfw/diбыл создан для загрузки исходных кодов es-модулей, создания и инъекции зависимостей в "мультимодульных монолитах" (единая кодовая база, состоящая из npm-пакетов) с возможностью одновременного использования es-модулей в браузерах и nodejs и без применения транспиляции к модулям.
Зачем? Сначала из любопытства, а потом пошло-поехало. Так получилось, в общем.
Ванильный JS, Apache, сурово :)
Но, для изучения однозначно круто
Для меня веским аргументом для перехода на TypeScript стало как раз сокращение работы по указанию типов через JSDoc - во многих случаях компилятор прекрасно стал определять их сам, а там, где их надо указывать - все равно получалась более компактная запись.
Я указываю типы в конструкторе и в большинстве случаев IDE далее в коде способна разобрать что-куда и помочь autocomplete'ом. Ну и в сигнатурах функций/методов, само собой, нужно ставить. В общем-то, как и в TS, только в JSDoc.
Если бы в JS были аналоги PHP'шного namespace, то аннотации можно было сделать ещё короче. Наверное :)
я 2 года сидел на JSDoc, потом на TS, по ощущениям - лишней работы стало меньше. Конечно, это субъективно. TS надо просто вбить в пальцы, первое время я смотрел на конструкции некоторых опытных кодеров как на мумбо-юмбо, но в итоге признал, что это крайне гибкий и мощный язык, который ограничивает там, где надо ограничивать, и значительно сокращает объем кода, когда выучиваешь его фокусы )
@teqfw/http2