Thanks for the quick reply Peter! I'm bringing it up because I'm writing code, and I'm writing bugs into that code, bugs that with the current design of `subscription`s, can't possibly be caught by the compiler. Like the bug in one of the most basic examples in the guide! I feel like I'm setting up traps for myself with every Command and Subscription because if I miss its complement (if it's a value-over-time and not an event), I'll never know until I notice the bug at runtime.
Maybe this unease will go away as I write more elm and become a better Elmer :) On Saturday, June 18, 2016 at 2:23:47 PM UTC-4, Peter Damoc wrote: > > 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] <javascript:>> > 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] <javascript:>. >> 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.
