The first impression of the new Docker Library. Any suggestions?

[evonox]

Hi all,
I am actively working on the new Docking Library based on the original DockSpawnTS code.
I am giving you the first impression here: https://docker.robotkarel.cz/
However, it is still a thing under heavy development.

I have reworked the internals of DockSpawnTS completely, so the bad news is it will not be possible to simply merge with the original codebase. In case of interest, the original DockSpawnTS might be a set of adapter APIs to provide backward compatibility.

Likes or dislikes of the demo? There are far more features to come.

[jogibear9988]

Love it.
It looks really good.

Few questions/suggestions:

• Would you still keep all the content in the DOM and only change the absolute position? In a old version of Dock spawn, the content was moved between some dom Nodes, but this will be really slow on big contents with many DOM nodes
• Would you support to undock to an external window?
• Lib should be usable as ESM later without needing to use a bundler

[evonox]

Dear @jogibear9988 ,
you are right, DOM manipulations are slow, slow and slow. I will do even more than you write. Let's summarize it a bit:

• Yes, I keep your approach of keeping big contents with many DOM nodes in the DOM and moved only by changing the absolute position.
• Next, I try to remove all the expensive JavaScript computations in original DockSpawnTS and try to rely on CSS engine as much as possible. This means, for instance, when you resize using the SplitterBar, the layout change means only setting one CSS property like grid-template-columns. This than triggers using ResizeObserver API the change in the corresponding PanelContainers exactly to update the positioning CSS properties for the content to be moved
• I will try to avoid as much DOM manipulation concerning tree hierarchy. This I leave for later measuring.
• I did a little interesting measuring. If I cache for each element the list of existing CSS classes to avoid adding it to classList property, it is 10x - 12x faster than if you used without this local cache. This feature is implemented now. I need to commit it only.
• The same cache I use even for CSS styles using a Map object. DockerTS will be using only a small set of CSS property styles.
• Another thing we do not want is Layout Trashing. There is an internal DOM update queue of handlers that triggers on requestAnimationFrame event. The idea is to do all the necessary DOM mutations at once. This is not working properly yet, because there are edge case where we want to apply some CSS styles and then we need to do some measuring using the new layout data. This edge case is for instance automatic context menu positioning algorithm that needs to check, if the popup appears in the visible area of window and if not, then it should change the layout.
• The last optimization approach is certainly debouncing handlers like mousemove where I use Lodash Throttle function to reduce the rate to 1000ms / 120Hz - reduce to throw away browser rendering frames. Maybe it is up to our discussion if not to change it to 1000ms / 60Hz interval.
• Undocking to external window I may support. I will just look how this feature is implemented.
• At last, it will be ESM without a bundler. We may create using Babel as many deployment targets as will be needed.
• The speed optimization list is not far not complete, we will need to do proper measuring of the behavior and see what needs to be optimized further. This will be part of the public testing of the library when it will be ready. I hope in couple of weeks.