-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: make deserialization use the new render management system #7306
fix: make deserialization use the new render management system #7306
Conversation
e7fab67
to
48737a2
Compare
* @returns The root block created. | ||
* @internal | ||
*/ | ||
export function domToBlockInternal( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get why you made domToBlock
render immediately, but I don't love this name. It's not very descriptive, and it implies external developers would never want to call it. But in reality they might be perfectly fine not triggering an immediate render. What about domToBlockAsync
? or something better than that in the same vein? Then we don't have to mark it as internal.
Or is your plan to eventually make the breaking change to domToBlock
? in that case i don't care quite as much if this method is intended to be temporary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My plan is indeed to eventually make the breaking change to domToBlock
(unless there's an important reason we don't want to do that)! I chose the domToBlockInternal
name to match the naming of the JSON serialization system.
sorry didn't realize this was a draft |
48737a2
to
abc61d7
Compare
The basics
npm run format
andnpm run lint
The details
Resolves
Fixes #7290
Proposed Changes
Changed both the JSON and XML deserialization systems to use the render queue, but trigger an immediate render.
Reason for Changes
Moving both sytems to use the render queue allows us to get rid of the old render management system. But I chose to make them trigger an immediate render (instead of waiting until the end of the frame) to ensure 100% backwards compatibility.
We could have people use the
finishQueuedRenders
method if they want to calculate things based on the size/position of the blocks after deserialization. However, as we discovered last time I was reorganizing stuff, that's technically a breaking change :/ And I think deserialization is a much more high-risk area for this kind of thing! (as opposed to like, adding an input to a block).Test Coverage
Documentation
N/A
Additional Information
N/A
Dependent on: #7296