You want all long-lived content to be stored in git as a means toward:
Rich content diffs
Zero dependencies between Notion and Svelte
Guaranteed synchronicity between code and content
Which brings us to notion2svelte, a tool whose sole purpose is transforming
Notion pages into .svelte files
Fetching
I forgot to include it in these diagrams, but you’ll need a .env file, properly configured, and stored wherever you intend to run npx notion2svelte:
typically, the root of your Svelte app
Anyway, once it’s able to query your document database in Notion, notion2svelte first fetches top-level data for all pages where Status: Publishable*…
*Or some other value, if you’ve set an override in your .env
…then, for each fetched page, notion2svelte recursively fetches all blocks
needed to render that page
The end result is a fully-fleshed out, in-memory* Page object
*As of notion2svelte 0.0.1, this object gets serialized to a .json file with the same root filename as the output .svelte, providing maximum flexibility to the end user with minimal effort on my part 😬
Rendering
Once the entire page has been collated, notion2svelte converts every* element
on the page — title, cover art, icon, and blocks — into a corresponding Svelte component, nesting
components as appropriate, and providing imports in a <script> tag
*Well, not every element. I haven’t gotten around to the hybrid Toggle Header blocks, nor to tables. Nor
have I looked into supporting any of the custom 3rd party integrations, not having had the
need. Oh, and while page props aren’t rendered by notion2svelte, you can do what you wish with
them by exposing Notion props as blockProps.
You provide the actual component implementations, stored in src/lib/notion2svelteOn the surface, there’s not much else to say about this particular detail, as this is basically
just Svelte 101!
You’ve got .svelte files output by notion2svelte
These import components from src/lib/notion2svelte
Those two banal statements are at the root of notion2svelte’s power. Put
another way, notion2svelte is as flexible and as powerful as Svelte, because,
in the end, Svelte is all you’re really dealing with…and Svelte is forking awesome!
Putting it all together
Once you’ve verified that your newly-rendered page(s) look and behave as expected, and maybe
scanned the git diff for undesirable changes, it’s time to commit and, when you’re ready for the
changes to go publish, to push
The role of Publishable
Notion’s API requires a minimum of n+1 fetches for every page, where n is the
number of blocks on the page
Aside from wasting server resources, this can also waste your time, since fetching loads of pages
can stretch out to dozens of seconds, or even minutes
As such, you’ll probably want to change each page’s Status to (e.g.) Published once it’s been processed by notion2svelte
Ejecting
If you want to keep the pages generated by notion2svelte, but otherwise remove its
presence from your project: