Consider exposing snabbdom lifecycle hooks

[grzegorz-bielski]

Having an access to some hooks would make it easier to integrate with outside systems and third-party code - like rendering React/Preact/X components inside Tyrian.

I'm not sure about the API, but probably sth like this would be fine:

div(onCreate(Msg.YourMsgToHandle))

[davesmith00000]

Just digging into this a bit... no conclusions just making notes (and I'm conscious that I'm doing this while slightly tired and may be talking nonsense!).

The first observation is that I think I was wrong about the original Scalm implementation of hooks. I'd leapt to the conclusion that it was exposing the Snabbdom hooks system, but that doesn't actually appear to be the case. I think what it did was to allow you to include entire arbitrary Snabbdom html. A link for the curious:

https://github.com/julienrf/scalm/blob/ff1789ba493d6a4c58c8980af0e72c8df5d20ace/src/main/scala/scalm/Html.scala#L30

My feeling is that bringing this back would not be enough, the reason is that the main use case seems to be the desire to detect node creation for loading in React components and such. So one could actually expose Snabbdom on purpose to allow people to take advantage of everything Snabbdom can do, hooks n' all. It's the shortest route to market but crucially it wouldn't tie into the Tyrian message loop. So by some funky callback process you could maybe inform a Sub that something had happened, but it wouldn't be a nice integrated experience of the kind expressed in the original issue description.

Assuming we don't want that then, the next approach is to expose our own hooks api underpinned by some of the Snabbdom implementation. Snabbdom exposes a lot of hooks:

https://github.com/snabbdom/snabbdom#overview

Which ones do we really care about as web app builders?

1. Things like pre for example feel like the kind of thing a library author building on top of Snabbdom might be interested in but maybe not a web app builder? Just a guess.
2. destroy and remove look useful, do our end users need the distinction?
3. create and insert similarly seem useful, here the distinction seems worth while?
4. update (or maybe postpatch?) feels like the only other useful one in a "tell me if someone messed with my node" kind of way?

(I'm not convinced I understand the Snabbdom hook descriptions entirely yet. I'll need to have a play with them.)

Then if we decide to go ahead, we get on to how to make them available. I feel like hooks are an advanced feature and I'd rather people didn't create them by accident because they looked like attributes - but maybe I'm overthinking this...? I'm wondering about something like this:

div(id := "abc123")(
  p("Hello!").withHooks(
    onCreate(Msg.Created),
    onRemove(Msg.Removed)
  )
)

Or at first glance I kinda prefer this...

div(id := "abc123")(
  Watch(onCreate(Msg.Created), onRemove(Msg.Removed)) {
    p("Hello!")
  }
)

(Note: I have not checked to see if these are possible. They are entirely made up!)

Thoughts welcome.