Faust.js Documentation

repository·canary·Indexed 23 days ago

https://github.com/wpengine/faustjs

A toolkit for building Next.js applications for headless WordPress sites. Faust.js provides specialized tooling for data fetching, authentication, previews, and rendering strategies (SSR and SSG). The ecosystem includes @faustwp/core, @faustwp/blocks for Gutenberg block rendering, @faustwp/block-editor-utils for converting React components into blocks, and the @faustwp/cli for application management.

Tokens
56.8K
Snippets
142
Records
286
Agent score
81%

What's inside Faust.js

  1. What is Faust.js®?

    canary
    Faust.js® is a toolkit designed to simplify the process of building headless WordPress applications using Next.js. It provides a modular set of tools that developers can pick and choose from, covering essential headless requirements such as data fetching and Block component rendering.
  2. Introduction to Faust.js

    canary

    Faust.js is a toolkit designed for building Next.js applications for headless WordPress sites. It provides specialized tooling to address common challenges in headless WordPress development, specifically around:

    • Data fetching
    • Authentication
    • Previews
    • SSR (Server-Side Rendering) and SSG (Static Site Generation)

    It aims to provide a high-quality experience for both developers and content publishers.

  3. How WordPress blocks and fragments work together

    canary

    When rendering blocks in Faust.js, there is a three-part relationship between the block components, the GraphQL fragments, and the rendering components:

    1. Block Mapping: You define a mapping of block names to React components in a central file (e.g., wp-blocks/index.js). This is passed to WordPressBlocksProvider.
    2. Data Fetching (Fragments): Because blocks can have complex nested data, you must use the .fragments.entry property of each block object in your GraphQL query to fetch the required fields. You also use .fragments.key to spread the fragment into the editorBlocks selection set so the data is available for the component.
    3. Hierarchical Rendering: WordPress returns blocks as a flat list. To render nested blocks (like columns containing paragraphs), you must use flatListToHierarchical to reconstruct the tree structure before passing it to WordPressBlocksViewer.
  4. How the Faust Plugin System Filters work

    canary

    The Faust Plugin System uses a filter pattern to allow developers to intercept and modify core system data.

    Every filter callback accepts two parameters:

    1. The filtered data: The current value of the data being processed (e.g., a string array, a configuration object, or a URL).
    2. The context object: An object containing metadata relevant to the specific filter, which can be used to make informed modifications to the data.

    To use these filters, you typically use the addFilter method within a plugin's apply method.

  5. Use the Faust WP Template System

    canary

    The WP Template Hierarchy allows you to define individual components for specific WordPress templates. These components are rendered automatically based on the route being visited. Common templates include:

    • front-page.js: For the site's front page.
    • single.js: For single posts.
    • page.js: For static pages.
    • category.js: For category archive index pages.

    You can check the browser dev console when visiting a page to see which templates Faust might match for that route.

  6. How the Seed Query works in faust.js

    canary

    The Seed Query is an initial GraphQL request sent to WordPress to determine the type and basic properties of the content requested via a URI. It does not fetch the full content itself; instead, it provides the metadata necessary for faust.js to determine which template to render.

    Workflow

    1. User Request: A user requests a page with a specific URI (e.g., /sample-page/).
    2. Seed Query: faust.js sends the SEED_QUERY to WordPress.
    3. Metadata Return: The query returns the __typename and essential properties (like templateName or contentType).
    4. Template Specific Query: Based on the seed query results, faust.js sends a secondary, more detailed query to retrieve the full content required for that specific template.
    5. Rendering: The determined template is rendered with the retrieved content.

    Implementation Details

    The seed query utilizes WpGraphQL's nodeByUri for standard requests and contentNode for preview requests ($asPreview: true). It uses several fragments to ensure the response structure adapts to the content type (e.g., Post, Page, User, TermNode, MediaItem).

    // Example of the SEED_QUERY structure used by faust.js
    export const SEED_QUERY = gql`
    	query GetSeedNode(
    		$id: ID! = 0
    		$uri: String! = ""
    		$asPreview: Boolean = false
    	) {
    		... on RootQuery @skip(if: $asPreview) {
    			nodeByUri(uri: $uri) {
    				__typename
    				...GetNode
    			}
    		}
    		... on RootQuery @include(if: $asPreview) {
    			contentNode(id: $id, idType: DATABASE_ID, asPreview: true) {
    				__typename
    				...GetNode
    			}
    		}
    	};
  7. Understand theme.json transformations in BlocksTheme

    canary

    When fromThemeJson processes a theme.json file, it transforms nested settings into top-level properties on the BlocksTheme object for easier access.

    Property Mappings

    theme.json PathBlocksTheme Property
    settings.color.palettetheme.palette
    settings.spacing.spacingSizestheme.spacingSizes
    settings.typography.fontFamiliestheme.fontFamilies
    settings.typography.fontSizestheme.fontSizes
    settings.layouttheme.layout (copied as is)

    Example Transformation

    Input theme.json snippet:

    {
      "settings": {
        "color": {
          "palette": [
            { "color": "#ffffff", "name": "Base", "slug": "base" },
            { "color": "#000000", "name": "Contrast", "slug": "contrast" }
          ]
        }
      }
    }

    Resulting BlocksTheme object:

    theme.palette = {
      "base": "#ffffff",
      "contrast": "#000000"
    }
  8. Understand the purpose of styles/wpcore

    canary

    The styles/wpcore directory contains stylesheets ported directly from WordPress core. These styles are intended to provide the standard WordPress look and feel for specific elements (like the admin bar and dashicons) within the Faust.js environment.

    Important: These stylesheets should remain untouched to ensure compatibility with the original WordPress core design and functionality.

  9. How redirect-based authentication works in Faust.js

    canary

    The default authentication strategy in the Faust.js toolkit is Redirect-based authentication. This is ideal for use cases where authenticated users are admins, editors, or staff (e.g., for previewing posts/pages) and do not require a custom "white label" login experience.

    The Flow:

    1. The user attempts to access a protected route in the Next.js application.
    2. The application redirects the user to WordPress to authenticate.
    3. After successful authentication in WordPress, the user is redirected back to the Next.js application with an authorization code.
    4. The toolkit uses this code to request a refresh and access token, completing the login process.
  10. Understand Apollo Client in Faust.js

    canary

    Faust.js uses @apollo/client@3 to perform GraphQL operations against your WordPress backend. To work effectively with Faust.js, you should be familiar with the following core Apollo Client concepts:

    • Queries: Used to retrieve data from your WordPress site.
    • Fragments: Used to modularize queries, making them more maintainable and reusable.
    • Mutations: Used to update or change data in your WordPress backend.
    • Apollo Client Cache: Used to cache responses to minimize network usage and improve performance.