Idea needed. How to architect Docking System, and avoid unneeded rerenders.

[latent sun]

Hi, I am developing a graphics editor. In which the user should be able to change the layout similar to how it can be done in Photoshop.

I found a couple of libraries like:

• golden-layout (https://golden-layout.com/)
• phosphorjs-dockpanel (https://phosphorjs.github.io/examples/dockpanel/).
  But even before I tried to integrate them, I realized that I don't fully understand what Solid mechanisms I should use to make it work adequately without unnecessary redraws, etc.

The problem of not allowing a component to be redrawn is important, because when dragging Tab from one View to another, its state must not be lost. Let's say we're drawing something on canvas and want to move the Tab with it. The content should be intact and signals and storages should be preserved.
So I guess I have to somehow manually change the DOM by setting element parent via appendChild or something like that. But I don't know how Solid will take into account the Lifecycle of this tab. For example how can I get onCleanup to be called when I close the tab?

If to structure, the questions will be about the following:
0. Is the lifecycle of a solid component related to its existence in the DOM? And where can I read/see more about it.

1. How to organize the ownership of the tabs so that when they are moved, there is no re-rendering and when they are closed, onCleanup is called.
2. Which Solid mechanism is better to use to organize tab content display (Dynamic, Show, Switch, ... ?)

Basically, I want to understand how to change the DOM structure, so that it makes sense from a Solid component lifecycle perspective. All in all, best practices are needed.

Translated with www.DeepL.com/Translator (free version)

Also to simplify the discussion, I offer the following set of terms:

• TabHeader: a tab label which can be dragged and dropped
• TabContent: the tab content (the displayed editor with the state you want to save)
• TabBar: container for headers
• TabViewport: the place where tab content is displayed
• TabView: TabBar + TabView
• SplitContainer: the horizontal/vertical container in which TabViews are placed

[random delta]

Hi JakErdy, I am going through the support looking for unanswered questions.

[random delta]

0. the idea of a component-lifecycle in solidjs is a bit synthetic. There are no real components, only set-up functions for signals and effects. Once a signal becomes a part of a reactive graph, it 'mounts', once it removes itself from the graph it 'unmounts'. I conceptualize JSX as 1 big nested effect, if your component removes itself from the JSX, it will 'unmount', if it adds itself back to the JSX, it will re-run the setup function aka 'mount', but otherwise it will never run again. A video that helped me a lot in getting an intuition for this auto-subscribing and -disposal is https://www.youtube.com/watch?v=J70HXl1KhWE
1. there are a lot of different strategies you could follow: the data could not be local, but global, so there is always a steady reference to the, independent of set-up functions. I don't know this 3rd party libraries, but mb something that could be of interest for you is https://www.solidjs.com/docs/latest#portal and https://www.solidjs.com/docs/latest#createroot
2. this is how I would do it: use a global store (with context or singletons https://www.youtube.com/watch?v=S-YZAJAd6hE ) and have the window-layout and the data as two separate properties of a store. Data is an object with ids as keys and the data as its value, the window-layout property is some data-structure where you define the columns/rows, and a reference to the id. Then you could either work with one of those 3rd party APIs depending on how they are implemented, or you render the window-layout out yourself with some LayOut-Components (flex-div with flex-direction: 'column' | 'row' and a For-Component).