Fork of

https://www.npmjs.com/package/@wordpress/dataviews/v/4.4.1

Bundled as a separate module

DataViews Component Documentation

List of Supported Layouts

The DataViews component supports multiple layout modes for displaying data. You can specify the layout via the view prop (as a View object). Below are the supported layouts with descriptions and sample configurations:

Table Layout

Displays data in a traditional table with columns for each field. This layout is useful for comparing many items across multiple attributes. You can optionally configure column styling (width, alignment) and row density (spacing).

// Example: Table view with compact row density
constview: View= {
type: 'table',
layout: { density: 'compact'} // Options: 'compact' | 'balanced' |
'comfortable'
};

Description: In table view, each field in fields becomes a column. You may provide layout.styles to define column widths or alignment per field (using field IDs as keys). For example, you could set a specific column to right-align numeric data:

constview: View= {
type: 'table',
layout: {
styles: {
age: { width: 50 , align: 'end' } // 'age' column 50px wide, right-
aligned
}
}
};

Grid Layout

Displays items as cards in a grid layout. Each item appears as a card that can include an image, title, description, and additional badge fields. This layout is ideal for visual content or overview dashboards.

// Example: Grid view showing "categories" as badges and a larger preview
image
constview: View= {

type: 'grid',
layout: {
badgeFields: ['categories'],// Field IDs to display as badges on each
card
previewSize: 150 // Image preview size (max width in pixels
for each card's image)
}
};

Description: In grid view, items are rendered as uniform cards. The badgeFields array lets you show certain fields (by ID) as badge labels or metadata on each card (e.g. categories or tags). The previewSize controls the size of media previews (like images) on the cards. You should also designate which field is the title, description, and media (image) via the view’s titleField, descriptionField, and mediaField properties (if not using defaults; see View type below). If not specified, the first field or a default may be used as the title.

List Layout

Displays items in a vertical list (one item per row) with a primary text (title) and optional description or metadata. This layout is great for readable lists of items (e.g. a list of posts or users).

// Example: List view with custom title/description/media field mappings
constview: View= {
type: 'list',
titleField:'name', // Field ID for the item's title
descriptionField: 'summary', // Field ID for the item's description text
mediaField:'avatar', // Field ID for an image/avatar to display
fields:
['tags'] // Additional fields (by ID) to show as badges or meta
};

Description: In list view, each item is shown with a primary field (often a title), and you can optionally show a description and a thumbnail/image. Use titleField, descriptionField, and mediaField in the view to tell DataViews which fields from your data to use for these parts. Any additional field IDs listed in view.fields will be displayed as extra info (for example, badges or secondary text). If you do not specify these, the component may choose reasonable defaults (e.g. the first text field as title). The list layout typically displays the title, description, and media (if provided) in a single row per item.

Full Component Props

The component accepts the following props (TypeScript types are indicated for each):

view (View): Required. An object describing the current view state and layout. At minimum
this includes type (one of 'table', 'grid', or 'list'). The view object can also hold
other state like current page, sorting, filters, and layout-specific settings. For example, a view
might be:

•

{ type: 'table', page: 1 , perPage: 20 , sort: { field:'name',
direction: 'asc' }, filters: [] }

(See View type definition below for full details.)

onChangeView ((view: View) => void): Required. Callback that is fired when the view
state changes. The component calls this whenever the user changes layout type, pages, sorting,
filtering, etc. Use this to update the view state in your parent component (e.g. via
useState). For example, if the user switches from table to grid layout or changes page
number, onChangeView will be called with the new View object.

fields (Field<Item>[]): Required. An array of field definitions describing each data field/
column. Each field in this array is an object specifying how to display and interact with a
particular property of your data items. For example:

constfields:Field<Person>[] = [
{ id:'name', label: 'Name', type: 'text', enableSorting: true},
{ id:'age', label: 'Age',type: 'integer', enableSorting: true}
];

At minimum, a field needs an id (which should correspond to a key in your data items) and
optionally a label (column header or field name to display). You can also specify field type
(e.g. 'text', 'integer', 'date', etc.), and various behaviors (sorting, searching, filtering
capabilities). (See Field type below for details.)

