State filtering idea

[OvermindDL1]

I do say that I wish there were some way to make some 'update' call as no-view and/or no-subscription re-call needed. Like instead of returning ( model, Cmd.none ) we could do ( model, Cmd.cancelView ) or ( model, Cmd.cancelSubscription ) or both via Cmd.batch, or perhaps as a three-argument tuple that defaults to ( model, Cmd.none, StateChanges.none ) or so, which would default to calling everything. I have a lot of update messages that are handled that do not change the view and/or subscriptions and it would be nice to prevent calling those somehow. Hmm, actually a backward compatible change would be to add a new Program callback, in addition to the usual init, update, subscriptions, and view, add another one that I will call just blah for now, optional in the Program or so, but have it be like:

blah : Msg -> ( Msg, States )
blah msg ->
  case msg of
    MyMessageThree _ -> ( msg, States.batch [ States.cancelView, States.cancelSubscriptions )
    MyMessageNine arg0 _ -> ( MyMessageThree arg0, States.noChanges ) -- or `States.none`?
    MyRedrawMessage -> ( msg, States.cancelView )
    MyMessageTwelve _ -> ( msg, States.onlyUpdate )
    _ -> ( msg, States.noChanges )

And it would be called after init and before every call of update. It would allow an easy way to translate one message type into another (maybe even a way to decorate it more so it can get passed to another modules update/subscription, this would be a great hooking location for modules), as well as a way to specify what states should be updated for a given message, a default no-op function could be supplied via States.defaultHandle or so that you could pass to the program so people do not have to override it in the easy cases.

Hmm, an idea for a module handler, one of the states could be something like:

    MaterialMessage msg -> ( msg, States.delegate { update=Material.update, subscriptions=Material.subscriptions } )

Which of course the other module could simplify via a helper to:

    MaterialMessage msg -> Material.blah msg

Looking at https://github.com/elm-lang/core/blob/4.0.4/src/Native/Platform.js shows that it would be easy to add that functionality to core.

So ideas about this style, issues, etc...?

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[evancz]

If your view is not changing, I'd recommend using Html.Lazy.lazy. If your view really is the same, you will do a handful of checks before you do no work. In the end, this is quite a small cost.

If you are in some special scenario where the cost becomes noticeable, it makes sense to explain your scenario fully, not look for solutions immediately. Gotta understand the problem first.

I'd recommend talking this through on community forums though. Like on Slack or elm-discuss.

[evancz]

If your view is not changing, I'd recommend using Html.Lazy.lazy. If your view really is the same, you will do a handful of checks before you do no work. In the end, this is quite a small cost.

If you are in some special scenario where the cost becomes noticeable, it makes sense to explain your scenario fully, not look for solutions immediately. Gotta understand the problem first.

I'd recommend talking this through on community forums though. Like on Slack or elm-discuss.