Lexical Block fields are not accessible via schema path provided by `useAllFormFields` and related React Hooks

[damnsamn]

Describe the Bug

Currently the field React Hooks will provide FieldState values for all fields in the document's config, except for those nested within Lexical Blocks. They are instead deeply nested within the richtext's own returned FieldState.

Expected Behaviour

Fields defined using payload's field config should all be accessible via the React Hooks, regardless of whether they're defined in a Lexical Block feature or not. I would expect the schema paths for Lexical Blocks to exist as siblings to the richtext field, similar to arrays and standard blocks. Eg;

{
  "arrayField": 1,
  "arrayField.0.nestedField": "...",
  "blocksField": 1,
  "blocksField.0.nestedField": "...",
  "richtextField": {  },
  "richtextField.0.nestedField": "..."
}

Link to the code that reproduces this issue

https://github.com/damnsamn/blank-payload-project/tree/issue/lexical-block-fields-react-hooks

Reproduction Steps

Context

Our TestCollection consists of several text fields in various nested contexts:

• fieldA
• arrayField -> fieldB
• blocksField-> fieldC
• richTextField -> fieldD

fieldA through fieldC are directly accessible via their schema paths in the useAllFormFields hook, but fieldD isn'

Steps

1. Create an item in Test Collection
2. Fill out the form, adding at least one array item, block, and richtext block, each with their text values filled
3. Check the devtools console for a log of the following input, which will log an object with all field values provided by useAllFormFields():

  const [allFields] = useAllFormFields()

  const currentFieldValues = Object.fromEntries(
    Object.entries(allFields).map(([key, field]) => [key, field.value]),
  )

  console.log(currentFieldValues)

4. Note that there is no schema path for fieldD. Example output:

{
  arrayField: 2,
  arrayField.0.fieldB: "lalala",
  arrayField.0.id: "67a052ab9e2fee1fb665ec8a",
  arrayField.1.fieldB: "lalal",
  arrayField.1.id: "67a052ad9e2fee1fb665ec8c",
  blocksField: 1,
  blocksField.0.blockName: undefined,
  blocksField.0.blockType: "fieldCBlock",
  blocksField.0.fieldC: "lalala",
  blocksField.0.id: "67a052b19e2fee1fb665ec8e",
  createdAt: undefined,
  fieldA: "lalala",
  listFields: undefined,
  richTextField: {root: {…}},
  updatedAt: undefined,
}

Which area(s) are affected? (Select all that apply)

area: core, area: ui

Environment Info

Binaries:
  Node: 22.12.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: 10.0.0
Relevant Packages:
  payload: 3.20.0
  next: 15.1.5
  @payloadcms/db-postgres: 3.20.0
  @payloadcms/email-nodemailer: 3.20.0
  @payloadcms/graphql: 3.20.0
  @payloadcms/next/utilities: 3.20.0
  @payloadcms/payload-cloud: 3.20.0
  @payloadcms/richtext-lexical: 3.20.0
  @payloadcms/translations: 3.20.0
  @payloadcms/ui/shared: 3.20.0
  react: 19.0.0
  react-dom: 19.0.0
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.0.0: Mon Aug 12 20:52:31 PDT 2024; root:xnu-11215.1.10~2/RELEASE_ARM64_T6030
  Available memory (MB): 18432
  Available CPU cores: 12

[GermanJablo]

Hi @damnsamn, This is not a bug. Subfields within the rich text editor are not part of the parent form. Maybe in the future we could provide some way, but right now it would require a pretty big re-architecture.

If you need to access the fields, you can look them up inside the editorState (your richTextField: {root: {…}} property).

Depending on your use case you might want to define a context to store them there.

Let me know if that answers your questions or if you need help with anything else!

[damnsamn]

Fair enough that it's not a bug, but I do think it's an unintuitive and confusing design decision in that case. I've not seen anything to indicate in the docs, and do not take it as a given, that when you're scaffolding out your Collection config, some of the fields you define are not a part of that form.

I don't really see a semantic difference between either of the form states - if a blocks field surfaces it's child fields, I can't think of a reason why richtext shouldn't (at a semantic level - I do understand it's not simple at a technical level). As far as I know, Lexical form state isn't independently saved/stored/published from the rest of the document from what I can tell, there's not really any cues to developers that this will behave differently from a blocks field. The pitch of the blocks feature is that "you can do anything payload config can do" and re-use your existing blocks - this is not currently true.

[damnsamn]

I'll describe the use case a little clearer.

We have a requirement where any uploads added to any upload field in the document must be mirrored on a separate master upload field (called Gallery). When a user adds an upload via any upload field, we need to add that new value to the Gallery.

We cannot achieve this as intended via field hooks when the upload fields change , as we need the state to update immediately on the Gallery field. Instead, we're using a selector provided to useFormFields on the Gallery upload field to listen for changes to all other upload fields, and update itself accordingly. This works perfectly with upload fields that are members of the base formState, but anything nested within a Lexical Block is inaccessible.

If you need to access the fields, you can look them up inside the editorState (your richTextField: {root: {…}} property).

This doesn't do the same thing - I'm expecting to be able to access FieldState per field, not just its value. I can traverse the richtext's nodes to retrieve values, but all other functionality provided by the FieldState is off-limits.

I'm sure there are alternative approaches that may get the intended outcome here - but the point of the ticket is that it's a reasonable expectation that useField, useFormFields and useAllFormFields would work the same for all payload fields in a config. There's nothing in the documentation either that would indicate that established pattern of nestedParent.[index].nestedFieldName schema paths to access nested field data is entirely off-limits for payload fields within the BlocksFeature.