onremove() should return a promise for actually removing the element
See original GitHub issueI wish the function onremove()
were to return a promise to tell the library to actually remove the element, instead of our having to manually do so in our own implementation.
Issue Analytics
- State:
- Created 6 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
How to wait for Promise to resolve before returning a new ...
Your current iteration through signIds 's Promises is not being chained with anything else - the .delete() Promises aren't being used ...
Read more >Using promises - JavaScript - MDN Web Docs
Essentially, a promise is a returned object to which you attach callbacks, instead of passing callbacks into a function. Imagine a function, ...
Read more >Lifecycle methods - Mithril.js
The onremove(vnode) hook is called before a DOM element is removed from the document. If a onbeforeremove hook is also defined, the onremove...
Read more >Upgrading from AngularJS to Angular
If an element is owned by AngularJS, Angular treats it as if it didn't exist, ... You can still call $apply() so there...
Read more >Updating For Beta 14 | Flarum Documentation
If a promise is returned, the DOM element will only be removed when the // promise completes. It is only called on the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@jbucaran how about supporting
onremove
returning a thunk? This seems like another case of an asynchronous update, except to the DOM instead ofstate
. For example:So instead of ignoring the return of
data.onremove
it would look something more like:We don’t want to support Promise in the core right ? So I approve the idea to make thunk a common practice for async operations.