Пишу либы на ваниле плюс плагины, никуда ничего не улетает. Последнее время оцениваю фронтенд с точки зрения удобства интеграции с ванилой, у свелт с этим все нормально. С бэком конечно проще всего, согласен.
Тоже начинал с toPromise))) думал зачем это все. Теперь честно делаю subscribe, но не из-за функционала больше, а потому что уж лучше что-то одно выбрать, везде использовать и не грузить зря мозг. Просто человеческий фактор.
Выберите один и разберём если хотите. С вас реализация и с меня. Хотя скорее всего это уже миллион раз было написано, может проще поискать? То что промисы не умеют это из коробки, не значит что нельзя вообще. Правильно? Вопрос в сложности реализации. Ок, можем померить. Только как будем оценивать?
Что касается retry policy ну такое себе. Даже если оно и есть, то уж наверно в одном месте завернуто и по большому счету какая разница как оно реализовано.
Мне кажется вы упорно пытаетесь игнорировать мой аргумент, что всему свое место. Допустим даже все ваши примеры будут в реальном приложении. Это ещё совсем не говорит о том, что теперь нужен rx. В этих случаях возможно красиво, но как насчёт всего остального? Концепция промисов проста и линейна, в ней проще разобраться, тогда как в Rx есть миллион операторов, которые ещё надо найти/запомнить. В целом то код усложнится. Вопрос ради чего? Ради красоты в трёх местах? Ок, у вас таких мест много — берите Rx, я бы и сам взял. Но это далеко не мейнстрим как мне кажется. И да, потом ещё отлаживать этот винегрет.
Не уверен что вы поняли мой посыл. Абстракция на то и абстракция, что берет только необходимое из реального мира. И в моем случае, также как мне кажется в большинстве, как минимум на данный момент то что я вижу на рынке и скорее всего останется — промисов вполне достаточно. А значит и не нужно пенеусложнять, придумывая себе проблемы на пустом месте. Я это про себя, а не про вас. Возможно у вас такие задачи составляют основную часть, но у меня — это такой минимум, что мне проще завернуть один хелпер, чем тащить Rx, потому что это однозначно усложнение, лишние абстракции, лишний вес, и пока нет нативной поддержки. Так что нет абсолют правильных абстракций, есть уместные. Таймауты прекрасно оборачиваются в промисы и я не понял о каком спагетти идёт речь, прекрасный линейный код на async/await.
А мне обычно достаточно промисов, а Rx считаю излишним усложнением. Ок, нельзя отменять, но зачем? Чаще всего результат идёт в локальный стейт компонента, ну и пусть пишет сколько хочет. Дебоунс нужен, но он просто вешается на внешнюю функцию/метод и все. А остальные Rx операторы если более менее серьезно использовать превращаются в кашу, которую ещё надо постараться отдалить. Не против Rx в целом, но против его пиара как универсального средства на замену промисам. Потому что ангуляр решил выпендриться. Почему observable? Давайте сразу каналы и возможность напихивать с двух сторон, но кому это надо?
На мой взгляд лучше взять простейшие промисы, async/await и допилить где надо, чем сразу брать Rx, потому что он как бы лишён недостатков промисов. Не надо забывать что главная проблема разработки — это сложность ПО, а ее недостаток фич. Ну я про свой CRUD все конечно, может у кого проблемы поглобальнее.
1. Работает везде, где есть javascript.
2. В том то и дело, что стратегия обработки таких ошибок может быть разная. В случае с травой валидаторы все независимые, но есть варианты как можно передать параметры.
1) использовать контекст (последний параметр) — он будет передан во все валидаторы, т.е. можно извлечь любые данные.
2) можно вначале проверить данные отдельно друг от друга, а затем проверить объект целиком. например:
const pointV = Trava([
{
width: isNumber,
height: isNumber,
},
Check((size, ...args) => size.width < size.height), // здесь ошибка вылетит на весь объект, последний элемент в args - контекст
// или например кастомная ошибка на одно из полей (при желании может быть что угодно):
Check(size => size.width < size.height, { height: 'должно быть больше width' }),
]);
const point = { width: 1, height: 2 };
pointV(point, { point }); // передали значение и контекст если нужно
Я больше за 2 вариант наверно. В траве ошибки — любые js примитивы, а валидаторы — обычные функции, поэтому довольно просто сделать любую обработку.
Все так и есть, но не для Compose, а для Keys и Each — там естественно возвращаются ошибки по всем полям/индексам. Но Compose — это последовательная цепочка валидаторов. Например
Да, подраздуло. Уже 57 )) А всего лишь обновил corejs. Я думал на счет модулей. Надо проверять конечно, но на первый взгляд проблему не решит, потому что основной объем — это обвязка над input + base + pattern, т.е. самое основное от которого никуда не деться. Маска для дат, enum и range зависят от pattern — тоже надо тянуть все. Независимые маски — это для чисел, функций и регулярок, из которых последние две — по 3 строчки кода. Сложностей добавляет то, что внутри есть определение маски по типу параметра mask и рекурсия. Честно даже не знаю как еще можно размер подрезать.
Даже выбросив поддержку ie11 и прочего старья получается 42КБ (imask.es.min.js), что тоже многовато. Остается надеяться разве что на gzip/brotli.
Спасибо за советы. Я конечно очень сомневаюсь что прям все будет работать))) но будем стараться.
Да, draggable очень больная тема, т.к. в разных браузерах вызывает разные события, или вообще не вызывает. Я выключил вообще drag, т.к. не нашел способа чтобы нормально работало хотя бы в большинстве случаев. Поэтому скорее всего все плохо :) Но у меня еще никто до вас про drag не спрашивал.
спасибо! было очень интересно
Пишу либы на ваниле плюс плагины, никуда ничего не улетает. Последнее время оцениваю фронтенд с точки зрения удобства интеграции с ванилой, у свелт с этим все нормально. С бэком конечно проще всего, согласен.
Что касается retry policy ну такое себе. Даже если оно и есть, то уж наверно в одном месте завернуто и по большому счету какая разница как оно реализовано.
Мне кажется вы упорно пытаетесь игнорировать мой аргумент, что всему свое место. Допустим даже все ваши примеры будут в реальном приложении. Это ещё совсем не говорит о том, что теперь нужен rx. В этих случаях возможно красиво, но как насчёт всего остального? Концепция промисов проста и линейна, в ней проще разобраться, тогда как в Rx есть миллион операторов, которые ещё надо найти/запомнить. В целом то код усложнится. Вопрос ради чего? Ради красоты в трёх местах? Ок, у вас таких мест много — берите Rx, я бы и сам взял. Но это далеко не мейнстрим как мне кажется. И да, потом ещё отлаживать этот винегрет.
На мой взгляд лучше взять простейшие промисы, async/await и допилить где надо, чем сразу брать Rx, потому что он как бы лишён недостатков промисов. Не надо забывать что главная проблема разработки — это сложность ПО, а ее недостаток фич. Ну я про свой CRUD все конечно, может у кого проблемы поглобальнее.
2. В том то и дело, что стратегия обработки таких ошибок может быть разная. В случае с травой валидаторы все независимые, но есть варианты как можно передать параметры.
1) использовать контекст (последний параметр) — он будет передан во все валидаторы, т.е. можно извлечь любые данные.
2) можно вначале проверить данные отдельно друг от друга, а затем проверить объект целиком. например:
Я больше за 2 вариант наверно. В траве ошибки — любые js примитивы, а валидаторы — обычные функции, поэтому довольно просто сделать любую обработку.
Вторая проверка зависит от первой, поэтому имеет смысл прерываться именно после первой. Compose можно рассматривать как and (&&), а Some как or (||).
Даже выбросив поддержку ie11 и прочего старья получается 42КБ (imask.es.min.js), что тоже многовато. Остается надеяться разве что на gzip/brotli.
Да, draggable очень больная тема, т.к. в разных браузерах вызывает разные события, или вообще не вызывает. Я выключил вообще drag, т.к. не нашел способа чтобы нормально работало хотя бы в большинстве случаев. Поэтому скорее всего все плохо :) Но у меня еще никто до вас про drag не спрашивал.