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

Đang mở
  • Có gì không ổn?
#2,296 3 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
react, typescript
Lĩnh vực
frontend

Hướng nghiên cứu

Không có tệp triển khai hoặc bài kiểm thử nào được nêu tên. Hãy bắt đầu bằng cách lần theo các entry point useForm, Field, FormGroup và form.handleSubmit được mô tả trong RFC, sau đó so sánh hành vi vòng đời của chúng. Công việc chỉ được xem là hoàn tất khi đã thống nhất giá trị mặc định cho các listener, validator và state ở cấp form đã unmounted, trước khi có thể xác định phạm vi công việc triển khai.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
6.8k
Fork
705
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
14

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TanStack/form

Tất cả issue của TanStack/form

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.