I got a little intrigued by the idea of combine ‘programs’ in some meaningful way in Elm.
Suggests that TEA is similar to a comonad. It also suggests that comonad user interfaces would be able to be combined together, such as display 2 at the same time. Well that doesn’t sounds completely useful, but I realize this is just an exploration of ideas, of academic interest.
I don’t know what a comonad is, so I thought I would find out. This slide deck was pretty helpful:
Intuitively its described as a side-effectual computation where a value is extracted in some context. Like the side effects of users selecting actions, updating a model, then displaying a new view in the context of the model. So yeah, it looks more comonadic to me than monadic.
I do use the nested TEA pattern. Yes, I know we try to avoid it and there is too much boilerplate and we don’t like components here, and its better to extract functions on the view or update before having to resort to it. One thing I find pushes me in that direction is animation state - I don’t want the consumer of my piece of UI to have to manage that, so it tends to end up as a stateful thing, like a component, whenever there is animation (another good reason to have not too much animation). Sounds terrible, but I am glad to see that Richards best-practice SPA does it too: https://github.com/rtfeldman/elm-spa-example/blob/master/src/Main.elm#L226
So I am thinking comonads are great when you have higher levels of polymorphism than Elm, by which I mean Haskell. And you can write clever functions that work with them to do clever stuff. But TEA is a concrete thing, so it does not need to be exactly a comonad, although its good to get my head around this stuff.
What useful ways can I combine multiple TEA structured programs together? The obvious one is the parent-child structure. So I am thinking, is there some set of ‘combinators’ that helps me build a nested TEA and takes care of the boilerplate aspect of it?