Р
это понятно, почему оно отложено?
Чтобы не блокировать основной поток, задача кладется таким образом в очередь колбэков.
Size: a a a
2021 February 04
AM
Там если чуть вниз пролистать, то будет регулярка еще короче.
Я бы предпочел написать длинный, но понятный разработчику вариант и поместить его в функцию, если нет стандартного решения. А не писать таких регулярок что бы потом голову ломать думая как её доработать.
A
Alexey M
Я бы предпочел написать длинный, но понятный разработчику вариант и поместить его в функцию, если нет стандартного решения. А не писать таких регулярок что бы потом голову ломать думая как её доработать.
Если речь о регулярках, то варианта "понятный разработчику" априори не существоует. Чтобы было понятно регулярки лучше не писать, а вместо них заюзать остаток от деления либо Intl.NumberFormat
AM
согласен
AM
но всё же есть ряд задач где регулярка более удобна.
это конечно была не одна из них ))
это конечно была не одна из них ))
KH
Это дебаунс для отложенного вызова reject из очереди когда запрос "протухнет"
пытался вникнуть. Не уверен, где здесь дебаунс. Мы делаем clearTimeout, насколько я понимаю он синхронный, значит reject не выполнится. Может углубимся немного? Например уберём setTimeout оттуда и вызовем resolve(), какая проблема появится?
V
я про то, что clearTimeout убивает reject по таймеру и ставит новый таймаут на resolve в очередь задач, который случится сразу после выполнения основного кода
DS
https://github.com/HowProgrammingWorks/NodejsStarterKit/commit/744df91ae3748be3f6933910f14e6c96204f038a
Пример как (не) надо писать коммит мессаджи) Описываем не то, что мы делаем, а зачем мы это делаем)
Пример как (не) надо писать коммит мессаджи) Описываем не то, что мы делаем, а зачем мы это делаем)
KH
отличная попытка кстати )) я и не подумал там искать.
KH
да, видимо пора, спасибо. Надеюсь там найду ответ. Только справедливости ради это видео было раньше того коммита =))).
V
просто я сам только вчера изучал код StarterKit и Example, и не во всю структуру еще въехал
KH
ну и речь тут не про семафор, а скорее понять, что надо откладывать, а что нет. Вот надо тебе вызвать resolve и без задней мысли бы вызвал. Не увидел бы причины, что он что-то "блочит".
V
application.init() меня вчера убил своей загрузкой модулей и файлов
N
подскажите если мы делаем в файле MyObj export new my_obj() в одном файле и дальше
вызываем в file1.js import my_obj from MyObj и дальше по коду
вызываем в file2.js import my_obj from MyObj , my_obj будет инициализироваться каждый раз (коммандой new) или проинициализируется только первый раз а дальше по коду везде где мы делаем import мы получим тот же самый первый обьект?
вызываем в file1.js import my_obj from MyObj и дальше по коду
вызываем в file2.js import my_obj from MyObj , my_obj будет инициализироваться каждый раз (коммандой new) или проинициализируется только первый раз а дальше по коду везде где мы делаем import мы получим тот же самый первый обьект?
N
спасибо. а где про это можно почитать? почему так происходит
A
Один раз
В большинстве случаев - да, но есть нюансы, которые могут быть в "и дальше по коду"
N
import выходит сквозной?
OJ
Вы когда проект клонируете потом его устанавливаете с npm i или npm ci?