Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 01 20:43
    dependabot[bot] labeled #224
  • Nov 01 20:43
    dependabot[bot] opened #224
  • Nov 01 20:43

    dependabot[bot] on npm_and_yarn

    Bump minimatch, browserify, ist… (compare)

  • Jan 05 11:17
    JamesRamm opened #223
  • Dec 22 2021 01:00
    NeoVance opened #222
  • Sep 03 2021 02:29
    andersonleite closed #143
  • Aug 10 2021 17:36
    dependabot[bot] labeled #221
  • Aug 10 2021 17:36
    dependabot[bot] opened #221
  • Aug 10 2021 17:36

    dependabot[bot] on npm_and_yarn

    Bump path-parse from 1.0.5 to 1… (compare)

  • Jun 23 2021 12:24
    jakubmazanec closed #195
  • May 09 2021 06:46
    coveralls commented #220
  • May 09 2021 06:44
    dependabot[bot] labeled #220
  • May 09 2021 06:44
    dependabot[bot] opened #220
  • May 09 2021 06:44

    dependabot[bot] on npm_and_yarn

    Bump hosted-git-info from 2.5.0… (compare)

  • May 06 2021 22:03
    coveralls commented #219
  • May 06 2021 21:45

    dependabot[bot] on npm_and_yarn

    (compare)

  • May 06 2021 21:45
    dependabot[bot] closed #210
  • May 06 2021 21:45
    dependabot[bot] commented #210
  • May 06 2021 21:45
    dependabot[bot] labeled #219
  • May 06 2021 21:45
    dependabot[bot] opened #219
Simon Friis Vindum
@paldepind
I'm very happy to hear that! I can only imagine that fixing #160 must have been really tricky. I think it's very impressive that you figured it out :thumbsup:
Einar Norðfjörð
@nordfjord
Thank you for your kind words. It took a while but I can now say I’m familiar with flyd’s internals which is great for me considering the sheer amount of code I have that depends on it :smile:
Einar Norðfjörð
@nordfjord
whoops, just noticed a glaring flaw in the flatMap implementation I copied to chain
it doesn’t preserve ordering
var flatStream = flyd.combine(function(s, own) {
    // Our fn stream makes streams
    var newS = f(s());
    flatEnd(flatEnd() + 1);
    internalEnded(newS.end);

    // Update self on call -- newS is never handed out so deps don't matter
    flyd.on(own, newS);
  }, [s]);
It should stop listening to the old stream when the newS is generated right?
Einar Norðfjörð
@nordfjord

otherwise we’re forced to write:

const src = stream();
const res = chain((d)=> takeUntil(fromPromise(d), src), src);

To ensure ordering

Einar Norðfjörð
@nordfjord
I’ll extend my PR to handle this
Einar Norðfjörð
@nordfjord
Screen Shot 2018-02-01 at 20.25.45.png
Was playing around with adding type signatures as the inspect method of flyd functions
I think it turns out nicely
@paldepind thoughts?
Einar Norðfjörð
@nordfjord
I’ve been thinking about how to best approach the deprecation of promise swallowing as well
I don’t think we can deprecate first and release later like you were talking about
because the helpers simply won’t work
flattenPromise excepts a Stream Promise a
which can’t exist in the current flyd implementation
Einar Norðfjörð
@nordfjord
It would be pretty easy to implement the monoid spec as well
Einar Norðfjörð
@nordfjord
since we already have a merge method
Ivan Pukhtin
@StreetStrider
@paldepind hello. Why flyd does not prevent user from emitting second end value?
Ivan Pukhtin
@StreetStrider
I would love to see this idea https://github.com/paldepind/flyd/issues/116#issuecomment-224702954 recieving approval.
Renato Marinho
@renatomarinho
This message was deleted
Antti Niemenpää
@niant
Hey, I've a weird problem with flyd.map when doing transformations inside a another flyd.map...
const log = message => val => {
  console.log(message, val);
  return val;
};

const stream$ = flyd.stream(false);

