Generate UI metadata dynamically

[dawehner]

Right now UI Metadata is hard coded. It basically contains everything form display related. Sadly in Drupal this information is stored both in field instance configuration (field_config) but also in entity_form_display configuration.

Let's provide an endpoint which returns, given a bundle and form mode, the necessary settings per field. Ideally it would return the same information as the current hardcoded uiMetadata.js file

[justafish]

We also want to register specific front-ends, so this should also accept a consumer ID as some kind of context (e.g. to distinguish between this React app and an Android app).

Here's the current data structure we want to replicate: https://github.com/jsdrupal/drupal-admin-ui/blob/master/src/components/05_pages/NodeForm/UiMetadata.js

[tedbow]

@justafish I think it would be good if we could use Form modes in Drupal for this. Otherwise we have to build another UI that allows configuring forms per consumer.

So the resource would be something like /api/entity-form/node/article for the default form and /api/entity-form/node/article/short_form for the short_form form mode.

The site builder would still be responsible for configuring the forms and the different form modes.

I am not sure how the JS side is going to handle different form widgets. In Drupal configuring the forms you have selection of all field widgets from any module.

Will the JS app support some widget using the same plugin-id for the widget? How would Drupal know which ones the JS app supports?

[dawehner]

I think we should just support the widgets Drupal offers right now. If the apps decide to not implement something, I think falling back to the default widget is something the app can decide by themselves, maybe depending on the schema type. Given that we don't need to know which widgets the app supports inside Drupal. I think this is an okay way, what do you think?

[justafish]

@tedbow I think we should be configuring forms per consumer, otherwise the consumer doesn't know which form to fetch

[justafish]

(and we can definitely punt on building the UI for different consumers and hard code the consumer ID for now)

[tedbow]

@justafish I guess understand what the consumer would not know. Would they know entity type node and bundle article? If not what happens when they need different entity types and bundles?

[dawehner]

Would it be fine to use the default form display right now?

[gabesullice]

If I understand what this is, I was thinking about something very similar and a way to link to this information from JSON API here: https://www.drupal.org/project/jsonapi/issues/2960550

[wimleers]

(@tedbow brought this up during the API-First Initiative call that just ended.)

Let's provide an endpoint which returns, given a bundle and form mode, the necessary settings per field. Is it really necessary to have a new endpoint for this? All that data is already available for configurable fields. You'd "just" have to request field_storage_config, field_config and form_display config entities separately, and merge the data together. That can be done on the client side too. That information can then be cached, meaning this is a cost only paid during initial boot or access.

(We'll need to solve the "configuration changed on the server, now client-side cached information based on configuration needs to be invalidated" problem anyway at some point.)

That being said, this does of course not work for base fields. I'm guessing that this is why you're choosing to write (and maintain!) code for a new endpoint for now?

Would it be fine to use the default form display right now?

I also think this would be preferable for now.

Especially because then the JS admin UI is not dependent on the concept of "consumers" (which I agree is a nice concept/abstraction!), which makes it easier to move the JS admin UI into core in the future.

[…] hard code the consumer ID for now)

Instead of consumer ID, this could hard code the form display mode for now.

---

Looking at https://github.com/jsdrupal/drupal-admin-ui/blob/master/src/components/05_pages/NodeForm/UiMetadata.js, seeing constraints in there scares me a bit, if it's meant to list validation constraints. Especially if the idea is to have one central place for all UI metadata that is also meant to be alterable, because then it becomes all too easy to add validation constraints to the UI only rather than to the underlying data model. If it would explicitly communicate that it's only about client-side validation constraints, I wouldn't find it scary anymore :)

---

Related: https://www.drupal.org/project/jsonapi/issues/2822768.

[dawehner]

Looking at https://github.com/jsdrupal/drupal-admin-ui/blob/master/src/components/05_pages/NodeForm/UiMetadata.js, seeing constraints in there scares me a bit, if it's meant to list validation constraints. Especially if the idea is to have one central place for all UI metadata that is also meant to be alterable, because then it becomes all too easy to add validation constraints to the UI only rather than to the underlying data model.

Well, my idea is to serve the constrains from within the existing Drupal constrains. The JS side can choose to implement those. Some of them do make sense to be client side (machine name validation or something), but some of them just don't make sense to be client side. Exposing the same metadata though gives the requirement flexibility in the future.

This approach makes it impossible to add constrains which aren't reflected in the data model. We have thought about that before :)

[wimleers]

Exposing the same metadata though gives the requirement flexibility in the future.

Sure, as long as there is no intent to allow the list of constraints to be modified.

[lauriii]

This issue was covered on yesterdays JavaScript weekly meeting (full record of the discussion will be released here).

As part of the discussion, we came to conclusion that as a first step we would proceed with the approach that @mattgrill introduced in #260 because this is the path with least resistance since it only affects the client, thus being fully controlled by our team. The approach uses pre-existing API endpoints and have the logic required for mapping the data together on the client.

There was agreement that it would be important to do further research how we could improve our current APIs to reduce complexity of implementing clients. Some of the missing features needed for the MVP could be added to pre-existing APIs such as the information about constraint validators on the backend.

---

Would it be fine to use the default form display right now?

This seems reasonable for now.

As a next step we should open a separate issue (preferably in Drupal.org) for discussing the consumer storage.