Fixes#10942

Before

Lexical nodes with nested fields (blocks, inline blocks, links, uploads) were fully isolated from the parent document's form system. Each node type managed its own form lifecycle: block and inline block components rendered their own<Form> component directly on the page, with their owninitialState built via a dedicatedbuildInitialState utility, their own state reducer, and their ownonChange hooks to sync field changes back into the Lexical node viaeditor.update(). Links and uploads did the same when their editing drawers opened.

This meant every node with sub-fields was effectively a mini-document with its own form context and submission flow that we had to handle manually - completely separate from the parent document form. From the perspective of Payload's form system, these fields didn't exist:useAllFormFields(),useFormFields(), and other form hooks couldn't see them. They were buried inside the rich text field's serialized JSON value.

After

Nested Lexical fields now live in the parent document's form state, just like array fields, standard blocks, and top-level fields. A lexical block's text field sits atlexicalField.{nodeId}.fieldName in the same flatFormState map. The node ID is the bridge between the freeform Lexical JSON tree and the flat form state - it's the one stable identifier every node with sub-fields already has. Drawers read from and write to the parent form state directly; thedata prop onFieldsDrawer has been removed entirely.

Why

Consistency and simplicity. Nested Lexical fields are Payload fields - they're defined with the same field config, validated the same way, stored the same way. There was no reason for them to be invisible to the rest of the form system. This change makes them first-class fields, which means any component, plugin, or custom hook can read and write Lexical sub-fields using standard form hooks. It also simplifies the client-side architecture: node components no longer need to manage their own state lifecycle,.

How

A newbuildFormState method on theRichTextAdapter interface lets the Lexical adapter hook into the existing form state pipeline. During server-side form state construction, the adapter walks the serialized Lexical tree, finds nodes with sub-fields via feature-providedgetSubFieldsData andgetSchemaPath functions, and calls the standarditerateFields utility to populate form state entries under{richTextPath}.{nodeId}.*. This works similarly to howgenerateSchemaMap already works for the schema map - just now for form state.

On save, abeforeChange hook merges flat form state values back into the Lexical JSON tree before persistence, using the samegetSubFieldsData map. Any feature that registers sub-fields automatically participates in both directions.

On the client, node components no longer receive full field data objects fromdecorate(). They receive only structural identifiers (blockType,id,relationTo,value) and read user-editable field data from the parent form state via standard hooks.getFields() andgetData() have been renamed togetStaleFields() andgetStaleData(), as form state is the source of truth and the editor state for the node fields will be stale until the form state is synced back, which happens in the beforeChange hook.

Links are a special case: as anElementNode, Lexical renders their DOM from internal node data. A targeted sync writes field values back to the link node viaeditor.update() on drawer submit, keeping rendering current.