flyd.map(() => {
  stream$
    .map(log('this prints...'))
    .map(log('...but it never reaches here'));
}, flyd.stream(true));
Has anyone struggled with this kind of situation? (If I take the surrounding flyd.map() away it'll work correctly)
Einar Norðfjörð
@nordfjord
Yes, a few times. May I ask what your use case is for this? I found that in most places where I was creating new streams within another stream body it was a huge anti-pattern.
Einar Norðfjörð
@nordfjord

For instance if we further your example.

const log = a => b => (console.log(a), b);
const s1 = stream(true);
const s2 = stream(true);

s2.map(()=> s1.map(log('1')).map(log('2'))

s2(true)(true);

What is your expectation of logging here?

1
2
1
2
1
2

Or is it just

1
2

Imagine we add s1(true) to the end of the example

What is your logging expectation then?

Renato Marinho
@renatomarinho
This message was deleted
Antti Niemenpää
@niant

Well, this is hard one to explain. I just did a simplistic example to highlight the issues. Let me try:

One example of such use case is when for example we have react-like components working with state in flyd streams (setState updates via stream updates). There comes situations when there's stateful components inserted into DOM after the state stream has already been initiated. While initiating the component - it reads in stream state nicely, but if you try to map the stream into another stream (transform, drop repeats, pick only specific props...) it didn't work properly. paldepind/flyd#177 tries to highlight the issue in a different format, but the underlying issue seems the same.

The recent fix: paldepind/flyd#178 will fix this issue though.

Antti Niemenpää
@niant
And what comes to example code @nordfjord : Yes, that's a difficult question. I'd say the expected result is 1 2 and after adding s1(true) it becomes even trickier, but i'd throw in another suggestion 1 2 1 2 :)
Einar Norðfjörð
@nordfjord
I believe in order for it to be guaranteed 1 2 1 2 you will need to:
s2.map(()=> takeUntil(s1, s2).map(log('1')).map(log('2')));
no sorry, s2 receives three updates in the example, (an initial value, + 2 updates)
so it's always going to be 1 2 1 2 1 2
adding an s1(true) to the end would log the same, but in a semi random order (probably reversed)
Einar Norðfjörð
@nordfjord

I used to have a similar problem with a react-like framework called mithril, where I was calling:

s.map(m.redraw)

because a redraw was happening inside a stream body weird things could happen. I ended up replacing every .map(m.redraw) with
.map(()=> requestAnimationFrame(m.redraw)) to fix it

Antti Niemenpää
@niant
Yea, I mean there's a logic for both expected results in my head :) I'm not fully sure yet what is the correct way. I only got my understanding behind it, and nothing mathematical or even theoretical behind it.
Antti Niemenpää
@niant
Regarding requestAnimationFrame, that's a good tip though I'm not sure would that have solved our issue. Our framework of choice (Inferno) is doing that behind the scenes I assume.. I'll try to create another example describing our original issue maybe better...
Einar Norðfjörð
@nordfjord
If it's a react clone then the setState method is what's doing the redraw :)
so you could on your component do something like:
class MyComponent extends Component {
  redraw() {
    requestAnimationFrame(()=> this.setState(this.state));
  }
}
Antti Niemenpää
@niant
Yea, actually now that I think of it. The problem might've been mitigating from that kind of issue, if the operations are sync enough you might end up in situation where child component stream is handled inside a parent setState/redraw (thus inside a parents flyd.map/on).
If that made any sense (I just came back from a holiday so my brain is kind of adjusting here :D)
Einar Norðfjörð
@nordfjord
Made perfect sense, I was in exactly the same situation but with another framework
So we decided that redraws should be async by default, but still exposed a synchronous redraw for those situations where you really really need it
Antti Niemenpää
@niant
Yea. That sounds reasonable.. Hmm, now I just need to figure out the way it's currently working. From my understanding React did/is doing changes into setState() sync/async side of things too
Thanks for the insight! :)
Einar Norðfjörð
@nordfjord
My pleasure, to be clear though, I think it's slightly obnoxious if flyd requires you to use a framework with async redraws because of an issue with nested streams :). So I'm hoping #180 gets merged soon
Antti Niemenpää
@niant
Yea, I hope too. Also it seems there's been some talk in Inferno github pages on this sync/async setState and perhaps changes in a specific version. I need to check that out too.
Antti Niemenpää
@niant
I assume this was the part you were talking about with the semi random call order previously @nordfjord ? And it does seems a bit weird, that order is different outside and inside a flyd.map..
const log = message => val => {
  console.log(message, val);
  return val;
};

const stream$ = flyd.stream(true);

stream$.map(log('1')).map(log('2'));
console.log('3');

flyd.stream(true).map(() => {
  stream$.map(log('5')).map(log('6'));
  console.log('4');
});
Einar Norðfjörð
@nordfjord
It has to do with the guarantees flyd gives you. Atomic updates are guaranteed, but the execution order of streams is not.
const log = a => b => (console.log(a), b);

const stream$ = stream(true);
stream$.map(()=> {
  // flyd makes no guarantee that this chain will resolve instantly
  // we only guarantee atomic updates
  const s2 = stream$.map(log('1')).map(log('2'));
  console.log('3');
});
// It's only here that you can be sure that the map chain has run.
Antti Niemenpää
@niant
Yea..
Daniel Gray
@DanielFGray
is there a better way to someArray.forEach(x => myStream(x)) ? in rxjs i can flatMap arrays into the stream, but chain always expects a stream and i don't see anything that looks similar