Tracking react-notion vs react-notion-x

[splitbee]

Tracking react-notion vs react-notion-x

[timolins]

Wow, thanks for sharing all your hard work! A lot of great improvements have been made with react-notion-x.

Moving forwards I'd love to leverage a lot of the stuff you built. I outlined some of my thoughts on how to implement those changes, while remaining true to the vision of providing a minimal content renderer for Notion in #37.

Those are the things I think make sense to look into:

• Leverage the notion-types & notion-utils packages. They are quite unopinionated, and mostly dictated by what Notion does. Makes sense to solve those problems on dedicated packages, like you did. 👍
• Look into notion-client for notion-api-worker (cc @tobiaslins). Same as above, makes sense to focus that work in one central point, and make it reusable for other projects. As you mentioned is a good idea to directly talk to the API when using Next.js. For projects that are not using Node or need client-side communication, I still think the worker still has it's place. Also the /table functionality is not handled by notion-client - not sure if it should, since I like the idea of it being just the a bare Notion API client without a lot of custom logic. Maybe the need for the /table endpoints will be redundant once they launch the official API.
• Start looking into the new block types and merge them over again.

Lazy loading complex blocks is definitely a good idea. I would try to avoid depending on next/dynamic, since this rules out applications in other environments like Gatsby or manual SSR. I will put the new custom component system to the test, maybe it can provide a way to bring your own™ lazy load system.