Use modals in field creation and field edit flow

Problem/Motivation

The high level plan in #3346539: [Plan] Improve field creation experience proposes to move all of the field creation end editing related pages from separate pages to modal dialogs. In general, this approach is preferred for pages where the UI would take the user outside the previous context (i.e. different base route than the previous page resulting in no local tasks rendered for the page).

The current approach for selecting a field was created as a workaround to a non-modal based workflow in #3356894: Make field selection less overwhelming by introducing groups. Even at the time when this was implemented, we were aware of some challenges with the designs. However, we decided to not optimize for these since we had tested a modal based workflow earlier which didn't have these challenges. Some of these challenges were also reported in #3389200: Field selection breaks conventions and increases cognitive load.

Proposed resolution

This issue focuses on the add new field flow by having the field creation/editing process open in modals (field selection form, combined field settings form).

• Split up FieldStorageAddForm to reduce text in a single modal into FieldStorageAddController and FieldStorageAddForm.
• Where the first [FieldStorageAddController] handles initial field selection such as [plain text, formatted text].
• The second half [FieldStorageAddForm] handles the fieldstorage selection such as [text, text long].
• Replace call to [FieldStorageAddForm], with a call to [FieldStorageAddController].
• Create new routes to reset unsaved field data on hitting the 'Change field type' and one for calling the repurposed [FieldStorageAddForm] for the second step of the field creation modal.

FAQ's

• Keeping the label on the second step of the modal flow for field creation as it accompanies the machine name which is immutable and moving it requires making it mutable which may require extra changes in \Drupal\field\Entity\FieldConfig and \Drupal\field\Entity\FieldStorageConfig
• Creation of dialog.url.js, This is needed because there isn't a way to "redirect" the user to a new dialog after form submission. We can't simply render the new dialog from the original route because form submissions are coupled with routing.
• core/misc/field-list-keyboard-navigation.js change is necessary here as the bug caused due to null object results in failing tests.

Out of scope

• Using modal flow for re-using a field to keep it in sync with the field creation flow.
• Voiceover fixes as it requires work around FormBuilder

A working prototype that was used for validating this

Remaining tasks

1. Mark required fields (like Label) as required.
2. Make sure that Selection lists work. Currently, every submit button goes to the previous modal. (See Comment #17.)
3. Make sure error messages use the same terms as the field labels. (Example: "You need to select a field type." is the error message when the field labeled "Choose an option below" is empty.)
4. Use links or radio buttons consistently so that keyboard navigation is consistent in the various modal screens.
5. Make sure that keyboard shortcuts like Enter, ctrl-Enter, and Tab have the expected results.: #3398568: Ajax submission by (ctrl+enter) causes jquery errors
6. Replace the "Change field type" button with one that goes to the previous step (with context of the selected type).: #3397709: [PP-1] Replace the "Change field type" button with one that goes to the previous step
7. Avoid modals with a single form element. For example, when adding a boolean field, one of the screens has just the label.: #3397711: Move label and machine name fields to the field config edit form
8. Change record for Drupal\Core\Ajax\OpenModalDialogWithUrl
9. Make sure that descriptions of field groups, field types, and options are announced by screen readers.: #73
10. Indicate where we are in the process: something like "step 3 of 5" or list all the steps with an indication of the active one. (Maybe this can be a follow-up issue.): #3397715: Indicate where user is in the process of creating fields

Some of these are probably existing problems. (For example, #3.) Either way, they can be done in follow-up issues if they are not done as part of this issue.

User interface changes

User interface changes

Before

Start on the "Manage fields" page:

• Path: /admin/structure/types/manage/page/fields
• Route: entity.node.field_ui_fields
• Controller: \Drupal\field_ui\Controller\FieldConfigListController::listing

Before

Follow the "Create a new field" link to the "Add field" page:

• Path: /admin/structure/types/manage/page/fields/add-field
• Route: field_ui.field_storage_config_add_node
• Form: \Drupal\field_ui\Form\FieldStorageAddForm

After

Follow the "Create a new field" link to the field selection modal.

• Path: /admin/structure/types/manage/page/fields/add-field
• Route: field_ui.field_storage_config_add_node
• Controller : FieldStorageAddController::getFieldSelectionForm

Before

If you select a category, such as Number, then the options appear at the bottom of the page:

After

After selecting a category you will be redirected to the next step to choose field storage and enter the label and machine name.

• Path: /admin/structure/types/manage/page/fields/add-field/plain_text/true?entity_type=node
• Route: field_ui.field_storage_config_add_sub_node
• Form: FieldStorageAddForm

Before

Submit the form to load the "[Field name] settings for [bundle]" page:

• Path: /admin/structure/types/manage/page/add-field/node/field_decimal (with destinations query parameters)
• Route: field_ui.field_add_node
• Controller: \Drupal\field_ui\Controller\FieldConfigAddController::fieldConfigAddConfigureForm

After

Submit the form and get to config edit for the field.

• Path: /admin/structure/types/manage/article/add-field/node/field_name (with destinations query parameters)
• Route: field_ui.field_add_node
• Controller: \Drupal\field_ui\Controller\FieldConfigAddController::fieldConfigAddConfigureForm

Submit this form to create the field storage and the field, and return to the "Manage fields" page.

API changes

Data model changes

Release notes snippet