Use layout builder for content add/edit form

My use case for this doesn’t depend on any correlation between edit form layout and content layout, but simply presenting a coherent looking edit form. I am working on a project with 30+ fields of all kinds on many content types and having them all stack in a column on the left with labels above the fields is far from ideal. So I’m with #3. I personally think the lack of edit layout capability for the most basic Drupal entity, the node, is the most glaring hole in the Drupal ecosystem at present.

I feel we are missing the point a bit. A good solution would be more granular than presenting the entire entity form.

The question I am always getting from editors is (paraphrased in Drupal terms) "Why do I have to go to a different tab to edit entity field content? Why can't I edit each entity field's content from its layout builder configuration form?"

Site editors do not care about or understand our distinctions between content, configuration and layout.

They don't want the entire entity form added to layout builder (way too complex), and they don't really want layout builder added to the entity form either (not wysiwyg). They want each individual entity field editable when they place it in layout builder, the same as an inline content block:

1. Site builder defines which content entity fields should be available in layout builder.
2. Site editor creates a new "page" (node) and immediately begins work in layout builder.
3. Site editor places a content entity field from (1) and edits its content directly.

My colleague and I were discussing what it would take to get to the point where inline editing of layout builder blocks would take. While it might not be strictly necessary, I think that an important first step is get to the point where the Layout Builder form object doesn't have to be entirely rebuilt every time a block is updated. This would provide more granularity for replacing a section of the main form with an inline form. I built a proof of concept for reloading of individual blocks: https://www.drupal.org/sandbox/pyrello/3321016 →

I did a little work to get a proof of concept as per #22. It loads up the parent entity form, puts the relevant field widget (only) into the layout builder configuration form, updates the entity field value in the layout, stores it temporarily until the layout page save button is submitted, then updates the entity field value on presave().

But validation does not happen for the entity field. I'm not sure if there is any best practice for validating an entity field in isolation - anyone have any ideas there?

https://www.drupal.org/project/komponent →

This module allows you to add a Layout Builder field to your content types (or any other entity type) which allows you to build content directly on create and edit form. You can also use Layout Builder like normally on the content type. So you would use regular LB for actual page layout and Komponent for building content.

#25: So it does the same thing as Layout Builder Widget, right?

#26 there are some differences

Komponent allows you have to multiple Layout Builder (similar to Paragraphs) since it provides you with a new field type that you add to your content type.

With Komponent you can enable regular Layout Builder and use it for layout, and then you can also have a Komponent field for the content creation.

Komponent have some nice widget configuration like instead of having a modal to select a block, it allows you to display the blocks as button directly, saving you a click.
It allows you to disable sections, for simple use cases where you only want a single section with blocks.

Regarding #23 have a look at module layoutbuilder_extras_live_update. It reloads the content from your sidebar into the content through Ajax.
Maybe we can alter it to render the block form in some form instead. I think block forms should then be split into actual content fields, rendered inline and settings fields rendered in the sidebar.

On a side node: The editor in Sharepoint does this in my opinion in a better way (also for adding, sections and blocks), but that's personal preference of course.

#22 is 100% the case, and the disconnect is something we hear about from our users. We have run into plenty of times where an editor made changes to the Body of a Node, then didn't understand why the changes did not show up, not realizing that they had replaced the body in the display. From an editor UX perspective, this kind of unified experience would be ideal. Other node options could exist in a similar sidebar/modal/layout builder interface.

The sidebar is fine for many fields, especially as it can be resized by the user, or resized by developers with CSS as we do now. Modal is another option.