Fetch - это API среды браузера/node, а не часть языка. Сам язык однопоточный
движок сам выбирает, создавать ли новый поток для промиса или нет. Это касается не только fetch а любого промиса.
В спецификации ничего не написано по поводу многопоточности, а это значит, что реализация остается на откуп автора среды для выполнения. Хочешь, будет многопоточным, хочешь нет.
Js не однопоточный, попробуйте замерить как работает fetch в браузере с помощью тех же систем мониторинга в самих os, и вы удивитесь, что js ни разу однопоточный и движок сам выбирает, создавать ли новый поток для промиса или нет. Это касается не только fetch а любого промиса.
Рассмотренные примеры где чередуется promise + settimeout лишено смысла. В спецификации не сказано как такой код должен обрабатываться и какие механизмы использовать, Каждый движок выбирает свой путь и такое поведение не детерминировано(я понимаю, что все привыкли что у нас везде v8, но пожалейте лису и webkit).
Намешали воркеров и arraybuffer о чем не каждый программист расскажет, и, на мой взгляд, про arraybuffer/sharedarraybuffer стоит рассказать отдельно, поскольку там много подводных камней.
Если касаетесь утечек памяти, то стоит и рассказывать/показывать как избежать. В статье нет информации про removeEventListener
Не замечание но наблюдение - Видно использование нейронки, особенно вначале
Не в обиду автору, но практической пользы тут мало. Каждая 10 статья на Хабре рассказывала про цикл событий. Сложилось впечатление, что была написана статья ради статьи.
Использую Affine self hosted только из-за того, что мне надо SSO и пользоваться заметками не только мне, но и тем, кто входит в мою группу близких людей
Вместо obsidian и notion лично я использую affine. По сути тоже самое что и notion. Плюс к affine можно подключить oidc, что я и сделал и для домашним использования между членами семьи очень подходит
но многопоточность язык не умеет, в отличии от например Java
Кто вам такое сказал?
В playwright для JS есть такие настройки как workers и shards. Чтобы запускать в несколько потоков/процессов.
Если мы говорим про скорость рана тестов. То JS/TS - тут вообще не в лидерах
Бутылочное горло любых e2e тестов это сам тул по работе с браузером. Если взять 1 и тотже тест и написать его на java и js вы заметите, что все будет упираться в выбор элемента и его взаимодействие. Разница будет на уровне погрешности. Ведь если у тебя тест находит элемент за секунда, то какая разница на чем написан тест, java или js?
Насколько я помню, у cloudflare свой рантаим для js, он отличается от годы(хотя апи такое же). Проверьте, точно ли у вас года запускается, или это косяк cloudflare
из-за того, что там очень много работы с типами, то мы ожидаем именно числа как константы(конкретные числа). Если привести тип как число(as number) - то будет ошибка валидации. Пока не нашел решения как это побороть.
Наверное пример не самый удачный подобрал. Имелось ввиду что если кастить к числу, то поплывет валидация. Несмотря на то, что числа будут правильны.
const after2 = s.string.minLength(3).maxLength(5 as number) // RangeError: MinLength = 3, maxLength = number
// ^ inline cast to number
Затем, что после валидации у нас должен возвращаться в тип, который мы описали. Например объект, который мы можем назвать "myObjSchema", должен будет сказать какой тип у этой переменной. Как минимум - это удобно, тк не нужно дублировать тип и схему, достаточно описать схему, тип уже будет валидным.
const myObjSchema = s.object({
a: s.number(),
b: s.string()
})
const parsed = myObjSchema.parse(data)
type P = typeof parsed // {a: number, b: string}
function doSmth(obj: P) {
// работа с уже валидным объектом тк до этого был вызван parse
}
doSmth(parsed)
для чего вы делали тогда SchemaBuilder, который строит json схему в рантайме?
Для того, чтобы создавать схемы простыми функциями, просто и декларативно. Думал, что это очевидно. ?
Плюс, мы не валидируем схему, это делает ajv. Мы же строим ее для того, чтобы отдать схему потом самому ajv.
Не натыкались на это решение, в любом случае она не подходила, тк у нас уже есть json-schema написанные в обычном объекте. Повторюсь, у нас уже использовался ajv для валидации до того как мы написали данное решение. Плюс мы работаем с реальной схемой, в любой момент можно вызвать свойство schema и работать с полученным объектом напямую, и никаких кастомных компиляторов не надо :)
Все так. По поводу openAPI. у нас не так чтобы прям advanced схемы. тип int32, nullable и что-то еще(не помню что) поддерживается самим ajv и нареканий нет (хотя после вашего коментария уже начал сомневаться).
P.S. можно у нас также создать билдер со своим ajv инстансом, в случае если стандартный не подходит, потому-что не мы валидируем схему, а ajv
import {create} from 'ajv-ts'
import customAjv from 'ajv-from-somePackage'
const s = create(customAjv(/** opts */))
// ваши схемы
как уже было написано в статье, у нас уже был ajv и тянуть еще один пакет для деклараций одного и того же быть бы слишком, к тому же у зода есть типы которые не поддерживаются в JSON-Schema (function, symbol, Map, Set) Аналоги валидации(и построения) схем кроме зода есть:
Потому что как правило трейдинговые терминалы под капотом используют другие немного технологии например протокол фикс. Который используется для передачи финансовых данных между биржами. Поэтому узким местом является именно скорость работы биржи с которой ведутся торги, а не сам http2 протокол.
Интересная статья. Хотелось бы еще узнать как у вас обстоят дела с автоматизацией? Как именно TMS реагирует на то что сценарий автоматизирован(руками или по скрипту)?
Интересная статья показывающая варианты использования отмены промисов. Единственное замечание - это то что если промис отменить то node.js(предполагаю что в браузере анологичное поведение) удалит промис из call stack и еще и удалит ссылку на выполнение. Это значит, что мы экономим память приложению тк явно показываем GC что данный блок кода уже неактуален
1) работа с предусловиями скорее всего будет реализована как система “компонентов”. Т.е. пользователь 1 раз проходит по, например логину. А затем будет возможность объеденить в “компонент логин”. Тут много пограничных случаев надо продумывать, поэтому только мысли.
2) Работает условно - page.screenshot() . Возможности сравнивать скриншоты пока что нет между собой.
3) Репо не пуст. Поскольку участники данного проекта не готовы выставить код на всеобщее обозрение в опен сорс, то ссылка ведет на публичный issue tracker.
Ваш ответ отличается от того, что будет в реальности. Если внимательно посмотреть на документацию к node.js в раздел про то как резолвятся зависимости из node_modules можно понять, что будет взят фаил исполняемый из "main" или "exports" package.json файла. Это значит, что если проект фронтедовский - там уже наверняка есть сборщик, который сминифицирует код как надо(например вебпак). Если проект на ноде, то с вероятностью 90% код не надо минифицировать, а если и надо, то скорее всего что-то не так и проблема в другом.
Получается Ваша статья лишена смысла, поскольку заниматься минифицированием это:
1) себе дороже, неблагодарный труд, особенно если библиотека и для node.js и для браузера
2) сборщик и так сминифицирует код (зачем дважды делать одно и тоже)
Тогда вопрос на засыпку. Вы написали библиотеку, сделали 2 сборки. dev и prod. Я как разработчик нашел вашу либу, по функционалу все круто, то что я искал. Пишу `<пакертный менеджер установи либу>`. А затем импортирую в свой проект.
получится как-то так:
// src/index.ts
import something from 'yourlib';
/// rest code
Как разработчик на Node.JS, иногда во время дебага приходится лазить в исходники других npm пакетов, чтобы понять что условно результат устраивает меня(да, гипотечески это решается тестированием, но от багов никто не застрахован). В таком случае достаточно будет перейти в github и там создать issue на функционал либы. Плюс если пользуетесь yarn,pnpm пакетными менеджерами у них есть функционал по патчингу пакетов что позволяет не ждать фикса вашего любимого\критически важного пакета. Минификация в этом случае будет наоборот мешать вам инспектировать проблему другой либы.
В спецификации ничего не написано по поводу многопоточности, а это значит, что реализация остается на откуп автора среды для выполнения. Хочешь, будет многопоточным, хочешь нет.
пару замечаний, о чем не было сказано в статье
Js не однопоточный, попробуйте замерить как работает fetch в браузере с помощью тех же систем мониторинга в самих os, и вы удивитесь, что js ни разу однопоточный и движок сам выбирает, создавать ли новый поток для промиса или нет. Это касается не только fetch а любого промиса.
Рассмотренные примеры где чередуется promise + settimeout лишено смысла. В спецификации не сказано как такой код должен обрабатываться и какие механизмы использовать, Каждый движок выбирает свой путь и такое поведение не детерминировано(я понимаю, что все привыкли что у нас везде v8, но пожалейте лису и webkit).
Намешали воркеров и arraybuffer о чем не каждый программист расскажет, и, на мой взгляд, про arraybuffer/sharedarraybuffer стоит рассказать отдельно, поскольку там много подводных камней.
Если касаетесь утечек памяти, то стоит и рассказывать/показывать как избежать. В статье нет информации про removeEventListener
Не замечание но наблюдение - Видно использование нейронки, особенно вначале
Не в обиду автору, но практической пользы тут мало. Каждая 10 статья на Хабре рассказывала про цикл событий. Сложилось впечатление, что была написана статья ради статьи.
Использую Affine self hosted только из-за того, что мне надо SSO и пользоваться заметками не только мне, но и тем, кто входит в мою группу близких людей
Вместо obsidian и notion лично я использую affine. По сути тоже самое что и notion. Плюс к affine можно подключить oidc, что я и сделал и для домашним использования между членами семьи очень подходит
Кто вам такое сказал?
В playwright для JS есть такие настройки как workers и shards. Чтобы запускать в несколько потоков/процессов.
Бутылочное горло любых e2e тестов это сам тул по работе с браузером. Если взять 1 и тотже тест и написать его на java и js вы заметите, что все будет упираться в выбор элемента и его взаимодействие. Разница будет на уровне погрешности. Ведь если у тебя тест находит элемент за секунда, то какая разница на чем написан тест, java или js?
Насколько я помню, у cloudflare свой рантаим для js, он отличается от годы(хотя апи такое же). Проверьте, точно ли у вас года запускается, или это косяк cloudflare
из-за того, что там очень много работы с типами, то мы ожидаем именно числа как константы(конкретные числа). Если привести тип как число(
as number) - то будет ошибка валидации. Пока не нашел решения как это побороть.Наверное пример не самый удачный подобрал.
Имелось ввиду что если кастить к числу, то поплывет валидация. Несмотря на то, что числа будут правильны.
Затем, что после валидации у нас должен возвращаться в тип, который мы описали. Например объект, который мы можем назвать "myObjSchema", должен будет сказать какой тип у этой переменной. Как минимум - это удобно, тк не нужно дублировать тип и схему, достаточно описать схему, тип уже будет валидным.
Для того, чтобы создавать схемы простыми функциями, просто и декларативно. Думал, что это очевидно. ?
Плюс, мы не валидируем схему, это делает ajv. Мы же строим ее для того, чтобы отдать схему потом самому ajv.
Не натыкались на это решение, в любом случае она не подходила, тк у нас уже есть json-schema написанные в обычном объекте. Повторюсь, у нас уже использовался ajv для валидации до того как мы написали данное решение. Плюс мы работаем с реальной схемой, в любой момент можно вызвать свойство schema и работать с полученным объектом напямую, и никаких кастомных компиляторов не надо :)
Смотрели, не выбрали тк нам надо из имеющейся схемы создавать типы для ts а не наоборот
Все так. По поводу openAPI. у нас не так чтобы прям advanced схемы. тип int32, nullable и что-то еще(не помню что) поддерживается самим ajv и нареканий нет (хотя после вашего коментария уже начал сомневаться).
P.S. можно у нас также создать билдер со своим ajv инстансом, в случае если стандартный не подходит, потому-что не мы валидируем схему, а ajv
как уже было написано в статье, у нас уже был ajv и тянуть еще один пакет для деклараций одного и того же быть бы слишком, к тому же у зода есть типы которые не поддерживаются в JSON-Schema (function, symbol, Map, Set)
Аналоги валидации(и построения) схем кроме зода есть:
joi
yup
runtypes
io-ts
можете посмотреть тренды этих валидаций, ajv несомненный лидер https://npmtrends.com/ajv-vs-joi-vs-yup-vs-zod
Потому что как правило трейдинговые терминалы под капотом используют другие немного технологии например протокол фикс. Который используется для передачи финансовых данных между биржами. Поэтому узким местом является именно скорость работы биржи с которой ведутся торги, а не сам http2 протокол.
Интересная статья. Хотелось бы еще узнать как у вас обстоят дела с автоматизацией? Как именно TMS реагирует на то что сценарий автоматизирован(руками или по скрипту)?
Интересная статья показывающая варианты использования отмены промисов. Единственное замечание - это то что если промис отменить то node.js(предполагаю что в браузере анологичное поведение) удалит промис из call stack и еще и удалит ссылку на выполнение. Это значит, что мы экономим память приложению тк явно показываем GC что данный блок кода уже неактуален
извиняюсь что ввел в заблуждение, исправил это в статье
Спасибо за комментарий.
1) работа с предусловиями скорее всего будет реализована как система “компонентов”. Т.е. пользователь 1 раз проходит по, например логину. А затем будет возможность объеденить в “компонент логин”. Тут много пограничных случаев надо продумывать, поэтому только мысли.
2) Работает условно -
page.screenshot(). Возможности сравнивать скриншоты пока что нет между собой.3) Репо не пуст. Поскольку участники данного проекта не готовы выставить код на всеобщее обозрение в опен сорс, то ссылка ведет на публичный issue tracker.
Ваш ответ отличается от того, что будет в реальности. Если внимательно посмотреть на документацию к node.js в раздел про то как резолвятся зависимости из node_modules можно понять, что будет взят фаил исполняемый из "main" или "exports" package.json файла. Это значит, что если проект фронтедовский - там уже наверняка есть сборщик, который сминифицирует код как надо(например вебпак). Если проект на ноде, то с вероятностью 90% код не надо минифицировать, а если и надо, то скорее всего что-то не так и проблема в другом.
Получается Ваша статья лишена смысла, поскольку заниматься минифицированием это:
1) себе дороже, неблагодарный труд, особенно если библиотека и для node.js и для браузера
2) сборщик и так сминифицирует код (зачем дважды делать одно и тоже)
Тогда вопрос на засыпку. Вы написали библиотеку, сделали 2 сборки. dev и prod.
Я как разработчик нашел вашу либу, по функционалу все круто, то что я искал. Пишу `<пакертный менеджер установи либу>`. А затем импортирую в свой проект.
получится как-то так:
Вопрос. Какая тут сборка будет: dev или prod?
Согласен, вставлю свои 5 копеек.
Как разработчик на Node.JS, иногда во время дебага приходится лазить в исходники других npm пакетов, чтобы понять что условно результат устраивает меня(да, гипотечески это решается тестированием, но от багов никто не застрахован). В таком случае достаточно будет перейти в github и там создать issue на функционал либы. Плюс если пользуетесь yarn,pnpm пакетными менеджерами у них есть функционал по патчингу пакетов что позволяет не ждать фикса вашего любимого\критически важного пакета. Минификация в этом случае будет наоборот мешать вам инспектировать проблему другой либы.