Project structure for an interactive book

[danprince]

I have a hierarchy of MDX files that I want to use as pages. I want to be able to mark a page as 'locked' and get a guarantee that the server won't render it or pass it to the client unless the client is authenticated. Here's an example page:

export const locked = true;
import Example from "../components/Example";

# Example Page
All written in _markdown_.
<Example />

If I put this file into my pages/ directory then I can't control whether the page is rendered or not based on auth because there's nowhere to implement getServerSideProps (not that I'd want to implement it separately for every page in the book though).

I've experimented with moving the markdown files out of pages/ and into a separate book/ dir, then having pages/[...slug].js which dynamically imports the markdown, checks whether it is locked and whether the user is authenticated, then either renders the content or renders a login screen. The problem with that approach is that the import logic is in the getServerSideProps method which must be serialized. I got a separate version of this working with a second dynamic import in the component itself, but that causes a flash of no content which is a huge no no for something that is 95% static content. This approach also feels overly complex.

Another idea that occurred to me would be to write a custom MDX loader that bakes a getServerSideProps implementation into the content the module exports. It feels a bit wrong to put app logic into a loader, so I thought I'd hold off on that until I got some feedback here.

So, looking for pointers on putting MDX files in my pages directory and implementing a check + redirect if they are not authenticated. Ideally I want to implement a single function/middleware/gate/whatever that can intercept the incoming SSR request, check the metadata of the requested page, then allow it to render, or redirect to a login page instead.

[leerob]

This library be might useful: https://github.com/hashicorp/next-mdx-remote