-
Notifications
You must be signed in to change notification settings - Fork 357
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
fix: fix cache error with geo country mock #4821
Conversation
📊 Benchmark resultsComparing with c766d51 Package size: 221 MB⬇️ 0.00% decrease vs. c766d51
Legend
|
src/lib/geo-location.js
Outdated
@@ -43,7 +43,7 @@ const getGeoLocation = async ({ geoCountry, mode, offline, state }) => { | |||
|
|||
// If we have cached geolocation data and the `--geo` option is set to | |||
// `cache`, let's try to use it. | |||
if (cacheObject !== undefined && mode === 'cache') { | |||
if (cacheObject !== undefined && mode === 'cache' && !geoCountry) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit of an edge case, but if you have something in the cache and it happens to be the same country as the one in geoCountry
, it'd probably be better to return the cached content than the mock data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be confusing for someone to be mocking their own country but be consistently returned their own location though, it may lead them to believe the feature is not working. Maybe once the full country names and/or subdivisions are mockable this might be more feasible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure there's ever any situation where you'd rather receive dummy data than an actual location from the country you're trying to emulate. But I'll defer to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, after thinking about it, I agree with you. I think I was originally looking down the road a bit more towards mocking subdivisions/states at which point the caching might be counterproductive. But seeing as that is probably either not going to happen, or a ways off at this point, I think your approach makes sense. I'll abstract out that logic into a function of its own, and it can be modified later if needed.
New caching function allows for the behavior like this in the event that a user mocks their own country:
|
src/lib/geo-location.js
Outdated
@@ -27,6 +27,9 @@ const mockLocation = { | |||
subdivision: { code: 'CA', name: 'California' }, | |||
} | |||
|
|||
const isCacheEligible = (cacheObj, mode, country) => | |||
cacheObj !== undefined && mode === 'cache' && (cacheObj.data.country.code === country || !country) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you run --country=XX
, shouldn't mode
become mock
? That's what the docs say is happening, and I wonder if reflecting that in the code would make this simpler, because then you wouldn't need to change this check at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we change the mode to mock, I'll still have to change the conditional in order to use the cached location in the case of a match though, right? To something like this?
const cacheObject = state.get(STATE_GEO_PROPERTY)
if (geoCountry) mode = 'mock'
// If we have cached geolocation data and the `--geo` option is set to
// `cache`, let's try to use it.
if (cacheObject !== undefined && (mode === 'cache' || cacheObject.data.country.code === geoCountry)) {
const age = Date.now() - cacheObject.timestamp
Does this now need a documentation update @JWhist? The docs suggest that not passing the |
Personally, I think there's no need, because we're still respecting the country you set with |
Co-authored-by: Eduardo Bouças <[email protected]>
Co-authored-by: Eduardo Bouças <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻 Thanks for the fix.
🎉 Thanks for submitting a pull request! 🎉
Summary
Fixes error by validating that no
geoCountry
value is set before checking the cache.For us to review and ship your PR efficiently, please perform the following steps:
passes our tests.
A picture of a cute animal (not mandatory, but encouraged)