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

Question: Exposing state variables for Promise #80

Closed
zackdotcomputer opened this issue Nov 9, 2018 · 2 comments
Closed

Question: Exposing state variables for Promise #80

zackdotcomputer opened this issue Nov 9, 2018 · 2 comments

Comments

@zackdotcomputer
Copy link

Sorry for leaving this as an Issue when it's more a "Request for change"

I notice that there are three protected accessors on Promises called isPending, isFulfilled, and isRejected. I've run into a case where it would be very useful to be able to introspect the isPending value in a synchronous way, but can't. Is there a reason for these variables to be protected, rather than being read-only public?

For the record, my use case is that I have a cache access function that returns a Promise, meaning that it's likely that it has either already been fulfilled or it will take quite some time to fulfill. I would like to be able to introspect that value synchronously so that I can show a loading spinner before attaching the handler via the .then chain. The app currently just always shows the loading spinner, but it is an unpleasant experience to flash it very quickly and it strikes me that there would be no issue with exposing this value.

Please let me know if there's something I'm missing here, thanks!

@shoumikhin
Copy link
Contributor

Hi Zack,

The functions you've mentioned are designed for testing purposes only. Exposing promise's state and checking it explicitly is usually error prone, because it potentially leads to race conditions.

Imagine your cache access function had a completion handler instead. How would you solve your issue with the activity indicator UX then? There's couple of ways on the top of my mind:

  • provide another sync function that would return either nil or a value directly if it's present in cache; if you got nil, then call the async function
  • add an out argument of boolean type along with completion handler to tell if there was a cache miss
  • delay showing the activity indicator and skip that if completion handler fired earlier

Similarly, you can use one of those patterns when you have an async func that returns a promise.

Hope that helps.

@zackdotcomputer
Copy link
Author

Thank you for the thoughtful reply, @shoumikhin! I had also landed on the solution of providing a direct access method and using the Promise as a fallback and it's working just fine. Thanks again and have a good week.

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