Skip to content
This repository has been archived by the owner on Dec 26, 2022. It is now read-only.

Optimized version of VDOM index #20

Open
agrinko opened this issue Dec 17, 2017 · 2 comments
Open

Optimized version of VDOM index #20

agrinko opened this issue Dec 17, 2017 · 2 comments

Comments

@agrinko
Copy link

agrinko commented Dec 17, 2017

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 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:

[ // 0
       [
            [ // 1
                [
                    null, // 2
                    [ // 3
                        [
                            [], // 4
                            null // 5
                        ],
                        2
                    ]
                ],
                4
            ]
       ],
       5
]

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 child
  5: [0, 0, 1, 1], // index 5 - 0th element (root) => its 0th child => its 1st child => its 1st child
  0: [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?

@andrew-templeton
Copy link

Did you ever implement this serialization scheme into a fork?

@agrinko
Copy link
Author

agrinko commented May 10, 2019

@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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants