> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
