It basically lets you supply a record of components (and their output adapters) and a variant that contains the data for the particular page (the slot and input to the component) and creates the H.slot invocation for you.
If this is interesting to you, feel free to let me know, and let me know if you need more functionality
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.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.
I’m starting work soon on some dynamic layouts in our application in which a user has designated areas of the UI they can customize to different types – for example, they might be able to display a dropdown, or a typeahead, or a date picker, or whatever. That region determines which component ought to display (if any), and is responsible for managing the outputs of any child components and handling them properly. This seems like an ideal use case for this component!
Take an analytics application that allows you to create different “tiles” where each tile visualizes data in chart or table format and various chart types are available. Each one might be a different component, but the tile is responsible for managing which chart or table displays along with any user interactions (like clicking to change the chart type). In this case, you’d create a record of possible components and an associated variant; each tile would be a copy of your component given the same possible components + variant.
Regarding your questions over PM, I would say that the key thing that instantiates and establishes identity for the components, is the p type, the slot index. So if you drag tiles around, just keep the p value the same, and the component should swap around just fine.
I wonder if I can make it handle (arbitrarily) nested pages … I think the only issue would be focusing on child slots, so that probably requires something like the child path machinery. I guess it requires a second class. </musing>