splitbee/react-notion

Are there plans to add a renderer for the official Notion API?

ademidun opened this issue · 7 comments

ademidun commented
  • Notion has released an official API which also returns page blocks similar to what notion-api-worker does, which this package uses.
  • However, the API structure returned by notion-api-worker is a bit different (see below)
  • It would be very useful to add support for rendering both types of API responses, is there plans to support his?

Also, I'm curious to get people's opinion on the following:

We originally used notion-api-worker as our CMS backend, now we're thinking of switching to the official notion API since notion-api-worker says:

Use with caution. This is based on the private Notion API. We can not guarantee it will stay stable.

But notion-api-worker has more feature support than the official API (though perhaps more features will be launched in the future).

So should we continue using the potentially unstable Notion API which has more features?

Or switch to the official API which has fewer features but is (potentially) more stable?

My current thought is we continue using notion-api-worker until the official Notion API has more features or if Notion decided to make it harder to use their private API.

kitze commented

Also interested in this.

bats64mgutsi commented

We also had the same issue. We instead built our own wrapper on top of the Official Notion API. Unlike react-notion, however, it transforms Notion pages to Markdown and also fetches the page media to be served with our static assets. We then run the docusaurus static site generator to render our website.

timolins commented

Looks like the time has come for this – would love to depend on the more stable Notion API. Notion added a lot of the missing blocks in the recent month to their API. We will start to explore this topic.

  • 👍5
  • 🚀5
tobiaslins commented

We already found something in the official API that doesn't allow us to port react-notion as it is now.
The notion.blocks.children.list call doesn't return all blocks needed to render a page. We would need to fetch recursively which could potentially fail due the rate limits of Notion.

For example:
A page that has 2 columns with content in it.

  • notion.blocks.children.list returns one column_list block.
  • We need to run the same request again for the column_list id. We now get 2 column blocks (again without content).
  • After that we will need to fetch all children for those blocks again to receive the content.

This means: 4 requests to Notion API for a single multi column page.

We try to reach out to the Notion team to talk about this. It would be great if they could allow us to fetch all blocks recursively within one request.

  • 👍1
pgerlich commented

Any updates on this? Is there any planned action to support the official Notion API given those limitations?

transitive-bullshit commented

notion-compat may be useful here. It provides a best-effort conversion from Notion's official API to their unofficial API, which react-notion and react-notion-x both use.

As Tobias mentioned, the performance is quite poor, though. I also tried to give a concrete, block-by-block comparison to show where the official API is missing information that would be necessary to render notion content faithfully.

pgerlich commented

Ooh thanks for pointing that out.. I'll check it out.