This is interesting!
If I’m understanding properly, you have a record of tuples, where each tuple holds a component + a function to convert that component’s Message type into the relevant handler (parent’s Query) type. That makes it possible for the parent to mount the component in the slot and attach it to the right handler. Ultimately this produces a render function compatible with the parent component (the result of mounting the slot), so ultimately you could have the parent do something like:
render st =
HH.div_
[ HH.text "Some content"
, HH.text "some other content"
, renderPage st.pager.components st.pager.variant
, HH.text "maybe a footer?"
]
I’m assuming you’d also have some HTML controlling say a list of buttons where each button will trigger a variant update to a given page (1, 2, 3 <- clicking ‘1’ will change the pager variant to be the first page).
Some other thoughts: it appears that this record of components doesn’t care what those components’ query algebras are, just whether their output can be attached to a proper handler. So you could have a pager with wildly different components inside. That’s pretty powerful! It’d be nice to see an example in action.
Might be interesting to implement a Formless add-on for making form wizards and the like with this class involved; the component could help you page through and unify information flowing through the various sub-forms on different pages.
We have a few places in our application where we’re handling the paging problem by defining a new data type for locations (data ThisLocation = Page 1 | Page 2) and then casing on it in our render code (case location of Page 1 -> HH.slot ...). It works fine for say 2 pages at a time, but I could see a larger number benefitting from your solution.
Do you have other use cases in mind?
