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 2021 17:02
    darcyparker commented #326
  • Oct 08 2021 16:01
    staltz closed #326
  • Oct 08 2021 16:01
    staltz commented #326
  • Oct 08 2021 14:08
    darcyparker opened #326
  • Sep 08 2021 07:10
    ftaiolivista commented #235
  • Sep 07 2021 13:00
    ftaiolivista commented #235
  • Sep 06 2021 15:21
    staltz commented #325
  • Sep 06 2021 14:47
    ftaiolivista commented #325
  • Sep 06 2021 14:38
    staltz commented #325
  • Sep 06 2021 14:37
    staltz commented #325
  • Sep 06 2021 14:30
    ftaiolivista edited #325
  • Sep 06 2021 14:30
    ftaiolivista opened #325
  • Sep 01 2021 10:38
    staltz closed #284
  • Sep 01 2021 10:38
    staltz commented #284
  • Sep 01 2021 02:14
    andykais commented #284
  • Aug 19 2021 18:31
    nukisman edited #324
  • Aug 19 2021 18:30
    staltz commented #324
  • Aug 19 2021 18:20
    nukisman edited #324
  • Aug 19 2021 18:18
    nukisman edited #324
  • Aug 19 2021 18:17
    nukisman edited #324
Michael Maier
@maiermic

this example works as expected

const xs = xstream.Stream

var stream = xs.periodic(1000).take(3)

xs.merge(stream, stream.take(1))
  .addListener({
    next: i => console.log(i),
    error: err => console.error(err),
    complete: () => console.log('completed'),
  })

Output:

0
0
1
2
"completed"
if I add a debug to stream I get unexpected output
var stream = xs.periodic(1000).take(3).debug('test')
Output:
"test:"
0
0
0
"test:"
1
1
"test:"
2
2
"completed"
bug or feature?
Steve Lee
@SteveALee
seems good to me. Why would it be a bug? Is printing your 'test' label and then the value - all be it on separate lines.
Michael Maier
@maiermic
I expect
"test:"
0
0
"test:"
1
"test:"
2
"completed"
oh, this might be a misunderstanding of mine caused by JSBin

it's console prints

"test:"
0

instead of

test: 0
Steve Lee
@SteveALee
Yeah, that was my point. I wondered why was on separate line - so it's JSBin!
Alex
@whitecolor
@staltz is it correct that operators convert MemoryStream to Stream?
André Staltz
@staltz
@whitecolor some of them do, like filter, because filter "removes" events and unless we buffer all events from the past, we cant guarantee that the output stream after filter would remain as a memorystream
Alex
@whitecolor
I think this should be stated in docs
Michal Vanko
@michalvankodev
Hello, I'm reading documentation for flattenSequentially

I think the Marble diagram is bit misleading.

* In essence, `flattenSequentially` concatenates all nested streams.
 *
 * Marble diagram:
 *
 * ```text
 * --+--------+-------------------------
 *   \        \
 *    \       ----1----2---3--|
 *    --a--b----c----d--|
 *          flattenSequentially
 * -----a--b----c----d------1----2---3--
 *

```

Shouldn't it be
 * --+--------+-------------------------
 *   \        \
 *    \       ----1----2---3--|
 *    --a--b----c----d--|
 *          flattenSequentially
 * -----a--b----c----d--1-2-3-----
Basically the events which were buffered shouldn't they be emmited right away?
Alex
@whitecolor
why? just after first streams completes it will subscribe to the second and emit the values
Michal Vanko
@michalvankodev
But those buffered events shouldn't be postponed by the time it took them to be emmited in the original stream
Alex
@whitecolor
it will not buffer, it will just subscribe, the example assumes that second stream has no subscribers yet
if it is started you would probably seen only 3 and if its memory stream 2 and 3
I believe it is so in theory) check it in pracice
Michal Vanko
@michalvankodev
Yea.. There is no documentation about subscribing to that second stream.
Alex
@whitecolor
Well the thing is that flattenConcurrenlty will subscribe to second stream as soon as arrives, and flattenSequentially only after previous stream completes
Michal Vanko
@michalvankodev
I get this.. I'm just concerned about the time which it takes to emit the values.
Alex
@whitecolor
say first stream is periodic(1000).take(4) and second periodic(5000).take(3) first start and emits abc, second arrives but will not be subscribed (no emittion) after 4 second, it will be subscribed and will emit 3 values in 15 seconds
you should consider hot/cold/multicasted and meta streams conceptions
it is simple
Michal Vanko
@michalvankodev
I'm going to try this out ;)
Alex
@whitecolor
on this diagram secons + is a moment of arrival of second stream to metastream, not the time of subscribtion
Michal Vanko
@michalvankodev
It dropped all of the values emitted before.. there is no buffer for those
Alex
@whitecolor
if your second stream had subscribers before
Michal Vanko
@michalvankodev
yes ;)
André Staltz
@staltz
Yes this is a tricky thing, and also occurs with concatMap in RxJS, it depends whether the thing being concatted is hot or cold
the intuition is not exactly "concatenation of values", it's more about "sequential subscription to different streams"
that's why I like "flattenSequentially" as a name
Michal Vanko
@michalvankodev
Wise choice :) .. Yesterday I got a question from my colleague if something like what I asked for is possible.. to deal with the events in order would be possible via some operator.. I can only think of flattenConcurrently with some extra logic to delay events from streams that are emitted before the first one finishes
André Staltz
@staltz
probably requires some buffering, we haven't yet made buffer or toArray in xstream, but I think it's on the to-do list
Michal Vanko
@michalvankodev
Didn't something with mapTo() changed in xtream@11? I was generating new IDs with mapTo and the function I've mapped to was always called before I've updated dependencies the last time. Now that function is only called once
Nick Johnstone
@Widdershin
@michalvankodev can you share a code sample?
is it stream$.mapTo(generateId())?
Michal Vanko
@michalvankodev
yes exactly
I get it that it shouldn't work.. .But it worked before
Nick Johnstone
@Widdershin
 λ cat > test.js
const xs = require('xstream').default;

xs.of(1, 2, 3).mapTo(Math.random()).addListener({next: console.log})

 λ npx -p xstream@10 node test.js
npx: installed 2 in 2.063s
0.5104117713843652
0.5104117713843652
0.5104117713843652

 λ npx -p xstream@11 node test.js 
npx: installed 2 in 2.463s
0.07187050076072277
0.07187050076072277
0.07187050076072277
From what I understand, it wouldn't be possible for xstream to change this behaviour
Michal Vanko
@michalvankodev
Thanks.. this is interesting
Michal Vanko
@michalvankodev
Yea I am thinking that the cause might be onionify .. As it might always build the component over and over again when state changed
Nick Johnstone
@Widdershin
can just use map(generateId) in any case
it will do what you actually want
Michal Vanko
@michalvankodev
yes i Know :) ... I've changed it to that way.. I'm just curious why the behavior changed after update