Review

Is it good?

Gitbook's integration API is quite limited, so all of these demos use iframes.

A better integration would involve contacting gitbook, and getting them to use the tldraw library.

But what if we can't do that

If we can't do that, let's evaluate what we have right now.

Approach	Pros	Cons
Modal shared project	The editor isn't cramped. There's lots of room for it in the modal. Similar to other blocks (eg: figma).	You can't see what's inside the board unless you open it (no thumbnails or title, like figma). Anyone can edit the board. We should get the read-only link for it somehow. But even that wouldn't be secure.
Inline shared project	It's editable in edit mode. Read-only in view mode. You can see what's in the board, without needing to open a modal.	Too much UI on the editor takes up valuable space, even in read-only mode. Read-only mode is not secure(?). Someone could edit your board. It's currently hardcoded with a room id. We'd need to autogenerate one, eg: /r/gitbook_etc Do we really want it to be a shared board?? You can't copy stuff out of the inline editor.
Inline snapshot	You can see what's in the board, without needing to open a modal. Nobody can edit it.	You can't edit it from within gitbook. You need to make a new snapshot if you want to change it. Too much UI on the editor takes up valuable space. You can't copy stuff out of the inline editor.
Classic export	Looks great in view mode. No UI getting in the way.	You can't edit it from within gitbook.

Future work

Thumbnails

It would be great to have a super-easy endpoint for getting thumbnails. The figma block displays a thumbnail underneath.

We could make just the thumbnail visible in read-only mode (for any of these options). The editor only needs to be visible in edit mode.

Minimal UI

When the editor is inline in something like gitbook, it's usually just for making a single diagram. You don't want the pages menu, or the desktop-view style panel.

We should make a simple prop for a 'minimal' layout. It would make both iframe and library integrations easier to whip up.

Secure read-only

How secure is 'read-only' currently? It's easy to get the original board from a read-only link.

Let's make a read-only link that is actually secure, with its own unique id. And let's disallow switching read-only off in the editor.

It would be great to have an endpoint for getting a read-only version of a public board (so that a user can just paste in a URL to their board, and the integration can retrieve the read-only version).

Login with tldraw

We don't have any way of allowing people to 'login with tldraw' on other apps. Until that happens, we're stuck with embedding public boards.

What should we do?

I think we should submit a PR for the "inline shared project". Some extra work would be needed:

• We'd need to make it derive the read-only board from a non-read-only url.

• We should implement a url query that changes the UI in certain ways, and use it. eg: Hide certain parts of the UI that overlap with gitbook UI. We could also strip out unwanted things, like the share button and/or pages menu.

Also, let's just speak to gitbook

These complications come from not being allowed to put the <Tldraw> component onto the page. Let's speak to them and work it out.