> 2. Figure out a state diagram describing the behavior of your UI. I find this
> is tending to align very well with one state for each element of the UI that
> can change. For example, something shown or hidden, or something shown in one
> state or another. Turn the state diagram into a Type - the sum.
Thank you very much. Let me see if I understand you right in my context. The
attached is the interface to a list of animals.
The first animal is in the Compact state, the second in Expanded, and the last
in Editable. Would you be suggesting a `Mode` like the following?
type Mode
= Compact Animal
| Expanded Animal
| Editable Animal FormData
I had problems with that. I too often had view code that had to know both that
it was given `FormData` and also had to take the whole `Mode` as an argument -
or had to assemble a Mode from the pieces they were given. (Unfortunately the
details are fuzzy in my memory.)
(Though now that I write, maybe it’s that I made a fundamental mistake. I
leaned toward messages containing, as their “payload”, an entire structure
rather than just some id (of an animal) and the data that changed. For example,
if you delete a tag (click on the X in “aggressive”, for example), the Msg that
gets sent is:
onDelete name = WithForm form (DeleteTag name)
https://github.com/marick/eecrit/blob/master/web/elm/Animals/View/Form.elm#L79
Maybe that decision is making it too hard to separate out the small relevant
pieces - because, for example, it pushes me to cases where code might need all
of the `Mode`, the `Animal`, and the `FormData`.
Eek. Big change, if so.)
Hmm. Given that one part of the product will be editing procedure documents as
Markdown, I should advance that feature, make it a separate app, and steal your
outline.
--
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
