Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling out of order responses from Promises #37

Closed
yelouafi opened this issue Jun 11, 2015 · 8 comments
Closed

Handling out of order responses from Promises #37

yelouafi opened this issue Jun 11, 2015 · 8 comments

Comments

@yelouafi
Copy link

function updateStreamValue(s, n) {
  if (n !== undefined && n !== null && isFunction(n.then)) {
    n.then(s); // here??
    return;
  }
  ...
}

If the promises are resolved in an arbitrary order (eg. the second promise resolve before the first) then the stream wll be updated with an outdated value

@iofjuupasli
Copy link

https://github.com/paldepind/flyd-switchlatest is what you want probably

@yelouafi
Copy link
Author

Yes, that's the way to do in other libs like bacon.js. If it's this is the desired behavior it' be preferable to mention it in the docs.

@paldepind
Copy link
Owner

I'm not particularly happy with this behavior.

@paldepind
Copy link
Owner

The tricky thing is that sometimes order matters and in some cases it don't. And when it doesn't matter you don't want slow promises to block results from later promises.

@yelouafi
Copy link
Author

IMO the default behavior should be preserving the order. The other case can be handled by something like

stream$.flatmap( v => flyd.fromPromise( $.ajax(...) )

@paldepind
Copy link
Owner

I agree.

@corps
Copy link

corps commented Apr 17, 2016

I believe the default behavior should do /the least special thing/. That's because the "I expect responses to preserve ordering" problem can be solved in at least two different ways:

  1. A response that comes later than a more recent response is simply dropped and not pushed down the stream (think making multiple update requests, where only the most recent update request is valid). This drops responses that arrive later than their ordering in the list.
  2. All responses are pushed into the stream, but each response is dependent on the previous request completing. This drops responses that arrive sooner than their ordering in the list, if the dependent responses error or never arrive.

I don't think there actually exists a single "intuitive" approach to this async problem, and it largely depends on what you're solving. The current default behavior is "dumb" and adds no special logic, leaving that as a problem to be solved with more specialized stream utilities.

You should not turn your brain off during async handling or trust in a default behavior. Always assume that things both come out of order and are dropped from responding at all.

@paldepind
Copy link
Owner

This issue is resolved by #168. The inbuilt promise handling is being removed. The new way to handle promises is documented here and it makes it possible to ensure the order of resolved values. Big thanks to @nordfjord.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants