[elm-discuss] Why is the signature of 'program.subs' 'model -> Sub msg' ?

[John Bugner]

The signature of program.subs (from
http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Platform ) is:
'model -> Sub msg'.

Why isn't it just 'Sub msg' ? What's the point of including the model in
there? Sure, it lets you control what subscriptions you listen too
depending on the current model, but what's the benefit of that? Is it wise
to rely on this function to control what messages you receive? The update
function still has to have a case for every message no matter the state,
after all. Is there some performance improvement from using this that I'm
not aware of?

[art yerkes]

Updates take CPU time, heat up your user's laptop, reinvigorate cold
memory, often when your user is trying to use their computer for other
things. If running some code won't be useful, you should avoid running
it. It also saves the environment just a tiny amount.

Post by John Bugner
The signature of program.subs (from
'model -> Sub msg'.
Why isn't it just 'Sub msg' ? What's the point of including the model in
there? Sure, it lets you control what subscriptions you listen too
depending on the current model, but what's the benefit of that? Is it wise
to rely on this function to control what messages you receive? The update
function still has to have a case for every message no matter the state,
after all. Is there some performance improvement from using this that I'm
not aware of?

[Marek Fajkus]

Sometimes you don't need subscriptions if you're in some state. For
instance, if you have game and subscription to say mouse position you can
subscribe to Mouse.position only when a user is in play state and avoid
subscription in game menu.

[Aaron VonderHaar]

Another example is a package like WebSocket, where the package will open a
network connection while you are subscribed and close it when you stop
subscribing.

On Jul 17, 2017 7:19 AM, "Marek Fajkus" <***@gmail.com> wrote:

Sometimes you don't need subscriptions if you're in some state. For
instance, if you have game and subscription to say mouse position you can
subscribe to Mouse.position only when a user is in play state and avoid
subscription in game menu.
--
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 elm-discuss+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Bugner]

Post by Marek Fajkus
Sometimes you don't need subscriptions if you're in some state. For
instance, if you have game and subscription to say mouse position you can
subscribe to Mouse.position only when a user is in play state and avoid
subscription in game menu.

Because the game menu would only need to detect clicks and not positions?
and/or would be made out of HTML with buttons that have an attached
'onClick' event. (Thus freeing you from needing to subscribe to even
'Mouse.clicks', right?)

Post by Marek Fajkus
Updates take CPU time, heat up your user's laptop, reinvigorate cold
memory, often when your user is trying to use their computer for other
things. If running some code won't be useful, you should avoid running
it. It also saves the environment just a tiny amount.

Ah, okay, so there is a performance advantage.

Post by Marek Fajkus
Another example is a package like WebSocket, where the package will open a
network connection while you are subscribed and close it when you stop
subscribing.

Interesting.

[Vasily Vasilkov]

Does it mean that Elm runtime creates and cancels subscriptions on the fly (for  every model change)?






On Mon, Jul 17, 2017 at 6:19 PM +0400, "Marek Fajkus" <***@gmail.com> wrote:










Sometimes you don't need subscriptions if you're in some state. For instance, if you have game and subscription to say mouse position you can subscribe to Mouse.position only when a user is in play state and avoid subscription in game menu.
--
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 elm-discuss+***@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark Hamburg]

My understanding is that yes, Elm does this with every update and then the
effects managers have to look at the new subscriptions and compare them to
the old subscriptions. I would love to hear that my understanding is wrong
because while this isn't bad if you have just a few subscriptions, it seems
like potentially a lot of overhead if you have a lot of subscriptions.

One could envision subscriptions being implemented more like views in which
there would be a differ that would generate patches to send to the effects
managers and there would be a subscription equivalent to Html.Lazy that
would cut off a lot of the computation when nothing had changed. This would
probably make frequent update to subscriptions less scary computationally
but it isn't how things are done.

Finally, you haven't asked the other subtle question brought on by dynamic
subscriptions: if you stop returning a subscription, are you guaranteed
that you won't receive any messages targeted to that subscription or are
you only guaranteeing that no more messages will be queued or even weaker
are you only letting the effects manager know that you aren't really
interested any more?

Mark

Post by Vasily Vasilkov
Does it mean that Elm runtime creates and cancels subscriptions on the fly
(for every model change)?
Sometimes you don't need subscriptions if you're in some state. For

Post by Marek Fajkus
instance, if you have game and subscription to say mouse position you can
subscribe to Mouse.position only when a user is in play state and avoid
subscription in game menu.
--
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
For more options, visit https://groups.google.com/d/optout.

--
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
For more options, visit https://groups.google.com/d/optout.