BB
правда там и вычисления от чейнджей порой как грузанут JS
<Route path={
/${year}/${month}} component={App} /><Redirect to={
/${year}/${month}} />Почему, если я от руки вбиваю данный route, то он его не находит?
Size: a a a
2020 July 15
АБ
First Name
Работаю с маршрутизацией проекта. Есть две строки.
<Route path={
<Redirect to={
Почему, если я от руки вбиваю данный route, то он его не находит?
<Route path={
<Redirect to={
Почему, если я от руки вбиваю данный route, то он его не находит?
а что за интерполяция строк path и to?
FN
а что за интерполяция строк path и to?
В этом есть какая-то проблема?
В month и year у меня находятся текущий год и месяц.
В month и year у меня находятся текущий год и месяц.
АБ
а, понел, вопрос отпал)
АЗ
Как это поможет в данной ситуации?
A
Как это поможет в данной ситуации?
всм
получим четкую ошибку на очепятку в
получим четкую ошибку на очепятку в
controller({name: "asdads", …})АЗ
всм
получим четкую ошибку на очепятку в
получим четкую ошибку на очепятку в
controller({name: "asdads", …})Отлично. В $values как типы этих полей попадут?
A
Отлично. В $values как типы этих полей попадут?
ну, как минимум, меня уже мало волнует, как они туда попадут
как максимум методом/ивентом, ватева у него там
а что смущает?
как максимум методом/ивентом, ватева у него там
а что смущает?
АЗ
ну, как минимум, меня уже мало волнует, как они туда попадут
как максимум методом/ивентом, ватева у него там
а что смущает?
как максимум методом/ивентом, ватева у него там
а что смущает?
Поправил сообщение. С точки зрения типизации сейчас разговор
A
Поправил сообщение. С точки зрения типизации сейчас разговор
это из $values сюда попадут типы и ключи полей
(должны во всяком случае)
у нас же слой модели должен быть выше слоя вью по иерархии
(должны во всяком случае)
у нас же слой модели должен быть выше слоя вью по иерархии
АЗ
это из $values сюда попадут типы и ключи полей
(должны во всяком случае)
у нас же слой модели должен быть выше слоя вью по иерархии
(должны во всяком случае)
у нас же слой модели должен быть выше слоя вью по иерархии
Это сразу перестаёт работать, так как в таком случае требуется иметь связи на уровне рантайма между инпутами и формой.
A
Это сразу перестаёт работать, так как в таком случае требуется иметь связи на уровне рантайма между инпутами и формой.
никто не мешает инитить форму через схему
АЗ
никто не мешает инитить форму через схему
Покажи код
A
Покажи код
const form = createForm({
age: number
.required
.min(18),
name: string
.pattern(/\w+/)
})
const Field = createField(form);
<Field name="age" />что то типа такого
дефолты тоже мозно завезти сюда
c
const form = createForm({
age: number
.required
.min(18),
name: string
.pattern(/\w+/)
})
const Field = createField(form);
<Field name="age" />что то типа такого
дефолты тоже мозно завезти сюда
👍
c
const form = createForm({
age: number
.required
.min(18),
name: string
.pattern(/\w+/)
})
const Field = createField(form);
<Field name="age" />что то типа такого
дефолты тоже мозно завезти сюда
а может сделать статическое поле?
const FieldName = createField(form, ‘name’)АЗ
const form = createForm({
age: number
.required
.min(18),
name: string
.pattern(/\w+/)
})
const Field = createField(form);
<Field name="age" />что то типа такого
дефолты тоже мозно завезти сюда
Неплохая идея.
АЗ
а может сделать статическое поле?
const FieldName = createField(form, ‘name’)Придётся кучу createField делать. Такое решение тяжело на собственные компоненты накидывать
A
а может сделать статическое поле?
const FieldName = createField(form, ‘name’)да, тоже вариант
для кастомных полей наверное особенно полезно будет
еще какой нибудь коллбек для рендера сверху
для кастомных полей наверное особенно полезно будет
еще какой нибудь коллбек для рендера сверху
c
Придётся кучу createField делать. Такое решение тяжело на собственные компоненты накидывать
да, под каждое поле.
Но мне кажется, это будет чуть лучше оптимизировано, за счет подписки на отдельный кусок стейта.
Ну и можно заворачивать в свои компоненты
Наверное, первый вариант тоже имеет смысл. Особенно во всяких динамических формах
Но мне кажется, это будет чуть лучше оптимизировано, за счет подписки на отдельный кусок стейта.
Ну и можно заворачивать в свои компоненты
Наверное, первый вариант тоже имеет смысл. Особенно во всяких динамических формах