Improve or extend component to add new values to datasets on-the-fly

[gappc]

This issue is was discussed in https://github.com/noi-techpark/it.bz.opendatahub.databrowser/issues/416 and is now moved into its own issue.

The next few lines contain the relevant parts of the discussion in issue https://github.com/noi-techpark/it.bz.opendatahub.databrowser/issues/416

############################################## sseppi commented on 2023-08-17 (https://github.com/noi-techpark/it.bz.opendatahub.databrowser/issues/416#issuecomment-1681929974) ############################################## Hi pkritzinger,

I tried the Published on functionality that has been implemented and, as you can see in the screenshot below, it is missing the possibility to add a new publisher as a string.

For the Publishers it is fine this behavior. But for the new fields we need to to provide to the user the possibility to add a new value as a string. This means that the steps the data manager will do are the following:

1. use the drop-down menu and search in the existing values
2. if he needs a need a new value selects the value "other" or "new" the fields becomes a string input filed
3. the user input the new value and saves
4. The next time the user should find the new value in the drop-down menu.

Did I clarify what I meant? The Published on attribute you designed in the Figma file was intended so?

MatteoBiasi Maybe the drop-down menu is already implemented like that and it must only be configured properly. Can you please check? MatteoBiasi The drop-down menu should be populated by using the distinct function on the field we are populating. ##############################################

############################################## pkritzinger commented on 2023-08-17 (https://github.com/noi-techpark/it.bz.opendatahub.databrowser/issues/416#issuecomment-1682223956) ############################################## Hi sseppi You are right, the published on functionality that is online does not include the features you requested since (as far as I remember) we implemented a more simple published on component. But the design in the figma-file should meet your needs (s. Screenshot below).

Let me know what you think.

##############################################

[gappc]

Although the solution seems fine there is some stuff that we need to discuss and refine before we can implement it:

• it won't work as depicted if an endpoint requires more than a simple name to add a new record
• there is no mentioning of error handling (what if adding a new value fails?)
• what if the new value has a typo? how could a user fix that?
• should we allow a user to add arbitrary values? What if a user adds position 1 and Position 1 and position1? What if a user adds a duplicate name ? (these questions are probably API related, but we should at least not forget about these cases)
• the current design shows the solution when the component is used in a table: a user clicks + ADD NEW, the DropDown disappears and a input-field without borders is shown instead, together with two icons in the last table column to accept or cancel the new value. In my opinion, this is to restrictive, how should this component behave if it is not used in a table? I think that a generic solution would be better

[sseppi]

@gappc I try to provide some more feedback below to be quicker in the refinement during the meeting.

Although the solution seems fine there is some stuff that we need to discuss and refine before we can implement it:

• it won't work as depicted if an endpoint requires more than a simple name to add a new record

This functionality has been implemented for String fields where information similar to tags has to be input, to help user in filling the fields quicker and reducing the risk of creating duplicates.

• there is no mentioning of error handling (what if adding a new value fails?)

New values will be stored as a String in the filed, this means that the error handling should be the same as the String. this means that the new value will be visible and the next page refresh only if the dataset gets stored correctly.

• what if the new value has a typo? how could a user fix that?

I see two different possibilities:

1. the user deletes the value and inputs as a new value the correct one
2. allow the user to switch to Sting input type also if there is a value in the field. N.B. In any case, since we are filling String fields, the typo will be corrected only in the record where I'm and not in all other record where the value has been chosen.

@pkritzinger what do you think?

• should we allow a user to add arbitrary values? What if a user adds position 1 and Position 1 and position1? What if a user adds a duplicate name ? (these questions are probably API related, but we should at least not forget about these cases)

For now the fields we are populating with this feature can have arbitrary values that we can't foresee before. We thought that helping the user to see already existing values we could reduce the input of duplicated values. I would suggest to start as it is, without specific checks and implementing more complicated checks only if needed.

• the current design shows the solution when the component is used in a table: a user clicks + ADD NEW, the DropDown disappears and a input-field without borders is shown instead, together with two icons in the last table column to accept or cancel the new value. In my opinion, this is to restrictive, how should this component behave if it is not used in a table? I think that a generic solution would be better

You,re right, probably we need this behaviour also outside a table.

@pkritzinger can you create a proposal also for an independent input field?