Skip to content

Calling the loader after API has failed does nothing except throw an error. It should retry fetching the library instead #93

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

Closed
louisnow opened this issue Nov 13, 2020 · 5 comments · Fixed by #99
Assignees
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. released type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@louisnow
Copy link
Contributor

louisnow commented Nov 13, 2020

Calling the loader after API has failed does nothing except throw an error. It should retry fetching the google maps library instead.

Environment details

  1. Specify the API at the beginning of the title (for example, "Places: ...")
  2. OS type and version: Linux
  3. Library version and other environment information: React

Steps to reproduce

  1. Block the maps.googleapis.com domain in the browser network tab
  2. Call the loader.
  3. Unblock the previously blocked domain/URL
  4. Call the loader again, it will fail to do anything.

This is important for recovery purposes, google-maps sends a request again if it originally failed and you called the loader again.

@jpoehnelt jpoehnelt added priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. labels Nov 13, 2020
@jpoehnelt
Copy link
Contributor

I'll look into adding automatic retries. Unfortunately it seems there isn't much information available as to the cause.

@louisnow
Copy link
Contributor Author

louisnow commented Nov 13, 2020

Would that mean, the original loader that was instantiated first would keep retrying? That would be a nice addition! :)
What about a way to inform the internal singleton that the Loader class was instantiated again and it should retry immediately as well?

@jpoehnelt
Copy link
Contributor

Would that mean, the original loader that was instantiated first would keep retrying? That would be a nice addition! :)

Yes, I have this implemented with tests.

What about a way to inform the internal singleton that the Loader class was instantiated again and it should retry immediately as well?

Adding a reset() that will enable this more easily.

@louisnow
Copy link
Contributor Author

louisnow commented Nov 13, 2020

Adding a reset() that will enable this more easily.

Will it be a public facing api? Would it require us to keep track of the previous/ call .reset() before .load() for every instance of Loader?

Maybe the library can internally call private reset() if the constructor loader is run again and it has already errored out?

@github-actions
Copy link

🎉 This issue has been resolved in version 1.10.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. released type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants