Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ids are a binary sequence that encode the position of a node in the tree. Every time the tree forks into multiple children, we add additional bits to the right of the sequence that represent the position of the child within the current level of children. 00101 00010001011010101 ╰─┬─╯ ╰───────┬───────╯ Fork 5 of 20 Parent id The leading 0s are important. In the above example, you only need 3 bits to represent slot 5. However, you need 5 bits to represent all the forks at the current level, so we must account for the empty bits at the end. We do this by tracking the length of the sequence, since you can't represent this using a single integer. For this same reason, slots are 1-indexed instead of 0-indexed. Otherwise, the zeroth id at a level would be indistinguishable from its parent. If a node has only one child, and does not materialize an id (i.e. does not contain a useId hook), then we don't need to allocate any space in the sequence. It's treated as a transparent indirection. For example, these two trees produce the same ids: <> <> <Indirection> <A /> <A /> <B /> </Indirection> </> <B /> </> However, we cannot skip any materializes an id. Otherwise, a parent id that does not fork would be indistinguishable from its child id. For example, this tree does not fork, but the parent and child must have different ids. <Parent> <Child /> </Parent> To handle this scenario, every time we materialize an id, we allocate a new level with a single slot. You can think of this as a fork with only one prong, or an array of children with length 1. You can also think of it as if the parent were inserted as the first child of itself; that's not how it's implemented, but the resulting binary encoding is the same because it has the same effect of adding a 0 to the left of the previous id. It's possible for the the size of the sequence to exceed 32 bits, the max size for bitwise operations. When this happens, we make more room by converting the right part of the id to a string and storing it in an overflow variable. We use a base 32 string representation, because 32 is the largest power of 2 that is supported by toString(). We want the base to be large so that the resulting ids are compact, and we want the base to be a power of 2 because every log2(base) bits corresponds to a single character, i.e. every log2(32) = 5 bits. That means we can lop bits off the end 5 at a time without affecting the final result.
- Loading branch information