Components Overview

This section documents the current Vaadin release line — Vaadin 24 LTS / 25.x, Java 17+, Spring Boot 3 / Jakarta EE 10 — as published at the official Vaadin documentation, which is the reference these pages are written and verified against. No specific patch version is pinned. Flow (server-side Java) is the authoring style used throughout, with Hilla / React shown where it differs; Vaadin 7 and the pre-Flow architecture appear only as migration contrast.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production, since Vaadin ships major releases roughly twice a year and its ecosystem iterates.

This section’s bibliography lists the reference material consulted while preparing these pages.

Every Vaadin Flow UI is a server-side tree of Component objects, each paired with one client-side element and each mixing in a small set of capability interfaces. This page maps that model and tours the built-in component set; see Components for the full catalog and Compose with Components for how to break a view into a hierarchy.

The Component base class and the Has* mixins

com.vaadin.flow.component.Component is the superclass of every UI component. It wraps a single root Element, and exposes lifecycle and identity methods — getElement(), getParent(), getChildren(), setId(), setVisible(), and attach/detach events. Beyond that, each component implements only the mixin interfaces for the capabilities it actually has, so the API a component offers is visible from its implements clause. See Using Vaadin Mixin Interfaces.

Interface What it contributes

Component

Base class: one root Element, getElement(), getParent(), getChildren() (a Stream<Component>), setId(), setVisible(), addAttachListener / addDetachListener.

HasComponents

add(Component...), remove(Component...), removeAll(), addComponentAsFirst, addComponentAtIndex — implemented by containers such as Div, VerticalLayout and FormLayout.

HasSize

Dimension setters: setWidth, setHeight, setMinWidth / setMaxWidth, setSizeFull, setSizeUndefined, plus the matching getters.

HasStyle

CSS class and inline-style API: addClassName, removeClassName, setClassName, getClassNames(), and getStyle() for individual inline properties.

HasValue<E, V>

The field contract: getValue / setValue, isEmpty, clear, addValueChangeListener, setReadOnly, setRequiredIndicatorVisible. This is what Binder binds against.

HasEnabled

setEnabled(boolean) / isEnabled(). A disabled component is greyed out and the server drops events and property updates coming from it — see Component Enabled State.

Focusable<T>

Keyboard focus: focus(), blur(), setTabIndex(), addFocusListener, addBlurListener.

Related mixins you will meet include HasText, HasLabel, HasHelper, HasTheme, HasTooltip and HasValidation; the mixins page above lists them all. Because these interfaces are additive, a single field carries several at once:

// TextField implements Component, HasSize, HasStyle, HasValue<..., String>, HasEnabled, Focusable<TextField>, ...
TextField name = new TextField("Name");

name.setWidth("20em");                       // HasSize
name.addClassName("highlight");              // HasStyle
name.getStyle().set("margin-top", "0.5em"); // HasStyle
name.setValue("Ada");                        // HasValue
name.addValueChangeListener(e -> System.out.println(e.getValue()));
name.setEnabled(false);                      // HasEnabled
name.focus();                                // Focusable

Custom components acquire the same API by extending Component (or Composite) and implementing whichever mixins apply — covered in Building Custom Components.

Adding and removing children

Any component that implements HasComponents manages its children through the same four methods, regardless of which layout it is. Structural changes take effect on the next server round trip.

VerticalLayout layout = new VerticalLayout();   // implements HasComponents
Span a = new Span("A");
Span b = new Span("B");

layout.add(a, b);                       // append one or more children
layout.addComponentAsFirst(new Span("header"));
layout.addComponentAtIndex(1, new Span("inserted"));

layout.remove(a);                       // detach a specific child
layout.removeAll();                     // detach every child

List<Component> children = layout.getChildren().toList();  // getChildren() returns a Stream<Component>

getChildren() returns only the direct children as a Stream; walk it recursively for the whole subtree. remove on a component that is not a child throws IllegalArgumentException, while removeAll is always safe. Adding a component that already has a parent moves it — it is detached from the old parent first.

Enabled and visible state

Two independent flags control whether a component is live.

Button save = new Button("Save");

save.setEnabled(false);   // rendered but greyed out; the server ignores clicks and value changes from it
save.setVisible(false);   // not rendered in the browser at all

