Skip to content
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

Can I use as a 1:1 replacement of window.Promise? #2

Closed
wintercounter opened this issue Jun 19, 2020 · 2 comments
Closed

Can I use as a 1:1 replacement of window.Promise? #2

wintercounter opened this issue Jun 19, 2020 · 2 comments

Comments

@wintercounter
Copy link

wintercounter commented Jun 19, 2020

I'd be really curious to try it on a Promise heavy app.

UPDATE:
I tried in a React application, I've got an infinite loop unfortunately :(

Uncaught Error: Too many re-renders. React limits the number of renders to prevent an infinite loop.
@anonyco
Copy link
Owner

anonyco commented Jun 20, 2020

Excellent question. Please see this section of the README.

I am not suprised that you got an infinite loop. In order to maximize performance, SPromiseMeSpeed does not delay until the next tick before executing the handle:

console.log("before");
SPromise.resolve().then(function(){
    console.log("inside");
});
console.log("after");

Will yield:

before
inside
after

Whereas an ordinary browser promise

console.log("before");
Promise.resolve().then(function(){
    console.log("inside");
});
console.log("after");

will yield:

before
after
inside

Coding using SPromise has to be written with the mindset that the delay is not guaranteed. Your react app is probably getting stuck because the code inside the then executes sooner than expected. Try moving your SPromises closer to the end of statements to reduce potential chronological dependencies.

Further, SPromise reserves the right to switch up the order of execution of deeply nested Promises in order to prevent stack overflows, and this allows for the infinite loop you are experiencing. When SPromise detects too many nested levels of promises (creating a promise inside the then inside the then inside more thens), it trampolines the stack and defers all further execution of thens to the outmost SPromise to avoid a stack overflow.

That being said, I don't think SPromise is a danger to most projects (in terms of increasing the liklihood of bugs). You just have to approach SPromise the right way, and your code will be fine. Infact, I would argue that SPromise sometimes makes things easier to debug because interwoven asynchronous stack traces can sometimes be hard to follow and SPromises eliminates all possible asynchrony.

I hope this helps.

@wintercounter
Copy link
Author

Thanks for the clear explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants