That is precisely how some of it is done (written more recently), the part
I showed above was one of the first bits written back when everyone was
saying "make model and msg flat!", I do not do that anymore and do need to
refactor, but it does bug me how people keep saying to make everything fla
OvermindDL why not refactor out that part of update as another function? With
24 and 8 actions per logical system it definitely seems like a separate update
(& maybe model) would benefit the maintainability.
Also why not keep the action constructors separate? (Room Joined) You can case
on them
Hold on folks. All of this is motivated by wanting to be able to change a text
box for a slider, yes? You want an interface, not a component.
The Msg type should include a SetSpeed Float tag. The view should have the
input send this Msg. The view can also expect to use the current speed in
cons
I would still like to find a good way to structure messages. I'm up to 146
in the base Msg type, and it is not flat, by counting it seems that I have
6 message types that just hold another message type for something further
down, which average in size from 2 for 1 of them, 4 for 3 of them, 8 fo
As far as Msgs go, why not just flatten it since it's, as you say, a simple
app?
type Msg
= NoOp
| Component1Msg
| Component2Msg
We decided to go down that route on our project and we currently have 10
Msgs, and it will likely grow to be a few dozen. Unless there's a really
good
Perhaps the idiomatic way is just forwarding, as in this from
https://medium.com/@_rchaves_/structured-todomvc-example-with-elm-a68d87cd38da#.prhqa9c5n
type Msg
= NoOp
| MsgForComponent1 Component1.Msg
| MsgForComponent2 Component2.Msg
--
You received this message because you are s
I’m having trouble understanding the right structure for a relatively simple
app. I’m thinking of this in actor-ish terms, which is probably wrong.
There’s a Main model that has the state of an animation. One part is the
animation's speed. At times, the user will want to change that speed.
At
