3 ms·

It's a bit pain to update nested types in elm, that's why I've often ended up having data that can change as flat as possible. But that also means that a too bi

It's a bit pain to update nested types in elm, that's why I've often ended up having data that can change as flat as possible. But that also means that a too big a model is passed around between functions I guess, because it's annoying having to extract and pass the 3-4 values it needs. What would happen if the view functions in elm by default were lazy? Since everything in elm is immutable, and the functions can't have side effects, it shouldn't be able to break anything. I guess the problem is that this kind of memoization can be memory heavy? But it doesn't really have to memorize everything. Just the last inputs, and then do nothing with the DOM if the inputs are the same. And the inputs are all derived from the main model, which is only ever updated one place in the runtime. So just keep track of changes when that happens, and what functions that affect, hmm.

Kaze404 5y ago
> a too big a model is passed around between functions I guess, because it's annoying having to extract and pass the 3-4 values it needs You can always take an extensible record type instead of the entire model. type alias Model = { count : Int , prop : String} initialModel : Model initialModel = { count = 0 , prop = "" } foo : { a | prop: String } -> String foo model = model.prop bar = foo initialModel
yakshaving_jgt 5y ago
I've found lenses to be a reasonable way around this issue, so I'm not too uncomfortable with nesting records. If you're interested, I wrote a bit about that here[0]. [0]: https://jezenthomas.com/how-i-write-elm-applications/ https://jezenthomas.com/how-i-write-elm-applications/
_greim_ 5y ago
> What would happen if the view functions in elm by default were lazy? `lazy` incurs a performance penalty not in memory but in execution steps, due to having to do a deep-equality comparison on the prev/next view inputs in the underlying JS. Enabling such a check globally would, on balance, slow everything down. Only if the work of running the view exceeds that small penalty, would you want to use it strategically here and there, hence the reason it's opt-in. Even if the Records and Tuples proposal[1] lands and Elm gets refactored to use it internally, thus allowing `===` comparisons in the underlying JS instead of deep-equality, it's unclear whether enabling it globally would be good or bad, simply because the JS engine itself would presumably still be doing some kind of deep-equality check behind that innocuous-looking `===` operator. When the time comes I'll be curious to see if there's any progress on that front. [1] https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple
- Skinney 5y ago
  It’s a shallow comparison, not deep. But yes, there is both computational and memory overhead when using Html.Lazy
  - matsemann 5y ago
    But isn't there also that when not using lazy? Instead of checking model equality, elm runtime now has to check shadow dom equality and calculate dom operations to apply. My thought is that my idea isn't obviously worse.
    - Skinney 5y ago
      Yes, but lazy adds to that work. So for views that will pretty much always need to be re-rendered (because the only changes are at the bottom of the view hierarchy) then wrapping them in lazy will only slow down the dom recalculation.
  - _greim_ 5y ago
    > It’s a shallow comparison, not deep. Interesting. I thought it was doing a deep comparison, but apparently it uses reference equality, and thus shallow.

Kaze404 5y ago

> a too big a model is passed around between functions I guess, because it's annoying having to extract and pass the 3-4 values it needs You can always take an extensible record type instead of the entire model. type alias Model = { count : Int , prop : String} initialModel : Model initialModel = { count = 0 , prop = "" } foo : { a | prop: String } -> String foo model = model.prop bar = foo initialModel

yakshaving_jgt 5y ago

I've found lenses to be a reasonable way around this issue, so I'm not too uncomfortable with nesting records. If you're interested, I wrote a bit about that here[0]. [0]: https://jezenthomas.com/how-i-write-elm-applications/ https://jezenthomas.com/how-i-write-elm-applications/

_greim_ 5y ago

> What would happen if the view functions in elm by default were lazy? `lazy` incurs a performance penalty not in memory but in execution steps, due to having to do a deep-equality comparison on the prev/next view inputs in the underlying JS. Enabling such a check globally would, on balance, slow everything down. Only if the work of running the view exceeds that small penalty, would you want to use it strategically here and there, hence the reason it's opt-in. Even if the Records and Tuples proposal[1] lands and Elm gets refactored to use it internally, thus allowing `===` comparisons in the underlying JS instead of deep-equality, it's unclear whether enabling it globally would be good or bad, simply because the JS engine itself would presumably still be doing some kind of deep-equality check behind that innocuous-looking `===` operator. When the time comes I'll be curious to see if there's any progress on that front. [1] https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple

Skinney 5y ago
It’s a shallow comparison, not deep. But yes, there is both computational and memory overhead when using Html.Lazy
- matsemann 5y ago
  But isn't there also that when not using lazy? Instead of checking model equality, elm runtime now has to check shadow dom equality and calculate dom operations to apply. My thought is that my idea isn't obviously worse.
  - Skinney 5y ago
    Yes, but lazy adds to that work. So for views that will pretty much always need to be re-rendered (because the only changes are at the bottom of the view hierarchy) then wrapping them in lazy will only slow down the dom recalculation.
- _greim_ 5y ago
  > It’s a shallow comparison, not deep. Interesting. I thought it was doing a deep comparison, but apparently it uses reference equality, and thus shallow.