Looking at my update code again, I see how I could further reduce the number of cases by combining two of the SetCountry cases as a default with careful sorting of the cases. That gain in brevity doesn't seem worth the increase in sensitivity to how exactly the code is written.
It might be worthwhile, however, to note that the "illegal" case is really just SetCity together with NotChosen. If there are further illegal cases in the future, they can all be piped through a utility to log them (or simply ignore them). Mark > On Dec 21, 2016, at 8:26 AM, Mark Hamburg <[email protected]> wrote: > > Per your Medium post and the search for Elm "patterns", let me suggest casing > on tuples. This is useful in update functions for state machines but it is > also useful in this case. I also broke things apart into slightly smaller > functions to keep them simpler. > > type Destination > = NotChosen > | ToCountry Country > | ToCity Country City > > > type alias Model = > { destination : Destination } > > > type Msg > = SetCountry Country > | SetCity City > > > updateDestination : Msg -> Destination -> Destination > updateDestination msg oldDestination = > case ( msg, oldDestination ) of > ( SetCountry newCountry, NotChosen ) -> > ToCountry newCountry > > ( SetCountry newCountry, ToCountry oldCountry ) -> > ToCountry newCountry > > ( SetCountry newCountry, ToCity oldCountry oldCity ) -> > if oldCountry == newCountry then > oldDestination > else > ToCountry newCountry > > ( SetCity newCity, ToCountry oldCountry ) -> > ToCity oldCountry newCity > > ( SetCity newCity, ToCity oldCountry oldCity ) -> > ToCity oldCountry newCity > > ( _, _ ) -> > Debug.log "Illegal message for destination (ignoring)" (msg, > oldDestination) > |> (always oldDestination) > > > update : Msg -> Model -> Model > update msg model = > { model > | destination = model.destination |> updateDestination msg > } > > The chief reason to keep the logic out of the view is that it's probably > easier to test the model by itself than via the view. > > I would probably be tempted to put destination into its own module and make > the representation private. This module could then be subjected to various > external tests with property testing confirming things like: we can't have a > city without a country; we can always set the country; and, if we have a > country, we can always set the city. Only the first of these follows from the > data structure itself. The rest are assertions about the update logic. > > Mark > >> On Tue, Dec 13, 2016 at 8:14 AM, Wouter In t Velt <[email protected]> >> wrote: >> Op zondag 11 december 2016 20:01:09 UTC+1 schreef Brian Marick: >>> Since FP has been around for a long time, too, I’m hoping that those idioms >>> and patterns have been written down, with a good effort toward explaining >>> them (with examples!) Where? >> >> As it happens, I just wrote a post on this topic over on Medium: >> https://medium.com/@wintvelt/how-to-make-impossible-states-impossible-c12a07e907b5 >> >> It is more of an experiment with different directions. It would be >> interesting if there were more extensive patterns around from people with >> more of an FP background.. >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
