Skip to content

Conversation

@nvie
Copy link
Contributor

@nvie nvie commented Jun 18, 2024

This now takes a LiveObject instance directly, so that users no longer have to bother with knowing about or calling toPlainLson() manually.

Creating a new room from the backend is now as easy as:

await client.initializeStorageDocument("my-room", new LiveObject({
  layers: new LiveMap(),
  layerIds: new LiveList([]),
}));

Fixes LB-884.

@vercel
Copy link

vercel bot commented Jun 18, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
examples-nextjs-notifications-custom ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 19, 2024 7:01am
4 Ignored Deployments
Name Status Preview Comments Updated (UTC)
examples-nextjs-comments-audio ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 7:01am
examples-nextjs-comments-canvas ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 7:01am
examples-nextjs-comments-notifications ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 7:01am
examples-nextjs-lexical ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 7:01am

roomId: string,
document: PlainLsonObject
document: LiveObject<S> | PlainLsonObject
): Promise<PlainLsonObject> {
Copy link
Contributor Author

@nvie nvie Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actual question: I just noticed we're returning the document in plain LSON format here. This format is of course technically needed to get the Live objects over the wire, but I don't think in actual apps it's a nice format to work with. Should we not lift the level of abstraction a bit higher here, and either return:

  • void (so people can use .getStorageDocument(..., "json" /* their preferred format */))
  • LiveObject instance
  • Simplified JSON (i.e. the equivalent of calling storage.toImmutable())

All of those three seem better than returning a PlainLsonObject.

@CTNicholas @nimeshnayaju What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right! I think LiveObject is not particularly useful on the back end, so I'd probably skip that. I think void or JSON makes the most sense to me. However, bear in mind that getStorageDocument returns LSON by default, and we want our APIs to be consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, so the consistency argument rules out option 3, too. So… should we make this void instead? That, however, would be a breaking change, so maybe not change anything after all?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vincent's written up more ideas here: LB-891

Co-authored-by: Marc Bouchenoire <[email protected]>
@CTNicholas
Copy link
Contributor

Nice! This would definitely be easier to use. I'm assuming LiveMap, LiveList, etc. work in all environments (Browser, Node.js, Workers, etc.).

Why not just have a plain object at the root of the argument? Since it's always a LiveObject anyway, or at least, it always is when you use initialStorage.

await client.initializeStorageDocument("my-room", {
  layers: new LiveMap(),
  layerIds: new LiveList([]),
});

@nvie
Copy link
Contributor Author

nvie commented Jun 18, 2024

Nice! This would definitely be easier to use. I'm assuming LiveMap, LiveList, etc. work in all environments (Browser, Node.js, Workers, etc.).

Yeah, they do, until you start "using" them, i.e. start calling myObj.set("foo", "bar"). This will want to start emitting messages to the server, which requires a WebSocket polyfill. But as long as you're only using them to build a document like in this case, that should work.

Why not just have a plain object at the root of the argument? Since it's always a LiveObject anyway, or at least, it always is when you use initialStorage.

We could do that too, can update 👍

@nvie
Copy link
Contributor Author

nvie commented Jul 3, 2025

Closing all PRs that have been opened for more than a year.

@nvie nvie closed this Jul 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

don't merge yet Don't merge this PR yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants