Overview
Views represent the different page types of the site. WordPress will choose which view to use based on the URL of the page. If for example, it identifies that the url /blog/my-first-post is a “post” object, it’ll first look for views/single-post.tsx, followed by views/single.tsx. If it doesn’t find either of those, it’ll use views/_error.tsx. The naming of view files follows WordPress’ Template Hierarchy .
Views exist within the views directory as .tsx files, often with a paired .graphql file.
A standard views/page.tsx would look something like this:
views/page.tsx
import { defineView } from "eddev/views"
import { ContentBlocks } from "eddev/blocks"
export default defineView("page", (props) => {
return (
<div className="grid-auto">
<div className="col-span-12">
<h1 className="type-h1 text-center">
{props.page?.title}
</h1>
</div>
<ContentBlocks blocks={props.page?.contentBlocks} />
</div>
)
})You’ll notice above that:
- The file exports a view defined with the
defineViewfunction, and the first argument passed to it is the name of the view. This must be consistent with the name of the file. The general rule isviews/{name}.tsx. We just care about the name part! - We’re getting some data from props —
props.page.titleandprops.page.contentBlocks. These are coming from the linked query file. - The code itself is quite lean. It wouldn’t be strange to have a more complex file, but in general it’s better to move as much code as possible into separate component files. This encourages reusability and makes it easier to maintain.
Last updated on