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. On Thursday, March 9, 2017 at 10:28:13 PM UTC+1, Martin Norbäck Olivers wrote: > > The Elm architecture is that there is a single state which is only updated > by messages, so observables (or signals) do not really fit into that. If > you want to count the number of clicks, then you count the number of clicks > and keep track of it in your model. If you want to handle a swipe then you > subscribe to mouse events and keep track of them, etc. > > 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. The reason there is a single state and only messages are > allowed to update it is not because it's hard to make the language more > complex with multiple states etc, but because it makes the program simple. > You know what can cause the state to change, a message. All messages pass > through the update function. You have control over the complexity of your > program. > > But that doesn't mean that you cannot do sophisticated things, of course. > It's not hard to keep track of the number of clicks in your model and > compare the time. If this is a feature that many people will want then it > could be made into a library with a good API. > > If you want to handle swipe events, perhaps you can use my html5 drag and > drop module as an inspiration. > http://package.elm-lang.org/packages/norpan/elm-html5-drag-drop/latest > > Swipe and drag are similar so the solutions should look similar. > > The versatility of observables is tempting but my experience is that when > the application gets bigger you get lost in them. They require discipline. > The point with the Elm architecture is that discipline is built-in. > > Den torsdag 9 mars 2017 kl. 13:39:30 UTC+1 skrev Răzvan Cosmin Rădulescu: >> >> Hi Martin, thanks for not bashing me from the start because I brought up >> reactive... Quite interesting it's happened a few times already. >> >> So, anything involving gestures for example. There is no Elm module for >> feature detection (swipe, tap, double tap etc.) so I wanted to learn by >> doing but unfortunately I discovered that the reactive part was dropped >> with v0.17.1. To be more specific let's take double tap (not click as this >> is already a DOM event). Here's a link on how this would be done in RxJS: >> http://jsfiddle.net/staltz/4gGgs/27/. >> >> As far as I can tell in Elm there's no other way but to keep track of >> state and do all sorts of "low level" calculations. >> >> Thanks again Martin >> >> -- 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.
