The unease will subside. The bug in the example is there because of improper initialization. In other words, the example did not stressed the starting state, it only wanted to show how to get messages into the app from a subscription.
When you are designing something other than a toy example, the initialization is the first thing you pay attention to. Elm catches as many of the bugs as possible but for meaning related bugs we'll probably need some kind of omniscient artificial intelligence. :) In the example you linked, the bug is a meaning bug, you considered that* the starting state should be in sync* with the time. Some other person will just look at the ticking then at how the subscription is used and be satisfied with the example. Or consider the case where someone would want to show how to achieve eventual synchronization. This would be a perfect example for that. The "bug" you saw there would actually be a feature of the example. The app starts in an inconsistent state and then it gets synchronized with the current time. On Sat, Jun 18, 2016 at 9:52 PM, phil <[email protected]> wrote: > 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]> 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. > -- 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.