data (Item[]): Required. The array of data items to display. Each item can be any shape
(object or record); usually it is a record of fields with keys matching the field definitions. For
example, if your fields have ids 'name' and 'age', each item should have item.name and
item.age. The DataViews component will render one row/card per item in this array.

actions (Action<Item>[]): Optional. An array of action definitions for operations that can be
performed on items. Actions appear as buttons or menu items in the UI. For example, you might
have a "Delete" action or "Edit" action. Each Action can either be a simple button action with a
callback, or a modal action that opens a dialog. You can specify properties like label (display
text), icon, isDestructive (for dangerous actions), isPrimary (highlight as primary
action), and disabled. For bulk operations, set supportsBulk: true to indicate the action
can apply to multiple selected items. (See Action type below.)

Usage: If actions are provided, DataViews will render them as follows: - Per-item actions: In list and grid layouts, an overflow menu (or similar) on each item will list the available actions (for single item). In table layout, an additional actions column may be shown with a menu for each row. - Bulk actions: If you enable selection (see selection prop) and mark actions with supportsBulk: true, a bulk actions toolbar will appear when multiple items are selected, allowing the user to apply those actions to all selected items at once.

search (boolean): Optional. If true, a search bar will be displayed above the data list for
filtering items by a search term. This provides a simple text filter on the data (works in
conjunction with fields that have enableGlobalSearch set). By default this is false. If

•

•

•

•

•

enabled, the current search query is stored in view.search. (Note: actual filtering of the data
by the search term is up to you to implement if needed, typically by updating the data prop or
using onChangeView to filter externally.)

searchLabel (string): Optional. Label text for the search input (if search is enabled). For
example, "Search posts...". If not provided, a default label may be used (e.g. "Search").

paginationInfo ({ totalItems: number; totalPages: number }): Required. An object
providing pagination details for the data set:

totalItems: The total number of items in the dataset (after any filtering, if applicable).
totalPages: The total number of pages available. This usually is
Math.ceil(totalItems / perPage).

This is used by the pagination controls to display the current page and total pages, and to enable/ disable navigation buttons. Even if you are not implementing pagination, you should supply these (for example, totalItems = data.length and totalPages = 1 if all items are shown on one page).

isLoading (boolean): Optional. If true, the DataViews will display a loading state (such as a
spinner) instead of the data. You can use this to indicate data is being fetched. Default is
false.

defaultLayouts (SupportedLayouts): Required. An object that defines default view
configurations for each layout type. This object’s keys can be table, grid, and list, and
the values are configuration objects to use as defaults when switching to that layout. For
example:

constdefaultLayouts= {
table: { }, // (use defaults for table layout)
grid: { layout: { previewSize:
150 } },// default grid preview image size
list: { } // (use defaults for list layout)
};

When the user switches layouts (or on initial mount), DataViews will use these defaults to fill in
view for the new layout if not already defined. Typically, you can pass an empty object for each
if you don’t have specific default overrides; the component will handle sensible defaults. Note:
The shape of each value corresponds to that layout’s View subtype without the type (since
type is implied by the key). For instance, defaultLayouts.grid can include
layout.badgeFields, etc., just like a ViewGrid object minus the type.

selection (string[]): Optional. An array of selected item IDs. Providing this prop enables
selection mode (usually checkboxes) in the UI. Each item’s unique ID (as determined by
getItemId) should be included in this array to mark it as selected. If present, DataViews will
allow multi-selection of items and show selection controls. For example, you might manage this
state in your parent component:

• • • • • • •

const[selection, setSelection] = useState<string[]>([]);
<DataViewsselection={selection} onChangeSelection={setSelection} ... />

If selection is not provided, no selection checkboxes will be shown.

onChangeSelection ((selectedIds: string[]) => void): Optional. Callback when the
user changes the selection. This is called with the updated array of selected item IDs whenever
an item is selected or deselected (including when using "Select All" if implemented). Use this to
update your selection state. This prop is only needed if you use selection.

