Частично по делу, но в основном перебор. Складывается впечатление, что время на чтение письма у этого ютьюбера в разы дороже чем у того кто ему пишет, а на ответ рассчитывать не стоит в любом случае. Прислать ключ, ассеты и полное описание? Мне кажется, что не хватает ещё одного пункта: пришлите мне готовый ролик про свою игру, чтобы мне не пришлось тратить время, и может быть, я его выложу.
Для реализации этого кейса мне не потребовалось пересматривать предложенный в статье API. Единственное, пришлось пересмотреть работу Validation и Transform в моей библиотеке, Transform был переделан, но не кардинально. Теперь функция трансформации выглядит так:
(values, model) => { [field]: { value } }
values — неполная копия model отражающая изменившиеся поля (в том числе изменённые другим Transform)
model — текущее значение полей формы с предыдущим значением изменившегося поля
field — имя поля для трансформации
value — новое значение этого поля
Возвращает объект вида { [field]: { value } }, подобный аргументу values, этот объект будет объединён с values и передан в следующий Transform.
Validation теперь добавляет свои ошибки к hight ordered Validation если таковой есть.
Если вы открывали пример из статьи на codesandbox, то вероятно пропустили асинхронную валидацию с сервера. Компонент Validation используется как контекст, связывающий значение полей формы и её валидацию
Мой пример позволяет вынести валидацию куда угодно, все что нужно для связи валидации и модели, это покинуть дополнительную информацию для валидации (асинхронную) как дополнительные пропы и распарсить эти данные в функции валидатор
Для реализации этих пунктов мне не пришлось вносить изменения в текущий API. Когда я реализовывал данную форму заметил, что часто для полей приходится прокидывать значение других полей или данных из стейта формы, поэтому добавил для Field проп хелпер subscribe, который позволяет выбрать данные из стейта формы и подписать Field на их изменение, без прямого прокидывания. Доступ к этим данным осуществляется через контекст Field.
В статье я подробно не описывал возможные схемы валидации, но в своей библиотеке, как пример, я реализовал поддержку Yup, по сути можно использовать любую библиотеку валидации данных которая принимает на вход значение полей формы, а на выходе формирует объект с ошибками
Статья как раз про разделение контроля над формой, валидацией и трансформацией данных. Если вы внимательно посмотрите на функцию `validator`, на аргументы которые она принимает и значение которое возвращает, то заметите, что эта функция совершенно не зависит от формы и реакта. В статье на которую вы ссылайтесь как раз описываются принципы по которым должна работать эта функция. Компонент `Validation` лишь предоставляет доступ к данным формы и формирует контекст для отображения ошибок.
По поводу `onSubmitErrors ` я с вами согласен, и опять же пишу про это в статье, что компоненты Field и Form должны максимально отражать проекцию на dom и соответственно иметь схожие пропы и эвенты как у элементов form и input.
В своей библиотеке изначально я хотел сделать состояние у Field, но в ходе разработки решил все же отказаться и оставить состояние только у поля Form, в итоге это решение лишило меня множества проблем и упростило data flow. По сути инпуты подписаны на колбеки Form.
Давайте перейдём 10 раз в чат через notification, теперь чтобы попасть в ленту или куда либо ещё 10 раз кликаем назад. Листаем ленту, пришло сообщение, читаем / отвечаем, возвращаемся в ленту и тут у нас два случайных варианта развития событий — попасть в начало ленты или на прошлое место чтения.
Табы — удобно. Табы в вк — больше проблем (кочующих ещё с прошлых версий с гамбургером) + новые.
Частично по делу, но в основном перебор. Складывается впечатление, что время на чтение письма у этого ютьюбера в разы дороже чем у того кто ему пишет, а на ответ рассчитывать не стоит в любом случае. Прислать ключ, ассеты и полное описание? Мне кажется, что не хватает ещё одного пункта: пришлите мне готовый ролик про свою игру, чтобы мне не пришлось тратить время, и может быть, я его выложу.
Скорее создана или объявлена, а не вызвана
Для реализации этого кейса мне не потребовалось пересматривать предложенный в статье API. Единственное, пришлось пересмотреть работу Validation и Transform в моей библиотеке, Transform был переделан, но не кардинально. Теперь функция трансформации выглядит так:
Возвращает объект вида { [field]: { value } }, подобный аргументу values, этот объект будет объединён с values и передан в следующий Transform.
Validation теперь добавляет свои ошибки к hight ordered Validation если таковой есть.
Мой пример позволяет вынести валидацию куда угодно, все что нужно для связи валидации и модели, это покинуть дополнительную информацию для валидации (асинхронную) как дополнительные пропы и распарсить эти данные в функции валидатор
Для реализации этих пунктов мне не пришлось вносить изменения в текущий API. Когда я реализовывал данную форму заметил, что часто для полей приходится прокидывать значение других полей или данных из стейта формы, поэтому добавил для Field проп хелпер subscribe, который позволяет выбрать данные из стейта формы и подписать Field на их изменение, без прямого прокидывания. Доступ к этим данным осуществляется через контекст Field.
По поводу `onSubmitErrors ` я с вами согласен, и опять же пишу про это в статье, что компоненты Field и Form должны максимально отражать проекцию на dom и соответственно иметь схожие пропы и эвенты как у элементов form и input.
Давайте перейдём 10 раз в чат через notification, теперь чтобы попасть в ленту или куда либо ещё 10 раз кликаем назад. Листаем ленту, пришло сообщение, читаем / отвечаем, возвращаемся в ленту и тут у нас два случайных варианта развития событий — попасть в начало ленты или на прошлое место чтения.
Табы — удобно. Табы в вк — больше проблем (кочующих ещё с прошлых версий с гамбургером) + новые.