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/_404.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.

The standard views/page.tsx looks like this:

import { Heading } from "@components/atoms/Heading"
import { Container } from "@components/layout/Grid"
import { defineView } from "eddev/views"
import { ContentBlocks } from "eddev"

export default defineView("page", (props) => {
  return (
    <Container>
      <Heading variant="h1" css={{ pb: "$6" }}>
        {props.page?.title}
      </Heading>
      <ContentBlocks blocks={props.page?.contentBlocks} />
    </Container>
  )
})

You'll notice above the following:

• The file exports a view defined with the defineView function, 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 is views/{name}.tsx. We just care about the name part!
• We're getting some data from props — props.page.title and props.page.contentBlocks. These are coming from the linked query file (see the next section)
• 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.