Comments (3)
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.
Related Issues (20)
- is this project still in development? HOT 1
- [Question] Vanilla JS usage ? HOT 2
- Type 'string' is not comparable to type 'NodeType' HOT 2
- Support for "any" datatype on ports
- Saving/loading of paths HOT 1
- I can't add nodetypes dynamic
- Clone of version v0.8.2 but version compatibility problem on installation HOT 1
- Bug: Cannot read properties of null (reading 'setAttribute')
- Connecting nodes to already connected input?
- Branching logic
- Getting and setting pan and zoom HOT 1
- Theming documentation missing closing backtick
- Animated connections
- How to actually extract context?
- Rendering custom components in nodes
- Flume for NEXT.js v14 HOT 3
- Support mobile? (ipad)
- Well done! HOT 1
- Inquiry on Project Maintenance Status for Flume HOT 3
- Custom node connectors
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flume.