-
Notifications
You must be signed in to change notification settings - Fork 1.1k
YAPPR - Yet Another Promise PR #262
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
Conversation
this simplifies the initial implementation of Promise support by @gero3, and allows for pluggable promise implementations. If a global `Promise` function exists, it will use that. Optionally, users can supply a promise implentation via `config.Promise`. this keeps the dependency list small, and gives people the freedom to choose their favorite Promise library.
Just stumbled in, it appears that the lead maintainer for this project has gone on hiatus, and I am itching for this feature. When can we expect @mikedeboer to be back and responding? If not, should a new fork be created? |
@jamestalmage There's effort to merge some of the PRs in this fork: I'd suggest to make the PR there. |
I'm not going to have time for that in the near future. |
👍 for this! I currently just wrap the calls in helper functions that return a new promise and this would simplify the code a lot! |
@codydaig Couldn't you do something like
|
@kaizensoze Primarily, I don't like the naming convention of adding Async to the end of every function name. Also, I don't like how it duplicates every method in the API, taking up twice as much space in memory. So, it's really just a personal preference. |
@codydaig Fair enough |
Thanks for merging! |
Hey folks, it's been a year and things have changed. We plan to drop support for the custom Promise option altogether. If that causes any trouble for you, could you please let me know at #622? Thanks :) |
this simplifies the initial implementation of Promise support by @gero3, and allows for pluggable promise implementations. If a global
Promise
function exists, it will use that. Optionally, users can supply a promise implementation viaconfig.Promise
:This keeps the dependency list small, and gives people the freedom to choose their favorite Promise library (there have been at least 3 different libraries recommended in the issues so far). Most promise libraries are pretty huge, and now that I have this working in the browser, I would be concerned about forcing large dependencies on people. This also has potential benefits for browser frameworks with existing promise implementations (I'm thinking specifically of angular.js $q).
see #258, #232