The Elm Architecture (TEA) is conceptually very nice, but it forces us to write large amounts of boilerplate whenever we need to use a component. We must:
None of these things have anything to do with what we want from the component, namely rendering it in our View function, and potentially reacting to some (but not all) of its actions---e.g., we want to react to a Click of a button, but we don't care when it updates its animation state.
This module provides an extensible mechanism for lifting arbitrary
(differently-typed) TEA components into components having the same type of Model
and Action, all of which can be dispatched by the single
update function in
this module. We call such a lifted component a "part" (think "interchangeable
Elm-parts moves work from component consumers to component authors. As a component author, you have to produce some elm-parts boilerplate. Producing this boilerplate is prone to sometimes difficult-to-debug type errors.
Elm-parts relies on sending functions in messages, in violation of the recent guidelines. This means consumers of components trying to debug parts messages with the idiomatic
update msg model = case Debug.log "update" msg of ...
will see an unhelpful
Msg <function> rather than the actual
Msg being sent.
Modelof your component or send messages to its
updatefunction, you'll need to write additional boilerplate for the component, exacerbating (1) above.
One appropriate use-case for elm-parts, where you can accept these drawbacks, is when writing a UI-component library. (Incidentally, its the only such use-case I know of.) As a library author, (1) you should be willing to take upon yourself the tediousness of (1) for your users. (2) Your users shouldn't care about your internal messages anyway. And (3) UI-components generally, but not always, can be written such that they are configured exclusively through view (3)---again, see sortable table.
Elm-parts was developed and is in active use as a supporting library for elm-mdl.
60a61 > , Counter.render CounterMsg  model
That is, additional instances of a single component require changes only where you
render them, in your