When you got some time give this a read: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#the-introduction-to-reactive-programming-youve-been-missing
On Thursday, March 9, 2017 at 11:08:38 PM UTC+1, Martin Norbäck Olivers wrote: > > Well, it may very well be that I missed the point of observables, I'll > have another look, but my somewhat limited experience using them was that > it was easy to lose track of all the event going through a lot of streams. > > Maybe what you are looking for is something like the Process in Elm, which > is not very useful right now, but with a message API could be used to > implement some kind of stream. > > Or maybe it's sufficient to have some kind of object in the state that > collects certain messages and then subscribes to a future time when it > emits them again. The multiple-click is not a really clear-cut example of > this as it's just a matter of collecting events and then comparing times. > > I find it helps enormously to have examples. Otherwise the discussion > about API and constructs can go on without making any progress, because you > don't really know what problem you are trying to solve, instead you have a > solution (streams) in search of a problem. > > Den torsdag 9 mars 2017 kl. 22:43:41 UTC+1 skrev Răzvan Cosmin Rădulescu: >> >> I agree with you on mostly everything. I think the current architecture >> with one state, update etc. works really well. The only thing is I see >> streams (reactive objects in general) is that when they *fulfill* their >> objective they will call the update function. Take for example debounce >> with 500ms interval, every 500ms it should trigger the update function with >> the latest object from the stream, that's it. I see this as a very natural >> way to extend the current architecture and I feel it fits very well, at >> least at this theoretical level, I don't know enough to think about the >> implementation, race conditions (if they were an issue), side effects etc. >> >> So, to recap, I'm not talking about using reactive objects to drive the >> state directly, but to manage incoming data through time transforms, which >> then trigger updating the state. I don't know if I was clear enough, I hope >> you get what I mean. >> >> <<The fact that you can combine observables and get very "complex" >> effects is true, but the point of Elm is not to make programs complex, but >> to make them simple>> here you missed the point, you don't combine >> observables to make a more complex program, but exactly the opposite, to >> manage complexity through time-aware transform operators. >> >>> -- 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.