onClickItem ((item: Item) => void): Optional. Callback for when a user clicks on an item
(row or card). If provided, the component will make each item clickable. In the table or list, this
typically means clicking anywhere on a row triggers onClickItem for that item. In grid,
clicking a card triggers it. Use this if you want to handle item click events (e.g. navigate to a detail
view or open an edit form in your app logic). If both onClickItem and a custom link (see
renderItemLink) are not provided, items are not clickable by default.

renderItemLink ((props: { item: Item } & ComponentProps<'a'>) =>
ReactElement): Optional. A function to render a custom link wrapper for clickable items. This is
an advanced alternative to onClickItem. If provided, DataViews will use this function to wrap
each item's content when the item is clickable. It allows you to define a custom anchor element
(or Link component from a router) for each item. The function is called with an object
containing the item and default anchor props (...ComponentProps<'a'>, such as
className, onClick, etc., and a children node which is the item’s content). You should
return a React element (usually an <a> or <Link> around the given children). See
Advanced Features below for an example.

In summary, use renderItemLink if you want to make items actual hyperlink elements (for example, for middle-click or right-click behavior, or integration with router links). If you just want to handle clicks in code, onClickItem is simpler.

isItemClickable ((item: Item) => boolean): Optional. Function to determine if a given item
should be clickable. By default, all items are clickable (the default implementation always returns
true). You can override this to conditionally disable clicking on certain items. This function is
consulted before applying onClickItem or renderItemLink. If it returns false for an
item, that item will not be given click behavior (it will render as static content even if
onClickItem/link is provided). For example, you might disable clicking on items that are
archived or have no permission. (See Advanced Features for example usage.)

header (ReactNode): Optional. A React node to render as a header above the data list. This
could be a custom title, toolbar, or any JSX you want to appear at the top of the DataViews
component (inside the component’s container, above the filters/search). If not provided, no extra
header is rendered (aside from the built-in search or filter bar if those are enabled).

children (ReactNode): Optional. Any React children passed into <DataViews> will be
rendered within the component’s container. This could be useful for inserting custom elements
into the DataViews layout (though typically, most customization is done via props rather than
children).

• • • • • •

getItemLevel ((item: Item) => number): Optional. Function to determine the hierarchical
level of an item (used for nested or tree data). If your data is hierarchical (e.g., categories with
subcategories), you can provide this to tell DataViews each item’s depth (starting from 0 or 1). In
list layout, for example, the component can then indent items according to their level and
potentially draw connectors to visualize hierarchy. By default, all items are level 0 (no
indentation). Use this in combination with view.showLevels (a boolean in the view state) to
display nested levels. If showLevels is true and getItemLevel is provided, the list view will
indent items based on the number returned. (See Advanced Features for an example.)

perPageSizes ([number, number, number, number]): Optional. An array of four numbers
specifying the options for "items per page" in the pagination UI. For example, [10, 20, 50,
100] would allow the user to choose to show 10, 20, 50, or 100 items per page. If not provided,
a default set of page size options will be used. The currently active perPage (in the view
state) will be reflected in the pagination controls. Make sure your
paginationInfo.totalPages corresponds to the perPage setting.

getItemId ((item: Item) => string): Required if items lack an id property. This function
returns a unique identifier string for a given item. DataViews uses this to track selection state
and keys for rendering. If your data items have a unique id field, DataViews will use that by
default (and you can omit this prop). However, if the items do not have a property named id ,
you must provide getItemId. For example:

// If items use "key" as identifier instead of "id":
getItemId={(item) => item.key}

If item.id exists, DataViews will call it by default internally. If an item has no stable unique
identifier, you may need to generate one (not recommended; better to have an ID in the data).

Important Types and Interfaces

Below are short explanations of key types used by DataViews:

