This will work fine, but has some important drawbacks, namely:
The built in debugger won’t work very well, since functions can’t be serialized. As such it is recommended to only have data (i.e. not functions) in msgs or models.
You are mixing business logic and view logic together. This tends to lead to messy code. The recommended way essentially follows the MVC pattern pretty strictly, which is a pattern that works well for most apps.
Msg types should not contain functions. This is possible with 0.18 but I would not be surprised to see it become invalid in future releases.
You can still use this pattern by simply updating the model in the view and sending the new model with the Upd
type Msg = Upd Model
update msg model =
case msg of
Upd newModel -> newModel
view model =
div []
[ button [ onClick (Upd (model-1)) ] [ text "-" ]
, div [] [ text (toString model) ]
, button [ onClick (Upd (model+1)) ] [ text "+" ]
]
If updating it like this is too expensive, consider switching strategies.
In more or less complicated apps the model changing functions are long and can’t be inlined. View function will just turn into mess. I can’t see a single benefit of this approach. Having drawbacks @gampleman mentioned in mind I would say this is definitely an anti-pattern.
@pdamoc I can’t find an example of this approach in elm-sortable-table. Were you referring to the latest version?
Yes, it is in the latest version but the code is not as explicit as I made it to be. You have to investigate how the State changes based on events in the widget (sorting) in order to figure it out.