feat(Forms): add inline HelpButton to all Field.* components as default (with option to open in Dialog)

[tujoworker]

This PR changes the existing behavior of the help prop for Fields that previously supported it. The content now opens inline instead of in a Dialog.

The help prop has now all of these optional props:

<Field.String
  label="Label text"
  help={{
    title: 'Help is available',
    content:
      'Take the time to help other people without expecting a reward or gratitude is definitely important in living an optimistic life.',
    open: false,// only for the inline variant
    renderAs: 'dialog'
  }}
/>

We use this prop description:

Provide help content for the field using title and content as a string or React.Node. Additionally, you can set open to true to display the inline help or use renderAs set to dialog to render the content in a Dialog (recommended for larger amounts of content).

Examples with inline "HelpButton":

• FieldBlock (several examples)
• Form.MainHeading
• Form.SubHeading
• Field.String
• Field.Number
• Field.Upload
• ... many other fields do have an example as well.

NB: We do not document the internals of the inline version at this time. This can be included in another PR. The reason is that it would require additional tests, examples, and documentation. It is also an "isolated" feature specific to the HelpButton. However, as of this writing, I am unsure if we will ever document it, as integration is not straightforward. There are several considerations to address when implementing it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
eufemia	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 17, 2024 8:47pm

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[langz]

I tested tabbing with keyboard, and it works great 👍
Found one edge-case when using enter/space to opening the help text, in the following example: https://eufemia-git-feat-forms-inline-help-button-eufemia.vercel.app/uilib/extensions/forms/create-component/FieldBlock/demos/#inline-help-button-vertical-label-description

