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

Reply via email to