Examples: Using `nodeByUri` to replicate WP template hierarchy

[justlevine]

It would be great to see an example of implementing WP's template hierarchy with next+Faust.js.

For WP-to-headless devs, a big part of the transition is trying to implement everything WP gives you for free (also arguably a strong impetus for headless devs choosing WP as a backend), and both types of devs could benefit from some more advanced gqty examples.

An ideal example would:

• have a primary pages/index.tsx that uses nodeByUri for hydration.
• demonstrate how to fetch data from post, page and taxonomy types on the nodeByUri interface.
• implement a few template/layout components that use WP's template hierarchy, e.g. <Template.Home />, <Template.Page />, <Template.Singular />, and maybe a custom template like <Template.FullWidthTemplate />
• Bonus: use Next.js Persistent Layouts for components like <Header /> and <Footer />.

[blakewilson]

@justlevine 👋

We have been giving this some thought in how we could support this. What you said about the WordPress to headless dev is spot on.

The tricky part here is rendering the appropriate template. Dynamic imports with variables is not possible in Webpack, which makes things challenging when trying to replicate the more specific cases in the WP template hierarchy (for example page-sample-page.js). I've tried playing around with Loadable Components but kept running into issue after issue, and the cases that do work tend to only support CSR, not SSR/SSG.

FWIW, I recently tried this out with a Next.js custom server, and got the full WP Template Hierarchy routing resolving properly by replacing the native Next.js router with a custom one that gets the templates from the FaustWP plugin. There's some caveats though.

[justlevine]

Just confirming: the need for dynamic components is because without pages we don't get any chunking?

Im still whetting my teeth with NextJS, but I was under the impression that that dynamic imports with template literals instead of variables work fine.

I don't know enough about the performance implications or the interplay with gqty, but my assumption has been that as long as there's a dedicated src/templates folder (for example) that enforced a structure that could map to the template hierarchy (similarly to the manual use of pages), chunking could still happen.
That said, if I could figure it out myself at my beginner level, I wouldn't suggest it as a good example candidate.

Jw: if performance is the sole concern, then maybe it's valid not to care? Meaning have nodeByUri serve as a fallback 'catch-all' page, but still encourage (and incorporate into the example repo) specific next.js pages?

[blakewilson]

Referring to this Next.js doc page:

Note: In import('path/to/component'), the path must be explicitly written. It can't be a template string nor a variable. Furthermore the import() has to be inside the dynamic() call for Next.js to be able to match webpack bundles / module ids to the specific dynamic() call and preload them before rendering. dynamic() can't be used inside of React rendering as it needs to be marked in the top level of the module for preloading to work, similar to React.lazy.

I think in regards to this, perf is unrelated; getting these components that follow the WP Template Hierarchy dynamically imported seems to be the main struggle.

[justlevine]

Does this workaround not work?

I guess as a NextJS noob, I'm trying to understand why we need dynamic imports at all, if it's not "just" a performance thing?
I've seen projects use a component wrapper to handle WP page templates or post formats without dynamic imports, and assumed my own hiccups at a nodeByUri setup were just about figuring out to get the content node type out of getStaticProps() and how to use gqty with union types, while also avoiding the limitations on gqty queries in conditionals that I still don't fully grok.