Runtime error when using defaultNodes with SSR about flume HOT 3 CLOSED

Interesting, thanks for doing this research. I agree, that sounds like the right approach especially as a first implementation, and it can be revisited again later if needed. Thanks for offering to PR this, if you put one in I'll be sure to get it reviewed and merged in short order.

from flume.

Thanks for reporting this! It's interesting that server rendering with Next has this problem, but apparently not server rendering with Gatsby, as this problem hasn't surfaced with the server-rendered examples in the docs. It's actually already using @reach/auto-id to manage the IDs of the various stage wrappers, so fully-supporting server rendering is definitely a goal.

I like your idea about providing an id as part of the default nodes, but it does mean the onus is on the developer to ensure that those ids are unique between nodes, and between other instances of the editor that may be on the same page. If it's something that could be abstracted away the way @reach/auto-id does, that would be ideal, but like you say, that's probably a more difficult approach.

One path forward might be to try to detect if a node is being added because it's been server-rendered, and give it a special data attribute if it has. Then when the editor loads in the browser and the default nodes are parsed, it could query the nodes in the stage to see if any of them were server rendered and have the same type as the node being added as a default. If so it could pull the node id from the data attribute of the server-rendered node. Server rendering isn't my forte, so I don't know if there's maybe some potential pitfalls to that approach, but it's maybe a possibility.

What thoughts do you have?

from flume.

tldr; jump to the last paragraph

I'm pretty new to server-rendering and next myself so I wanted to do some research before I responded to make sure I wasn't using the framework incorrectly. It looks like what next is doing is expected: calling React.hydrate does not clear out existing markup or replace attributes within that markup (sources: facebook/react#10189 and facebook/react#10339)

If you load the flume documentation and check the devtools, you'll see that the default nodes in the flume graph have an ID generated by the server but the client ends up with a different ID. Interestingly, docusaurus does indeed use React.hydrate but never throws warnings in the console. Not sure why it regenerates the ID when next doesn't but my best guess is that docusaurus generates a different structure on the client than on the server so the markup isn't reused (like maybe it's got an extra div surrounding the whole thing)

It looks like React expects that the markup you generate on the server and the markup you generate on your first client render will be identical. So I don't think we can add a data-attribute on the server only because that attribute won't be added in the first client render and we'll get a similar warning about the react output not matching. The way @reach-ui/auto-id handles this is by letting that first server/client render generate undefined as an id and then populating a true id on the second render (source: https://github.com/reach/reach-ui/blob/develop/packages/auto-id/src/index.ts#L80-L107). I don't think this exact approach works for us because each node needs a unique id.

I propose we do something similar to what you suggested: Let's use reproducible IDs for defaultNodes on the first client/server render of flume (maybe id: default-{index}) and give them an extra attribute (something like defaultNode: true). Then on the second render we can replace all those ids with actual ids: useEffect(() => findEveryNodeWithDefaultNodeEqualToTrueAndGenerateANewIdForIt(), []). What do you think?

from flume.