replacer support

[maxence-charriere]

Hi @oderwat, made a PR here so we can discuss directly by pointing code.

Seems like the replacer interface is not usable in its current state. Sorry about that.

When reading the code, I was wondering if you could use func ()app.UI rather than a component pointer. The issue here is that the first component is mounted and overridden by the other at each update, which results in the loss of the "A" content.

[oderwat]

Well, this works for this example. But it recreates the component each time. The components we want to switch need to keep their state while being dismounted. We talked about this before as I created the mountpoint implementation. AFAIR you wrote that you are not sure if it works when mounting/dismounting the component without destroying it. But this is what we do all the time. Without that you had all the overhead of creating the state of a component on every single tab or page switch in our apps. The other solution would be to have everything in the DOM at all times, which could be a lot of nodes. Or to have the state not inside the component and "plug" it inside every time it is switched. I wonder if that makes sense.

Let's use an example: A component that lists thousands of rows of data of an external source using different filters. It shows a partial window off them that can be scrolled through with automatic loading and disposing of elements. This is inside a page/tab in the UI. You want to keep the position, the filter and the cache of the data. You also need to manage the backend connection (for example NATS consumers). This is all inside of the component and if you re-create it, you need to recreate all of this data. When using the mountpoint I can decide for each case if I want to dispose the data and handlers on dismount or if I want to keep the internal state till the next mount of this component.

One example I use to check for this possibility was creating a lot of pseudo pong games using canvas rendering and place them in different tabs. Some tabs get destroyed when switching (on dismount), others keep their internal data, some use "hidden" nodes and other use "absolute -1000 x" positioning to hide and show again. So if you now switch tabs, some games are continuing in the background, some pause and keep state and others restart in frame 1. IMHO, all four methods should be supported. If I needed to implement "your" variant, I would need a "save/load" implementation for the state, that then can be used on tab switching to recreate everything from scratch. This may also be possible, but I do not like that solution for something that can be much simpler being implemented by just keeping the component around.