Components and views
Contents
An XP page is composed of page, layout, part, text, and fragment components. Next.XP maps their XP descriptors to queries, processors, and React views through ComponentRegistry.
The adapter builds on @enonic/react-components, a shared library for rendering XP component trees and rich text in React applications. That library provides base views, regions and rich-text renderer. Adapter 5 uses its rich-text renderer and types directly; the adapter’s own base views and registry provide the page-tree integration described on this page.
Mapping a component
Register mappings once, before calling fetchContent(). The starter keeps them in src/components/_mappings.ts.
import {ComponentRegistry} from '@enonic/nextjs-adapter';
import Hero from './views/Hero';
ComponentRegistry.addPart('com.example.app:hero', {
query: `query($path: ID!) {
guillotine { get(key: $path) { displayName } }
}`,
view: Hero
});A mapping may define:
| Property | Purpose |
|---|---|
|
|
Guillotine selection and, when needed, a variables function. |
|
|
Additional selection for component configuration. Can only contain fields from the component’s |
|
|
Asynchronous transformation applied on the query result before props reach the view. Return an |
|
|
React component used to render the mapping. |
Content types, pages, layouts, parts, macros, and generic component kinds have separate registration methods, but all mappings share the same query, processor, and view properties. See Adapter type definitions for more details.
View props
Page and component views receive their descriptor data, component path, runtime meta, shared common data, and processed data when a query is registered. Layout views also receive their regions.
Render regions with the adapter’s Region view. They preserve component ordering and add editing attributes in Content Studio. Applications using the component-tree renderers from @enonic/react-components receive equivalent region and component annotations from that library.
Fallback mappings
The special CATCH_ALL mapping is useful while developing because it exposes unmapped content through a diagnostic view. A catch-all is ignored for Content Studio renderability checks and for production visitor rendering, so every production component needs an explicit mapping.
The adapter’s baseMappings module registers its built-in handling for page component kinds. Import it before application-specific mappings.
See Common API for ComponentRegistry and Views for the built-in renderers.