Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 08 17:02
    darcyparker commented #326
  • Oct 08 16:01
    staltz closed #326
  • Oct 08 16:01
    staltz commented #326
  • Oct 08 14:08
    darcyparker opened #326
  • Sep 08 07:10
    ftaiolivista commented #235
  • Sep 07 13:00
    ftaiolivista commented #235
  • Sep 06 15:21
    staltz commented #325
  • Sep 06 14:47
    ftaiolivista commented #325
  • Sep 06 14:38
    staltz commented #325
  • Sep 06 14:37
    staltz commented #325
  • Sep 06 14:30
    ftaiolivista edited #325
  • Sep 06 14:30
    ftaiolivista opened #325
  • Sep 01 10:38
    staltz closed #284
  • Sep 01 10:38
    staltz commented #284
  • Sep 01 02:14
    andykais commented #284
  • Aug 19 18:31
    nukisman edited #324
  • Aug 19 18:30
    staltz commented #324
  • Aug 19 18:20
    nukisman edited #324
  • Aug 19 18:18
    nukisman edited #324
  • Aug 19 18:17
    nukisman edited #324
Victor Borja
@vic
Hello, is there an easy way to convert an Rxv5 stream into an xstream ? Should I use xs.fromObservable or perhaps rxv5$.subscribe(...) ?
Victor Borja
@vic
looks like xs.fromObservable(rxv5) worked
Michal Vanko
@michalvankodev
@vic Yes xs.fromObservable works.. even with higher order observables ;)
Guys I have a question. I want to do a reactive programming workshop in our company. I don't have much experience with RxJS. But I want that workshop to be useful for people. I think that teaching xstream is far more easier than RxJS as well. Should I focus only on xstream or do you think that xstream is not that useful outside of cycle js
André Staltz
@staltz
Hi @michalvankodev, good news! I think you should teach RxJS or most.js, because of the simpler internals
xstream is complicated, internally
but something like https://github.com/staltz/toy-rx is easy to show
often when teaching something, in order to explain "why are things like this" you will have to go into the internals, and RxJS is conceptually "cleaner" than xstream
Michal Vanko
@michalvankodev
I have no idea about xstream or rxjs internals :D
André Staltz
@staltz
take a look at toy-rx
it's really simple
Michal Vanko
@michalvankodev
Thanks, I'm looking into it ;)
That's not a bad idea how to start a workshop.. by building an Observable itself.
André Staltz
@staltz
I've done it many times and it's a good way of making people less scared of it
Michal Vanko
@michalvankodev
But do you believe that RxJS is easier to explain and learn than xstream?
André Staltz
@staltz
depends on the use case
if you're just going to use xstream basics, and you have 1 subscribe in your app, then yeah xstream
if you have 3+ subscribes, then RxJS
Michal Vanko
@michalvankodev
I will like to show off both of them and compare them anyway.. But want to have something to teach how higher order observables work and etc.
ok Thanks. :) I will have to learn RxJS then :D I am really interested why @ntilwalli likes it so much :D
André Staltz
@staltz
Or most.js for that matter : )
the big advantage of xstream is how it's multicast everywhere, and how that helps our goal to make cycle.js more visualizable
Michal Vanko
@michalvankodev
Yes :) that's why I like it. I don't have to care about sharing and stuff.. Makes logic really easy to translate to code
Nikhil Tilwalli
@ntilwalli
@michalvankodev I think xstream, most and RxJS are all good libs. I've used them all. It's personal preference thing. I chose RxJS for my own project mainly because 1) it's good and 2) it's the most widely adopted and therefore most widely-tested stream lib. I like that when I say I'm using RxJS, occasionally people are like "Ohhh, I've heard of that..." :wink:
I also find it useful to distinguish between unicast and multicast streams
That being said, my code is littered with .publishReplay(1).refCount()
Michal Vanko
@michalvankodev
:D I thought so ;) Do you have an example of use case where you want to have unicast?
Nikhil Tilwalli
@ntilwalli
The biggest reason to distinguish is efficiency. Multicast streams introduce an array for each operator which is iterated for each emission, (xstream uses an optimization under the hood to reduce the time complexity, but it's there...)
Michal Vanko
@michalvankodev
@ntilwalli Other than optimization? I'm more concerned about use case where I will really want my stream be unicast
Nikhil Tilwalli
@ntilwalli
@michalvankodev I can see how it comes across as an optimization, but I don't think of it that way. Unicast streams are more elemental. They're the most basic form. Multicast streams are the basic-concept + an additional behavior. The basic-concept (unicast streams) offers lazy-instantiation and callback-chaining. Multicast-ness builds on that concept to say, if something has already been lazily-instantiated, don't do it again... reuse it. As you get into more advanced apps, understanding that level of nuance can be useful
I agree that as a beginner that nuance can be confusing...
Michal Vanko
@michalvankodev
I actually understand the concept behind it. I still might be confused as I am not relying on it yet. But still just trying to think of a use case in my app that I would actually want this behavior.
Nikhil Tilwalli
@ntilwalli
There's no real utility. It like creating an Integer class that stores its one internal value inside an array
The interface still operates as if it's a single unit
I dunno if that's the best analogy, but yeah, I can't think of a use-case...
Other than speed
Michal Vanko
@michalvankodev
Please alert me when you do. This is really important actually :)
Nikhil Tilwalli
@ntilwalli
:thumbsup:
André Staltz
@staltz
@michalvankodev without unicast we can't have referential transparency (purity) everywhere
here's a basic example:
    const inc$ = sources.DOM.select('.inc').events('click').mapTo(+1);
    const refresh$ = sources.DOM.select('.ref').events('click').startWith(0);
+   const sum$ = inc$.fold((x, y) => x + y, 0);
+   const lastSum$ = refresh$.map(_ => sum$).flatten();
-   const lastSum$ = refresh$.map(_ => inc$.fold((x, y) => x + y, 0)).flatten();
    const vdom$ = lastSum$.map(count =>
      div([
this simple refactoring changes program behavior
cyclejs/cyclejs#365
Nikhil Tilwalli
@ntilwalli
@staltz Am I right that your example has varying behavior in xstream but not in RxJS?
By my understanding since xstream does an async unsubscribe (under the hood) during flatten the new subscriber will be added before the old one is removed ensuring the sum$ never goes down to zero subscribers, thus causing it to never reset. RxJS does synchronous unsubscribe during switchMap thus in RxJS the sum$ would go from one down to zero subscribers temporarily before immediately adding the new subscriber and going from zero back to one subscriber (resetting it). The reset from zero subscribers would happen in either version of the code...
Nikhil Tilwalli
@ntilwalli
The unicast/multicast referential transparency issue is exposed when sum$ has subscribers other than lastSum$. No matter the lib, xstream or RxJS, in the sum$ example, the number of subscribers will never go down to zero so the stream will never get reset, whereas in the commented-out version a new stream reference (with zero existing subscribers) is created on every refresh$ emission...
André Staltz
@staltz
@ntilwalli did you test that in RxJS? I don't think RxJS would have this issue becaues xstream does sync-start, async-stop, so when switching to the same inner stream as the previous, in xstream no unsubscribe of the inner will happen
in RxJS, switchMap does sync-start, sync-stop, so it will unsubscribe
furthermore, there's no multicasting and refcounting in RxJS's sum$ in that example, unless you explicitly choose it
Nikhil Tilwalli
@ntilwalli
I thought that's what I said. In RxJS the subscriber count will go down to zero so the stream will reset, in xstream the subscriber count will not go down to zero, so the stream will not reset