Sorry, I made a keyboard error as I was typing and posted that before I was 
ready! Continuing with worries about matching Commands in Init to 
subscriptions:

- For quickly-changing subscriptions (like Time.every second), I can leave 
out the Command and the app will mostly work, but feel (and in fact, be) 
buggy
- For slowly-changing subscriptions, I can lave out subscriptions 
(especially if I have to set up a bunch of parent components to forward it) 
and just use the command, which will again mostly work, but be buggy and 
get out of sync.

I'm not coming at this from any kind of FRP background, so I did some 
reading last night to see how this is handled with streaming libraries, and 
I learned that Bacon.js has two distinct kinds of observables: EventStream 
and property 
<http://baconjs.github.io/api.html#eventstream-and-property-semantics>, 
where `property` has a concept of a "current value" like most subscriptions 
I'm interested in Elm seem to have. Bacon.js properties immediately call 
new subscribers with this current value at the time they subscribe. 
`EventStream` is like keyboard presses, that don't have a current value, so 
they only call subscribers when their event occurs.

So I'm wondering how to cleanly handle these two kinds of subscriptions in 
Elm. Any help, advice, or discussion would be seriously appreciated :)

On Saturday, June 18, 2016 at 1:45:42 PM UTC-4, phil wrote:
>
> Hello,
>
> I'm looking for help understanding how subscriptions are supposed to be 
> used, and how to solve different problems with them. My questions boil down 
> to: how do Elm subscriptions handle changing values?
>
> The clock example in the guide and at elm-lang.org/examples/clock has a 
> bug: the second hand is in the wrong position during the first second that 
> the program runs. You can see it easily right after you refresh the 
> examples page.
>
> There is a concept of the "current time" when subscribing to Time.every, 
> but that subscription (and subscriptions in general?) only generates 
> messages when that value changes. It's only wrong for a second in the clock 
> example, but if you change it to show only minutes, you're in a wrong state 
> for an entire minute after the program starts.
>
> I can fix the clock example by adding a Command to `init` to ask for the 
> current time when things start up, and I can do this in general for 
> subscriptions to time-varying values that need to be available for the 
> component's lifetime. Is that the recommended way of dealing with this?
>
> I'm worried about that solution because:
>
> - I have to set up matching commands for most subscriptions. For 
> subscriptions that are more complicated (say graphQL queries), this means 
> either duplication, or moving the query out away from the `subscripitonto 
> be shared.
>
>
>

-- 
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.

Reply via email to