You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 26, 2022. It is now read-only.
Your serializer does a great job for sending data between client and server. But in our project we faced a problem.
Each serialized patch contains a property called a - a simplified tree that mimics DOM structure and holds number of nested nodes in each node (for quicker search), correct?
When DOM tree is big, even this simplified tree gets quite huge, containing thousands of elements. Moreover, it contains lots of null values, that take up at least 4 bytes each when sent as a stringified JSON. Big stringified a might contain a million of characters - thus taking up at least 1MB (in ASCII). It may be compressed before sending though. But still if we're sending lots of big diffs - we're sending megabytes of data. The data that is only needed to find correct element in VDOM to patch it!
So my proposal is to use a different format. Instead of a tree, how about we use a hash containing paths to each element that needs patching? It means we'll store only paths to elements that will be patched, not the whole DOM tree index.
For example, suppose we have the following a tree:
And the patch affects indices 0, 2 and 5. The alternative structure then would be:
{2: [0,0,0],// index 2 refers to 0th element (always root) => its 0th child => its 0th child5: [0,0,1,1],// index 5 - 0th element (root) => its 0th child => its 1st child => its 1st child0: [0]// index 0 refers to 0th element itself (root)}
It's a simplified example, but in larger scale the difference is significant: thousands (if not millions) of extra characters to send between client and server and to process in JS versus simple hash of arrays of integers, containing only relevant information for patching.
patchRecursive function would be also simplified as it only needs to access child nodes by specified indices for each patch, instead of traversing through the tree.
We've already started implementing this in our project - seems working. Just wanted to hear your thoughts about it. Maybe I am missing something important?
The text was updated successfully, but these errors were encountered:
@andrew-templeton , we implemented something like this in our private project. But unfortunately I left that project a year ago and don't have access to it any more. I don't remember much, but I guess it was not much of a problem to change this structure format for us.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi @nolanlawson !
Your serializer does a great job for sending data between client and server. But in our project we faced a problem.
Each serialized patch contains a property called
a
- a simplified tree that mimics DOM structure and holds number of nested nodes in each node (for quicker search), correct?When DOM tree is big, even this simplified tree gets quite huge, containing thousands of elements. Moreover, it contains lots of
null
values, that take up at least 4 bytes each when sent as a stringified JSON. Big stringifieda
might contain a million of characters - thus taking up at least 1MB (in ASCII). It may be compressed before sending though. But still if we're sending lots of big diffs - we're sending megabytes of data. The data that is only needed to find correct element in VDOM to patch it!So my proposal is to use a different format. Instead of a tree, how about we use a hash containing paths to each element that needs patching? It means we'll store only paths to elements that will be patched, not the whole DOM tree index.
For example, suppose we have the following
a
tree:And the patch affects indices
0
,2
and5
. The alternative structure then would be:It's a simplified example, but in larger scale the difference is significant: thousands (if not millions) of extra characters to send between client and server and to process in JS versus simple hash of arrays of integers, containing only relevant information for patching.
patchRecursive
function would be also simplified as it only needs to access child nodes by specified indices for each patch, instead of traversing through the tree.We've already started implementing this in our project - seems working. Just wanted to hear your thoughts about it. Maybe I am missing something important?
The text was updated successfully, but these errors were encountered: