[v2] [RFC] What should happen when `Field` and `FormGroup` unmount?

Aberta
  • Algo errado?
#2,296 3 comentários 1 reação 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Stack de tecnologia
react, typescript
Domínio
frontend

Direção de pesquisa

Nenhum arquivo de implementação ou teste é mencionado. Comece rastreando os pontos de entrada useForm, Field, FormGroup e form.handleSubmit descritos no RFC e, em seguida, compare o comportamento deles ao longo do ciclo de vida. O trabalho estará concluído quando houver um acordo sobre o padrão para listeners, validadores e estado no nível do formulário desmontados, antes que o escopo do trabalho de implementação possa ser definido.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

area: runtime scope: core v2

RFC: What should happen when Field and FormGroup unmount?

In TanStack Form, a Field or FormGroup follows the lifecycle of the UI component that renders it: it mounts and unmounts with that component. After it unmounts, the form may still retain state and behavior associated with it. This leaves us with an important question: should unmounting only stop the field or group from rendering, or should it also change how it participates in the form?

This RFC looks at what should happen to that retained state and behavior once the corresponding UI is no longer mounted.

The problem

Once a field has mounted, the form keeps state associated with it. This includes metadata such as whether the field has been touched, along with any validation errors.

Some field state also contributes to the state of the form as a whole. For example, changing a field sets that field's isTouched state to true. It also sets form.state.isTouched to true, because the form-level value tells us whether any field has been touched.

When an application explicitly deletes or resets a field, it is clear that the field's state is meant to change. The form can update its form-level state at the same time, and those explicit actions give us a clear point at which to decide what should happen to the field's validators and listeners.

Unmounting does not carry the same intent. A field might disappear because the user moved to another step, switched tabs, or scrolled it out of a virtualized view. The field is no longer rendered, but the user did not necessarily delete or reset it. We therefore need to decide whether unmounting should affect only the UI or also the field's role in the form.

The ambiguity

A two-step form makes the issue easier to see. In this example, the first step contains a name field and the second step contains the submit button. The code uses React syntax, but the same lifecycle question applies to other UI frameworks:

import { useState } from 'react'
import { useForm } from '@tanstack/react-form'

function SignupForm() {
  const [step, setStep] = useState(1)
  const form = useForm({
    defaultValues: { name: '' },
    onSubmit: ({ value }) => console.log(value),
  })

  return (
    <form
      onSubmit={(event) => {
        event.preventDefault()
        form.handleSubmit()
      }}
    >
      {step === 1 ? (
        <>
          <form.Field
            name="name"
            validators={[
              {
                // Validators run on submission by default.
                triggers: [],
                run: ({ value }) =>
                  value ? undefined : 'Please enter your name',
              },
            ]}
          >
            {(field) => (
              <input
                value={field.value}
                onChange={(event) => field.handleChange(event.target.value)}
              />
            )}
          </form.Field>
          <button type="button" onClick={() => setStep(2)}>
            Next
          </button>
        </>
      ) : (
        <button type="submit">Submit</button>
      )}
    </form>
  )
}

Clicking Next unmounts the name field, but its value remains in the form. The field is now absent from the UI while still being part of the form's stored data. What should happen when the user submits from the second step? Should the unmounted field's validator still run? If the user edited the field before moving on, should the form still be considered touched? If the field has a listener, should that listener remain active even though the field is no longer rendered?

More generally, we need to decide which parts of an unmounted field should continue to participate in the form:

  1. If the field has a listener, should that listener remain active after the field unmounts, or should it stop being called?
  2. If the field has a validator, should that validator still run as part of form.handleSubmit(), or should it be disabled while the field is unmounted?
  3. Should form-level state such as isTouched include every field the form knows about, or only the fields that are currently mounted?

The same questions apply to FormGroup, which also follows the lifecycle of a rendered component.

Why this matters

  • Virtualized or dynamically rendered fields are frequently mounted and unmounted as the visible UI changes. Their behavior should not be surprising simply because they moved out of view.
  • In a multi-step form, switching steps may unmount an entire group. We need to know whether that group still participates in the final submission.
  • Persistent form state such as isPristine could change only because a different set of fields is currently rendered, even if the user did not change any values.

The goal of this RFC is to agree on a predictable default for these cases. We would especially like to hear about use cases where mounted and unmounted fields need to behave differently.

Linguagem predominante
TypeScript
Estrelas
6.8k
Forks
705
Merge médio
1d 6h
PRs com merge (30d)
12

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de TanStack/form

Todas as issues de TanStack/form

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.