Комментарии 17
react-hook-form.com
подгружаемые скрипты:
обработчик команд, скрытие полей
валидация
Есть пример многооконного СПА :)
Документация
Исходники
Давно не слежу. А есть для mobx либа/фреймворк для форм приличный?
и final-form.
Final-form + mobx — показалось идеальным для меня.
Final-form имеет, по сути, свой реактивный (?) стейт-менеджер. насколько оправдано интегрировать его с mobx?
Необходимо дополнительно оборачивать кусок разметки, нуждающийся в каком-то наблюдаемом значении, в observer (nesting-caveat).
Но самое важное в mobx, что логику можно пытаться писать в декларативном виде. Т.е. не как обычно принято, что можно назвать событийное программирование, когда например пишем обработчик обработки события изменения текста в поле ввода, и в этом обработчике вызываем десяток функций которые что-то вычисляют и меняют в других полях, в итоге получается лапша. А более декларативно, например что данное поле на форме является функцией вот этих трех полей. И если значение любого их этих трех полей поменяется, то перевычислится и значение данного поля. Причем не важно как оно поменяется, пользователь поменяет, или оно само зависит от 4го поля.
С MobX же любые вопросы в том числе и этот элементарно на раз два и никаких проблем с производительность вне зависимости от того, какой размер формы.
Основная проблема заключается в том, что при вводе каждой буквы в соответствующих полях вся форма будет перерисовываться, что влечет за собой проблемы с производительностью, особенно на мобильных устройствах.
Вы серьезно? Знаете что я делаю когда мне нужно отобразить сложные формы как в вашем случае когда у нас "в общей сложности более 80 разных полей"?
Я не использую никакие стейт-менеджеры или библиотеки для форм я просто использую обычный реакт и в каждом обработчике поля onChange пишу примерно такое
<input onChange={(e)=>{
AppState.form.someField = e.target.value;
//валидация или другая логика
actualize() //однострочный хелпер который вызывает ReactDOM.render(<App/>, el)
}}/>Увидев вызов ReactDOM.render(<App/>), вы наверное подумаете "о боги, это же перерисовка всего приложения при вводе каждой буквы!". Поэтому позвольте мне напомнить что такое "перерисовка" в терминах реакта. В реакте "перерисовка" это просто рекурсивное сравнение двух деревьев js-объектов чтобы изменить в html/dom только то что отличается. Сравнение очень быстрое — никаких медленных обращений к дом-элементам, алгоритм линейный (просто спуск по дереву объектов и сравнение свойств с соответствующим объектом от предыдущего вызова перерисовки), сам javascript умеет компилироваться в ассеблер и его скорость на уровне с++ или даже быстрее (https://www.youtube.com/watch?v=UJPdhx5zTaw). В общем за 1мс можно "перерисовать" или точнее сравнить дерево из 50к объектов. И на этом фоне ваши желания оптимизировать вызов "перерисовки" отдельных компонентов для формы из всего лишь 100 полей выглядят забавно
хотя бы раз нужно читать документацию…
чтобы форма не ререндерилась каждый раз при вводе символа в какой-либо инпут, нужно убрать подписку на values у всей формы
https://final-form.org/docs/react-final-form/examples/subscriptions
и, если нужно, использовать доступ только к определенным полям ближе к коду, где это необходимо (через Field или FormSpy)
в целом все «живые» библиотеки для форм плюс/минус одинаковые, я работал с redux-form 2 года, переехал на final-form.
причем у нас на проектах формы бывают и по 200 инпутов, и более. и где надо каждый инпут пересчитывать относительно значений в других (по типу гугл таблиц). final-form отлично справляется с производительностью. redux-form не справлялась
Мне одному кажется, что 80 полей для одной формы это признак не очень хорошего UX? Мне трудно представить случай, в котором такого монстра нельзя разбить на несколько маленьких форм по 3-8 полей и показывать пользователю по очереди (e.g. wizard). Это также решит проблему с перерисовкой и перевалидацией огромной формы.
Борьба за производительность по-настоящему больших форм на React