mhtml-onmount fires after attaching to the main document dom

[fizzy33]

Currently onmount fires after the children have been built but before the parent has been attached to the dom. onmount should fire after the parent has been attached.

Various tools (like jquery plugins) rely on being attached to the document dom. This will make integrating with jquery much simpler.

I would suggest the scaladoc be updated to reflect this. Time permitting I will provide a pull request with this change and the scaladoc update.

As a temporary workaround use

Future[Unit] {
  // run code assuming we are attached here
}

This works since it fires in a later event loop cycle and hence after the attach happens.

[OlivierBlanvillain]

@fizzy33 thanks for bringing up the issue! As I've said on gitter, I totally agree these callback should only be called after everything is actually mounted to the dom.

For performance reasons, you might also want to do things before node are mounted, to prevent a repaint. But let's keep things minimal until someone comes with a proper use case. Also, it seems that react folks are thinking about removing their componentWillMount callback, so it might be a good idea no to had that too quickly.

Fixing this issue properly might require non-trivial refactoring. These are the options I'm currently seeing:

• Internalize the Future hack, but that might surprising consequences like other Futures being resolved in between the mount and the on-mount callbacks...

• Refactor the entire mounting recursion to return a tuple of Cancelable + onMountCallBacks: () => Unit. All the Tuple2 allocation are probably going to slow things down quite a bit...

• Use a global mutable list of callback (it hurts just writing down the bullet point :P).

[fizzy33]

Implicit in your statement but worth noting explicitly that this is performance critical code hence even the consideration of the third bullet point.

Throwing a fourth option out there. What about attaching the onmount to the dom element and then using a query selector to call them all after mount?

[OlivierBlanvillain]

How would you keep track of the list query selection to use for calls after mount? I think that would still be point 2/3 above...

[fizzy33]

Add a data-mhtml-onmount attribute which is the actual function to call. Then later after it is attached to the dom do a

document.querySelectorAll("[data-mhtml-onmount]")

To get and call all the callbacks.

So a philosophical question does mutation count if the browser is doing it for you?

[OlivierBlanvillain]

I see, nice idea, that's indeed a 4th option! It does affect the dom itself, that might not be desirable...

[fizzy33]

Agreed on affecting the dom. For me if I have

<div
  mhtml-onmount = { () => console.log("mounted") }
></div>

It isn't completely surprising for me to see that on the in browser dom element.

What about removing it once it was run (noting I feel dirty even typing this sentence).

[OlivierBlanvillain]

Something like this:?

• Mount all elements with a mhtml-onmount attribute with a reference to the callback
• After mount, query for $("#mhtml-onmount")
• Run the callback on each of these
• Remove all the mhtml-onmount attributes

Querying over the entire page for a class and iteratively mutating the dom might have a cost that the global mutable list doesn't have...

[fizzy33]

Yes with the refinement to query from the mounted element will give better performance.