Field<Item>: Defines a field (column or attribute) of the data. Some important properties of a
Field:
id: string – (required) Unique identifier of the field, and typically the key in your data
objects.
label?: string – Human-friendly label for the field. Defaults to the id if not provided.
header?: string | ReactElement – Custom header content for the field (e.g. an icon with
text). Defaults to the label. If you need an icon or custom JSX in the column header, you can use a
React element here.
type?: FieldType – The data type of the field. This can influence default rendering, sorting,
and filtering. Supported types include 'text', 'integer', 'date', 'datetime',
'boolean', 'email', 'media', 'array', etc.
render?: ComponentType<DataViewRenderFieldProps<Item>> – Custom render
function/component for displaying the field’s value. If not provided, a default renderer based on
type is used (for example, dates formatted nicely, booleans as checkmarks, etc., provided by
the library).

• • • • • • • • •

Edit?: ComponentType<DataFormControlProps<Item>> | string – (For editing use
cases) A component for editing this field’s value (or a string indicating a built-in control type). If
not using inline editing or forms, this can be ignored or left undefined.
getValue?: ({ item: Item }) => any – Function to extract the field’s value from an item.
Defaults to item[field.id] if not set. You can override this if the data for this field needs
computation or resides in a nested structure.
enableSorting?: boolean – Whether this field is sortable. If true, and no custom sort
function is provided, DataViews will attempt a default sort (for example, alphanumeric for text,
numeric for numbers, etc.). You can also provide a custom sort(a, b, direction) function
in the Field to override sorting logic.
enableGlobalSearch?: boolean – Whether this field’s content should be included in global
search filtering. If true, the field’s values are considered when filtering by the search bar input.
filterBy?: FilterByConfig | false – Configuration for filter operations on this field. If
set to an object, you can specify what filter operators are available (and which are default) for
this field. If set to false, the field will not be filterable via the UI.
elements?: Option[] – An array of predefined options for this field (used in filters or maybe
dropdowns). Each option has a value and label. For example, a field "status" might have a
few allowed values; you can list them here for filter UI.
Other props: description (field help text), placeholder (for edit controls), isVisible?:
(item) => boolean (to dynamically hide the field for certain items), readOnly?: boolean
(if true, the field is not editable and always uses the read-only renderer), isValid?:
Rules<Item> (validation rules for editing).

NormalizedField: Internally, DataViews converts your Field definitions into a normalized form that ensures label, header, getValue, render, etc. have default implementations if you didn’t provide them. This is mostly internal, but understanding that Field definitions will be completed with defaults (e.g., label defaults to id, a default render function based on type, etc.) can be helpful.

Action<Item>: Defines an action (operation) that can be performed on one or more items. This
is a union of two shapes:
Button Action (ActionButton): Has a callback: (items: Item[], context:
{ registry: any; onActionPerformed?: (items: Item[]) => void }) => void. This
callback is executed when the action is triggered (e.g., user clicks the action). The items
array passed to it will contain either the single item (for item-level actions) or all selected items
(for bulk actions). The context can provide additional info, including a registry (for WP
data registry, if relevant) and an onActionPerformed callback you can call to signal
completion.
Modal Action (ActionModal): Has a RenderModal: ({ items, closeModal,
onActionPerformed }) => ReactElement property. This defines a React component (or
function) that renders a modal dialog. When the action is invoked, DataViews will open a modal
using this component. You receive the items (selected or single item), a closeModal()
function to call when your modal should close, and an onActionPerformed(items) to call if
the action inside the modal completes. You can use these to manage the modal lifecycle.
Additional modal-related props include modalHeader (string for the modal title bar),
hideModalHeader (if true, no header/title is shown), and modalSize (one of 'small' |
'medium' | 'large' | 'fill' for modal sizing, default is 'medium').

