A capability typeclass for making HTML components?

[armanbilge]

So we don't have to pass Async everywhere 🤔

[armanbilge]

The Async constraint is largely driven by the switching between F[_] and Rx[F, _] I believe (specifically the evalOn?). That seems harder to make go away.

[armanbilge]

As of #18, I think what is currently Dsl[F] can become a capability typeclass, that along with Concurrent should be more than enough to make interesting interactive components.

[armanbilge]

This is actually really hard, not necessarily technically, but in terms of sheer amount of work.

Any interaction with the raw DOM will need Sync (at least). So unless/until all of that is wrapped up nicely in pure APIs, users will still be reaching for Sync anyway.

[armanbilge]

So unless/until all of that is wrapped up nicely in pure APIs, users will still be reaching for Sync anyway.

It's still crazy ambitious, but fs2-dom is where this might happen.
https://github.com/armanbilge/fs2-dom/

The Smart:tm: thing to do would be to whip up a custom blend of ScalablyTyped that does this wrapping automatically. See scala-js/scala-js-dom#487 (reply in thread).

[armanbilge]

So unless/until all of that is wrapped up nicely in pure APIs, users will still be reaching for Sync anyway.

Another note about this. If we indeed go the wrapper route with something like

class HtmlElement[F[_]](raw: dom.HTMLElement)(using F: Async[F])

That means that every node in our DOM tree will need another allocation. I am not really sure if that's a good idea.

OTOH if we wrapped everything in IO we could avoid the allocation via an opaque type. It would not help with the typeclass / tagless final route, but an IO-based API is still better than an unsafe one. Something to think about.

---

The redesign work I'm doing for 0.2 will close this specific issue, but the wrapper issue persists.

[armanbilge]

Actually, I guess we could do it via ops typeclasses 🤔