Form of v4 is not need create context by `Form.create()`. Form is now have own data scope and you don't need `getFieldDecorator` anymore. Just use Form.Item directly:
Since `Form.create()` is removed, origin `onFieldsChange` or other methods moved to Form, and control by `fields`. ref [example](/components/form/#components-form-demo-global-state)。
### Form control
If you want to control form, you can use `Form.useForm()` to create Form instance for operation:
New Form use incremental update which only update related field. So if there are some linkage between fields or update with whole form. You can use [`dependencies`](/components/form/#dependencies) or [`shouldUpdate`](/components/form/#shouldUpdate) to handle that.
### replace onSubmit with onFinish
You need to listen `onSubmit` and call `validateFields` to handle validation in old Form. New Form provides `onFinish` which only trigger when validation is passed:
In v3, modifying the `initialValue` of un-operated field will update the field value synchronously, which is a bug. However, since it has been used as a feature for a long time, we have not fixed it. In v4, the bug has been fixed. `initialValues` only takes effect when initializing and resetting the form.
### Remove field no longer removes field value
In v3, we will clean up the values when the fields removed. However, it has been found that clearing fields can cause greater inconvenience than retention in practice. For example like some switching operations, the user has to retain the field value in a hidden way. Therefore, the new version of Form will always keep the fields value, and the validation rules for removing field will be ignored. So `preserve` is no longer needed.
### Nested field paths using arrays
In the past versions we used `.` to represent nested paths (such as `user.name` to represent `{ user: { name: '' } }`). However, in some backend systems, `.` is also included in the variable name. This causes the user to need additional code to convert, so in the new version, nested paths are represented by arrays to avoid unexpected behavior (eg `['user', 'name']`).
Therefore, paths returned by methods such as `getFieldsError` are always in an array form for the user to handle:
`validateFields` will return a Promise, so you can handle the error with `async/await` or `then/catch`. It is no longer necessary to determine if `errors` is empty: