Государственное управление Apollo Form
Каков наиболее традиционный способ управления состоянием формы с помощью клиента React Apollo? Слишком много пошаговых руководств по базовым запросам apollo и простым приложениям задач, но я не видел ни одного, показывающего, как работать с реалистичными формами.
Представьте себе три разных пользовательских потока:
- Редактировать существующую сущность (форма обновления)
- Редактировать коллекцию, добавляя / удаляя элемент (форма обновления)
- Создать новую сущность (создать форму)
Кажется, есть несколько решений:
Используйте компонент React с отслеживанием состояния. Эта форма с сохранением состояния вложена в
<Query />и<Mutation />или иным образом имеет доступ как кdata, так и кmutate. При отправке используйте функциюmutateнапрямую, чтобы отправить мутацию и (при необходимости) вручную обновить кеш в случае успеха. Это работает, но требует более сложного компонента с отслеживанием состояния. Одним из побочных эффектов является то, что вам нужно вычислять состояние из свойств (componentWillReceivePropsи т. д.), Потому что форма требует какquery(для формы обновления, чтобы показать текущие значения), так иmutation, и потенциально может получать новые данные после уже обработано (при обновлении / опросе)Используйте запросы Apollo-Link-State и
@client-scoped. Кажется, что это сталкивается со всеми теми же проблемами, что и компонент с отслеживанием состояния, если не больше из-за дополнительной косвенности. Это интуитивно понятно для создания формы / новой сущности, поскольку эта новая сущность может быть сохранена в локальном кеше, а затем отправлена в удаленный API при отправке и автоматически появится в обычном кеше в случае успеха. Однако это менее интуитивно понятно для формы обновления, поскольку теперь у вас, по сути, есть две копии одного и того же объекта. Форма также должна будет переключить свой источник истины, чтобы первоначально читать из нормального кеша для заполнения формы, затем записывать / читать из локального кеша во время редактирования, а затем, возможно, вернуться к обычному кешу после отправки. В противном случае хорошие объяснения, такие как https://www.robinwieruch.de/react-apollo-link-state-tutorial/, не показывают, как отправлять эти локально кэшированные данные, и обычно сосредотачиваются на данных, которые предназначены только для того, чтобы оставаться локальными, таких как результаты API устройства и конфигурация пользователя.Запишите в авторитетный / «нормальный» кеш apollo прямо поверх данных, полученных через API, затем прочитайте их обратно из кеша, чтобы отправить их удаленному API. Кажется, это имеет больше смысла для формы обновления, поскольку для этой сущности есть только одно состояние, но не будет работать для новой сущности, поскольку у этой сущности еще не будет идентификатора (хотя мы могли бы сгенерировать uuid на клиенте, Я бы предпочел, чтобы серверная часть генерировала идентификатор), и, следовательно, это не то, с чем может работать кеш Apollo, AFAIK. Другая проблема заключается в том, что данные формы, которые только что отправил пользователь, будут перезаписаны при извлечении, что может расстроить, если что-то не сработает.
Цените любые советы, примеры или отзывы - заранее спасибо!
Ответы 1
Я считаю, что apollo-link-state более полезен в ситуациях, когда вы хотите управлять состоянием, которое полностью выполняется на стороне клиента, а не является частью данных, которые вы получаете с сервера. Я не думаю, что он хорошо подходит для управления состоянием компонентов, особенно форм. Что отлично работает, так это объединение Apollo с такой библиотекой, как Formik. Это снижает стандартную и общую сложность вашего компонента. Вот примерный пример:
<Query query = {SOME_QUERY} />
{({ loading, data }) => {
if (loading) return <LoadingIndicator/>
return (
<Mutation query = {SOME_MUTATION}>
{(mutate) => (
<Formik
initialValues = {_.pick(data.someData, ['foo', 'bar'])}
validate = {/** optional validation function or schema **/}
onSubmit = {values => mutate({ variables: values })}
>
{(formikProps) => (
<YourFormComponent {...formikProps}/>
)}
</Formik>
)}
</Mutation>
)
}}
</Query>
Функция рендеринга компонента Formik получает массу свойств, которые все описываются здесь. Фактический компонент формы может быть без состояния и в основном просто отображать, какие реквизиты ему передаются (значения, ошибки, обработчики onChange и т. д.). Formik принимает схемы Ага для проверки, что также упрощает проверку входных данных.
Лично у меня проблем с этим не было, API очень гибкий и хорошо документированный. Если вы не хотите использовать эту или другую подобную библиотеку, то да, компонент с отслеживанием состояния будет в значительной степени вашим единственным вариантом.
Очень здорово, спасибо, я попробую. Обнаружили ли вы какие-либо ограничения для Formik или кейсы, которые вам нужно было обойти? Если да, будет ли ваш запасной вариант ванильным компонентом с отслеживанием состояния?