paldepind/flyd

The minimalistic but powerful, modular, functional reactive programming library in JavaScript.

Einar Norðfjörð

@nordfjord

I'm mainly thinking of it as a way to deprecate map

const selected = available
- .map(find_selected)
+ .let(map(find_selected))

James Forbes

@JAForbes

Yeah cool. I think it's convenient in it's own right. It's basically |>

Do you know why they went with let I've been struggling to name this myself

Einar Norðfjörð

@nordfjord

they eventually moved away from let to pipe

James Forbes

@JAForbes

Einar Norðfjörð

@nordfjord

We're calling them "pipeable operators", because no one knows what the heck "lettable" means.

Ivan Pukhtin

@StreetStrider

I used to call it thru from time to time.

Einar Norðfjörð

@nordfjord

@paldepind I've opened a PR with all of the things discussed yesterday. It's not quite complete yet, but I wanted to get your thoughts on it none the less.

Einar Norðfjörð

@nordfjord

Okay, I'm up to 100% coverage again, it just needs documenting now! My free time is up for today, I'm hoping I have time on sunday to continue/finish

Einar Norðfjörð

@nordfjord

@paldepind I wanted to give you props for being one of the most enjoyable maintainers I’ve come across! Thanks for your work

Simon Friis Vindum

@paldepind

@nordfjord Haha :smile: I'm really flattered that you feel that way. But I'm also slightly baffled as to why you think so? I'm certainly not without my flaws :wink: I can sometimes be unresponsive and let things slip through the cracks :sob:

Einar Norðfjörð

@nordfjord

It has to do with the simple things. When you said “Thank you for your effort” as a response to #162 it motivated me to actually find the solution! The simple things like saying thank you really go a long way.

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

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));
  }
}

Where communities thrive

People

Repo info

Activity