UX: Design for updated data model selection

[nkylstad]

Description

Going forward, Studio must support both the old format for dataModelBindings in component:

"simpleBinding": "<data-model-field>"

and the new format:

"simpleBinding": {
  "property": "<data-model-field>",
  "dataType": "<data-model-name>"
}

We must be able to show the users the old format. When the user edits the dataModelBinding for a component, it will be converted to the new setup. So we should not support setting up the old format.

The apps support both setups. If the old format is used, then the default datamodel is fetched. This is the datamodel that is defined in layout-sets.json.
Therefore, we will always be able to display both the datamodel (either explicit in the new format, or default in the old format) and the data model field.

Points to consider

User should be able to select which data model they want to use for a given component.
When editing/adding a datamodel field for a component:

• Should we automatically select a default datamodel, so the user does not have to do that with every component?
• Should we allow the user to define/switch which datamodel they want as the default selected?

[Annikenkbrathen]

We discussed this issue in this slack channel: https://altinndevops.slack.com/archives/CDU1S3NLW/p1715090076581889

FIGMA LINK

We made a new design for the Datamodellknytning component, adding a new select option. So now we have one for Datamodel and one for datamodel binding. (With the name of the binding on top, so it still match the closed design )

When editing a new existing datamodelbinding/old config (Who only has selected a binding) the new component should show, and the user should be forced to chose a data model.

And we discussed the validation when the bindings are not valid anymore.

In the process page, we discussed showing this message when the user change datamodel here.

I gathered it all with som discussion points in Figma ☺️

[Ildest]

Update text @Ildest - rephrase "vil ikke fungere"

[nkylstad]

For first implementation, we should implement the component as-is, but add a feature flag to the datamodel select. This is to make sure that the user cannot select the new setup before apps releases the new functionality for multiple data models.
We should show the data model just as info for now, unless the feature flag is enabled.

[nkylstad]

Validation of data model bindings is not part of this issue, only implementing the new data model selection component.

[Ildest]

If I have understood this correctly @nkylstad :

As a simple solution, I think I would just remove the check/validate-part of the message, and then we can check whether we need more than one message tailored to different scenarios.

Suggestion: Du har byttet datamodell. Sjekk eventuelle knytninger mot komponenter som tilhører den gamle datamodellen, og velg om du vil oppdatere dem med ny datamodell.

[nkylstad]

Implementation in #12738