Promise.withResolvers(), Object.groupBy и неудержимые регулярки

[@igormalykhin5528]

Автору благодарность за обзор. Всегда с удовольствием жду Ваших новых видео!

[@it-sin9k]

спасибо большое!) очень приятно)

[@DubinArtur]

withResolwers очень давно не хватало. Приходилось обходиться костылями

[@AbraKadabra000]

тогда лови полифил 🩹
Promise.withResolvers || (Promise.withResolvers = function withResolvers() {
let resolve, reject, promise = new this((res, rej) => { resolve = res; reject = rej; });
return { resolve, reject, promise };
});

[@AlexanderBorshak]

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 один только синтаксический сахар останется...

[@Maxim9575]

Ну написать же свой полифил была не судьба глядя на внутренний алгоритм promise?

[@aleksd286]

Приведите пример пожалуйста)

[@DubinArtur]

@@Maxim9575 написать свой полифил для промиса - это и есть костыль

[@theDenQ]

Что-то вот с регулярками перебор. Синтаксис регулярных выражений должен быть одинаков независимо от языка программирования, а тут чет накрутили.
Поправьте, мб я не прав...

[@it-sin9k]

я тоже как то столкнулся с тем, что надо было одно и тоже валидировать с помощью регулярки на нескольких языках. И вот был для меня сюрприз, что все регулярки по разному отрабатывали)

[@AlexanderBorshak]

Вытянуть ресолв наружу промиса - как два байта описать... ))
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);

[@Maxim9575]

Такая реализация нарушает две защиты:
1) resolver и reject должны быть функциями
2) resolver и reject не должны быть переопределены
Исходя из этого ваша соска-пустышка может знатно взорвать кусок большой логики если не предусмотреть эти защиты которые описаны в спецификации

[@it-sin9k]

так то да) только теперь не надо иметь такие обертки) все из коробки же)

[@AlexanderBorshak]

@@it-sin9k Как по мне, проблема в том, что у JS непонятно, где ядро языка, а где стандартная библиотека. И если бы все эти свистоперделки вносились в библиотеку, то все ОК. А тут такое впечатление, что они вносятся в ядро JS. Ядро, в котором постоянно прирастают какие-то второстепенные фичи - ну, такое, на любителя (ИМХО, конечно).

[@gooseob]

@@Maxim9575 можешь с примерами? оба пункта непонятны

[@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")

[@TheTexPro]

Спасибо большое!

[@HEX_CAT]

♥♥♥

[@amat0ru]

что так редко видео выходят. один из немногих каналов про жс который мне нравится смотреть, и то я не знаю почему может как раз потому что редко видео выходят

[@Virass]

Думаю что в первую очередь Синяк разработчик, а потом лишь ютубер, потому и видео не так часто

[@it-sin9k]

хорошо сказано) это хобби) не более того)

[@Virass]

@@it-sin9k Думаю это даже очень хорошо, не стоит на конвеер ставить производство видео. Лучше редко но отлично чем часто но посредственно)

[@Vitali_1976]

Саня ты супер 🙌

[@kai.hexendorf]

Хотя promise можно передавать от одного модуля другому, и у него могут быть множество подписчиков, но всё равно, как его не расширяй, он не заменит собой RX библиотеки. Поэтому кроме как обработки fetch-запросов я нигде не использую promise. Асинхронную коммуникацию между модулями, управление потоками данных удобнее осуществлять rx-пайплайнами, особенно если rx интегрировать еще в jsx-компоненты и в state-managment.

[@user-px5no4vy9e]

Вот буквально позавчера свой костыль groupBy писал.. А тут такое

[@dmtrkskv]

Почему костыль? Это же просто функция, которая кстати есть во многих библиотеках

[@kai.hexendorf]

groupBy более короткий вариант того, что можно было сделать с помощью reduce

[@dmtrkskv]

@@kai.hexendorf так можно и про большинство других утилитарных функций сказать: map, filter, join, find, includes и т.д.. Все их можно через reduce сделать))
reduce - это универсальный инструмент обхода массива с накоплением результата, а groupBy ясно дает понять намерение программиста.
P.S. includes и find через reduce будут избыточно обходить весь массив.

[@kai.hexendorf]

@@dmtrkskv как их сделать через reduce? filter не меняет тип, но меняет длину массива; map - меняет тип, но сохраняет длину массива, а find и includes не обязаны обходить все элементы массива. reduce - принципиально другой, и groupBy можно свести к reduce

[@dmtrkskv]

@@kai.hexendorf find и includes при реализации через reduce будут избыточно обходить весь массив, да. Но filter и map при реализации через reduce будут эффективно работать: в качестве аккумулятора нужно использовать новый массив, заполняемый по мере обхода исходного. Также через reduce можно эффективно сделать функции sum, min, max для массива чисел, функцию join и др.. Я к тому, что reduce это очень универсальный инструмент для обхода массива с накоплением результата, а groupBy более специализированная функция, использование которой в коде очень понятно выражает намерение программиста.

[@AbraKadabra000]

регулярки не доразжёваны. а так ок.
можно было бы добавить что груп бай работает примерно как groupBy в lodash

[@SuperWolchara]

Как по мне предыдущий промис был нормальный. Этот какой то беспорядок вносит

[@Maxim9575]

"Альтернативный метод работы с промисами" - хорошая шутка.

[@it-sin9k]

почему?

[@Maxim9575]

@@it-sin9k потому что писали простейшие аналоги, что следовательно не приводит к какой-то новой механике взаимодейcтвия с promise

[@jyjyjyj3]

@@Maxim9575чел. Дай угадаю. Ты либо только учишь фронт, либо у тебя коммерческого опыта не больше года.
Только новички могу так подрываться на такие формулировки и придираться к мелочам

[@it-sin9k]

альтернативный метод работы не тоже самое что новая механика. Была бы новая механика прям, я бы так и сказал бы

[@Maxim9575]

@@it-sin9k согласен)