admin管理员组文章数量:1283354
In the OpenUI5 code-base I came across this snippet:
// Wait until everything is rendered (parent height!) before reading/updating sizes.
// Use a promise to make sure
// to be executed before timeouts may be executed.
Promise.resolve().then(this._updateTableSizes.bind(this, true));
It looks like the native Promise function is being used, with no argument being passed to it's resolve
function which takes an:
Argument to be resolved by this Promise. Can also be a Promise or a thenable to resolve.
So, since it looks like the promise would simply immediately resolve and invoke then
's callback, perhaps the intent is similar to:
var self = this;
setTimeout(function() {
self._updateTableSizes.bind(self, true)
}, 0);
...basically, freeing the JavaScript run-time event-loop to finish other things (like rendering) and then come right back to the callback?
My question is:
Is this a common pattern? Best-practice? Are there any advantages/disadvantages to either approach?
In the OpenUI5 code-base I came across this snippet:
// Wait until everything is rendered (parent height!) before reading/updating sizes.
// Use a promise to make sure
// to be executed before timeouts may be executed.
Promise.resolve().then(this._updateTableSizes.bind(this, true));
It looks like the native Promise function is being used, with no argument being passed to it's resolve
function which takes an:
Argument to be resolved by this Promise. Can also be a Promise or a thenable to resolve.
So, since it looks like the promise would simply immediately resolve and invoke then
's callback, perhaps the intent is similar to:
var self = this;
setTimeout(function() {
self._updateTableSizes.bind(self, true)
}, 0);
...basically, freeing the JavaScript run-time event-loop to finish other things (like rendering) and then come right back to the callback?
My question is:
Is this a common pattern? Best-practice? Are there any advantages/disadvantages to either approach?
Share Improve this question asked Jun 22, 2016 at 20:22 Jonathan.BrinkJonathan.Brink 25.4k20 gold badges82 silver badges124 bronze badges 2 |2 Answers
Reset to default 19Yes, Promise.resolve()
does immediately fulfill with the undefined
value that you implicitly passed in. The callback is still executed asynchronously - quite like in the setTimeout
snippet you posted.
However, as the comment in the code explains, the intent is not just to execute the callback asynchronously:
Use a promise to make sure to be executed before timeouts may be executed.
Promise callbacks do run before timeouts or other events, and these subtle timing differences are sometimes important. Given that choice of the task loop is usually not important, No this is not a common pattern; but it is a valid pattern that does exactly what you need when you need it.
I noticed the technique in this polyfill: https://github.com/wicg/inert (with comment)
const newButton = document.createElement('button');
const inertContainer = document.querySelector('[inert]');
inertContainer.appendChild(newButton);
// Wait for the next microtask to allow mutation observers to react to the DOM change
Promise.resolve().then(() => {
expect(isUnfocusable(newButton)).to.equal(true);
});
本文标签: javascriptPromiseresolve with no argument passed inStack Overflow
版权声明:本文标题:javascript - Promise.resolve with no argument passed in - Stack Overflow 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1738442455a2087031.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
Promise.resolve().then(...)
quite often to be sure to catch errors thrown in synchronous code that is used inside promise chains, so I don't think it's a bad choice to do. – Daniel B Commented Jun 22, 2016 at 21:18Promise.resolve().then(…)
isn't enough. As far as I know, there isn't a way to queue a function to run after rendering but before the next task. – JaffaTheCake Commented Jun 1, 2017 at 15:45