wp-dataviews-dataform

WordPress DataViews and DataForm

Use the public package to build consistent dataset and editing interfaces. It renders UI; it does not fetch, authorize, mutate, paginate, or persist records for you.

Choose the component

• DataViews: browse, search, filter, sort, paginate, select, and act on items.
• DataViewsPicker: controlled single- or multi-item selection. It supports only pickerGrid and pickerTable, and has a narrower action contract.
• DataForm: edit one record or a deliberately composed bulk-edit value.

Do not use these components to replace a simple settings field or a tiny static list. Their value starts when fields, views, selection, or actions are reusable.

WordPress build contract

Install @wordpress/dataviews and, when building with @wordpress/scripts, import from its WordPress entry point:

import { DataForm, DataViews } from '@wordpress/dataviews/wp';

Do not copy examples that import the package root unchanged into a WordPress build. The official package explicitly requires /wp for that environment. Ship the package CSS through the plugin build and declare wp-components as a dependency of the plugin stylesheet. Never depend on private exports obtained through @wordpress/private-apis or code copied from the Site Editor bundle.

Keep the data flow controlled

const [ view, setView ] = useState( {
	type: 'table',
	page: 1,
	perPage: 20,
	search: '',
	filters: [],
	sort: { field: 'title', direction: 'asc' },
	fields: [ 'status', 'updated' ],
} );

<DataViews
	data={ records }
	fields={ fields }
	view={ view }
	onChangeView={ setView }
	getItemId={ ( item ) => String( item.id ) }
	paginationInfo={ { totalItems, totalPages } }
	isLoading={ isLoading }
/>

The consumer owns every transition. Convert view.page, perPage, search, filters, and sort into an allowlisted server query, fetch the matching page, then return correct totals. Do not fetch every record and claim server pagination. Reset or clamp an invalid page when filters reduce the result set.