Это я к тому что это просто стандартное поведение js. Даже прокси не нужны.
Сложности появляются если вам при этом нужно сделать дополнительные действия при этом, например, перерисовать все зависимые элементы (mobx, короче). Тут задача разбивается на две категории: список всех известных полей заранее известен и не известен. В первом случае можно через defineProperty выкрутиться, ещё вроде был метод watch, но либо был очень давно либо мне приснился.
Во втором случае, когда список свойств, в которые будут записывать или считывать, не известен, уже без прокси не обойтись (либо нужно менять структуру на такую, при которой он известен или пользоваться getItem/setItem).
У меня есть заводские из икеи. Я там не увидел концевика, а судя по тому что они докручивают до предела, а потом и ещё немного, они измеряют сопротивление на двигателе и когда оно резко выросло, считают что штора докрутилась. Хммм, нужно будет как-то проверить, потянув за штору и посмотрев, запомнит ли он новый минимум.
правда это решение выглядит как гораздо более оверинженерное чем старый добрый концевик, так что может я просто был недостаточно внимательный
Но нам надо понимать, что это действительно человек, а не фото или видеозапись, смонтированная злоумышленниками.
Самый интересный пункт описан почти никак. Ну смотрят ваши сети на мимику, форму лица и голос. Но уже сейчас можно подделать все это по отдельности, если не все сразу. И в какой-то момент подделка будет достаточно качественной чтобы просто собатировать все ваши попытки, и любой сможет авторизоваться в любом банке / услуге с дип фейком, после чего систему останется просто свернуть.
я вот не понимаю зачем лезть в биометрию кроме как для сбора данных (которые и так собираются при оформлении паспорта, например), а не пойти как те же скандинавы - есть приложение-ключ на телефоне. Приходишь в банк, получаешь приватный сертификат, потом все остальные системы просят авторизацию через это приложение. Легко использовать, универсально, безопасно, легко сменить сертификат (в отличие от лица) и не подвержено поломке дип фейком.
Насколько я понимаю, ресурсоемким является именно обучение модели. Когда она уже обучена - дальше нужно относительно небольшое количество вычислений (но все ещё очень много из-за того что на вхоже картинка и вам так или иначе нужно пройтись по всем пикселям), вопрос лишь к исходной модели. Но исходная модель растёт вместе с ростом корпуса (чем больше и точнее она может распознавать, тем больше размер самой модели), что для js библиотеки большая проблема.
видимо, для этой модели нашли такой баланс. Ну она распознала лягушку, даже конкретную (tree frog / древесная лягушка), что уже неплохо, как по мне
UPD Прочитал сам ПМ №141791 (fips.ru) . В целом, в патенте перечислено всё подряд, без оригинального иска (который я не смог найти) не понятно на что именно подали на Apple. В целом, новизна патента, как я понял, в выбора разных каналов связи (интернет / GSM / экстренная связь), покуда он ссылается на другой документ, в котором представлена сама идея определяет экстренную ситуацию и отправлять записанное заранее сообщение с включенными координатами.
Не очень только понял в чем новизна именно этого патента, всё это существовало и сильно заранее, но тут перечисленно почти всё в куче, что дает свободу его обладателю подавать на Apple в суд. Например "например, при резком ухудшении самочувствия, нападениях, когда возможности управления мобильным телефоном ограничены" -- это было встроено в apple watch пару лет назад и уже есть повод наехать на apple, ведь они точно подсмотрели супер очевидное поведение в российском патенте.
Я так понял, что история такая: этот патерн каким-то образом мешает Apple, они подали обжалование паттерна как "это уже было придумано до него и очевидно", на что человек обиделся и подал в ответ на Apple, придравшись что айфон позволяет выбрать "экстренный контакт" и отправить ему записанное заранее сообщение, что является частью патерна. Про вторую часть ("отправку даже без симки") не думаю что имеет место быть.
Вообще патент какой-то в вакууме, сам по себе. Его частичные формулировки чуть ли не часть протокола GSM или очевидное капитанство, а другие -- никто не будет делать (иначе все начнут обузить возможность отправить сообщение без симки).
Но я лишь мимо проходил и дальше оригинальной новости на ТАСС не смотрел, могу и заблуждаться.
В описании модели говорится, что такой телефон позволяет в случае наступления экстренного случая отправить заранее записанное текстовое или голосовое сообщение, а также письмо по электронной почте одному или нескольким адресатам, связаться со службой спасения через специальный модуль.
Я так понимаю, идея именно в отправке заранее записанного сообщения, а не в том, что он запатентовал час протокола GSM. В этом хотя бы смысл появляется.
ну и новость просто невероятно информативная, конечно
Потому что. Оптимальная ширина текста от 7 до 10 слов на линию. Меньше и больше этого не удобно. Да, я могу поменять ширину браузера, но ведь все сайты разные, мне, каждый раз когда я переключаю вкладку, предлагаете ещё изменять размер экрана? Ведь Хабр удобен с одной шириной, почта с другой, гитлаб с третьей, и так далее. Пусть уж лучше сайты оптимизируют вывод текста.
обратите внимание на «режим чтения», который нынче есть почти во всех браузерах: что-то он всегда делает текст по центру и довольно узким, а не шириной на всю страницу, хотя могли бы.
Тоже зацепился про относительную скорость. Большая часть мусора вращается в одном и том же направлении и с одинаковой скоростью (иначе они бы сходили с орбит друг относительно друга). Угроза на пересекающихся орбитах, но таких вроде как не очень много.
Я фронтэнд и мне 16 категорически мало. Инструмент большой, вебпак жрет много памяти, хром дев тулзы жрут много памяти, юнит тесты делают макбук неюзаебельным на две минуты пока не закончатся.
И ладно обычный день, все вроде влазит, но когда нужно разворачивать бэк локально или вообще лезть в докеры - все становится печально.
Недавно перешли на микрофронэнды, выехавшие инструменты сильно похудели, людям, которые их разрабывают, стало проще жить. Но мне, иронично, как ответственному за эти самые микрофронэнды, нужно запускать сразу по 5 вебпаков и макбук начинает свапить вообще все и 16 гб категорически мало.
Конечно, можно долго ругаться на прожорливость вебпака и что у нас раздутый продукт, но что имеем.
А вот ещё задача, которая неожиданно ресурсоемкая: видеозвонки. Вот разрабатываю инструмент для видеозвонков и звоню сам себе в трёх экземплярах. Не знаю что не так с хромом, но оно выжирает всю оперативку и процессор для этого. И ничего не поделать, а нужно ещё пару докеров и вебпаков крутить где-то.
Правда покуда он сугубо асинхронный (в отличие от вашего синхронного, что, к слову, проблематично сделать на жс и будет жутко тормозить первое время пока все не прогрузит), у него основное назначение - разбивать код по отдельным чанкам. Тогда возвращаюсь к моему пункту - хотите пользоваться ts / webpack / миллионы плагинов на все случаи жизни - играйте по их правилам. Хотите свои правила - пожалуйста, но поддерживать это никто не будет. Ну и «их» правила, при желании, можно адаптировать к вашим. Вон, первый ангулар (angularjs который) похожим образом работал, правда ожидал что вы все склеите в один файл, но не сложно доделать до дозагрузки файлов, но что-то не пошло.
P.S. Вообще продуманная система зависимостей позволяет построить дерево зависимостей перед исполнением кода и, таким образом, загрузить все нужные зависимости заранее, а не тормозить UI пока что-то там прогрузится (и, в вашем примере, оно будет генерировать просто тысячи запросов на сервер, что проблематично без http2), а если начнёте делать так (декларировать модули либо заранее, либо декоратором), короче переизобретете inversifyjs или ангулар. Правда оба этих играют по правилам вебпака, но суть это не меняет.
Речь не об этом, а о том, что вы вроде бы обьявили класс, но все методы класса навесили через this в конструкторе. Так никто не делает ни старым синтаксисом, ни новым. Этих методов не будет в прототипе, они будут пересоздаваться каждый раз и вообще выглядит странно, вам вообще класс не нужен в данном случае, просто фабричная функция (ну или как оно там называлось, недоинкапсуляция в жс). В классе есть синтаксис объявления методов, который вы игнорируете без особой на то причине (да, вы замыкаете свой spec, но вообще это можно сделать изящнее и правильнее).
spec - это прокси-объект, который по идентификатору зависимости (вот этому
Т.е. это самописный автоимпорт как я и предполагал. Опять же - в ноде сработает без проблем, в вебе уже не все так просто. Вам нужно либо заведомо включить вообще все файлы в бандл, покуда иным способом вы не можете убедиться будет ли он использоваться, либо писать кастомный плагин, который будет понимать этот синтаксис и получите import() (ну или require, просто с необычным синтаксисом). К слову, сам по себе import() поддерживается тс, так что теоретически заменив ваш волшебный spec[…] на import(“root/module/blabla”) может даже сработает ваш импорт.
хочу заметить что в данном случае вы откровенно вводите в заблуждение что у вас нет импортов других модулей. У вас другой синтаксис, но импортом он от этого не перестаёт быть.
рефакторинг обычных импортов лучше тем что он будет править только шапку, файла, но функции как были с коммитами соответствующими правкам, так и останутся. В вашем же примере он их всех подправит с «добавил зависимость для задачи АБ-1234» на «отрефакторил абсолютно не относящийся к этому коду модуль»
В моем полностью типизированном проекте есть куча файлов без импортов. Да, зависимости в них обычно глобальные или нет вообще, но это не показатель сам по себе.
Собственно подразумевается что этот файл кто-то где-то будет импортировать. Хотя признаю, что в ноде легко сделать автоимпорт конкретно для подобного подхода. Но см. пункт 8
Конкретно это пример фабричных методов, которые получают зависимости от аргументов. Для JS нормально в данном случае не иметь импортов, потому что они передаются как аргументы. Осталось только убедиться что они переданы и корректного типа.
Для пункта 3 в TS тоже есть корретный форкфлоу. Более того, он часто даже более предпочтительный. Дело в том, что ts основан на структурном тайпинге, т.е. он проверяет что в переданном объекте есть требуемые поля, но при этом сами объекты могут быть разными. Подробнее тут https://www.typescriptlang.org/docs/handbook/type-compatibility.html Это позволяет переписать ваш пример с ТС так же без импортов.
Большинство типов в вашем примере - "какой-то объект", полезность чего под вопросом, но опустим этот пункт. Местами навешать дженериков всё же не помешает.
Добавьте сюда что-то вроде axios, не загружая им контекст и не вставляя его глобально. Опять же, в ноде не сложно дописать волшебный импорт, который это сделает, а в вебпаке если уж очень хочется есть import() API (раньше был require()), но и то и другое предназначено для других кейсов.
Убедитесь что ваш объект spec передан в корретном виде и поля, которые вы из него читаете, соответствуют типу, который вы ожидаете. Ну или иными словами, получите какую-то пользу от типизации (кроме возможно волшебного DI).
Ну и заставьте хоть какую-то IDE перейти в определение типа по клику. И отрефакторить (переименовать, например).
Возможно ли так писать? Да, конечно, многие из этих пунктов можно обойти, но только никто кроме вас это поддерживать не будет и разрабатывать большой проект на этом будет невозможно. Если бы это было внесено в стандарт -- может вообще бы хорошо было (хотя по пять раз писать один и тот же путь, например, если я работаю с математикой и у меня 10 полей с типом "вектор" слегка бы утомило. И рефакторинг с переносом файла в другое место замусорил бы весь гит правками прямо в коде).
Хотел написать про тестирование, но, справедливости ради, как раз для тестов мокать будет проще.
Да и вообще, если так подумать, это просто другой синтаксис импорта, у которого есть преимущества и недостатки, и без специальных доп программ он тоже не будет работать. Ну вот решили в TS придерживаться синтаксиса ES Modules, и придерживаются. Такие правила игры, никто не мешает форкнуть ТС или написать свой плагин к бейбелю для поддержки именно такого синтаксиса. Хотя есть справедливый вопрос: почему сущности должны импортироваться / экспортироваться одним образом, а типы для них другим?
Ну и бонус: ts без импортов для данного файла, если очень хочется:
interface DEFS {
SHARED {
SPACE_API: string
}
}
interface CONFIG {
root: string;
door: string;
urlBase: string;
// прочие поля, используемые конкретно этим классом
}
interface SPECS {
TeqFw_Web_Front_Defaults$: DEFS;
TeqWf_Web_Front_Api_Dto_Config: CONFIG;
}
export default class TeqFw_Web_Front_Service_Gate {
constructor(spec: SPECS) {
const DEF = spec['TeqFw_Web_Front_Defaults$'];
const config = spec['TeqFw_Web_Front_Api_Dto_Config$'];
...
}
}
// думаю, идея понятна: указыаем что используем, тогда ТС проверит что в переданном объекте есть все необходимое
PS. Я так понимаю, синтаксис классов вы тоже не принимаете?
Более того, все надмножества над жс (тот же flow and pure script) используют такой же синтаксис для модулей, да даже сильно другие от жс языка, компилируемые в жс, используют его (elm, dart, …). Причём не потому что не могут ничего другого, а потому что он удобнее и позволяет для каждого места проследить цепочку импортов и понять откуда что берётся.
Пока что никто не смог опровергнуть моё предположение, что без import'а es-модули в JS/TS не связываются.
«Пока что никто не смог опровергнуть мое предположение, что без использования знака «=« переменной нельзя присвоить значение».
Серьезно, это конструкция языка, вот так она задана и с этим ничего не сделать. Конечно, можно найти обходной путь (как в давние времена, когда все файлы просто склеивались в один большой файл, никаких импортов писать не нужно было, и этт было адски неудобно, либо можно написать свой плагин к бейбелю), но лучше смириться с тем как язык спроектирован именно сейчас и как абсолютно всё ожидает что он будет выглядеть (IDÉ, webpack, eslint, Babel, оптимизаторы кода, uglifyjs, да даже браузер с нодой). Синтаксис из php, который вы показали, просто не существует в js/ts
Конечный автомат конечному автомату рознь. Регулярка работает на них, или, если хотите, это специальный язык описания правил для конкретного конечного автомата. Однако распарсить js регулярками - задача прям мягко говоря не тривиальная, а вот самописный конечный автомат для этого будет… сложный, но несопоставимо более простой чем регулярка, которая не будет сходить с ума от вложенных в скобочки символа комментария. (Конечно, лучше взять готовый парсер или генератор парсеров на крайний случай, но это исключительно для примера).
Я о том же, что следует использовать библиотеки / готовые протестированные решения если они есть. Но если нет или не подходят, иногда стоит рассмотреть иные варианты. Например, конечные автоматы гораздо проще расширять в будущем, потому что с специфичными условиями регулярки быстро теряют хоть какую-нибудь читаемость. Правда, признаю, конечные автоматы грамотно написать та ещё задача, может даже сложнее чем регулярку.
Является ли значение числом (целым или с плавающей точкой/запятой)?
Игнорирует возможность использовать разделители (пробелы, например, нижнее подчеркивание), а так же как экспотенциальную нотацию (1.23е33), так и более специфичные (0b1100). И если специфичные нотации редкость, отделять разряды запятыми достаточно популярно. А главное, parseInt (parseFloat) хорошо справляются, хоть есть и свои проблемы.
Является ли значение номером сотового телефона?
Игнорирует возможность написать 008 вместо +8 (это вполне легально). И вообще, номера телефонов парсить регулярками огромное зло, хотя и раздражает, что нет стандартного способа работы с номерами кроме как невероятно раздутой google-libphonenumber. В целом, номера создают не столько проблем, как email, но тоже достаточно. (Ну и если вы скажите "я только для России разрабатываю и игнорирую городские номера" я отвечу: даже только для России быстро может понадобиться необходимость поддерживать иностранные номера. Ну т.е. если кто-то приехал домой на недельку и не смог себе пиццу заказать — будет обидно).
Это я к чему: регулярки — мощный инструмент и бывает очень полезным, но для той же валидации их следует избегать как самое большое зло, потому что это гарантированный выстрел себе в ногу из-за бесконечного числа специфичных кейсов. Многие поля имеют структуру, чексуммы, которые с регулярками не проверить (хотя регулярки будут полезны для извлечения частей этой структуры), даты можно проверить только очень абстрактно, номера телефонов бывают разными (а еще люди их вбивают по-разному), числа бывают разными и так далее. Да даже самое простое: проверить корреткность имени (что имя состоит только из букв) та еще задача, имена бывают очень разными, некоторые используют спецсимволы (хотя не в России, к счастью), есть даже с цифрами в имени (впрочем, это совсем редкость и у них проблемы будут еще на уровне банков).
Это я к тому что это просто стандартное поведение js. Даже прокси не нужны.
Сложности появляются если вам при этом нужно сделать дополнительные действия при этом, например, перерисовать все зависимые элементы (mobx, короче). Тут задача разбивается на две категории: список всех известных полей заранее известен и не известен. В первом случае можно через defineProperty выкрутиться, ещё вроде был метод watch, но либо был очень давно либо мне приснился.
Во втором случае, когда список свойств, в которые будут записывать или считывать, не известен, уже без прокси не обойтись (либо нужно менять структуру на такую, при которой он известен или пользоваться getItem/setItem).
У меня есть заводские из икеи. Я там не увидел концевика, а судя по тому что они докручивают до предела, а потом и ещё немного, они измеряют сопротивление на двигателе и когда оно резко выросло, считают что штора докрутилась. Хммм, нужно будет как-то проверить, потянув за штору и посмотрев, запомнит ли он новый минимум.
правда это решение выглядит как гораздо более оверинженерное чем старый добрый концевик, так что может я просто был недостаточно внимательный
Самый интересный пункт описан почти никак. Ну смотрят ваши сети на мимику, форму лица и голос. Но уже сейчас можно подделать все это по отдельности, если не все сразу. И в какой-то момент подделка будет достаточно качественной чтобы просто собатировать все ваши попытки, и любой сможет авторизоваться в любом банке / услуге с дип фейком, после чего систему останется просто свернуть.
я вот не понимаю зачем лезть в биометрию кроме как для сбора данных (которые и так собираются при оформлении паспорта, например), а не пойти как те же скандинавы - есть приложение-ключ на телефоне. Приходишь в банк, получаешь приватный сертификат, потом все остальные системы просят авторизацию через это приложение. Легко использовать, универсально, безопасно, легко сменить сертификат (в отличие от лица) и не подвержено поломке дип фейком.
Насколько я понимаю, ресурсоемким является именно обучение модели. Когда она уже обучена - дальше нужно относительно небольшое количество вычислений (но все ещё очень много из-за того что на вхоже картинка и вам так или иначе нужно пройтись по всем пикселям), вопрос лишь к исходной модели. Но исходная модель растёт вместе с ростом корпуса (чем больше и точнее она может распознавать, тем больше размер самой модели), что для js библиотеки большая проблема.
видимо, для этой модели нашли такой баланс. Ну она распознала лягушку, даже конкретную (tree frog / древесная лягушка), что уже неплохо, как по мне
UPD Прочитал сам ПМ №141791 (fips.ru) . В целом, в патенте перечислено всё подряд, без оригинального иска (который я не смог найти) не понятно на что именно подали на Apple. В целом, новизна патента, как я понял, в выбора разных каналов связи (интернет / GSM / экстренная связь), покуда он ссылается на другой документ, в котором представлена сама идея определяет экстренную ситуацию и отправлять записанное заранее сообщение с включенными координатами.
Не очень только понял в чем новизна именно этого патента, всё это существовало и сильно заранее, но тут перечисленно почти всё в куче, что дает свободу его обладателю подавать на Apple в суд. Например "например, при резком ухудшении самочувствия, нападениях, когда возможности управления мобильным телефоном ограничены" -- это было встроено в apple watch пару лет назад и уже есть повод наехать на apple, ведь они точно подсмотрели супер очевидное поведение в российском патенте.
Я так понял, что история такая: этот патерн каким-то образом мешает Apple, они подали обжалование паттерна как "это уже было придумано до него и очевидно", на что человек обиделся и подал в ответ на Apple, придравшись что айфон позволяет выбрать "экстренный контакт" и отправить ему записанное заранее сообщение, что является частью патерна. Про вторую часть ("отправку даже без симки") не думаю что имеет место быть.
Вообще патент какой-то в вакууме, сам по себе. Его частичные формулировки чуть ли не часть протокола GSM или очевидное капитанство, а другие -- никто не будет делать (иначе все начнут обузить возможность отправить сообщение без симки).
Но я лишь мимо проходил и дальше оригинальной новости на ТАСС не смотрел, могу и заблуждаться.
Можно было хотя бы ТАСС до конца процитировать.
Я так понимаю, идея именно в отправке заранее записанного сообщения, а не в том, что он запатентовал час протокола GSM. В этом хотя бы смысл появляется.
ну и новость просто невероятно информативная, конечно
Потому что. Оптимальная ширина текста от 7 до 10 слов на линию. Меньше и больше этого не удобно. Да, я могу поменять ширину браузера, но ведь все сайты разные, мне, каждый раз когда я переключаю вкладку, предлагаете ещё изменять размер экрана? Ведь Хабр удобен с одной шириной, почта с другой, гитлаб с третьей, и так далее. Пусть уж лучше сайты оптимизируют вывод текста.
обратите внимание на «режим чтения», который нынче есть почти во всех браузерах: что-то он всегда делает текст по центру и довольно узким, а не шириной на всю страницу, хотя могли бы.
Тоже зацепился про относительную скорость. Большая часть мусора вращается в одном и том же направлении и с одинаковой скоростью (иначе они бы сходили с орбит друг относительно друга). Угроза на пересекающихся орбитах, но таких вроде как не очень много.
Я фронтэнд и мне 16 категорически мало. Инструмент большой, вебпак жрет много памяти, хром дев тулзы жрут много памяти, юнит тесты делают макбук неюзаебельным на две минуты пока не закончатся.
И ладно обычный день, все вроде влазит, но когда нужно разворачивать бэк локально или вообще лезть в докеры - все становится печально.
Недавно перешли на микрофронэнды, выехавшие инструменты сильно похудели, людям, которые их разрабывают, стало проще жить. Но мне, иронично, как ответственному за эти самые микрофронэнды, нужно запускать сразу по 5 вебпаков и макбук начинает свапить вообще все и 16 гб категорически мало.
Конечно, можно долго ругаться на прожорливость вебпака и что у нас раздутый продукт, но что имеем.
А вот ещё задача, которая неожиданно ресурсоемкая: видеозвонки. Вот разрабатываю инструмент для видеозвонков и звоню сам себе в трёх экземплярах. Не знаю что не так с хромом, но оно выжирает всю оперативку и процессор для этого. И ничего не поделать, а нужно ещё пару докеров и вебпаков крутить где-то.
Да, опять же, третий раз, наверное, вы переизобрели https://webpack.js.org/api/module-methods/#import-1
Правда покуда он сугубо асинхронный (в отличие от вашего синхронного, что, к слову, проблематично сделать на жс и будет жутко тормозить первое время пока все не прогрузит), у него основное назначение - разбивать код по отдельным чанкам. Тогда возвращаюсь к моему пункту - хотите пользоваться ts / webpack / миллионы плагинов на все случаи жизни - играйте по их правилам. Хотите свои правила - пожалуйста, но поддерживать это никто не будет. Ну и «их» правила, при желании, можно адаптировать к вашим. Вон, первый ангулар (angularjs который) похожим образом работал, правда ожидал что вы все склеите в один файл, но не сложно доделать до дозагрузки файлов, но что-то не пошло.
P.S. Вообще продуманная система зависимостей позволяет построить дерево зависимостей перед исполнением кода и, таким образом, загрузить все нужные зависимости заранее, а не тормозить UI пока что-то там прогрузится (и, в вашем примере, оно будет генерировать просто тысячи запросов на сервер, что проблематично без http2), а если начнёте делать так (декларировать модули либо заранее, либо декоратором), короче переизобретете inversifyjs или ангулар. Правда оба этих играют по правилам вебпака, но суть это не меняет.
Речь не об этом, а о том, что вы вроде бы обьявили класс, но все методы класса навесили через this в конструкторе. Так никто не делает ни старым синтаксисом, ни новым. Этих методов не будет в прототипе, они будут пересоздаваться каждый раз и вообще выглядит странно, вам вообще класс не нужен в данном случае, просто фабричная функция (ну или как оно там называлось, недоинкапсуляция в жс). В классе есть синтаксис объявления методов, который вы игнорируете без особой на то причине (да, вы замыкаете свой spec, но вообще это можно сделать изящнее и правильнее).
Т.е. это самописный автоимпорт как я и предполагал. Опять же - в ноде сработает без проблем, в вебе уже не все так просто. Вам нужно либо заведомо включить вообще все файлы в бандл, покуда иным способом вы не можете убедиться будет ли он использоваться, либо писать кастомный плагин, который будет понимать этот синтаксис и получите import() (ну или require, просто с необычным синтаксисом). К слову, сам по себе import() поддерживается тс, так что теоретически заменив ваш волшебный spec[…] на import(“root/module/blabla”) может даже сработает ваш импорт.
хочу заметить что в данном случае вы откровенно вводите в заблуждение что у вас нет импортов других модулей. У вас другой синтаксис, но импортом он от этого не перестаёт быть.
рефакторинг обычных импортов лучше тем что он будет править только шапку, файла, но функции как были с коммитами соответствующими правкам, так и останутся. В вашем же примере он их всех подправит с «добавил зависимость для задачи АБ-1234» на «отрефакторил абсолютно не относящийся к этому коду модуль»
Хорошо, давайте по порядку.
В моем полностью типизированном проекте есть куча файлов без импортов. Да, зависимости в них обычно глобальные или нет вообще, но это не показатель сам по себе.
Собственно подразумевается что этот файл кто-то где-то будет импортировать. Хотя признаю, что в ноде легко сделать автоимпорт конкретно для подобного подхода. Но см. пункт 8
Конкретно это пример фабричных методов, которые получают зависимости от аргументов. Для JS нормально в данном случае не иметь импортов, потому что они передаются как аргументы. Осталось только убедиться что они переданы и корректного типа.
Для пункта 3 в TS тоже есть корретный форкфлоу. Более того, он часто даже более предпочтительный. Дело в том, что ts основан на структурном тайпинге, т.е. он проверяет что в переданном объекте есть требуемые поля, но при этом сами объекты могут быть разными. Подробнее тут https://www.typescriptlang.org/docs/handbook/type-compatibility.html Это позволяет переписать ваш пример с ТС так же без импортов.
Большинство типов в вашем примере - "какой-то объект", полезность чего под вопросом, но опустим этот пункт. Местами навешать дженериков всё же не помешает.
Добавьте сюда что-то вроде axios, не загружая им контекст и не вставляя его глобально. Опять же, в ноде не сложно дописать волшебный импорт, который это сделает, а в вебпаке если уж очень хочется есть import() API (раньше был require()), но и то и другое предназначено для других кейсов.
Убедитесь что ваш объект spec передан в корретном виде и поля, которые вы из него читаете, соответствуют типу, который вы ожидаете. Ну или иными словами, получите какую-то пользу от типизации (кроме возможно волшебного DI).
Ну и заставьте хоть какую-то IDE перейти в определение типа по клику. И отрефакторить (переименовать, например).
Возможно ли так писать? Да, конечно, многие из этих пунктов можно обойти, но только никто кроме вас это поддерживать не будет и разрабатывать большой проект на этом будет невозможно. Если бы это было внесено в стандарт -- может вообще бы хорошо было (хотя по пять раз писать один и тот же путь, например, если я работаю с математикой и у меня 10 полей с типом "вектор" слегка бы утомило. И рефакторинг с переносом файла в другое место замусорил бы весь гит правками прямо в коде).
Хотел написать про тестирование, но, справедливости ради, как раз для тестов мокать будет проще.
Да и вообще, если так подумать, это просто другой синтаксис импорта, у которого есть преимущества и недостатки, и без специальных доп программ он тоже не будет работать. Ну вот решили в TS придерживаться синтаксиса ES Modules, и придерживаются. Такие правила игры, никто не мешает форкнуть ТС или написать свой плагин к бейбелю для поддержки именно такого синтаксиса. Хотя есть справедливый вопрос: почему сущности должны импортироваться / экспортироваться одним образом, а типы для них другим?
Ну и бонус: ts без импортов для данного файла, если очень хочется:
PS. Я так понимаю, синтаксис классов вы тоже не принимаете?
Более того, все надмножества над жс (тот же flow and pure script) используют такой же синтаксис для модулей, да даже сильно другие от жс языка, компилируемые в жс, используют его (elm, dart, …). Причём не потому что не могут ничего другого, а потому что он удобнее и позволяет для каждого места проследить цепочку импортов и понять откуда что берётся.
«Пока что никто не смог опровергнуть мое предположение, что без использования знака «=« переменной нельзя присвоить значение».
Серьезно, это конструкция языка, вот так она задана и с этим ничего не сделать. Конечно, можно найти обходной путь (как в давние времена, когда все файлы просто склеивались в один большой файл, никаких импортов писать не нужно было, и этт было адски неудобно, либо можно написать свой плагин к бейбелю), но лучше смириться с тем как язык спроектирован именно сейчас и как абсолютно всё ожидает что он будет выглядеть (IDÉ, webpack, eslint, Babel, оптимизаторы кода, uglifyjs, да даже браузер с нодой). Синтаксис из php, который вы показали, просто не существует в js/ts
Анонсировать игровой лэптоп на прошлогоднем процессоре когда уже есть 11th Geni7 11800H, я уже молчу про AMD Ryzen.
Лучше скажите, когда покажите ноутбук на связке AMD Ryzen + AMD Radeon (AMD advantage или как они это называют).
Конечный автомат конечному автомату рознь. Регулярка работает на них, или, если хотите, это специальный язык описания правил для конкретного конечного автомата. Однако распарсить js регулярками - задача прям мягко говоря не тривиальная, а вот самописный конечный автомат для этого будет… сложный, но несопоставимо более простой чем регулярка, которая не будет сходить с ума от вложенных в скобочки символа комментария. (Конечно, лучше взять готовый парсер или генератор парсеров на крайний случай, но это исключительно для примера).
Я о том же, что следует использовать библиотеки / готовые протестированные решения если они есть. Но если нет или не подходят, иногда стоит рассмотреть иные варианты. Например, конечные автоматы гораздо проще расширять в будущем, потому что с специфичными условиями регулярки быстро теряют хоть какую-нибудь читаемость. Правда, признаю, конечные автоматы грамотно написать та ещё задача, может даже сложнее чем регулярку.
Отличная статья! Понимаю, что тут примеры для демонстрации, но хотел бы заметить:
Регулярки стоит избегать как можно сильнее. Вот прям со всей силы, особенно если есть другие способы решения задачи. Примеры:
/[A-ZА-ЯЁ]+/i.test('Њ')дает false (македонская кириллица, и да, я придераюсь.)Игнорирует возможность использовать разделители (пробелы, например, нижнее подчеркивание), а так же как экспотенциальную нотацию (1.23е33), так и более специфичные (0b1100). И если специфичные нотации редкость, отделять разряды запятыми достаточно популярно. А главное, parseInt (parseFloat) хорошо справляются, хоть есть и свои проблемы.
Игнорирует возможность написать 008 вместо +8 (это вполне легально). И вообще, номера телефонов парсить регулярками огромное зло, хотя и раздражает, что нет стандартного способа работы с номерами кроме как невероятно раздутой google-libphonenumber. В целом, номера создают не столько проблем, как email, но тоже достаточно. (Ну и если вы скажите "я только для России разрабатываю и игнорирую городские номера" я отвечу: даже только для России быстро может понадобиться необходимость поддерживать иностранные номера. Ну т.е. если кто-то приехал домой на недельку и не смог себе пиццу заказать — будет обидно).
Это я к чему: регулярки — мощный инструмент и бывает очень полезным, но для той же валидации их следует избегать как самое большое зло, потому что это гарантированный выстрел себе в ногу из-за бесконечного числа специфичных кейсов. Многие поля имеют структуру, чексуммы, которые с регулярками не проверить (хотя регулярки будут полезны для извлечения частей этой структуры), даты можно проверить только очень абстрактно, номера телефонов бывают разными (а еще люди их вбивают по-разному), числа бывают разными и так далее. Да даже самое простое: проверить корреткность имени (что имя состоит только из букв) та еще задача, имена бывают очень разными, некоторые используют спецсимволы (хотя не в России, к счастью), есть даже с цифрами в имени (впрочем, это совсем редкость и у них проблемы будут еще на уровне банков).