[NcField] [NcSelect] field in forms

[kra-mo]

This came up recently in #7838 (comment), a little while ago in nextcloud/talk-desktop#1530 (comment), and nextcloud/server#59431 which is still open.

It's clear that we want a way to more easily fit inputs into forms.

I'm proposing to adapt a solution similar to Talk Desktop:

For fields, a pencil icon would indicate that the field is editable. After clicking it, the "button" would be swapped out by an actual NcField, matching the styling and metrics of the button. Clicking on the checkmark would "save" the value and bring back the button.

For selects, it would be a similar story. Clicking on the button would swap it out with an expanded NcSelect of the same proportions, collapsing it would swap it back.

#7838 may still be viable for simpler selects, but we agreed that it isn't useful for everything, so we'd still need something like this.

What do you think @susnux @ShGKme @nimishavijay?

[ShGKme]

Since this is a custom select, it would be interesting, what features we want to have:

• Custom option formatting (images, sublines, users) like in NcSelect, or only plain text like in the native select
• Groups, like in the native select
• Multi-select support, in forms of select or tags input
• Combobox, allowing to enter a new option (an input with a datalist), or only for search
• Mobile version (native select is very good on mobile, but custom may need a second implementation)

[ShGKme]

For the field, it's similar. I don't know if we can reuse the existing fields with a different styling, or reimplement existing fields features, such as:

• Helper text, error message
• Password field
• Additional buttons (like show-password)

[kra-mo]

Since this is a custom select, it would be interesting, what features we want to have

I think all of them would be nice to have, but most of them are probably not blockers. There's also always the option of representing some of these (like users) as just text in the button state.

For the field, it's similar.

Here, I think it might be fine for all of these features (helper text, revealing the password, additional buttons) to only show up while editing, not when it's just a button.

[susnux]

Since this is a custom select, it would be interesting, what features we want to have

I think we should have different solutions.
It would be great to have a native select for basic tasks (I recently had to copy-paste my wrappers across multiple places where I just needed a native select without all the ncselect overhead).

But in general I think the best case would be we can reuse the components.
So we can have NcSelect for normal content and NcFormBoxSelect for forms while both share the same logic underneath but just have different visual representation.
Same for other component where we ideally can split the components into a shared internal component and only some different visual wrappers around it.

Otherwise we end up with many components duplicating the same logic and likely break the same way but at different times.
So that if we fix something for one its automatically fixed for all.

[susnux]

Here, I think it might be fine for all of these features (helper text, revealing the password, additional buttons) to only show up while editing, not when it's just a button.

I do not think this fulfills a11y - helper texts must be visible as soon as the content is considered invalid (e.g. on submit).

[kra-mo]

I do not think this fulfills a11y - helper texts must be visible as soon as the content is considered invalid (e.g. on submit).

Okay, then that could be visible in both cases.

So we can have NcSelect for normal content and NcFormBoxSelect for forms while both share the same logic underneath but just have different visual representation.

Something like that. I definitely think this is the way to go.

[nimishavijay]

Nice, this looks good! For simple text/selects, it's pretty much there, but I'm thinking about Mail account settings and visually many of the text fields have little explanations for the label in the form of a subline. We should definitely reword/shorten or even completely do away with some of the sublines, but I doubt it will be possible to not have them at all. So it will be important to structure that well (cc @ChristophWurst)

[kra-mo]

@nimishavijay these explanations are still outside the actual input though, right? In that case, you could keep them the way they are. But being brief is nicer :)

[kra-mo]

iOS uses a similar pattern of placing it outside as they do not have descriptions for fields:

[nimishavijay]

Yes, makes sense. Just wanted to make sure there is no unexpected behaviour :)

[jancborchardt]

Looks great! :)