Build-time state can be user or "segment" specific, and it's actually easy to setup

[eric-burel]

This issue is reporting a bug in the documentation.

• Documentation version: v0.3.2
• Documentation source: On the website (book)
  The user described the issue as follows:

Hi,

I wanted to point out an issue regarding Perseus understanding of static/build-time rendering:

"When you generate state at build-time, you're generating it without knowledge of who will be using it. For instance, you can't generate personalized dashboard pages at build-time, because you don't know yet who your users are."

This is similar to what you could have found in Gatsby or Next.js documentation in the past. Despite being a common take, this however never has been true, counter-example are as simple as statically rendering translated content.

User-specific content is of course usually not something you want to do statically (though it's doable, including personalized dashboards), however group specific, or what I call "segment-specific" rendering in the marketing sense of "segment", is totally doable and even a good practice.

You can achieve it very simply by adding a URL redirection/rewriting server in front of your page.

I invite you to read my work on "Segmented Rendering" which describes this pattern:
https://www.smashingmagazine.com/2022/07/new-pattern-jamstack-segmented-rendering/
There are also resources at the bottom with more specific takes (the equivalence between this approach and HTTP caching ; how to scale to multiple parameters with the "megaparam").

Hope this will help in your journey!
Feel free to reach me out at [email protected] if you want to discuss the subject further
Best regards

Tribble internal data

dHJpYmJsZS1yZXBvcnRlZCxDLWRvY3MsQy1idWcsQS13ZWJzaXRlLWRvY3M=

[arctic-hen7]

This is a really nice pattern, and one I've considered in the past as well, but the problem is that static content is hosted by frameworks in opaque, but accessible, URLs. To do this, you would have to add authentication middleware to block access to certain parts of the .perseus/static/ section of your site. While possible, this is hardly ergonomic as-is, but I'd be very willing to look at a library that would extend the Perseus servers to support this more ergonomically!

Do you have another way around this? I don't see that issue mentioned in your article (which was great by the way!).

[eric-burel]

Glad you liked it!
In the article I hide the logic in the isPaidUser function, however you are right that it's the hard part, for instance in Next.js the Edge middleware runtime is so limited that you can't establish a TCP connection to a db, so most often you can't check current user state reliably, unless you also use an HTTP-ready serverless database.
However, it's conceptually not much different from redirecting to for an A/B test, or towards the right language, the difference between those use cases only lies on how complicated is the logic that selects your "segment" and how many segments it creates. Either way you indeed need a dispatching middleware.
In an earlier version, this lead me to call this pattern the "unicorn architecture" or "rainbow rendering", as the magic is provided by adding a tiny proxy server, like the horn of the unicorn, and then you can render your site statically in as many colors as you want :)

[arctic-hen7]

Understood, right now Perseus doesn't have good support for middleware beyond customising the server used to host the app, but v0.5.x will include this, and I'd be happy to look at something then to make this approach more ergonomic at a framework-level, maybe even with first-class support --- this would certainly be possible by checking a JWT in a cookie or similar, although that limits the auth patterns this could be used with. This will probably be a plugin or otherwise separate crate, but we'll see how the final middleware API ends up looking! I'll leave this open for now.