Merge "select codelist" and "edit codelist" views

[TomasEng]

The user should be able to edit a codelist regardless of whether it's a predefined codelist or a codelist that is defined directly on the component. When we have this functionality in place, we should merge these to views into one. However, we should leave some visual clues to let the user know whether they are working on a predefined codelist or a direct one.

Additional information

Based on meeting about how we handle saving across the Studio solution, we should strive to always use debounce, but if that involves technical issues, we should save on onBlur instead of on onChange.
A part of this issue will therefore include adapting the StudioCodeListEditor usage in ux-editor to take advantage of the onBlur callback instead of the onChange callback.

Dependencies

• Implement StudioCodelistEditor in component edit view #13505
• Make it possible to use manual editor to edit predefined codelists #13678
• feat(ui-component): Add event listeners on table level #13923

[Annikenkbrathen]

When this is picked up, could you do a check-in with ux?

[Annikenkbrathen]

I have some design suggestions for this merge. See Figma link

[Annikenkbrathen]

🔥
@Konrad-Simso and I discussed the design pattern for editing directly in the library from the component and identified some drawbacks with the current approach.

The delete icon removes the code list that has been chosen, while edit icon edits the main file in the library. My intuitive expectation was that you would only edit the code list within the component itself, meaning the file would be overwritten and saved as a separate version within the component, independent of the file in the library. After all, you don’t delete the entire code list when you press delete here.🤔

So, we discussed what users intend to do with the code list when they choose to edit a code list retrieved from the library within the component. Do they want to edit the main file or customize the code list for their own use? We assume it’s likely the latter when working within the component—unless they find a typo in the code list that they will fix . Therefore, it might be confusing to let users edit directly in the library from the component, as we currently allow.

We discussed possible solutions to improve the user experience:

• Present the user with the option to either create a copy or edit the library file when they click edit. This clarifies what they are choosing to modify.
• If the user edits an existing library file within the component, the code list should automatically be saved as a copy that does not affect the main file in the library (although this could lead to a lot of duplicated code). Additionally, there’s the question of whether the copy should be added to the library or not.
• When the user clicks edit, they are redirected to the library so they understand where the edits are being made. In this case, we might need to find a way to guide the user back to where they were.

We should create an issue and discuss this challenge with the domain😊

Feel free to share some screenshots @Konrad-Simso

[Konrad-Simso]

Here is a video of the current solution i've come up with after discussing options with Anniken last week.

20241120-0715-57.1485237.mp4

I'm in the process of changing the color of the delete/remove choice button, we already have a studio component for this, i'd forgotten it exists. And also making the entire left side a clickable button to open the edit modal.

[Annikenkbrathen]

Jeg lager et issue på å teste bibliotek og fokusere på redigering av kodeliste i komponenten

Et annet alt for løsning er også å legge til en infotekst :D