A subscription is something that sends messages into the update loop based on some event management logic that it incorporates. For example, Time.every will send message every second. The first message sent is after the first time period that you give it. So, Time.every (5*second) Tick will send the first message after the 5 seconds have passed and every 5 seconds after that.
If you need to start in a synchronized state, you need to either have init return some sort of initialization command (as you have already intuited) or provide initialization data via flags from the JS land (use App.programWithFlags). That's about it. Elm is simple like that. Slow changing or fast changing matters less. The important issue is to start in the proper state, this is why init evaluates to a (Model, Cmd msg) tuple. As for FRP, forget about it. Elm said goodbye to FRP <http://elm-lang.org/blog/farewell-to-frp> with the move to 0.17. You don't need to worry about that anymore. Just model the data, display it however you like and make sure your update function gets all the messages it needs to have your app behave how you want it to behave. As for advice, best advice is to write stuff. Write code and if you get stuck, describe what you want to achieve, how you approached it and where you got stuck. I used to worry a lot about various things that Elm does or does not do without writing any code. That was silly. Don't be like me then, be like me now. Write code. :) On Sat, Jun 18, 2016 at 8:54 PM, phil <[email protected]> wrote: > 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. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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.
