Что-то вот с регулярками перебор. Синтаксис регулярных выражений должен быть одинаков независимо от языка программирования, а тут чет накрутили. Поправьте, мб я не прав...
я тоже как то столкнулся с тем, что надо было одно и тоже валидировать с помощью регулярки на нескольких языках. И вот был для меня сюрприз, что все регулярки по разному отрабатывали)
Такая реализация нарушает две защиты: 1) resolver и reject должны быть функциями 2) resolver и reject не должны быть переопределены Исходя из этого ваша соска-пустышка может знатно взорвать кусок большой логики если не предусмотреть эти защиты которые описаны в спецификации
@@it-sin9k Как по мне, проблема в том, что у JS непонятно, где ядро языка, а где стандартная библиотека. И если бы все эти свистоперделки вносились в библиотеку, то все ОК. А тут такое впечатление, что они вносятся в ядро JS. Ядро, в котором постоянно прирастают какие-то второстепенные фичи - ну, такое, на любителя (ИМХО, конечно).
@@gooseob суть такова: 1) Если вы расширяете Promise конструктор, то вы можете в методе конструктора класса вызвать тот самый executor передав ему какие-либо аргументы; далее создавая такой promise экземпляр вы получите ошибку, которая будет гласить что нельзя переопределить resolver и reject. 2) Если вы используете методы Promise, например для конструктора который не является Promise или наследует его Promise.resolve.call(function(executor) { let obj = {value: null}; /// Убрав аргументы ниже вы получите ошибку что аргументы должны быть function типа т.е. callable executor((v) => obj.value = v, (v) => {}); return obj }, "hello")
что так редко видео выходят. один из немногих каналов про жс который мне нравится смотреть, и то я не знаю почему может как раз потому что редко видео выходят
Хотя promise можно передавать от одного модуля другому, и у него могут быть множество подписчиков, но всё равно, как его не расширяй, он не заменит собой RX библиотеки. Поэтому кроме как обработки fetch-запросов я нигде не использую promise. Асинхронную коммуникацию между модулями, управление потоками данных удобнее осуществлять rx-пайплайнами, особенно если rx интегрировать еще в jsx-компоненты и в state-managment.
@@kai.hexendorf так можно и про большинство других утилитарных функций сказать: map, filter, join, find, includes и т.д.. Все их можно через reduce сделать)) reduce - это универсальный инструмент обхода массива с накоплением результата, а groupBy ясно дает понять намерение программиста. P.S. includes и find через reduce будут избыточно обходить весь массив.
@@dmtrkskv как их сделать через reduce? filter не меняет тип, но меняет длину массива; map - меняет тип, но сохраняет длину массива, а find и includes не обязаны обходить все элементы массива. reduce - принципиально другой, и groupBy можно свести к reduce
@@kai.hexendorf find и includes при реализации через reduce будут избыточно обходить весь массив, да. Но filter и map при реализации через reduce будут эффективно работать: в качестве аккумулятора нужно использовать новый массив, заполняемый по мере обхода исходного. Также через reduce можно эффективно сделать функции sum, min, max для массива чисел, функцию join и др.. Я к тому, что reduce это очень универсальный инструмент для обхода массива с накоплением результата, а groupBy более специализированная функция, использование которой в коде очень понятно выражает намерение программиста.
@@Maxim9575чел. Дай угадаю. Ты либо только учишь фронт, либо у тебя коммерческого опыта не больше года. Только новички могу так подрываться на такие формулировки и придираться к мелочам
Автору благодарность за обзор. Всегда с удовольствием жду Ваших новых видео!
спасибо большое!) очень приятно)
withResolwers очень давно не хватало. Приходилось обходиться костылями
тогда лови полифил 🩹
Promise.withResolvers || (Promise.withResolvers = function withResolvers() {
let resolve, reject, promise = new this((res, rej) => { resolve = res; reject = rej; });
return { resolve, reject, promise };
});
const promiseWithResolver = () => {
let resolve, reject;
const promise = new Promise((res, rej) => {
resolve = res;
reject = rej;
});
return {
promise,
resolve,
reject
};
}
const {resolve, reject, promise} = promiseWithResolver();
promise.then(result => {
console.log("PROMISE RESULT", result)
})
setTimeout(() => {
resolve(123);
}, 1_000);
Тянут в язык все подряд, скоро от JS один только синтаксический сахар останется...
Ну написать же свой полифил была не судьба глядя на внутренний алгоритм promise?
Приведите пример пожалуйста)
@@Maxim9575 написать свой полифил для промиса - это и есть костыль
Что-то вот с регулярками перебор. Синтаксис регулярных выражений должен быть одинаков независимо от языка программирования, а тут чет накрутили.
Поправьте, мб я не прав...
я тоже как то столкнулся с тем, что надо было одно и тоже валидировать с помощью регулярки на нескольких языках. И вот был для меня сюрприз, что все регулярки по разному отрабатывали)
Вытянуть ресолв наружу промиса - как два байта описать... ))
const promiseWithResolver = () => {
let resolve, reject;
const promise = new Promise((res, rej) => {
resolve = res;
reject = rej;
});
return {
promise,
resolve,
reject
};
}
const {resolve, reject, promise} = promiseWithResolver();
promise.then(result => {
console.log("PROMISE RESULT", result)
});
setTimeout(() => {
resolve(123);
}, 1_000);
Такая реализация нарушает две защиты:
1) resolver и reject должны быть функциями
2) resolver и reject не должны быть переопределены
Исходя из этого ваша соска-пустышка может знатно взорвать кусок большой логики если не предусмотреть эти защиты которые описаны в спецификации
так то да) только теперь не надо иметь такие обертки) все из коробки же)
@@it-sin9k Как по мне, проблема в том, что у JS непонятно, где ядро языка, а где стандартная библиотека. И если бы все эти свистоперделки вносились в библиотеку, то все ОК. А тут такое впечатление, что они вносятся в ядро JS. Ядро, в котором постоянно прирастают какие-то второстепенные фичи - ну, такое, на любителя (ИМХО, конечно).
@@Maxim9575 можешь с примерами? оба пункта непонятны
@@gooseob суть такова:
1) Если вы расширяете Promise конструктор, то вы можете в методе конструктора класса вызвать тот самый executor передав ему какие-либо аргументы; далее создавая такой promise экземпляр вы получите ошибку, которая будет гласить что нельзя переопределить resolver и reject.
2) Если вы используете методы Promise, например для конструктора который не является Promise или наследует его Promise.resolve.call(function(executor) {
let obj = {value: null};
/// Убрав аргументы ниже вы получите ошибку что аргументы должны быть function типа т.е. callable
executor((v) => obj.value = v, (v) => {});
return obj
}, "hello")
Спасибо большое!
♥♥♥
что так редко видео выходят. один из немногих каналов про жс который мне нравится смотреть, и то я не знаю почему может как раз потому что редко видео выходят
Думаю что в первую очередь Синяк разработчик, а потом лишь ютубер, потому и видео не так часто
хорошо сказано) это хобби) не более того)
@@it-sin9k Думаю это даже очень хорошо, не стоит на конвеер ставить производство видео. Лучше редко но отлично чем часто но посредственно)
Саня ты супер 🙌
Хотя promise можно передавать от одного модуля другому, и у него могут быть множество подписчиков, но всё равно, как его не расширяй, он не заменит собой RX библиотеки. Поэтому кроме как обработки fetch-запросов я нигде не использую promise. Асинхронную коммуникацию между модулями, управление потоками данных удобнее осуществлять rx-пайплайнами, особенно если rx интегрировать еще в jsx-компоненты и в state-managment.
Вот буквально позавчера свой костыль groupBy писал.. А тут такое
Почему костыль? Это же просто функция, которая кстати есть во многих библиотеках
groupBy более короткий вариант того, что можно было сделать с помощью reduce
@@kai.hexendorf так можно и про большинство других утилитарных функций сказать: map, filter, join, find, includes и т.д.. Все их можно через reduce сделать))
reduce - это универсальный инструмент обхода массива с накоплением результата, а groupBy ясно дает понять намерение программиста.
P.S. includes и find через reduce будут избыточно обходить весь массив.
@@dmtrkskv как их сделать через reduce? filter не меняет тип, но меняет длину массива; map - меняет тип, но сохраняет длину массива, а find и includes не обязаны обходить все элементы массива. reduce - принципиально другой, и groupBy можно свести к reduce
@@kai.hexendorf find и includes при реализации через reduce будут избыточно обходить весь массив, да. Но filter и map при реализации через reduce будут эффективно работать: в качестве аккумулятора нужно использовать новый массив, заполняемый по мере обхода исходного. Также через reduce можно эффективно сделать функции sum, min, max для массива чисел, функцию join и др.. Я к тому, что reduce это очень универсальный инструмент для обхода массива с накоплением результата, а groupBy более специализированная функция, использование которой в коде очень понятно выражает намерение программиста.
регулярки не доразжёваны. а так ок.
можно было бы добавить что груп бай работает примерно как groupBy в lodash
Как по мне предыдущий промис был нормальный. Этот какой то беспорядок вносит
"Альтернативный метод работы с промисами" - хорошая шутка.
почему?
@@it-sin9k потому что писали простейшие аналоги, что следовательно не приводит к какой-то новой механике взаимодейcтвия с promise
@@Maxim9575чел. Дай угадаю. Ты либо только учишь фронт, либо у тебя коммерческого опыта не больше года.
Только новички могу так подрываться на такие формулировки и придираться к мелочам
альтернативный метод работы не тоже самое что новая механика. Была бы новая механика прям, я бы так и сказал бы
@@it-sin9k согласен)