I was wondering about the Html type today. Do we have a compelling use case for the
Html a as opposed to
List (Html a)? In which cases do we really care that our argument is a single DOM node?
The reason to ask the question is because if we generally don’t care, the
html library (or a wrapper?) can define its
Html type to always represent a list of DOM nodes. The benefit is that can simplify types, that you don’t have to pick and that you certainly don’t need meaningless wrapper
I’ve done a bit of research. The
http library only has
Html a in argument position on one function, which is
map. Judging from that, such a refactoring seems feasible. At least two other areas remain: low-level details and HTML semantics.
I don’t really expect performance to change that much, because
html is dealing with a lot of lists anyway. However, I don’t know how it’s implemented, so I really can’t judge this.
Regarding HTML semantics, at first I thought
html has to be by itself, but is that really a requirement? For the DOM API it is, so probably it does make sense to have it as a low level type at least.
Browser has the
element function which takes an
Html a so that’s a use case. (what happens if I insert a text node in
So my question is, which APIs or even elements did I miss? Do you want to enforce single DOM nodes in certain cases?
Update: naming idea:
Node for DOM nodes and
Html for multiple
Nodes. Consider it a mass noun.
- it makes the type signatures align with expectations from other APIs (thanks @pdamoc)