DS
не советую листать мой гитхаб. там просто свалка разных идей, из которых большинство оказались провальными))
Звучит как "никогда не заходи в эту комнату", теперь еще ж больше захотелося)
Size: a a a
2020 August 17
AA
очевидно, как и пилить очередную такую же, для решения проблемы нужен другой подход
Кстати, какой другой подход помимо фабрики юнитов поможет избежать ручного описания всех юнитов всех полей и ручного их связывания? Мне действительно интересно, поскольку мне не приходит в голову ничего кроме фабрики или композиции из фабрик (что не сильно отличается)
YL
Как ты понял, что они провалились
Даже идея с формами?
Даже идея с формами?
так инструмент с формами уже ему не принадлежит, он упомянул)
ЕГ
так инструмент с формами уже ему не принадлежит, он упомянул)
Я другое у него видел, но сам подход для статического объявления полей и их обработки мне зашел - удобно
2020 August 18
🚀🚀
+ имхо это идет в разрез с эффектором. он про атомарные сторы, ивенты и вот это все, а тут одной функцией создаем все поля. А потом идут неконсистентные использования combine
Куда лучше бы, на мой взгляд, было юзать что-то типа такого
Куда лучше бы, на мой взгляд, было юзать что-то типа такого
const $login = createField({
init: "",
rules: [required]
})
console.log($login.value, $login.isValid, $login.errors)чтобы использовать декларативный подход нужно иметь гарантии того, что решение вообще покрывает кейсы
то есть нельзя просто сказать «го всё делать в стиле сэмпла», нужно сначала покрыть все необходимые ситуации, а только потом уже обобщать апи для работы с ними
то есть нельзя просто сказать «го всё делать в стиле сэмпла», нужно сначала покрыть все необходимые ситуации, а только потом уже обобщать апи для работы с ними
🚀🚀
а в случае с формами всё, вот буквально всё указывает на то, что до обобщения сути работы с ними ещё как до луны
З
чтобы использовать декларативный подход нужно иметь гарантии того, что решение вообще покрывает кейсы
то есть нельзя просто сказать «го всё делать в стиле сэмпла», нужно сначала покрыть все необходимые ситуации, а только потом уже обобщать апи для работы с ними
то есть нельзя просто сказать «го всё делать в стиле сэмпла», нужно сначала покрыть все необходимые ситуации, а только потом уже обобщать апи для работы с ними
так
createForm такой же декларативныйЗ
и страдает теми же проблемами)
🚀🚀
поэтому я воодушевлён подходом @aanarion, потому что в такой ситуации нет никаких вариантов кроме как идти от реальных кейсов, причём критически важно идти именно от своих
AA
а в случае с формами всё, вот буквально всё указывает на то, что до обобщения сути работы с ними ещё как до луны
Тут полностью согласен, на такое боюсь претендовать :)
Пока моя задача - покрыть типичные кейсы с динамическими полями - например получения полей формы с апи и условные поля. Дальше посмотрим)
Пока моя задача - покрыть типичные кейсы с динамическими полями - например получения полей формы с апи и условные поля. Дальше посмотрим)
DS
@ZeroBias customDocument нужон для ssr ?
꧁岡
такс, а можно ли замапленым сторам имя дать?
а почему нельзя?
или не нужно?
а почему нельзя?
или не нужно?
DS
такс, а можно ли замапленым сторам имя дать?
а почему нельзя?
или не нужно?
а почему нельзя?
или не нужно?
Зачем сторам вообще имена давать?
꧁岡
꧁岡
ну хотя да, там и так все через $ видно
꧁岡
хм, я тут подумал может добавить опцию в бабельконфиг эффектора чтобы выборочно транспилить юниты для логгера?
а то ща в редакс девтулзах сторы приложения и тонны эффектов где 2 стора inFlight и pending и все в перемешку
а то ща в редакс девтулзах сторы приложения и тонны эффектов где 2 стора inFlight и pending и все в перемешку
꧁岡
вот такая помойка выходит
꧁岡
DS
хм, я тут подумал может добавить опцию в бабельконфиг эффектора чтобы выборочно транспилить юниты для логгера?
а то ща в редакс девтулзах сторы приложения и тонны эффектов где 2 стора inFlight и pending и все в перемешку
а то ща в редакс девтулзах сторы приложения и тонны эффектов где 2 стора inFlight и pending и все в перемешку
console + filter
꧁岡
console + filter
?