fix: use preloaded data in useDoc

[Gozala]

Per https://linear.app/common-tools/issue/CT-308/usedoc-should-return-data-read-from

[Copilot]

Pull Request Overview

This PR fixes the useDoc hook by removing the defaultValue parameter and instead returning the preloaded data from window.sourceData.

• Removed the defaultValue parameter from useDoc and its related effect block
• Updated the return logic to use preloaded data instead of a default value

Comments suppressed due to low confidence (1)

jumble/public/module/charm/sandbox/bootstrap.js:11

• Removing the defaultValue parameter changes the fallback behavior of useDoc. Confirm that all callsites have been updated to rely on window.sourceData for preloaded data instead of passing a default value.

window.useDoc = function (key) {

[Gozala]

@seefeldb would be great to get your input on this because we went back and forth in regards to what we want to do if key was not preloaded here https://linear.app/common-tools/issue/CT-308/usedoc-should-return-data-read-from and https://discord.com/channels/1232452732963655720/1252747522678460466/1364692637533208727

I also have since realized that useDoc could still return stale value and end up overwriting data just like it did here https://linear.app/common-tools/issue/CT-273/data-seems-to-get-lost-when-opening-charm-in-another-window

[bfollington]

I originally wanted to achieve this kind of behaviour by blocking the initial React render until we had received the first copy of the Charm's data, then useDoc wouldn't need to have such complex fallback behaviour.

This PR seems cleaner to me in achieving some of that, but I actually don't know how to protect against stale data completely... not without @seefeldb's input

[seefeldb]

Were you able to verify what happens when the schema defines a key, where the value undefined is allowed (e.g. an optional key with no default value) and it is undefined? Will sourceData include it?

[seefeldb]

Ah, since we're not throwing, this is fine.

One thing to watch for: The way to set default values is via the schema, but if the LLM doesn't do that, then it might instead use useEffect, which might exacerbate the issues.

[Gozala]

Ah, since we're not throwing, this is fine.

One thing to watch for: The way to set default values is via the schema, but if the LLM doesn't do that, then it might instead use useEffect, which might exacerbate the issues.

Perhaps alternative tack would be to kickoff schema alteration when useDoc is called with unknown key ? Which may be aligned with more broader idea of lazy bindings.