поэтому у себя я хочу реализовать модель { field: { value, isChanged } field2: [{ value, isChanged }, ...] } и последующий парсинг в { field: "" field2: ["", ...] } но тут возникают некие неоднозначные моменты с группой чекбоксов с одним именем, ибо по сути мне не важены стейты типа isChanged у каждого, а один общий и значение типа: { checkbox: { value: ["flag1", "flag2"], isChanged } } так что, формы совсем не изи

@Wrouds ты отталкивайся от результата, который нужно получить

зачем тебе форма? чтобы отправлять form-data на сервер?

или для формирования json для отправки через ajax/ws?

так мы делаем либу для контроля формы, для validate и трансформаций, а отправить я могу и обычную html форму

форма ради формы? :))

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

ну я себе делаю инструмент для трансформаций и валидации + правильный парсинг значений формы для работы в React

вот от формата отправляемых данных и нужно идти кмк

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

по мимо отправки на сервак, в реакте форма ещё может менять стейт

ну я не про стейты формы сейчас

ты спрашиваешь как тебе правильно именовать поля

как правильно сформировать модель данных для формы

я тебе предложил подумать надо целью, кто конечный потребитель этой модели будет

чтобы ты потом не болел головой с трансформацией данных формы

вот от формата отправляемых данных и нужно идти кмк

1. html представление формы 2. представление данных этой формы 3. представление стейта этой формы в реакте 4. представление данных для отправки на сервер

перед отправкой данных

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

для отправки данных не нужно ничего писать, берём обычную форму и FormData, всё

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

отсюда все либы типа formik, final-form

И все они дико медленные

вот мне проще, т.к. у меня уже больше двух лет нет ни одной формы, которая бы стандартным сабмитом отправляла запросы на сервер

все бакенды в проектах где я участвовал принимают json

final-form сделал сабскрипшены и весь такой реактивный - но сабскрайб на другое поле не сделали

так из шейпа формы этот json ещё нужно сформировать

final-form сделал сабскрипшены и весь такой реактивный - но сабскрайб на другое поле не сделали

а зачем?

так из шейпа формы этот json ещё нужно сформировать

у меня налету формируется json

у меня налету формируется json

field[0], field[1]?

а зачем?

Ну, у нас есть компонент адреса. У него меняется лэйаут в зависимости от выбранной страны

Но это пример из головы

У нас было что-то более серьёзное, и там нужно было обновлять значение, когда одно из других изменилось

field[0], field[1]?

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

а значения регулируются getters/setter конвертором

Ну, у нас есть компонент адреса. У него меняется лэйаут в зависимости от выбранной страны

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

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

Но тогда сабскрайб триггерится каждый раз, когда хоть одно значение изменяется. Можно конечно sCU напилить

У нас было что-то более серьёзное, и там нужно было обновлять значение, когда одно из других изменилось

для такого кейса я сделал трансформации, можно изменить значение другого поля в ответ на изменение одного, и все они обновятся

Но тогда сабскрайб триггерится каждый раз, когда хоть одно значение изменяется. Можно конечно sCU напилить

не

Скажем так, я не углублялся в дебри, ибо мы просто прошлись по доке, протыкали примеры

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

я же говорил, field[0] не верное json представление, field:[] верное, очевидно же

на сервер передаются данные, а не шейп html разметки

на сервер передаются данные, а не шейп html разметки

This

Данные в json'е должны иметь форму редактируемой модели

И если модель : some_fields: Array<string> То и json должен быть в таком же формате

так я о том же, <input name="some"> <input name="some"> имеет модель some: string[]

а <input name="some[0]"> <input name="some[1]"> имеет модель { 'some[0]': string 'some[1]': string } и это уже совсем другое представление

так я о том же, <input name="some"> <input name="some"> имеет модель some: string[]

это вообще глупость какая-то

не нужно загонять себя в такие ситуации просто

за имена полей ты сам отвечаешь

это вообще глупость какая-то

это то как формы работают

за имена полей ты сам отвечаешь

так твоя форма говорит мне, если хочешь массив полей, то будь добр отвечать за имена полей и контролировать индекс, а не юзать html паттерн

это ситуация в которой твой подход диктует свои правила работы с формой, а не соответсвует тому как работают формы в html

он платный,если что х)

net

some[0]!==some

redux-actions vs redux-act?

net

https://www.typography.com/blog/introducing-operator

ну офиц да платный

ну офиц да платный

ясно

за имена полей ты сам отвечаешь

т.е. по сути ты предлагаешь свой подход к реализации кейса не соответствующий html подходу и нарушающий представление модели

т.е. по сути ты предлагаешь свой подход к реализации кейса не соответствующий html подходу и нарушающий представление модели

вот честно, взяв реакт в руки мне насрать на html

и на эти странные их подходы

так я тебе и говорю, что в реакте если массив полей то field:[] а не field[0], field[1]

Посмотрите как филд array сделан в final form

как отдельный npm пакет лол

customers массив, а не customers[{index}]

кстати с чего ты взял, что если ты задашь 3-м инпутам одно имя, то форм дата тебе сделает массив из них?

ERROR: S client not available

потому что он сделает field[0]

0-2 крч

хотя да можно

FormData не уверен, но обычный submit сделает field[0-2]

если в FormData делать getAll по имени

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

можно чекбокс сделать со своим стейтом

и размапить его

кстати с чего ты взял, что если ты задашь 3-м инпутам одно имя, то форм дата тебе сделает массив из них?

в таких кейсах fiend[{index}] используется обычно если index не просто идентификатор, а порядковый номер

жаркий дискус по формам.

вот честно, взяв реакт в руки мне насрать на html

оч плохо

@Wrouds так ты в итоге сам обрабатываешь формы кастомно или юзаешь плагин?

оч плохо

ну если бы я лендингами занимался, где юзаются нативные формочки часто, то наверное пересмотрел свое отношение к ним

а когда тебе годами вообще от верстки кроме div/a ничего не нужно....

плохо

т.е. с чистым html вообще раз в пятилетку :)))

@Wrouds так ты в итоге сам обрабатываешь формы кастомно или юзаешь плагин?

https://github.com/Wroud/react-painlessform

это не плохо, а очень даже гуд :)

потому что все эти проблемы мне неизвестны

сейчас пишу обнову для поддержки массивов данных

painless form название много обещающее ))

потому что все эти проблемы мне неизвестны

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

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

узкий подход в данном случае это прибивать себя гвоздями в form data

заведовмо ограничив себя в возможностях использовать всякие прикольные компоненты

типа расширенных датапикеров

я не юзаю FormData, мой onChange на форме возращает трушный json представление

которые вообще понятия не имеют что такое тег form

При использовании redux-act-async нужен redux-thunk?

customers массив, а не customers[{index}]

Ну так это самое норм решение

которые вообще понятия не имеют что такое тег form

так у меня как раз таки можно (будет) делать сложные штуки, onChange по мимо эвента может принимать любое значение, можно писать компоненты инпута вообще не связанные с формами и input

Ну так это самое норм решение

так да

@Wrouds вот ты делаешь либу для реакта и сидишь паришься над тем "а что если юзер сделал одинаковые name для input-ов"