Preserve Component State Independent of Location

[yossicadaner]

BS"D

Is it possible to preserve a component's state even it gets moved to another listing of children?
Say I have

• Left Sidebar
  • Chat
    and I move Chat to Right Sidebar
• Right Sidebar
  • Chat

I know I could technically store and reload the state values, but it is possible to do this in another way, say by just providing a common key?

[spacejack]

@yossicadaner I don't believe you can, at least not without an undesirable amount of hackery.

You can preserve the component instance if it moves within a list of siblings (in an array, using keys) but I don't think you can if it moves arbitrarily across the dom tree.

I think your best bet is to externalize its state.

[pygy]

What you are trying to achieve is not supported. It could be achieved for a fixed version of Mithril, using a unholy amount of hackery, but any such hack could be broken by a Mithril point release that tweaks the diff/patch algo. So I wouldn't recommend it, at all.

As @spacejack suggested, you can achieve what you want by externalizing your state to a common object or stream.

const chatState = {
   log: [],
   currentDraft: "",
   cursorPosition: 0
}

const Chat = {
    view: () => m(".chat", 
        chatState.log.map(msg => m(".", msg.author, ": ", msg.text)),
        m("input", {
            oninput() {
                // save the current draft and cursor position
                // submit on "enter"
            },
            oncreate(vnode) {
                // set the cursor position
            }
     )
}

[orbitbot]

I've tried a simplistic version of moving components around in designated sections for a drag and drop implementation, but it ended up in a very weird state where the data layer indicating what should be drawn where was coherent but Mithril just didn't populate the dom properly and wouldn't correct itself. So wouldn't advise trying, really.

If maintaining the component state is really important for whatever reason, you could probably achieve the same with CSS changes while keeping the DOM tree more or less intact.

[yossicadaner]

It could be achieved for a fixed version of Mithril, using a unholy amount of hackery, but any such hack could be broken by a Mithril point release that tweaks the diff/patch algo. So I wouldn't recommend it, at all.

Possibly there are simpler methods of doing this. For example, if mithril provided control over initializing the .dom attribute/ the dom node or from an existing 'vnode'?

[pygy]

In order to do that, we'd have to provide expose the nextSibling (and optionally the parent node, but that can be obtained from client code already by passing it as an attr)...

It may be something we'll do at some point (rather than domSize), in order to get rid of fragments (DOM fragments, used under the hood, not m.fragment() vnodes).

I don't want to commit to it though, or to ensuring that patterns that rely on it keep on working when we update the diff code.

[leeoniya]

some food for thought...

domvm achieves this by offering imperative component instantiation via createView() and allowing these component instances to be injected into any other domvm tree via injectView() vnodes. this way it does not have to track keys globally.

https://jsfiddle.net/phtd6vqb/

[pygy]

@leeoniya That's neat! I'll have to dig into domvm at some point.

I've tried to have it move back and forth between the "left" and "right" panes, and it starts in the top one, then blinks below... Am I doing something wrong?

https://jsfiddle.net/dvkm3qzm/

[leeoniya]

heh, no it should work, time to dig! :D

[leeoniya]

fixed!

[barneycarroll]

Mithril Machine Tools has a mechanism for this via the Mobile > Unit composite component. The Mobile component has a view which exposes the Unit component: Unit components identified with the same key attribute can be rendered anywhere within their Mobile context and retain state and DOM.

Here's an example of the 'mobile' chat box.