Hi all I m not sure if I understood the `SlotTable` responsi

Question

Hi all I m not sure if I understood the `SlotTable` responsibility in compose algorithm it keeps slots and other concepts that are made do manage slots but what exactly is stored on those slots values and what its relationship with a compose tree Is it the core of a compose tree management or something like that Could anyone explain it please

Leland Richardson [G] · Answer

I m writing a blog that should make this a bit more clear

Leland Richardson [G] · Answer

the slot table is where compose memoizes data during composition the whole runtime is built on top of it and it s built to be fairly efficient You can think of it as an array of the flattened depth first traversal of the composition hierarchy

Leland Richardson [G] · Answer

under the hood it uses a gap buffer algorithm <https en wikipedia org wiki Gap buffer>

bloder · Answer

Nice Thank you for the answer One more and dumb question where is this memorization needed As I know we have a compose node that waits a value emmition to recompose with the updated value where is this memorization needed in a struct like that

elizarov · Answer

You don t have to recompose everything You can check if the input to the composable function that is called is still the same as it was last time and skip it completely retaining its memoized effect on the tree as it was

elizarov · Answer

That is why composable functions have to be pure And that is the key to efficiency and the speed of it

bloder · Answer

Oh then SlotTable was made to keep tree state in a way that we can make a kind of lightweight tree diffs

Leland Richardson [G] · Answer

right we compare a lot of things against their previous versions to determine if we can skip certain operations

Leland Richardson [G] · Answer

the most important example of this is the allocation of the nodes themselves

Leland Richardson [G] · Answer

we don t create a whole new tree every time we recompose we mutate the nodes in that tree on subsequent composes and we only mutate the properties that we know need to be changed

Leland Richardson [G] · Answer

most memoization in the traditional sense though is implemented with a global cache the unique thing here is that it only tries to memoize based on the previous value at that exact point in the tree we leverage execution order as an implicit input essentially This allows the cache to be very efficiently consulted basically an array look up which should be O 1

bloder · Answer

Nice Thank you for the explanations I was having a wrong idea of compose struct and probably there are some details that I m still having it I was thinking that we don t needed to make any kind of diff to recompose a view since we have reactive values in each node and it s a good approach to that I ve already implemented some similar solutions to study purposes but I ve never thought in a gap buffer solution for that sweat smile

Leland Richardson [G] · Answer

yeah gap buffers are typically used for text editors but we think that most UIs will be mutated in a way where the gap buffer algorithm will make the right set of compromises ie when there are structural changes there will be many inserted removed sequentially at the same point in the tree hopefully we re right about that wink

moetouban · Answer

does this work similar to redux reselect

Leland Richardson [G] · Answer

Only in that it only keeps the previous set of inputs The positional aspect is different but other than that they are similar yeah

Leland Richardson [G] · Answer

In compose the createSelector part is done automatically I guess you could say