With that setup, I imagine it's fairly trivial to add a "static site generator":
- Run the local server that serves the rendered pages.
- Run a Node.js process that will take a given array of all page routes; make HTTP requests to those local URLs; and save the rendered HTML into folders, for a complete static site.
People tend to think of React rendering and the like as this special, mysterious process. But the only special thing about it is the way it efficiently reconciles and updates an existing DOM to match a new DOM. That initial render is really no different from PHP. Static site generators are just PHP with a prewarmed cache.
You can do the same thing with Next.js, and you can move between client-side and static with Gatsby
> But the only special thing
I think there might be more to unpack here, but when using react being able to typecheck and lint my jsx is pretty sweet. React also makes it much harder to create cross site scripting vulnerabilities.
I heard the analogy (equivalence?) before, that statically rendered sites are caches that are invalidated at build time.
Makes sense, and thinking of it as a strategy that can be partially applied - rather than as an all-encompassing framework or tool - is insightful, so it can be mixed and matched with dynamic rendering as needed.
The blog post mentions the 3 APIs that make this possible:
- getStaticProps (Static Generation): Fetch data at build-time.
- getStaticPaths (Static Generation): Specify dynamic routes to prerender based on data.
- getServerSideProps (Server-Side Rendering): Fetch data on each request.