vercel/spr-landing

Refactor with SWR

Closed this issue · 2 comments

wbunting commented

should likely be refactored with SWR https://github.com/zeit/swr

possibly blocked on vercel/swr#11

It's good for most blog style content to be ssr for SEO purposes

ijjk commented

Hey folks! We have upgraded this repo to take advantage of incremental static site generation (iSSG). In short:

  • There’s never a cold boot anymore when accessing the page
  • The page gets incrementally re-built asynchronously
  • Always fast & available

This is thanks to Next.js' new hooks for static site generation, see the RFC here, where you can learn more about how this works.

I’m closing this issue for now as it’s no longer applicable. Feel free to ping me with any questions.

  • ❤️2
wbunting commented

@ijjk I'm sure it's just the APIs being unstable, but it's unclear to me from your second bullet point exactly how re-builds get triggered.

Eg. One of the nice things about the existing thing was:

  • always serve a cached version of the ssr
  • async revalidate that against possible changes in notion
  • frontend refreshes automatically if the revalidation yields a differnet etag.

It's unclear to me how next build is being triggered by changes in Notion. Is there some way that the page is doing the revalidation by itself in the background? eg:
https://github.com/zeit/spr-landing/blob/master/pages/index.js#L186

It seems like that's a nice feature, but it might only work if you deploy Next.js on Zeit now so the host knows that it has to use the code from getStaticProps to revalidate against?

I could be totally off the mark / things are still in flight so feel free to push back 😄