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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