setEnabled(false) keeps the element in the DOM but tells the server to reject any event or property update originating from it (and from its descendants). setVisible(false) goes further: before first render the element is never created, and after render Flow marks it hidden, stops sending it updates, and ignores RPCs that target it.

Security: server-side setVisible(false) — or simply never adding a component — means the component’s markup and the data bound into it are never sent to the browser, and the server will not act on requests against it. This is fundamentally different from hiding an element with CSS (display: none / visibility: hidden), where the value still sits in the DOM and is trivially readable from dev tools or a crafted request. A field that must not reach an unauthorized user should be removed or made invisible on the server, not merely styled away. See Component Visibility and the Flow security documentation, whose architecture overview notes that Vaadin "denies actions to components that aren’t currently visible on the screen."

The built-in components: a grouped tour

Vaadin ships more than 40 components. They fall into a few groups, each with its own dedicated page in this section; the Components catalog has a live example for every one.

Group Components (selection) Dedicated page

Input fields

TextField, TextArea, EmailField, PasswordField, NumberField, IntegerField, BigDecimalField, Checkbox, CheckboxGroup, RadioButtonGroup, ComboBox, MultiSelectComboBox, Select, ListBox, DatePicker, TimePicker, DateTimePicker, Upload, CustomField

Input Components

Buttons & menus

Button, MenuBar, ContextMenu, Tabs / TabSheet, SideNav, Breadcrumbs

Interaction and Overlays

Data visualization

Grid, TreeGrid, GridPro, VirtualList, Charts, Spreadsheet, ProgressBar, Avatar / AvatarGroup, Badge, MessageList

The Grid Component

Layouts

VerticalLayout, HorizontalLayout, FlexLayout, FormLayout, SplitLayout, Scroller, AppLayout, MasterDetailLayout, Accordion, Details, Card, Dashboard

Layouts

Overlays & feedback

Dialog, ConfirmDialog, Popover, Notification, Tooltip, LoginOverlay

Interaction and Overlays

Input fields all implement HasValue, so they plug straight into a Binder (Data Binding). The range runs from TextField and ComboBox to the lazy-loading MultiSelectComboBox and the DatePicker family; Upload handles file transfer and CustomField composes several inputs into one value.

Buttons and menus drive actions. Button carries variants and icons, MenuBar and ContextMenu build nested menus, and Tabs plus SideNav structure navigation.

Data visualization centers on Grid — a lazy-loading, sortable, editable data table (in Vaadin 7 this role was filled by Table) — with TreeGrid for hierarchies and VirtualList for custom row rendering. See The Grid Component for data providers and lazy loading.

Layouts arrange components without hand-written CSS: VerticalLayout / HorizontalLayout wrap flexbox, FormLayout does responsive label grids, and AppLayout provides the application shell. Details in Layouts.

Overlays open above the page: Dialog and ConfirmDialog for modal content, Popover and Tooltip for anchored hints, and Notification for transient messages. See Interaction and Overlays.

In Hilla / React: the same components ship as @vaadin/react-components and compose with JSX and hooks instead of add() / remove(); child structure is expressed as nested elements and state, not method calls. The visible/enabled semantics and the commercial licensing below are identical.

Pro (commercial) components

Most components are free and open source. The following require an active commercial Vaadin subscription; using any of them adds a license check at build and production start-up (see License Validation). For an at-a-glance comparison with third-party UI kits, see UI Component Libraries.

  • Grid Pro — inline cell editing on top of Grid.

  • CRUD — a ready-made list-plus-editor for one dataset.

  • Charts — interactive chart types (line, bar, pie, gauge, …​).

  • Spreadsheet — an Excel-compatible spreadsheet surface.

  • Rich Text Editor — WYSIWYG editing producing HTML or Delta.

  • Map — an OpenLayers-based map (production use needs a paid tile service).

  • Dashboard — a draggable, resizable widget board.

  • Confirm Dialog — a ready-made confirm / cancel / reject modal (vaadin-confirm-dialog).

  • Cookie Consent — a GDPR/CCPA consent banner.

Free alternatives cover many cases — Grid instead of Grid Pro, a hand-built form over a Grid instead of CRUD (Forms, CRUD and Master-Detail), and a plain TextArea instead of Rich Text Editor.

See also