Common Action Props: Both action types extend a base that includes: - id: string – Unique identifier for the action. - label: string | ((items: Item[]) => string) – Text for the action. If a function is provided, it can compute a dynamic label based on the selected items (e.g., show "Delete (3)" when 3 items are selected). - icon?: any – Icon for the action (could be a Dashicon name or an

• • • • • • • • • •

SVG element). This provides a visual cue in the UI for the action. - disabled?: boolean – If true, the action will appear disabled (not clickable). - isDestructive?: boolean – If true, indicates this action is destructive (e.g. a delete), so the UI may style it with a warning (like red text). - isPrimary?: boolean – Marks this action as a primary action (could be styled more prominently). - isEligible?: (item: Item) => boolean – A function to determine if this action is applicable for a given item. If provided, the action might be hidden or disabled for items where this returns false. For example, an "Publish" action might only be eligible for items in a "Draft" status. - supportsBulk?: boolean – If true, this action can be applied to multiple items at once. Such actions will be shown in the bulk actions toolbar when multiple items are selected. If false or not set, the action is assumed to be for single items (it might still appear in the per-item menu, but not as a bulk option). - context?: 'list' | 'single' – (Meta information, not heavily used in logic) Indicates whether the action is meant for list (bulk) context or single item context. Generally, supportsBulk and this help the UI decide where to show the action.

View: Represents the state of the current view (layout and various UI state). It is a union of three
specific types:
ViewTable:
{ type: 'table'; layout?: { styles?: Record<string, ColumnStyle>; density?:
Density } & *no other table-specific fields* }. In table view, layout.styles
can define per-column CSS widths or min/max widths and alignment, via a ColumnStyle
object for each field. ColumnStyle has shape { width?: string|number; minWidth?:
string|number; maxWidth?: string|number; align?: 'start'|'center'|'end' }.
The density property can be 'compact', 'balanced', or 'comfortable' to adjust row
padding.
ViewGrid: { type: 'grid'; layout?: { badgeFields?: string[]; previewSize?:
number } }. In grid view, badgeFields lists field IDs that should be displayed as badges or
tags on each item card. previewSize is a number (pixels) for the maximum width of the
image or media preview on each card.
ViewList: { type: 'list'; } (no extra layout config beyond the base fields).

ViewBase (common fields): All view types may include these general properties (inherited from a base interface): - search?: string – The current search query string (if the search bar is used). - filters?: Filter[] – Array of active filter criteria applied. - sort?: { field: string; direction: SortDirection } – Current sorting configuration. field is a field ID by which the list is sorted, and direction is 'asc' or 'desc'. - page?: number – Current page number (1- indexed). If not set, defaults to 1. - perPage?: number – Number of items per page. - fields?: string[] – The list of field IDs that are currently visible in the view. This can be used to hide or show certain columns/fields in the current view. If not provided, it’s assumed all fields prop fields are shown (or a default subset per layout). For example, you might allow users to toggle columns and store the visible column IDs here. - titleField?: string – The field ID to use as the title in list/grid layouts. - mediaField?: string – The field ID for the media (image/icon) in list/grid layouts. - descriptionField?: string – The field ID for the description in list/grid layouts. - showTitle?: boolean – Whether to display the title field in list/grid items. Default is true. - showMedia?: boolean – Whether to display the media (image) in list/grid items. Default true. - showDescription?: boolean – Whether to display the description field in list/grid items. Default true. - showLevels?: boolean – Whether to visually show hierarchy levels (indentation lines) for nested items. Default is false. If true, the list layout will indent items based on their level (as given by getItemLevel) and might draw connectors between parent and child items. - groupByField?: string – If set, the list view may group items by the unique values of this field, rendering group headings. (For example, group tasks by status.) This is an optional feature – if provided, DataViews could

•

•

•

•

automatically cluster items by that field’s value. (Note: group-by might need additional styling/handling; check the package documentation for specifics.)

Typically, you will maintain the view object in state and pass it into DataViews, updating it via onChangeView. The initial view should specify at least the type of layout, and can include any defaults for page, sort, etc. The component will update view as the user interacts with the UI (for example, selecting a different page will result in a new view with an updated page number).

SupportedLayouts: An interface (or type) that defines an object with keys for each layout type,
used for the defaultLayouts prop. Its shape is:

interfaceSupportedLayouts {
table?: Omit<ViewTable, 'type'>;
list?:Omit<ViewList,'type'>;
grid?:Omit<ViewGrid,'type'>;
}

Each key (table, list, grid) is optional, and its value is the default configuration for that
layout (basically a partial view object for that layout, without the type field). By omitting
type, it avoids confusion, since the key implies the type. For example, you might set
defaultLayouts.list = { titleField: 'name', descriptionField: 'desc' } so
that whenever the user switches to list view, those defaults are applied. If a layout is not
supported in your app, you could leave it undefined or simply not provide it (though generally all
three are supported by DataViews).

