Покажи плз

@XaveScor раз уж ты проявил небезразличие. мне интересен итоговый фидбек, чем final form еще лучше кроме как его оптимизациями.

гайз есть поле где пользователь ввел регулярку например ‘\w{2,3}’
помогите написать регулярку которая пройдется по значению этому и если там  есть вот такой промежуток {2,3} то проверит что некое a и b к примеру не больше 3

@XaveScor в общем мне не удалось быстро устроить краш тест для final form, но я тебя уверяю 200к инпутов и все будет лагать. ведь тут не только вопрос в перерендере но и в количество дом узлов на странице. в итоге все равно приходиться прибегать к виртуализации. и в этом плане спорно преимущество final form.

хоть за счет его оптимизаций он быстрее моей релазиации на N милисекунд)

а за счет чего достигается нелагучесть 200к инпутов в твоем случае?

виртуализация жи, со стороны)

@XaveScor то есть я хочу сказать вот что:
если у нас начались лаги, скорее всего у нас очень очень много дом узлов на странице. а если у нас очень много дом узлов на странице, самое эфективное решение это виртуализация. и в случае final-form или в случае с моей релизацией мы в итоге приходим к ней. и final-form нас не спасает.

то есть, жирная форма на 1 экран, то все, ггвп)

в моем случае как и в любом другом. достигается за счет виртуализации.
react-virtualized например.

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

я знаю как работает виртуализация, но не понимаю, почему это оптимизация работы библиотеки, и зачем ее вообще сюда втащили

в том что когда нужно сделать огромный список инпутов. ну например мы делаем что-то вроде xcel таблицы. у нас начинаются проблемы в случае с библиотеками, потому что при размаунчивании инпутов, они стирают наши values или портят валидацию.

вот потому и показана демонстрация в examples, что в случае с effector-react-form, это достигается довольно просто без каких либо проблем.

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

это не обсирание и хейт, это проблемные моменты, которые надо исправить)

вообще я может не встречал настолько жирных форм, но чтоб их оптимизировали с помощью виртуализации - ни разу не видел

Помедленней, я записываю

1. непривычность API субъективна и тем кто работал с react-hook-form, ничего особо нового не увидит
2. типизация работает и она присутствует. за счет интеграции effector она лучше чем когда либо. но если мы решаем юзать утилитарные методы getIn/setIn ради удобства, то да, не все с ними так просто.  но это всегда было и можешешь сам лично посмотреть как реализована типизация lodash get к примеру)
3. при изменении одного поля, происходят обновления, но их не больше чем в redux-form или formik. вот react-final-form все же выигрывает, но с сомнительным превосходством.

ну видимо не приходилось писать формы где тысяча инпутов)

кажется в таких проектах проблема с ux, и там не формменеджером надо решать проблему)

ну вот google docs, которые сделали excel в браузере, разве повернется язык говорить что у них проблемы с ux?) просто бывает разная специфика

есть же ещё жесткий энтерпрайз
например металлургия
приложения для работы инженеров и работников заводов

там дофигище полей