[3895] Memoize the explorer

[mcharfadi]

No description provided.

[mcharfadi]

I had issues typing useRef since it's using scrollIntoViewIfNeeded
I removed scrollIntoViewIfNeeded (it's deprecated) since scrollIntoViewseems to be well supported now

https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView

[sbegaudeau]

I'm not sure why but with this PR, the explorer feels way more slow, everything seems to be blinking.

[mcharfadi]

The refDom.current.scrollIntoView behave differently.
But I also found that with the rebase, it seems the expand now has an issue. I don't know if you're referring to this.
Otherwise selecting from the diagram is noticeably faster on my end with the performance papaya.

[mcharfadi]

So for the expand, it's missing some dependencies in the useCallBack.
For the scrollIntoView , I'm not sure, it seems to me that it was not working properly before and fixing that makes the interaction less smooth.

[mcharfadi]

I confirm that with the PR #3875 , most optimizations I made in this PR will not work anymore.
For example the method onExpand now uses state.expanded and as such we can't memoize onExpand correctly now.
I'm not sure how to handle these newly added states while only rerendering the treeItems impacted by a change.

[mcharfadi]

I pushed a prototype version that would restore the performance gains.
Please note that I have used Zustand as a quick way of prototyping a solution but on a concrete implementation we might either :

1. useExternalStore to replicate the behaviour of Zustand without adding the library
2. adopt our current partern with a context and a customHook (but in this case I'm not sure we could have the same behavior easily)

The main goal is to avoid having onExpand as a prop, but I also wrapped several component in memo
Here are the results when expanding a node on papaya with only the explorer opened.

This is on master, we can see that around 15 rerender took each around 100ms totaling more than 1.5s

This is with the updated PR, we have as much "big" rerender as we expect. The first one is due to the selection change context (and has been reduced from 150ms to 30ms due to the different memo). The second one is due to receiving the TreeEventPayload and is taking 200ms.

Also note, that I have not tried with tree item action contributions, and I have not tried with several Tree (this might require an instance of a store for each Tree)

I put the PR on draft, we could probably find another way to get back the performance gains, but since it was relatively quick to prototype, I wanted to share this possible solution.