PaginationInfo: (Not an explicit TypeScript interface in the source, but conceptually) an object
with totalItems: number and totalPages: number. This is the shape of the
paginationInfo prop. Ensure these numbers reflect the data after any filtering/searching
that’s applied. If you are filtering/paginating on the server, you’d update these accordingly when
data changes.

Basic Usage Example

Below is a minimal example of using the DataViews component in a React TypeScript application. This example sets up a simple data set of people with a table layout, defines a couple of fields, and one action:

import React, { useState} from'react';
import DataViews, { Field, Action, View } from'@blockbite/dataviews';

// Define a data type for items
interfacePerson {
id:string;
name: string;
age:number;
}

// Sample data (could be fetched from an API in real use)

•

•

constdata: Person[] = [ { id:'1', name:'Alice', age: 30 }, { id:'2', name:'Bob', age: 25 }, // ... more items as needed ];

// Define fields for the DataViews (columns configuration) constfields:Field[] = [ { id:'name', label: 'Name', type: 'text', enableSorting: true}, { id:'age', label: 'Age',type: 'integer', enableSorting: true}, ];

// Define an action (for example, a delete action) constactions: Action[] = [ { id: 'delete', label: 'Delete', isDestructive:true, // icon: some icon if available (optional) callback: (items) => { // This function is called when the action is triggered. // Here we simply log, but you could perform deletion. console.log('Deleting items: ', items); }, supportsBulk: true // allow this action for multiple selected items } ];

// Provide default layout configs (can be empty objects for defaults) constdefaultLayouts= { table: {},list: {},grid: {} };

functionExampleComponent() { // Manage view state (initially a table view showing first page of 5 items) const[view, setView] = useState({ type: 'table', page: 1 , perPage: 5 });

// Compute pagination info based on data length (assuming no filtering here) consttotalItems= data.length; consttotalPages= Math.ceil(totalItems / view.perPage);

return(
<DataViews
view={view}
onChangeView={setView}
fields={fields}
data={data}
actions={actions}

paginationInfo={{ totalItems, totalPages }}
defaultLayouts={defaultLayouts}
/* Otherprops likesearch, selection, etc.can be added as needed*/
/>
);
}

Explanation: In this example, we import DataViews and supporting types from the @blockbite/ dataviews package. We define a Person type and some mock data. We then specify two fields: "Name" and "Age", marking both sortable. We define a single "Delete" action that simply logs the items to delete. We set up the default layouts (here just empty, meaning use library defaults). We use React state to hold the current view (initially set to a table layout). We render with all the required props: the current view, the onChangeView handler to update state, the fields, data, actions, and paginationInfo (calculated from the data size and current page size). This will render a table of our data with Name and Age columns, a Delete action available (both per item and as a bulk action if multiple selection is enabled), and pagination controls (though in this small data example, all items fit on one page).

In a real application, you might integrate filtering, server-side pagination, etc., by updating data and paginationInfo in response to onChangeView events (for example, fetching new data when view.page changes, or filtering data when view.search changes). This example is kept simple for clarity.

Advanced Features

The DataViews component provides additional props for advanced use cases, such as custom link rendering for items and hierarchical data display. Below are some advanced features and how to use them:

Making Items Clickable (Custom Links vs Click Handlers)

By default, items are not clickable unless you provide an onClickItem or a renderItemLink. You have two main ways to make each item in the list interactive:

Using onClickItem: This prop lets you handle item clicks via a callback function. If you supply
onClickItem, the DataViews will attach click handlers to each item (e.g., each row or card
becomes clickable). Use this approach if you want to perform an action in code when an item is
clicked (such as navigation using your router, or opening a detail pane via state). For example:

<DataViews
/* ...other props... */
onClickItem={(item) => {
// handle the click, e.g., navigate or open detail
console.log('Item clicked:', item);
}}
/>

•

With this, clicking an item will trigger the provided function. DataViews will also add a CSS class
indicating clickability for styling.

Using renderItemLink: If you prefer the items to be actual anchor links (for semantic HTML
or to allow opening in new tabs, etc.), use renderItemLink. This function should return an
<a> (or a router <Link>) element wrapping the item’s content. DataViews will call it for each
clickable item. You can integrate with React Router or any custom link component here. For
example, using a standard anchor:

<DataViews
/* ...other props... */
isItemClickable={(item) => !item.disabled} // Onlymakecertain
itemsclickable
renderItemLink={({item, children, className }) => (
<a href={`/profile/${item.id}`} className={className}>
{children}
</a>
)}
/>

In this snippet, we also used isItemClickable to disable clicking for any item where
item.disabled is true (those items will render as plain text). For items that pass the check,
renderItemLink wraps the item content in an <a> tag linking to a URL based on the item’s
id. The children parameter represents the default rendered content of the item (for
example, the row’s cells or the card’s inner layout), and className is passed along (DataViews
provides a CSS class like "dataviews-item--clickable" to style the link). You should ensure
to include {children} inside your link so that the item’s content is not lost.

Tip: Instead of a plain , you can use your router’s Link component. For instance, with React Router:

import { Link} from'react-router-dom';
...
renderItemLink={({item, children, className }) => (
<Linkto={`/profile/${item.id}`} className={className}>
{children}
</Link>
)}

This integrates navigation into the DataViews items seamlessly.

Use isItemClickable in conjunction with these props if you need conditional clickability. By default, DataViews assumes all items are clickable when you provide an onClickItem or link. If some items shouldn't be interactive (due to state or permissions), supply an isItemClickable that returns false for those items.

•

Hierarchical Data (Nested Item Levels)

If your data has a tree or nested structure (for example, categories and subcategories, or tasks with subtasks), DataViews can visually represent hierarchy in the list layout. To enable this, you use the getItemLevel prop and adjust the view settings:

getItemLevel: Provide a function that returns a numeric level for a given item. Typically level
0 (or 1 ) is top-level, and increasing numbers indicate deeper levels. For example, if your items
have a property depth:

<DataViews
view={{ type: 'list', showLevels: true, /* ...other view settings...
*/}}
data={hierarchicalData}
getItemLevel={(item) => item.depth}
/* ...other props... */
/>

In this example, we also set showLevels: true in the view object to instruct the list layout
to display indentation guides. When showLevels is true, the list layout will indent each item by
some amount per level (and may draw connector lines or tree structure visuals depending on
the styling). The getItemLevel function tells the component how deep each item is.

Sorting and grouping: Often, hierarchical data is sorted or grouped by parent/child relations.
DataViews itself does not automatically re-order or nest the items; your data array should be
organized in the desired order (for example, parent followed by its children). The
getItemLevel just informs how to render indentations. If you want visual grouping, you could
also use groupByField in the view (for grouping by a category, for instance), but for strict
parent-child hierarchies, getItemLevel is the primary tool.

Use case example: Imagine an array of categories, where each category item has an id , name, and parentId. You could compute a level (depth) for each category (root categories level 0, their subcategories level 1, etc.) and include that in the item, or compute it on the fly. Then:

constcategoriesView: View= {type: 'list', showLevels: true};
<DataViews
view={categoriesView}
onChangeView={setCategoriesView}
data={categories}
fields={categoryFields} // e.g., id andnamefields
getItemLevel={(cat) => cat.level}
/>

This will render the categories in a list, indenting subcategories under their parents. The UI will draw indentation lines if styled to do so (the default stylesheet of DataViews does include some styling for hierarchical list display).

•

•

By leveraging these advanced props, you can customize the behavior of DataViews to fit a variety of scenarios – from making list items navigate to detail pages, to handling multi-select actions, to displaying complex nested data. The DataViews component is designed to be flexible yet provide a consistent user experience across different data presentation needs. Developers can mix and match these features (for example, a list layout with search, filters, custom item links, bulk actions, etc.) to create a rich data exploration interface in their React applications using the @blockbite/dataviews package.