Documentation on NextJS w/r/t SSR (e.g. GitHub pages)

[bchristie]

Been playing with this, and love it. However, I'd like to see one primary addition, mostly around when you want to leverage outstatic with NextJS for an SSR (static) website.

To elaborate, I love how easy it is to create posts (well, content in general) with outstatic. However, it seems very catered to being ran on a server where NextJS can run (as opposed to one leveraging NextJS for SSR/"headless"). To that point, at a high level, I'd like to see the following:

Firstly, outline how you can continue to use outstatic as-is, but maybe how you can get it to stand out of the way for static builds. What I found was renaming the necessary file extensions from page.tsx and route.tsx to page.standalone.tsx and route.standalone.tsx (respectively), then massaging the nextjs.config.mjs to behave differently based on the build I was targeting by adjusting pageExtensions. e.g.

// @ts-check
import { PHASE_DEVELOPMENT_SERVER } from "next/constants.js";
/**
 * @param {string} phase
 * @param {object} obj
 * @param {import('next').NextConfig} obj.defaultConfig
 */
const nextConfig = async (phase, { defaultConfig }) => {
  /** @type {import('next').NextConfig} */
  const sharedConfig = {
    // your default behaviors
  };
  switch (phase) {
    // here we target SSR, so those "page.standalone.tsx" and "route.standalone.tsx" will be
    // ignored/skipped over.
    case PHASE_PRODUCTION_BUILD:
      /** @type {import('next').NextConfig} */
      const prodConfig = {
        ...sharedConfig,
        output: "export",
      };
      return prodConfig;
    // here we target a dev server/normal site, so let's loop in outstatic again
    // so its endpoints work
    case PHASE_DEVELOPMENT_SERVER:
    default:
      /** @type {import('next').NextConfig} */
      const devConfig = {
        ...sharedConfig,
        pageExtensions: ["standalone.tsx", "standalone.ts", "standalone.jsx", "standalone.js", "jsx", "js", "tsx", "ts"],
      };
      return devConfig;
  }

Next, while It's great it auto-commits to a repo, the ability to use a different saving mechanism would be amazing (like direct to filesystem). Basically, use it as a pseudo-CMS and put the onerous of pushing files on me, the dev. As it stands now, I need to git pull every time I want to grab a recent change, then play around with how I can integrate it with the site. The local save would speed up that process, and give more flexibility for use cases of using this as a local tool (and serious competition against the gatsby/jekylls).

Just food for thought, Hit me up with any questions, but this took me some time to work-around, and at the very least might allow my solution to help others in the same boat.

Happy coding!

p.s. Came across these two similar posts, but one was inconclusive, and the other used a hack (manual delete of the files).

• Is it possible to use output: "export" in nextJS with Outstatic ? #227 (inconclusive)
• Static html export to GitHub page? #123 (manually deleted headache files)

[avitorio]

Hey @bchristie,

Thank you for the code snippet. If you want, feel free to clone the project and add a new section to the docs. Perhaps in the FAQs about this.

If not, I'll get to it eventually.

As for saving to disk, this is something I have considered and will add as a feature in the future.
As of right now, the focus in mainly on non-dev users. I'm improving some other aspects of the framework but more granular control in terms of how content is saved will come at some point. Thank you for the suggestion!