Thank you so much for this fascinating discussion. On Friday, March 10, 2017 at 9:52:02 AM UTC-8, Mark Hamburg wrote: > > Let's consider throttling. > > We'll assume that we want to throttle messages of a particular type to not > arrive more often than a particular interval. The exact rules are exactly > the sort of thing we want to hide inside the throttle module. > > We've got some state to manage. The last time we let a message through, > maybe a message that hasn't gotten through yet, etc. So, we'll have to put > this in a value and stash it somewhere in our model. > > This state can get updated in two ways. It can receive messages to be > throttled and it can receive responses to commands that it issues — e.g. > requests for signals after a particular delay, requests for the current > time, etc. Each of these forms of update need to return a new state, > possibly a command, and possibly a message to deliver. A little messy but > doable. > > The hosting module needs to store the throttle in its model and route > appropriate messages through the throttle object. Furthermore, when > messages come back out of the throttle, it needs to route them to a version > of the update function that doesn't throttle them. This could be handled by > having a ToThrottle wrapper around the actual messages to be delivered and > pulling this wrapper off before feeding to the throttle. Again, a little > messy but doable. > > If we put this all just at an outermost level and put the "real" model > inside of that, it might make for a reasonable way to segregate the "little > bit messy" code. On the other hand, if we have parts of the model coming > and going — e.g., because we have a dynamic list of external items we are > observing — and those individual parts need to throttle messages for those > parts, then we likely end up with throttling code and constructs threaded > through our model logic and structures. > > What it feels like one wants to write but can't is the function: > > throttle : Float -> Sub msg -> Sub msg > > On the other hand, the moment you have merges, streams become potentially > non-deterministic, so I can see the arguments against them. Is there a yet > better way to separate concerns — in this case model logic from update > frequency? > > Mark > > On Mar 10, 2017, at 9:13 AM, Martin Norbäck Olivers <[email protected] > <javascript:>> wrote: > > The point is not that I want to implement things "on my own" in Elm. The > point is that we need to understand the problems before discussing > solutions. Elm has high level tools, they're called functions, so any > collection of Elm state manipulation and subscriptions etc that you need > can be put in functions that the user of your library calls. > > How would you do debouncing/throttling/buffering? Well, you'd have a piece > in your state that handles this and call functions from the corresponding > module to handle the events. The question is, do we need anything else than > tasks and subscriptions to be able to implement this? If not, then we can > look at what problems people have and write a good library for it. If we > do, then let's explore what that other thing could be. > > It's not just Signals from Elm 0.16, they don't give anything that you > don't have in Elm currently. RxJs hav higher order functions on > streams/observables, which has never been in Elm. > > If it's more than the inconvenience of explicitly declaring your state, > then this is a difference more in the mindset about being able to clearly > reason about your state and how it changes in one single place. > > Den fredag 10 mars 2017 kl. 17:00:41 UTC+1 skrev Răzvan Cosmin Rădulescu: >> >> Here's an example of drag&drop implemented in RxJS: >> https://github.com/Reactive-Extensions/RxJS/blob/master/examples/dragndrop/dragndrop.js. >> >> Look how simple it is. And there are a bunch of examples in that examples >> folder. I think you have the wrong mindset, it is not about "what problems >> it solves", you can very well solve the same problem in Elm as you did, but >> again, this is more about the difference between C & assembler or Python & >> C etc. Why do you choose Python and not assembler? Because it gives you >> high level tools to work faster and simpler. >> >> As Andrew mentioned, it's about the plumbing in the end. Reactive >> observables just makes working with time simpler, you don't have to keep >> track of anything. Sure you can do double click/tap by keeping track of >> time in current Elm and do some maths, what happens when you want to detect >> 3-4-n clicks? Same with swipe for example, etc. RxJS (and here I'm talking >> about RxJS because this is what I experimented with before Elm but could be >> any other library) just makes this low level state tracking work for UI >> especially really really simple. How would you do >> debouncing/trottling/buffering etc. in Elm? I've only seen a module on >> debouncing and I have absolutely no idea how it works (I checked the source >> code) but it looks super complicated. So if you want to implement some of >> this things on your own in Elm currently working with present state and no >> time transformations makes this work a lot less pleasant let's say. >> >> There isn't really anything like "RxJS solves this - here's an app for >> it". RxJS gives you some tools to integrate with other tools (Cycles.js, >> Angular etc.) to build apps in a better more manageable way. >> >> Exactly, I saw your last comment, I'd really be interested to see how you >> implement Swipe with Elm. Here's an implementation I just came across with >> RxJS: >> http://www.chetcorcos.com/projects/2015/02/07/observable-streams.html >> >> On Friday, March 10, 2017 at 3:02:50 PM UTC+1, Martin Norbäck Olivers >> wrote: >>> >>> No, I'm not looking for examples in Elm necessarily, I'm looking for >>> realistic problems that are solved in a simple way with observables so that >>> we can figure out how to solve them in Elm and if we need some additional >>> language constructs or libraries to be able to solve them. There may very >>> well be a case for some kind of asynchronous stream construct, but it's not >>> at all obvious that we should use the same construct as for instance RxJS. >>> >>> Like the double click or swipe example, but with a more complicated >>> state. The state for double click and swipe is pretty simple to model in >>> Elm, it's just a matter of saving the time of click and the number of >>> clicks. >>> Even if Elm would have kept it's signals, they were not the kind of >>> observables you have in RxJS. For asynchronous messages you have to use >>> Commands/Tasks anyway. >>> >>> Den fredag 10 mars 2017 kl. 11:16:18 UTC+1 skrev Răzvan Cosmin Rădulescu: >>>> >>>> Well they are not "needed" the way that C is not "needed" over >>>> assembler for example. >>>> >>>> Reactive observables are what high level programming is to low level >>>> programming. That's how I see it at least. They shine only when you need >>>> to >>>> deal with time, if you only need to work on current state/values then >>>> they're not that useful. But since Elm tires to be a frontend >>>> framework/language for me at least having reactive objets subs very >>>> natural. >>>> >>>> You mean to give your actual practical examples in Elm? I'm afraid I'm >>>> to new to the language to be able to do that, I'll have to think about it >>>> for a while. That's why I'm giving examples in JS where we have lots of >>>> them and cycles.js for example is very similar to the Elm architecture >>>> except it's entirely based on reactive objects. >>>> >>>> In any case, I'll try to think of how one might create such things in >>>> Elm and see if I can come up with practical examples >>>> >>>> -- > 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. > >
-- 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.
