> > 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 diffing desired state with current state) is a pattern for future capabilities, such as updating local storage. For example, it's conceivable that rather than local storage being mutated with Cmds or Ports, instead there could a LocalStg construct that represents what should currently be persisted in local storage. And Elm could do a diff and derive mutations to make the current state match the desired state. I wonder if that were the case if there'd be a special function for local storage that takes a Model and returns a LocalStg, similar to how there's a special view function that takes a Model and returns an Html Msg. Just food for thought. -- 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.
