вы такой на FF форму, скажем "покупатель" (фио, почта, телефон) и используете это как есть, и у вас есть форма, в которую пользователь введет или не введет значения, исходя из этого вы строите правила валидации и реакции вашего приложения на ввод и т.д. и т.п.
И тут вы такой - так, а вот уу меня есть кейс что «Покупателей» может быть несколько - и вы такой - ну ОК, берем FieldArray и БАЦ… тут выясняется что для того чтобы форма вообще была отображена - состояние не может быть пустым, вы уже обязаны инициализировать минимум одно значение - при чем с «пустыми полями» и пошла «пляска» по рефакторингу всего что с этой формой было связано 🙂
и еще раз повторюсь - «руками» написать и подстроиться можно под что угодно и как-то с этим жить - но это не отменяет концептуальных изначальных архитектурных проблем решения.
Да - FiledArray это блин типо плагин 🙂 и типо FF не виноват в том что он корявый… ну так и само решение для форм - которое не предоставляет инструментов для организации списка полей - это тоже архитектурная проблема - вы не находите ?
еще раз - если вам не походит именно FieldArray не берите его Либо берите и допиливайте(оберткой) до того что лично вам нужно. И не нужно будет пляски с рефакторнгом. FF - state manager. Мапинг стейта в UI - уже другая проблема. Кто как хочет тот так и мапит. RFF лишь предоствлаяет примитивы. Не вижу тут никаких архитеркутрых проблем. Кстати вы находили какие-то готовые решения для форм без этих “проблем”?
Обсуждают сегодня