AA
Выглядит достаточно неплохо. Нужен бы пример с Yup, и хотелось бы что типы через валидацию тянулись
с Yup могу завести, там довольно легко врапнуть
Size: a a a
2020 August 17
AO
форма это далеко не всегда один объект, который отправляется целиком на сервер
мб, я сужу по своему опыту
AA
Динамические поля конечно будут храниться в сторе (для кейсов когда мы получаем форму с бэка например), так как создание сторов на лету противоречит статической природе эффектора.
А вот для статических полей мне кажется так все же удобнее
А вот для статических полей мне кажется так все же удобнее
c
Aleksandr Osipov
мб, я сужу по своему опыту
у нас бывает когда часть полей формы формируют body запроса, а другая часть параметры и тип.
когда делали CRM так вообще такое сплошь и рядом
особенно когда от значения селекта отображается одна или другая форма
когда делали CRM так вообще такое сплошь и рядом
особенно когда от значения селекта отображается одна или другая форма
AA
у нас бывает когда часть полей формы формируют body запроса, а другая часть параметры и тип.
когда делали CRM так вообще такое сплошь и рядом
особенно когда от значения селекта отображается одна или другая форма
когда делали CRM так вообще такое сплошь и рядом
особенно когда от значения селекта отображается одна или другая форма
CRM/ERP это очень больно с точки зрения форм :(
c
CRM/ERP это очень больно с точки зрения форм :(
есть упрощенные варианты таких форм почти в любом продукте
AA
Вообще я наверное могу оба подхода увязать на самом деле на выбор юзеру, надо только придумать как с точки зрения апи красиво будет :)
AO
у нас бывает когда часть полей формы формируют body запроса, а другая часть параметры и тип.
когда делали CRM так вообще такое сплошь и рядом
особенно когда от значения селекта отображается одна или другая форма
когда делали CRM так вообще такое сплошь и рядом
особенно когда от значения селекта отображается одна или другая форма
я просто не очень понимаю в чем разница, тебе же все равно надо выделить где-то явно наборы полей которые в боди идут, а какие в get-парметры и так далее, ну вот .map сделать $values что combine($value1, $value2,..) один фиг
DS
типы тянутся)
Нужно посмотреть более пристально, на вид все так как хотел реализовать)
Уже опробовали на проекте каком либо?
Уже опробовали на проекте каком либо?
AO
Aleksandr Osipov
я просто не очень понимаю в чем разница, тебе же все равно надо выделить где-то явно наборы полей которые в боди идут, а какие в get-парметры и так далее, ну вот .map сделать $values что combine($value1, $value2,..) один фиг
мб я чет не понял
c
Aleksandr Osipov
я просто не очень понимаю в чем разница, тебе же все равно надо выделить где-то явно наборы полей которые в боди идут, а какие в get-парметры и так далее, ну вот .map сделать $values что combine($value1, $value2,..) один фиг
комбайн тупо проще, чем мап
AA
Нужно посмотреть более пристально, на вид все так как хотел реализовать)
Уже опробовали на проекте каком либо?
Уже опробовали на проекте каком либо?
Ага, в RN приложении опробовал
DS
Ага, в RN приложении опробовал
А в form не валяется скомбайненый стор всех полей?
AA
А в form не валяется скомбайненый стор всех полей?
валяется) form.$values
DS
валяется) form.$values
Супер
DS
Было бы неплохо api описать а то по типам тяжело понимать( ну мне лично
AA
Было бы неплохо api описать а то по типам тяжело понимать( ну мне лично
Да, апи на выхах закину
AA
Не успел еще)
AO
комбайн тупо проще, чем мап
Ну ок, допустим. А как с таким подходом (отдельные сторы на поле) разруливать динамические поля (ну вот то что выше чуть обсуждали)?
AO
Aleksandr Osipov
Ну ок, допустим. А как с таким подходом (отдельные сторы на поле) разруливать динамические поля (ну вот то что выше чуть обсуждали)?
Динамически сторы создавать не effector-way же?