Comments 8
Почему мы решили создать свои формы?
Изначально для работы с формами мы использовали библиотеку Redux-Form. Она обеспечивала автоматическое обновление состояния, валидацию и другие полезные функции.
Со временем мы упёрлись в проблемы производительности. В сложных формах на React и React Native постоянно сталкивались с лишними перерендерами и фризами страницы. К тому же Redux-Form перестала поддерживаться автором. Поэтому настал момент переехать на другое решение или написать свой движок. Для этого предварительно выделили основные пункты, которые нам нравились в Redux-Form, и сформулировали то, что мы хотим от собственного решения.
А про react-hook-form вам никто за эти годы так и не рассказал? Которая легко прикручивается к любым ui-китам через собственный Controller. Нет, я вижу, что вы в конце о ней вспомнили и даже сравнения провели, просто в начале почему-то ни слова, будто упёрлись, решения нет, и вот решили сделать своё. Решение уже было, и прекрасное - так зачем своё? Босс захотел? И зачем врать во вступлении в таком случае?)
Что же касается работы с глобальным стором, здесь вообще муть какая-то. Вы хоть раз видели компоненты форм из ui-китов, которые могут работать только с каким-то одним стором(глобальным ИЛИ локальным), которые вообще знают что-либо о сторе? Обычно это всегда передаваемые методы в компонент, в духе onInput и так далее, и значения в value из того же стора, если нужен именно он.
У вас же просто слепились в одно и библиотека логики работы формы, и потребители этой логики в виде компонентов - первое просто не нужно, потому что есть react-hook-form, а второе тем более не нужно, во втором абзаце написано, почему.
А про react-hook-form вам никто за эти годы так и не рассказал? Которая легко прикручивается к любым ui-китам через собственный Controller. Нет, я вижу, что вы в конце о ней вспомнили и даже сравнения провели, просто в начале почему-то ни слова, будто упёрлись, решения нет, и вот решили сделать своё. Решение уже было, и прекрасное - так зачем своё? Босс захотел? И зачем врать во вступлении в таком случае?)
Да, react-hook-form действительно существовал уже тогда. Но когда мы принимали решение, библиотека только набирала популярность, а мы были завязаны на Redux. React-hook-form не закрывал все эти требования из коробки. Его можно было прикрутить, но тогда пришлось бы писать свой слой обёрток и решать те же проблемы, что мы и так решали. В итоге проще оказалось написать движок под свои задачи.
Что же касается работы с глобальным стором, здесь вообще муть какая-то. Вы хоть раз видели компоненты форм из ui-китов, которые могут работать только с каким-то одним стором(глобальным ИЛИ локальным), которые вообще знают что-либо о сторе? Обычно это всегда передаваемые методы в компонент, в духе onInput и так далее, и значения в value из того же стора, если нужен именно он.
У вас же просто слепились в одно и библиотека логики работы формы, и потребители этой логики в виде компонентов - первое просто не нужно, потому что есть react-hook-form, а второе тем более не нужно, во втором абзаце написано, почему.
В статье речь идет только о core части Steroids, которая включает в себя работу с формами, состоянием и тд. Ui компоненты ничего и не знают о сторе, а работают как контролируемые компоненты.
Собственно вопрос. Какую проблему решает ваш продукт? Для кого он создан?.
В статье по факту упоминается что создавалась потому что есть свое апи и не охота было все переносить и переписывать под новую либу. Фактически вы создали движок для себя исходя из своей проблемы
Но зачем скажем она другим проектам которые не имеют ваших проблем с учетом вашей архитектуры? Зачем мешать стору с формами? Для кого это все? В чем удобство? В чем преимущество глобально (а не в кейсе вашей команды) над тем же реакт хук форм?
В статье описано чем отличается на фоне конкурентов. Да только если вы изобрели велосипед с квадратными колесами - он тоже отличается от конкурентов у которых круглые. Но это не значит что ваш велосипед будет удобен и ваще кому то нужен.
Зачем мешать стору с формами? Для кого это все? В чем удобство? В чем преимущество глобально (а не в кейсе вашей команды) над тем же реакт хук форм?
Redux не обязателен, по умолчанию форма работает с локальным useReducer. Но в местах, где данные должны «жить» дольше, чем компонент, поддержка Redux снимает необходимость вручную синхронизировать значения формы со стором. А за счет единого API, для разработчика форма выглядит одинаково, независимо от того, где она хранится. Это экономит время и снижает вероятность ошибок.
Вопрос: для чего так нужен был redux в библиотеке форм, из-за чего по итогу пришлось писать велосипед?
Сливать хранение данных и контроллер формы - явный антипатерн.
Ну это, очевидно, поделка "чисто для себя". Никакой пользы для сообщества не несет. Есть множество универсальных, гибких, проверенных временем библиотек, которые решают все эти задачи.
Steroids Form — как создать собственный движок форм для React