>
> If all commands were treated equally, abstracting away these optimizations
> would not be possible.
>
Got it. The virtual DOM diffing makes sense that this is a special case.
A slight tangent to this post, I would assume that this pattern (using a
separate construct for the purposes of
>
>
>- Any html returned from the app are descriptions of side effects to
>the DOM specifically and Elm takes care of that as well
>
> As Laszlo says, this is incorrect, at least conceptually. *Html Msg* means
a description of HTML, independent of any existing HTML, whose events
Actually, Html is a very special case. Rendering the same Html multiple
times will give the same result and not cause any visible side effects
(even though it is it DOM manipulations underneath).
This is similar to how the browser distinguishes between GET and POST
requests. It allows the browser
I don't fully understand your explanation but that is in part due to my
ignorance of the underlying implementation of both Cmd and Html.
Let's see if we can discuss at a more conceptual level. Here is a snippet
from the Elm examples page:
getRandomGif : String -> Cmd Msg
getRandomGif topic =
Sure, you can imagine turning a Html Msg into a Cmd Msg but if you do that
you lose the information that makes it a Html Msg.
If the children of a div could be any Cmd Msg, you could put an Http
request there and it would type check but what would that mean?
You can look at it like you would
I can speculate as to why DOM side effects are different than all other
side effects. But when explaining the Elm architecture to a friend I
explained it like this:
- Elm apps take in a model and a Msg as inputs and run those two inputs
through an update function
- The update function
