Determine support for Faust templates in App Router

[blakewilson]

We are currently lacking support for Faust templates in our experimental-app-router package. Let's determine if it's something we can support given the new abstractions in app router (RSC, new router, etc), and ticket next steps forward.

Acceptance Criteria

• [ ] Document is created outlining if support is possible in experimentanl-app-router for Faust templates
• [ ] If so, give examples of possible solutions

[justlevine]

Let's determine if it's something we can support given the new abstractions in app router (RSC, new router, etc), and ticket next steps forward.

The "how" is likely via a similar catch-all route to the existing pattern, or as a middleware layer (my personal preference, since it would make the solution significantly more pluggable and decouple it more from whatever abstraction comes after ~gqty~ ~pages/wp-templates~ the app router).

The "whether" is ultimately up to all y'all at Faust, but IMO it would be a major hit to the ecosystem if y'all moved away from WP-as-the-default-source-of-truth for routing just as the pattern is finally seeing adoption.

[blakewilson]

@justlevine The concern that I have is that people that want to use App Router are likely using it for the new features in React Server Components and the new page's and layout's. If we were to go the catch-all route, I can't come up with a mental model in my head how layout's are still supported. Since in the pages router, you know that /about-us for example is one single js file vs with app router, it could be the page, and several layouts.

I like the idea of using middleware too, and perhaps that can be possible with app router since things could be done on the server now asynchronously. Really the challenge is coming up with the architecture to support this see how the new things in Next can still be supported (RSC, async components, mix of server and client components and how that plays into Faust templates, etc.)

[justlevine]

@justlevine If we were to go the catch-all route, I can't come up with a mental model in my head how layout's are still supported.

Not 💯 sure I follow. To maintain parity with the existing solution, we'd have fallback layout / page files, or even a static layout and a page that tunnels into the components. (See this example from @CalebBarnes https://github.com/Jambaree/jambaree-next-wordpress-workspace/blob/main/next-wordpress-starter/src/app/%5B%5B...paths%5D%5D/page.tsx, and this [WPGraphQL slack discussion] before it disappears ).

Anything else is additive - and yeah long term I think middleware is the ideal solution for the ecosystem, and will make all this way easier, but in the meantime maintaining parity is the benchmark, im assuming (like how the App Router wasn't held up to improve auth , and just brought parity to server-side queries ).