HelperText on Checkbox?

We have screens with lots of configurations. For some items, the regular label is enough, but for others we need a description of the purpose.
For TextFields we can use setHelperText, but for some reason Checkboxes do not have this.

I’ve done a quick test to see if I can hack it by wrapping a Checkbox in a CustomField, which does have helperText, and it looks ok

There’s an issue about it:

Nice :slightly_smiling_face:

In the meantime, you can use a CheckboxGroup with a single item

Thanks Rolf, but trying helperText out in our application, I’m not sure I can use it anyway.
Maybe FormItem should have support for putting helperText to the right?

Wow those are long helpers.

Here’s the old app

Perhaps you could consider tooltips instead?

No. Then users can’t scan the text, or use ctrl-f to find it

One thing I’d like is to be able to filter. Haven’t gotten to it yet, but I have thought about using a Grid

filtering fields based on label/helper?


right. Interesting idea. I suppose you could try doing that with GridPro so that you’d have proper inline editing… but I suspect the UX of working with that form would not be very nice. You’d probably be better off with a custom solution – I don’t think it would be too difficult to build.

Yes, it should be easy enough to loop over all children and setVisible based on filter.
Tried it in our old app, but our custom

-based layout made it awkward.

yeah, I would (again) propose a css-grid based approach for that, with an element structure along these lines:

<div class="form">
  <div class="row">
    <label>Name tag format</label>
    <vaadin-text-field class="field" />
    <span>Helper text</span>
  <div class="row">

An a few lines of css to do the actual layout. (If needed, small viewport support could be done easily with css-grid e.g. wrapping the row contents into a vertical stack)

Then you iterate through the labels and helpers and hide the rows that don't match (or highlight the ones that do).

(Screen reader support could be provided through aria attributes if needed.)

Something like this should suffice for the layout (without responsiveness):

.form {
  display: grid;
  grid-template-columns: [label] auto [field] auto [helper] auto;
.row {
  display: contents;
.form > label {
  grid-column: label;
.form > .field {
  grid-column: field;
.form > .helper {
  grid-column: helper;

You’d lose the required indicator on the label that FormItem gives you, but you should be able to roll your own with a bit of css:

.row:has(.field[required]) > label::after {
  content: '*';
  display: inline;
  color: red:
or something like that

Haven’t tried the grid-based approach yet. Currently I’m trying your suggestion of having several 1-column FormLayouts next to each other. It seems to work reasonably well. I get the column-1st tab order I want, and I mostly get the layout I want. The only thing missing is “colspan”, but we use that less than I thought. When we have it, it is usually a TextArea at the bottom, and that can become its own thing.

Back to filtering: I was actually a bit more awkward than expected to write a generic routine.
It is easy to get the label from a regular field, but not so much from a FormItem.

right, there’s no API for that. Maybe it would be better anyways to store the label and the field in a Map when you populate the form? That’s going to be much quicker and less code to find labels matching the filter.