Data Grid

Guidelines

When to use

• to help users consume large amounts of information: Data Grids are great for displaying structured data in an easy-to-digest manner.
• When a user needs to find a specific piece of data and perform an action: Data Grid’s features allow locating information quickly and performing an action directly on a single record or in bulk on a bigger selection.
• When a user needs to compare and analyze the data thoroughly: While charts and graphs are helpful in providing insights, some power users will want to see the source data behind them.
  

When not to use

• When you have only a couple of columns: Data Grid with fewer columns will have a lot of white space, making the information more difficult to digest. Try using lists or cards for a better experience.
• In confined spaces: Once a user has to scroll to view all data, it becomes challenging to compare, analyze, or locate the information effectively. Opt for a list or cards instead.
  

Placement

The Data Grid is designed to be placed in the main content area of a page within a full-width layout to ensure optimal user experience. Its usability may decline on smaller screens due to the need for both vertical and horizontal scrolling, but users can still access all data. In certain scenarios, the Data Grid can be used within smaller containers, such as a large side panel, in “view mode" under specific conditions:

• it must contain a limited amount of data to avoid the need for vertical scrolling,
• all UI features like filtering, sorting, search, and reordering should be disabled to hide the Data Grid Header and its controls,
• if a title is needed, a new one must be created since the default title's font is too large to fit in a smaller container.

While Data Grids’ usability decreases on smaller screens, thanks to both vertical and horizontal scrolling, users can still consume all the data.

---

UI features

Search

Located in the Data Grid Header, the Search input allows users to quickly find specific records by matching the searched term to the data. The term can be a string, a number, or a date, as long as it matches the column formatting (it also works if text is inside another component, like a Tag or Status indicator).

Search is enabled by default on all columns but can be disabled at the Data Grid or individual column level, though this should be avoided to prevent user confusion and frustration.

 

Sorting

Columns can be sorted in ascending or descending order by clicking the Column’s title label (supported by an arrow icon appearing on hover) or through the Column's Menu.

When sorted, an icon is displayed next to the title: arrow up for ascending or arrow down descending order. Only one column can be sorted at a time; selecting another removes the previous sorting.

Sorting is enabled by default on all columns but can be disabled at the Data Grid or individual column level.

 

Filtering

Filters are accessed through a filter Icon Button in the Column’s Header. An active filter is marked with a primary badge on top of the filter icon.

There are currently six filter types, each with controls adjusted to the data type:

• string - for text-based columns with unique values, e.g., user name, notes, reservation number.
• number - for columns with numerical values only, e.g., price, age, revpar.
• multiselect - for columns with repeated values, e.g. payement status, service,
• boolean - for values that are stored as true/false in data base (though could be displayed differently in the UI) e.g. enabled/disabled status,
• date - for columns with date format
• date+time for columns with date and time format

All filter types, except boolean, include a predefined set of logical conditions that enable more refined filtering.

 

Grouping

Grouping by column allows users to “bundle” multiple rows into a group based on the same value in the given column. Multiple levels of grouping can be defined simultaneously, resulting in a nested structure with expandable rows.

Grouping can be done through the Column’s Menu, or via the Group by Control in the Data Grid Header. The user can select multiple columns and reorder them using drag-and-drop. Ungrouping can be done in bulk through the “group” Column’s Menu or the Group by Control.

The default view can be grouped by columns if such a structure logically corresponds to users’ needs or mental models.

A column can be excluded from grouping if its content makes it redundant. This is typically the case with columns where each row would have a different value, e.g., a column with notes or payment amounts.

 

Aggregation

For numeric columns, an aggregated function can be computed over all rows, such as:

• Sum (total revenue, total nights, total items)
• Average (average price, average lead time)
• Count (number of reservations, number of guests)
• Min/Max (earliest check‑in, latest checkout)

In Data Grid, aggregation can be done on two levels:

• in a footer, taking into account values from all rows
• in parent rows when grouping is applied, calculated over values from child rows.

 

Selection and bulk actions

Use enableRowSelection property to enable users to select multiple rows and perform actions on all of them simultaneously, and reduce the effort required to apply the same action to each item individually.

When enabled, the first column of the Data Grid displays checkboxes that let users select specific rows. The checkbox in the Column’s Header lets users quickly select or deselect all rows at once.

When one or more rows are selected, a floating Action toolbar appears, providing the user with access to a set of available actions.

 

Pinning

The pinned column is moved to the far left/right of the Data Grid and made “sticky,” so it remains visible during horizontal scrolling.
A column can be pinned through the Column’s Menu or in the Visibility Settings Panel.

Columns can be pinned by default, which can be useful to keep the main identification column always visible.

 

Column visibility

