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