Hi all, I'm not sure if I understood the `SlotTabl...

# compose

[bloder]

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

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

[Leland Richardson [G]]

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

under the hood it uses a gap buffer algorithm: https://en.wikipedia.org/wiki/Gap_buffer

[bloder]

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]

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]

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

[bloder]

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

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

[Leland Richardson [G]]

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

[Leland Richardson [G]]

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

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]

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 😅

[Leland Richardson [G]]

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 😉

[moetouban]

does this work similar to redux reselect ?

[Leland Richardson [G]]

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

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