Add UI for adding unions (field_union_ui.module)

Thanks for the effort! It would be huge to get this working and adapted to projects.
I'd assume "Needs work" is the correct status. I tried with https://git.drupalcode.org/issue/field_union-3011353/-/tree/field_union-... branch and following notes:
1) It requires layout_builder enabled, otherwise faces fatal error when trying to enable the module
2) Not possible to add Field unions to nodes, will face fatal error: Error: Call to undefined method Drupal\field_union\FieldUnionStorageDefinition::create() in Drupal\field_union\Plugin\Field\FieldType\FieldUnion::schema() (line 78 of /git/core/modules/contrib/field_union/src/Plugin/Field/FieldType/FieldUnion.php).

Tested again https://git.drupalcode.org/issue/field_union-3011353/-/tree/field_union-... with latest commit (core 9.5&10.1). Now I was able to create a Field Union and add it to node, however it doesn't seem to save the field union fields value and is causing fatal error when viewing the just saved node Call to a member function build() on null in Drupal\field_union\Plugin\Field\FieldFormatter\FieldUnionFormatter->viewElements()

Some screenshots showing field unions on node edit screen

❤️

larowlan → changed the visibility of the branch 3011353 to hidden.

larowlan → changed the visibility of the branch 3011353-add-ui-for to hidden.

Fyi

We can only see following branches

8.x-1.x
3011563-computed
3011353

This is the branch @johnwebdev https://git.drupalcode.org/issue/field_union-3011353/-/tree/field_union-...

I've taken a look at the branch and made a few observations and stumbled across a few potential problems while testing in the context of adding a field union/composite field. After clicking the Add field union button I am forwarded to /admin/structure/field-union/add:

Is it necessary to set an initial field already on the add field union page? Has the initial field a sort of special role? Cuz if not i wonder if it would make sense to be more consistent with other pages in the context of structure? have the required label field and maybe already add the option to add the machine name next to the label field like you are able to at a later point when you are editing an already existing field:

Instead of the initial field it would make more sense to add a description for the field union field. that might be the more reasonable to step for the initial add field union step, to only set the label and the description of the field union there. As you can see in the screenshot before, for existing field unions the user is able to add and edit a description at a later point. Without the description / context, adding an option for the field union is challenging:

.

The description is more or less essential and got more important with the new ui for adding fields introduced in 10.2. It might even make sense to make the description field required. And the general pattern for options of a field group is providing a bulleted list outlining some basic information as you can see with the example of the number field type group:

.

There is a dedicated issue with discussions on improving the micro copy of those descriptions further: 📌 Refine field descriptions Active (but still a work and idling for a while now). So for one the description currently used for the field union A custom field made my joining other fields together. might be adjusted to the pattern there but on the other hand i wonder if it would make sense to follow the pattern of having a bulleted list of half sentences for each field union as well, to provide some sort of guidance to the user. bu

And the last point about the add field union page is the add new field union button. I wonder if it would make sense for the sake of consistency follow the same pattern used for example for block types. There you have the primary button save and manage fields and a regular button save redirecting to the block type overview page.

In regards of the other points i've noticed (limited the scope of the feedback solely to the add field union page), should i open dedicated issue in the field_union queue for now or should i open issues over in the composite queue already? what would be the preferred way?

Thanks roller
In the composite field queue would be the best place

The reason we ask for the initial field is that the field union must have at least one field and you will always need to do that after creation, so combining it made sense

oki, i've already opened three issues, and have two more in the "backlog". one you probably already have on your roadmap adding local items to composite fields but the other is a bit more tricky but i still have to think it through a bit more. on the manage display page of a content type with a composite field added you have the label " field union view mode" on the display field widget which is sort of confusing - maybe only a labeling problem.

in regards of the initial field thanks for the clarification! having an add composite field page with those more or less homogenous form element, the composite field label, the select list for the initial field and the label for the initial field, has a cognitive load to a certain degree. with the need of defining at least one field for a composite field i agree that the field should be created there already. I wonder if it would be possible to add/prepend one step to that wizard as soon as ✨ Use modals in field creation and field edit flow Needs work is in. that way you would have a clear separation of concerns. on the first step / page you have the composite field label field plus you would be able to add a required field for the description of the composite field. on the second step you would have the cards of the field types available (at the moment you have the select list which is breaking with the pattern of the new cards introduced in 10.2) and depending if you pick a field group or a single group you then have a step with the available options or directly the step with the field config settings.

And with the initial field already created on the add composite field i withdraw my suggestion of adding two buttons and go with just a single primary button and simply change the label from Add new field union to just Save settings, inline with the label on the add a field to a content type flow.

I'm very keen to help with this and give some tasks to my (small) team, however this issue's scope is a little rangy, it might be good to get this merged, moved to the new namespace, and follow up tasks defined.