-
Notifications
You must be signed in to change notification settings - Fork 16
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
Change Promise returning methods to return Observable (except forEach) #69
Comments
I strongly disagree with this direction, as previously discussed. |
If we want to really stick with the "Observable is a dual of Iterator" analogy, then I think we should keep the promise-returning methods as they are.
As discussed a bit at TPAC, I don't think the concerns about the promise-returning methods interacting poorly with events is very serious. Consider
There seems to be no reason to make those helpers return Observables, and making them return promises more-closely matches what Iterator helpers do. Now regarding the other methods: Footnotes
|
In short, promise-returning methods reduce to a single value, which seem less suited to be wrapped in an Observable, with all of the compositional operators. For example, what would be the purpose of calling |
I think Microtask should not be too late to That's always been a challenge with custom EventTargets having different microtask behavior which should probably be solved in a different way (ex. an explicit checkpoint API, or having a way to queue a task to dispatch the event like native would |
More questions on the Promise-returning methods:
|
I think no, given https://www.w3.org/2001/tag/doc/promises-guide#reasons-should-be-errors, https://www.w3.org/2001/tag/doc/promises-guide#rejections-should-be-exceptional, and https://w3ctag.github.io/design-principles/#error-types.
I think that's standard practice for the rejection value, yes. If there is some other principle that demands it to be something else, I am not aware of it. |
I think there's not much more to be done here, and I think we are satisfied with the previous comments in this issue describing the rationale behind the promise-returning methods, so I'll go ahead and close this. If someone thinks this is immediately actionable, please let me know! |
Promises bearing events have problems
Because promises force scheduling, any API that returns a promise runs the risk of confusing users because:
e.preventDefault()
.Basically, we should have everything accept
forEach
return anObservable
.Semantics of forEach
forEach
would still synchronously execute its callback, but the completion being a promise would mean completion is scheduled. This is okay, because completion doesn't bear a value.The text was updated successfully, but these errors were encountered: