What is the idiomatic way of getting a Surface's dom exit point?

[culyun]

Mithriljs uses the same notion of dom mounting as a Samsara context, ie. it needs a dom node to render into. As it turns out it's very easy to use Mithriljs with Samsara. You just mount your Mithriljs object at a Surface exit point to the dom.

But I'd like to know the idiomatic way of getting a Surface's dom element.

[dmvaldman]

A Surface's DOM node is in its surface._currentTarget. The reason for the cryptic nature is that a surface can inject its content into a different DOM node. For instance if you remove a surface (the removal API is being worked on currently) and then add it back, it may use a different DOM node the second time. A surface will emit a deploy and recall event with the current DOM node that you can listen to.

surface.on('deploy', function(target){
   // target is the current DOM node the Surface has injected its content/styles/attributes into
});

[culyun]

Thanks David, I'll have a good look at this soonish.

Apologies up front, my head-space tends to be a bit "sparky" (ie. I think out loud). But I reserve the right to be opinionated and I reserve the right to eat humble-pie :-)

Anyway, I did have a few "yeah but" moments when you mentioned the removal api. Do you intend to hold a reference to the removed DOM node? For caching purposes?? How expensive is document.createElement in a time sensitive environment?? Have you talked to the browser devs??

Sorry these are all gumptions and brain-farts, I just can't help myself but ask..

[dmvaldman]

The use-case to keep in mind is a scrollview. You may have hundreds of items you can scroll through, but only a handful are on the screen at once. The way the removal API would work is to only have that handful of <div>s in the DOM, and the content of surfaces injected into them as they are needed.

You could completely remove the DOM node, and create a new one, as you mention, but that doesn't change the fact that the DOM node will be different the second time around. The same is true for React. A React component maps to some DOM tree, but the association is not tightly coupled, elements don't map to the same DOM node every time.

[culyun]

I like what I'm hearing! Look forward to seeing this pan out.