I’ve been thinking about what the developer experience should be for enabling route-based prerender in a Redwood app and here’s a proposal:
Let’s say your home page is a marketing page that doesn’t take any parameters and should just be static. All you’ll have to do is add prerender to the route:
// web/src/Routes.js
<Route path="/" page={HomePage} name="home" prerender />
And that’s it! It will be rendered out at build-time and delivered as a static file. Now, if you have route parameters, it gets more interesting. You’ll still specify prerender in the route:
// web/src/Routes.js
<Route path="/todo/{id}" page={TodoPage} name="todo" prerender />
But now you need to get all possible values of id at build time. There are two ways you might want to do this. Perhaps you have a static list of IDs that don’t change very often (you would be happy changing a code file to update it). In that case, you could create a file on the web side at src/prerender.js:
// web/src/prerender.js
export const todo = [ {id: 1}, {id: 2}, {id: 3} ]
The idea here is that you can export an array-of-objects with the same name as the route you’ve requested to be prerendered and Redwood will grab the possible route params from there. You could also use this method to read them off disk from a JSON file or the like.
This is cool, but often you’ll want to get a dynamic list of route params from your database at CI build-time. In this case, it would be handy for the code to live on the api side so you can have access to whatever data access machinery normally lives there. But we don’t want to make you have to do complicated data fetching, so we could allow you to instead create a src/build/web/prerender.js file on the api side:
// api/src/build/web/prerender.js
import { todos } from 'src/services/todos'
export const todo = todos
This example is in the context of the example-todo app, and in it we can import the todos function from the todos service (which is exactly why services are written like this!). It will simply return an array of Todo objects, each of which contains an id parameter. Redwood will then orchestrate how that data is consumed by the prerender build process (maybe via a build-time-only GraphQL service, or maybe something else).
In either case, with only a few lines, you can enable prerender on a per-route basis and provide the necessary route params so Redwood can iterate over the possible pages and get them all rendered for you at build time.
You might wonder why we don’t simplify this and JUST have the api side file. The answer is two-fold:
- If you don’t have an api side at all (which is fine), then you’d have no way to prerender!
- If you don’t have an api side prerender file, then we can simplify the build process and not have to spin up any database access there, which will make the build happen faster and easier, so it ends up being an optimization to use the web side prerender file.
Let me know what you think!
First, we travel back to Fall 2016, Winter 2017. I jumped aboard the JAMStack train.
My first approach was basically (little simplified):
Where can I optimize? Yaml generation.
Can we scale to more articles?
Scrap it all and make React app.
Pagination
Memory
Timeouts / Connection Resets
Prerender data fetch fails = Incomplete Site?
Number/Cost/Limits of API Calls
. That brings me to the idea of writing the