-
Notifications
You must be signed in to change notification settings - Fork 27
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
Promises implementation not working if results are available right away #5
Comments
+1 This is due to the "Promise" implementation being too simplistic - it does not not automatically call registered handlers if they are registered after the event. Also, there is nothing preventing the promise to, erronously, be "resolved" to a success after being resolved to an error. This should be solved by statefulness and automatic calling once the promise has been resolved. I think it's still possible to make a simple and short implementation by reusing Riot.js event features, but it needs some more logic and state.. It is wrong and misleading to call it a "generic promise interface" when it does not even behave similar to most promise implementations. |
@magwo makes sense. Thanks for pointing that out. Will be fixed. |
Cool. I think that this implementation would be highly interesting to include in Riot.js. It's such a powerful and useful construction in JS code, and used very often. If it can be robustly implemented in a compact way, I would very much like to see it included in Riot. Edit: It also goes hand-in-hand with the philosophy that jQuery is fine, but it needs to work outside of the DOM, which Riot.js solves partially with its observable pattern. jQuery promises/deferred are fine albeit messy and overcomplicated, so Riot.js could provide a minimalistic, fast and DOM/ajax-agnostic implementation. |
moot, are you working on a patch? Otherwise I might take a shot.. |
Please do! I'm not working on it atm. (I was logged in as muut previously) |
Ok I wasnt sure how you wanted the tests written, so I did the implementation and tests in a personal, unrelated repository. Commits here: Tests running here: Promise implementation here: Let me know what you think! ...which I personally find confusing, especially regarding beginner coders. I much prefer the idea of resolving by just calling done() or fail() on the promise object. Or am I misunderstanding some crucial feature of promises? Edit: Updated with correction - wasn't correctly calling functions registered after resolution. |
However, I have been thinking about attempting to make a Promises/A+ compliant minimalistic implementation, that would work well as a shim for browsers that do not have native Promises yet. |
Looking good. Any chance to make a pull request? Would be much easier for me . |
Yeah sure, just might not get the tests included in the pull request. |
If any of the back-end functions returns a result right away and calls always(..), the event is missed as the always callback is yet to be registered.
In slightly better English:
Callback handlers registered after the promise is fulfilled are not being called.
The text was updated successfully, but these errors were encountered: