fullstack-development
Выпилить react-final-form. Вернуть redux-form
Мы не можем шарить стейт формы между фичами. С redux-form приложения лучше будут масштабироваться в общем случае потому что redux не накладывает ограничений на доступ к своему стейту. Уход от redux-form должен был как-то обосновываться, приведите эти обоснования пожалуйста
Одно очень весомое обоснование, redux-form на больших формах лагает безбожно.
и если тебе нужно дублировать стейт формы в редакс, ты можешь легко это сделать с помощью final-form.
Одно очень весомое обоснование, redux-form на больших формах лагает безбожно.
за счёт чего лагает?
и если тебе нужно дублировать стейт формы в редакс, ты можешь легко это сделать с помощью final-form.
single source of truth же. Дублирование - источник багов
за счет того что редакс)) а в форме очень много данных постоянно меняется, там же не только текущие значения инпутов, а еще много разной доп. информации, и на каждое изменение у тебя перерисовывается вся форма.
Ну вообще, если ты хочешь шарить весь стейт формы в другую фичу, то возможно ты что-то делаешь не так))
за счет того что редакс)) а в форме очень много данных постоянно меняется, там же не только текущие значения инпутов, а еще много разной доп. информации, и на каждое изменение у тебя перерисовывается вся форма.
так а чо редакс) Редакс не добавляет лагов, если рендер оптимизирован. У нас просто не оптимизируют и это предмет отдельного обсуждения. Т.е. можно писать так чтобы не лагало всё это
Ну вообще, если ты хочешь шарить весь стейт формы в другую фичу, то возможно ты что-то делаешь не так))
очень редко, но всё-таки появляется. И очень грустно будет когда она снова появится, но react-final-form мне не позволит(
у тебя форма принимает функционального чилдрена, и он будет перерисован на любое изменение стейта формы, остается городить костыли и как-то отсекать перерисовку, но если даже ты так сделаешь, то что-то мне подсказывает, что поломаешь отрисованные внутри филды и они не подхватят новый стейт (могу ошибаться). Плюс филды тоже перерисовывают переданную им компоненту постоянно. в final-form ввели механизм подписок, ты можешь гибко управлять перерисовками.
Писал большой коммент и гитхаб его просрал... переписывать нет времени пока :(
В общем были конкретные кейсы на проектах, когда redux-form дико лагал и мы ничего с этим сделать не могли.
Вообще я предлагаю пока эту тему немного позже обсудить. Может быть мы свое type-safe решение для форм напилим на алгебраических типах.
Писал большой коммент и гитхаб его просрал... переписывать нет времени пока :(
В общем были конкретные кейсы на проектах, когда redux-form дико лагал и мы ничего с этим сделать не могли.
Я не вижу в redux-form ничего что могло бы провоцировать лаги на самой форме. У тебя всё прозаично возможно было: redux-form обильно диспатчит экшены, а рендер контейнеров зачастую неоптимизирован и реагирует на эти диспатчи и вызывает лаги.
Вообще я предлагаю пока эту тему немного позже обсудить. Может быть мы свое type-safe решение для форм напилим на алгебраических типах.
Во-первых, пока мы соберёмся это пилить, пока напилим, всё это время мы не будем иметь возможности идиоматично решать отдельный класс задач на новых проектах.
Во-вторых, не думаю что мы сможем напилить что-то значительно лучшее по сравнению с redux-form. Автор полировал API под десятки-сотни различных примеров форм, у нас такого количества нет.
Ну и не заметил особых проблем с типами в redux-form
я не хочу заниматься оптимизацией рендера форм, у меня нет на это времени.
В чем разница между redux-form и final-form - redux-form дает возможность управлять формой извне, если быть точным из любого уголка твоего приложения, т.к. ты можешь диспатчить экшены редакс-формы. И ситуация, когда тебе, в каком-то рядовом проекте, нужно залезть в потроха формы не из формы, мне кажется уже выглядит криво.
короч нужно из двух зол выбрать наименьшее))
- с одной стороны final-form, который не позволяет лезть в форму извне (читать стейт формы мы можем без проблем), но при этом решает проблемы производительности redux-form
- с другой стороны redux-form, который дает больше гибкости по управлению формами извне (что мне кажется приводит к увеличению кол-ва говнокода на проекте), но при этом есть проблемы с производительностью, о которых нужно постоянно думать и закрывать какими-то ~костылями~ оптимизациями рендера.
Мне кажется, тут оставить просто как есть, чтобы не тратить время в пустую, пока есть final-form, который не имеет столь критичных недостатков, чтобы с него уходить. На других проектах, где реально нужно иметь всю полноту гибкости, можно юзать redux-form :)
я не хочу заниматься оптимизацией рендера форм, у меня нет на это времени.
я не говорил про оптимизацию форм. Я говорил про все контейнеры в принципе, потому что они все откликаются на любые диспатчи, включая диспатчи от redux-form. У тебя в любом случае в любой момент может появиться требование от заказчика с каким-нибудь высоко-интенсивным обновлением стейта приложения и тогда тебе всё равно придётся оптимизировать рендер. В этом нет ничего сверх сложного, просто надо учитывать в самом начале.
В чем разница между redux-form и final-form - redux-form дает возможность управлять формой извне, если быть точным из любого уголка твоего приложения, т.к. ты можешь диспатчить экшены редакс-формы. И ситуация, когда тебе, в каком-то рядовом проекте, нужно залезть в потроха формы не из формы, мне кажется уже выглядит криво.
Что значит потроха? Нужен доступ к стейту формы за пределами формы. Регулярно такие требования возникают. Ничего кривого не вижу: у тебя могут возникать моменты в которых тебе необходимо заполнить форму из других частей приложения
короч нужно из двух зол выбрать наименьшее))
- с одной стороны final-form, который не позволяет лезть в форму извне (читать стейт формы мы можем без проблем), но при этом решает проблемы производительности redux-form
- с другой стороны redux-form, который дает больше гибкости по управлению формами извне (что мне кажется приводит к увеличению кол-ва говнокода на проекте), но при этом есть проблемы с производительностью, о которых нужно постоянно думать и закрывать какими-то ~костылями~ оптимизациями рендера.
ещё раз подчеркну. У redux-form нет проблем с производительностью, связанные с ним проблемы могут быть только у всего приложения. Проблемы в реации на высокоинтесивный диспатч экшенов. Такой диспатч может понадобиться и при других требованиях заказчика. Отказ от redux-form это попытка ухода от необходимости оптимизировать приложение
Мне кажется, тут оставить просто как есть, чтобы не тратить время в пустую, пока есть final-form, который не имеет столь критичных недостатков, чтобы с него уходить. На других проектах, где реально нужно иметь всю полноту гибкости, можно юзать redux-form :)
так ты не сможешь на старте определить насколько гибко нужно работать со стейтом формы. Когда ты уже напилишь кучу форм c final-form и тебе понадобится гибкость - будет поздно менять всё это на redux-form
А почему final-form менее гибкая? Может быть эта либа не позволяет легко залезть в стейт извне, но в целом там ты тот же класс задач можешь решить, что и на redux form, насколько я понимаю. И мне кажется норм, что если тебе надо нарушать абстрагирование форм, то это будет не так просто — заводи тогда явный контракт у контейнера-держателя формы и явно там прописывай как извне могут влиять на стейт.
По поводу гибкости final-form мне кажется даже обходит redux-form, там можно писать декораторы для формы и вклиниваться в работу формы, подписываться на какие-то изменения в форме, как-то на них реагировать и в том числе взаимодействовать с формой (изменять ее стейт/поведение). Тут код реализации calculated fields, тут демка. Хз как такое сделать на redux-form (без задротства).
А почему final-form менее гибкая? Может быть эта либа не позволяет легко залезть в стейт извне, но в целом там ты тот же класс задач можешь решить, что и на redux form, насколько я понимаю. И мне кажется норм, что если тебе надо нарушать абстрагирование форм, то это будет не так просто — заводи тогда явный контракт у контейнера-держателя формы и явно там прописывай как извне могут влиять на стейт.
Мне не нужно нарушать абстрагирование форм. Формы в redux-form предоставляют интерфейс в виде экшен креаторов, которые я могу передать в любую часть приложения и диспатчить там. Это их публичный интерфейс и он не нарушает абстракцию. Это единый механизм по предоставлению доступа к стейту в react-redux архитектуре в принципе.
Ввод каких-то особенных штук со своим локальным стейтом, со своими контрактами которые нужно по-особенному заполнять портит эту архитектуру: т.е. на верхнем уровне при коммуникации между фичами у меня к привычным контейнерам, экшенам и селекторам начнут появляться особенные штуки, которые отвечают отдельно за работу со стейтом форм. Чем это формы так особенны?
Ну и я не думаю что эта либа позволит залезть в стейт в принципе. Как ты себе это представляешь?
Сам автор пишет, что для тесной интеграции с redux react-final-form не подойдёт
Хз как такое сделать на redux-form (без задротства).
мне кажется тут легко реализовать: слушать экшены по изменению филдов, селектить значения зависимых филдов и диспатчить экшен по изменению калькулируемоего филда
Это их публичный интерфейс и он не нарушает абстракцию.
Сысле не нарушает? Ты видел что там с формой можно творить из "любой части приложения"? Нужно всего-то знать имя формы и возможно имена интересующих полей.
Сам автор пишет, что для тесной интеграции в redux
Мне кажется прежде чем пытаться тесно интегрироваться с чем-то, нужно сотню раз подумать, а стоит ли настолько глубоко связываться с этим чем-то, и можно ли обойтись какой-то менее тесной интеграцией. В случае с редакс форм мы можем нахреновертить такого, что потом концов не найдешь. Файнал форм такого не позволяет делать, и это ящитаю правильно.
Мне кажется прежде чем пытаться тесно интегрироваться с чем-то, нужно сотню раз подумать, а стоит ли настолько глубоко связываться с этим чем-то, и можно ли обойтись какой-то менее тесной интеграцией. В случае с редакс форм мы можем нахреновертить такого, что потом концов не найдешь. Файнал форм такого не позволяет делать, и это ящитаю правильно.
Так требования нахреновертить идут от бизнес-требований. Если есть требование ткнуть в одно место и заполнить форму или засабмитить форму совершенно в другом месте то redux-form тут ни в чём не виноват. Наоборот, позволяет легче сделать
мне кажется тут легко реализовать: слушать экшены по изменению филдов, селектить значения зависимых филдов и диспатчить экшен по изменению калькулируемоего филда
У меня сразу возникает много вопросов касательно того где и как должна быть написана такая логика:
- кто будет запускать эти дополнительные саги?
- что делать если инстансов форм может быть несколько?
- что если одна и та же форма с одинаковой калькуляцией понадобилась в двух других фичах?
Тут по-моему выход один, придется эту форму делать фичей, тем самым делая структуру проекта и дерево зависимостей между фичами немного сложнее.
кто будет запускать эти дополнительные саги?
фича в которой находится эта форма
что делать если инстансов форм может быть несколько?
делать несколько инстансов фичи
что если одна и та же форма с одинаковой калькуляцией понадобилась в двух других фичах?
сделать два инстанса фичи и передать контейнеры с формами
ткнуть в одно место и заполнить
это реализуемо
засабмитить форму совершенно в другом месте
А это немного противоестественное требование, и решение будет соответствующим, что в случае с редакс форм (диспатч сабмита формы хз откуда), что в случае с файнал форм (можно сделать через рефку). Согласен с редакс форм будет проще, но это по мне всё равно остаётся костылем.
как? дублированием стейта формы с прокидыванием в филд?
Инициализацией формы, насколько я помню Form обновляет значения филдов при изменении пропса initialValues.