eddev

Views

Page and post-type templates

Views are the React templates for a site. WordPress still decides what URL maps to what content; eddev lets that normal WordPress template hierarchy resolve to files in views/*.tsx instead of PHP templates.

Common view names follow WordPress conventions:

  • front-page.tsx for the site's front page
  • page.tsx for normal pages
  • single.tsx for posts
  • single-{post-type}.tsx for a specific post type
  • archive-{post-type}.tsx for a post type archive
  • 404.tsx or _error.tsx for not-found and error states

Most views also have a paired .graphql file with the same name. The query result becomes the view's props.

query Page($postId: ID!) {
  page(id: $postId, idType: DATABASE_ID) {
    title
    contentBlocks
  }
}
import { ContentBlocks } from "eddev/blocks"
import { defineView } from "eddev/views"

export default defineView("page", (props) => {
  return (
    <div>
      <h1>{props.page?.title}</h1>
      <ContentBlocks blocks={props.page?.contentBlocks} />
    </div>
  )
})

The view name passed to defineView should match the file path without views/ or .tsx. For views/page.tsx, use defineView("page", ...). For views/single-case-study.tsx, use defineView("single-case-study", ...).

How A View Renders

When a request comes in, WordPress resolves the matching template. If it finds a React view, eddev:

  1. Resolves the view name from the file path.
  2. Executes the paired views/name.graphql file if one exists.
  3. Builds a route payload containing the view name, query result, app data, route metadata, and admin context.
  4. Renders views/_app.tsx around the active view.

On the first request, that payload is embedded in the HTML. During client-side navigation, the router fetches the same payload as JSON, then loads and renders the matching view component.

Keep Views Thin

A view should usually compose the page rather than contain every component detail. Put reusable UI in components/, features/, or other project folders, and let the view focus on:

  • selecting the right layout for this route
  • rendering ContentBlocks
  • composing archive or listing data from its query
  • reading route state when the URL itself affects presentation

For the data side of views, see View Data. For the site-wide wrapper, see _app.tsx.

On this page