Thanks for pointing this out, Eric!
To be able to compare the different versions, I figured it would be better to keep all versions “extraction-free”. But it is kind of an omission in the article, so thanks for pointing this out.
You are absolutely right that extractions will improve the code. They make the top-level
update more compact and readable, like you demonstrate.
Another benefit is that these extracted functions also make testing easier.
The same benefits would hold for version 4 (where the logic moves to the
view function). View functions are generally more cumbersome to test properly (although there is a package for that now), so extraction would improve testability even more in that variant.
The danger of version 4 (which would be somewhat obscured by extraction), is that you would essentially be making a (not recommendable) micro-update in the view before passing the message out:
- The user selects a city from the dropdown.
view(or view helper) then uses that selection + bits of info from the model to construct a new destination.
- And passes that on to the runtime, which passes it on to call the main
I usually make my messages from the view function as minimal and bare as possible. It is the view function’s job to pass on the user interaction (and no more). It is the update’s job (and its helpers) to figure out if and how the model should change.
In any case, both variants will benefit from code extractions into separate functions, so thanks again!