It only happens when spacing/entering, not when clicking.
Sometimes it can be hard to reproduce, but double spacing/entering twice fast can lead to it, but is not necessary(in the video provided, I don't do it fast).

The issue/error is that it somehow focuses the section(?)-element inside the help text, which I don't think it should? As it doesn't do so when clicking with the mouse.

Screen.Recording.2024-11-15.at.09.21.06.mov

[langz]

Suggested change

	### Inline help button (horizontal label)
	### Inline help button (horizontal label)
	Help text will appear above the field when using horizontal labels.

Makes sense, but just got surprised when I tested this https://eufemia-git-feat-forms-inline-help-button-eufemia.vercel.app/uilib/extensions/forms/create-component/FieldBlock/demos/#inline-help-button-horizontal-label, as I sort of still expected it to show up the same as with vertical labels, but that's not possible 😅

[tujoworker]

I gave it a try. And I think its better to have it appear always "below" the label. Also when the layout is horizontal.

[langz]

I tested the following example with the following code:

<Field.Composition info="Info at the bottom" width="large">
  <Field.String label="Field A with a long label" width="medium" help={{
    title: 'Help title',
    content: 'Help content',
  }}/>
  <Field.String label="Field B" width="stretch" help={{
    title: 'Help title',
    content: 'Help content',
  }} />
</Field.Composition>

And for the field with width="stretch" the help text appeared(animated in) in the opposite way then usual:

Screen.Recording.2024-11-15.at.10.10.12.mov

[langz]

I made a CSB to try out help together with layout="horizontal".
Not sure what we should support or not for Field.Composition
Here's some observations:

Upload: help goes over border

Field.Selection input fields changes position and/or width when opening/closing the help:

Screen.Recording.2024-11-15.at.11.44.04.mov

Screen.Recording.2024-11-15.at.11.44.55.mov

Screen.Recording.2024-11-15.at.11.44.34.mov

Screen.Recording.2024-11-15.at.11.44.44.mov

Further, it's also not all Fields that support layout="horizontal", but that's probably on purpose, and then we don't have to care about the "styling issues" if it's not supported for these components/fields:

[langz]

Should we add this help functionality to the ValueBlock as well?
Could see us doing so at a point, and perhaps even add inheritHelp

[langz]

Field. BankAccountNumber when layout horizontal, changes position and/or width when opening/closing the help:

The same happens with almost all feature fields

Screen.Recording.2024-11-15.at.12.02.41.mov

[langz]

Here's a CSB displaying some possible alignment issues when using help with layout vertical for fields that have two fields., in a card
https://codesandbox.io/p/sandbox/funny-ishizaka-sgcp6x?workspaceId=9eb653cb-4406-4b8f-bc96-714927cc7fcd

It's like it takes a bit more width than the width of the input field.

[tujoworker]

I think I have covered now all of your fantastic feedback.

The rotation animation runs now also when hiding the help content.

Some fields do not support a horizontal layout, such as PostcalCode and PhoneNumber. But also Composition does not support it.

[tujoworker]

Thanks, sure, fine that we don't support horizontal layout in PostCodeAndCity, PhoneNumber, Composition, etc.
But how could/should we say that to our users?
In the docs, it seems like we should support it, at least for:

I have update the docs for the PostalCodeAndCity field. PhoneNumber is already taken care of.

I'm still able to reproduce this, but I'm not sure how important this is to fix, or if actually is anything to fix 🤔

I'm not able to reproduce it anymore. Also, we already have dnb-no-focus to the section element. Not sure what I do wrong 😄

I'm still able to reproduce this as well, https://codesandbox.io/p/sandbox/autumn-glade-r4n5v6?workspaceId=9eb653cb-4406-4b8f-bc96-714927cc7fcd

Found another solution.

Here's a CSB displaying some possible alignment issues when using help with layout vertical for fields that have two fields., in a card https://codesandbox.io/p/sandbox/funny-ishizaka-sgcp6x?workspaceId=9eb653cb-4406-4b8f-bc96-714927cc7fcd

Also enhanced + added a visual test.

[langz]

Thanks for the updates @tujoworker
I've forked and updated the Eufemia version to be of latest commit f63c8181 in this PR for the following CSBs:

• Card vertical(can't remember what I used this for)
• BankAccountNumber vertical
• All fields horizontal
• All fields vertical

I've not tested them yet.

EDIT: I've tested them now, and it looks better 👏
Only two thoughts left from me:

• feat(Forms): add inline HelpButton to all Field.* components as default (with option to open in Dialog) #4282 (comment)
• feat(Forms): add inline HelpButton to all Field.* components as default (with option to open in Dialog) #4282 (comment)

[langz]

I quickly re-tested tabbing and openeing/closing with enter and space keys, and I feel it works worse now.
I'm not able to reproduce the active/focused state of the section(?), which is good, but when using space and enter now it works worse.

Using space, first time it opens, next time I do space it scrolls down the page(even though the button looks active/focused).

Using enter, first time it opens, next time I press enter it won't close (even though the button looks active/focused):

Screen.Recording.2024-11-16.at.12.46.25.mov

https://eufemia-git-feat-forms-inline-help-button-eufemia.vercel.app/uilib/extensions/forms/create-component/FieldBlock/demos/#inline-help-button-vertical-only

Maybe we just revert this funcionality, and fix it if it becomes a issue down the line, I'm not sure if the issue initially reported is critical or not.

[langz]

Since last time I checked the CSBs, the All fields horizontal latest commit looks quite different from what it did in the previous commit/change.
Is it intentional that it doesn't use the full width anymore when layout is horizontal?
For me it's fine, just curious 👍

How it was:

How it is now:

[langz]

Some fields do not support a horizontal layout, such as PostcalCode and PhoneNumber. But also Composition does not support it.

Do we have to support it in the future?
Does it today exist a component that you can wrap all fields in, and say layout=horizontal, like in the form.handler Field.Provider, etc? Probably Field.Provider. Wouldn't the form look very strange now, when some Fields support horizontal and other don't? Or perhaps those fields(PostalCode and PhoneNumber) looks best as vertical, even when in a form where all other fields are horizontal? 🤔

Here's a CSB using Field.Provider with layout horizontal.

Sidenote: Not sure why, but in that CSB I'm not able to enter anything in the postalcode field 🤔

[tujoworker]

Using space, first time it opens, next time I do space it scrolls down the page(even though the button looks active/focused).
Using enter, first time it opens, next time I press enter it won't close (even though the button looks active/focused):

We set focus on the section so screen readers can navigate in there and also get read out the text. Even if the content is placed on a different DOM order.
But also so we can show the "hover" state (larger than focus).
I added support for the enter/space key to close it again. From before we had support for esc key.

Is it intentional that it doesn't use the full width anymore when layout is horizontal?

Yes. Not it is aligned on how the status messages looks. Same border radius too. I think this is the most logical way to display this information on in a consistent way.

Do we have to support it in the future?

I have never seen any PhoneNumber etc. layout that could work with these fields. So as of now, this is how it is. Most horizontal layouts are used within a small part of the form. So we do not need to support necessarily all fields with that layout.

[langz]

Using space, first time it opens, next time I do space it scrolls down the page(even though the button looks active/focused).

Using enter, first time it opens, next time I press enter it won't close (even though the button looks active/focused):

We set focus on the section so screen readers can navigate in there and also get read out the text. Even if the content is placed on a different DOM order.

But also so we can show the "hover" state (larger than focus).

I added support for the enter/space key to close it again. From before we had support for esc key.

Is it intentional that it doesn't use the full width anymore when layout is horizontal?

Yes. Not it is aligned on how the status messages looks. Same border radius too. I think this is the most logical way to display this information on in a consistent way.

Do we have to support it in the future?

I have never seen any PhoneNumber etc. layout that could work with these fields. So as of now, this is how it is. Most horizontal layouts are used within a small part of the form. So we do not need to support necessarily all fields with that layout.

Thanks Tobias, that sounds smart.
I'm very pleased with this.
Will take a quick round of testing now

[langz]

Thanks again the updates @tujoworker 🚀
I've forked and updated the Eufemia version to be of latest commit 24ab19b3 in this PR for the following CSBs:

• Card vertical
• BankAccountNumber vertical
• All fields horizontal
• All fields vertical

[langz]

Thanks for the great job 👏
Works perfect now :)

[tujoworker]

🎉 This PR is included in version 10.56.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