Hiding individual columns allows users to adapt the Data Grid to their specific needs by displaying only the necessary information.
The user can hide a column through the Column’s Menu or in the Visibility Settings Panel, where they can also show previously hidden columns.

Although columns can be hidden by default, this should be done carefully. The best practice is to show users all the data and let them narrow down what they find important and what they prefer to hide.

For crucial columns, such as those with main identification information, hiding can be disabled.

 

Resizing

By default, all columns are set to content-based distribution (autosize). To optimise the viewing experience, users can adjust the initial column width by dragging the resize handle that appears when hovering over the Column’s Header right border.

Once the user resizes the column, it changes to static width. It can be changed back to autosize through the Column’s Menu or in the Visibility Settings Panel.

The default view can be adjusted by setting some columns to fixed widths to make the data more readable for the user (for example, to avoid truncation in columns with longer text). There is also a property to disable the resizing for the whole DataGrid.

 

Column reordering

The user can decide to change the order in which columns are shown. This can be done by dragging and dropping on the Column’s title directly in the Data Grid or in the View Settings Panel.

The grouped column will always come first on the left and cannot be reordered. Pinned columns can be reordered only through the View Settings Panel. The default order of columns is established by their order in columns definition. If necessary to improve the user experience, an initial change in order can be made.

---

 

Client VS. Server-side model

When working with the Data Grid, you must decide on the model to use based on the amount of available data. While in theory both models support the same features, our current infrastructure and chosen data models limit what the server-side model supports, and additional improvements are necessary to fully unlock its capabilities.

Client-Side Model

The client-side model downloads all data to the user's browser (client) when the page loads. All filtering, sorting, searching, etc. happens instantly on the user's device, with no waiting for the server to respond, providing a faster, smoother experience.
However, this model is best for grids with fewer than a couple of hundred rows, up to about a thousand rows, as performance degrades with very large datasets. Also, the initial load can feel slow since all data must be downloaded when the page first loads.

Server-Side Model

The server-side model is intended to handle significantly larger datasets, as the server is responsible for performing the data operations, such as sorting, filtering, and grouping. Meanwhile, the browser (client) is responsible only for rendering the data. After each change to the view, the browser requests updated data from the server in small batches. This approach results in a faster initial load, but users may observe loading indicators while waiting for server responses, making the experience feel less smooth.

---

 

Common patterns

Row actions

If actions can be performed at the row level (on specific records or entities), they should be presented in the last column, called Actions.

• 1 action: Button or Icon Button
• 2 actions: Icon Buttons
• 3 or more actions: Max 1 Icon Button and a more Dropdown Icon Button, grouping all remaining ones in a dropdown menu.
  

 

View more details

Users often need more detailed information about an entity/item in the Data Grid. To keep this behavior consistent, follow these rules.

1. Choose the detail view format based on content and user needs:
1. Side Panel – For simple content that adds context to the table and doesn’t require many actions (a “view mode”). Also useful when users compare data and open details for multiple items.
2. New page – For larger or more complex content, or when users need to focus on a single task, such as processing or editing a specific entity/item.
2. Open details directly from the Data Grid by linking the detail view to the entity/item name. By default, place this entity/item column first, so it clearly identifies each row. If multiple items in a row can open details, make them all links and keep the primary one in the first column.
3. You can also add a “View details” action in the Actions column:
1. Preferably, group it with other actions in the more Dropdown Icon Button.
2. If “View details” is the only action, show it as a link, not a button.

 

Link style

Because the Data Grid is a visually dense component, standalone links inside cells should use underline: false so that they are rendered without any text decoration. When the user hovers over a row, the links in that row’s cells become underlined to clearly indicate which items are clickable.

---

Content

Data Grid title

• The Data Grid Title should be used when it’s one of multiple sections on the page. It shouldn’t be used if it simply repeats the Page Title/tab category.
• Use sentence case.
• Use a subtitle only if there is something truly useful to add to the title in a couple words.

Column title

Use short, scannable titles
Keep titles to 1–3 words for readability — avoid long phrases.
✅ Check-in date
🚫 Date when guest is expected to check in

Think globally
Most other languages require more characters than English. Leave space for localization.

Use sentence case with no punctuation
✅ Payment status
🚫 Payment Status. / Payment Status:

Match terminology used elsewhere in the UI
Use the same terms as field labels, forms, or filters to maintain consistency.
For example, if the field is called "Guest name", do not call the column "Customer".

If it avoids confusion, add units to the title
For example, if it's unclear which currency is used throughout a table, add it to the column title. If it's clear, no need to add it.
✅ Price
✅ Price (EUR)

---

 

Known issues/improvement ideas

As the Data Grid component is very complex, we identified areas for further improvements that could be contributed to when needed.