-
Notifications
You must be signed in to change notification settings - Fork 2
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
Allow to specify default location in a static Closure #33
base: main
Are you sure you want to change the base?
Conversation
$this->config('default_location', []) | ||
); | ||
$this->default_location = is_callable(self::$defaultLocationResolver) | ||
? call_user_func(self::$defaultLocationResolver)->toArray() |
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.
Hey @alies-dev,
Does this mean that we now have two places to change this value?
Also, this discards one of the usecases that we have, which is changing the country for local testing & in tests.
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.
@mithredate
yes, this is a public repo, I implemented this resolver and will remove other options on next major version of the package
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.
Also, this discards one of the usecases that we have, which is changing the country for local testing & in tests.
I'm not sure it exactly discards, but changes a way on how to fake/set the response, right? For tests, we can use a fake implementation of the IpGeoLocator
.
For local testing: well, it's more interesting. It's not an issue of this package, but by GEO_DEFAULT_COUNTRY_ISO_CODE
we can change only iso_code what is currently ok for us. But what if we need to change e.g. postal_code
? Should we also introduce a new .env var? Such a resolver is more flexible, but the downside is that we need to touch committed to git code to change the default result, what is also not ideal. I don't see an ideal solution here.
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.
What I mean is that this code is being committed to git. Currently, we use the env to change the default location for local development. This new snippet doesn't allow that, unless you ignore the file (unstage it). This is error-prone and not really a configuration to enhance DX IMO.
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.
Please give me some time to think about this. I also like the new approach better, but it doesn't help since we might accidentally commit things and then we need to roll-them back, etc.
Why: more flexibility as it can be resolved dynamically, e.g. based on the Request or globals. This is a BC breaks-free implementation, simplified one. In the magic version we should minimize the number of ways to specify the default location. Plus, in the next major version, we should not call
$defaultLocationResolver
in the constructor but do it on the first access to the default location. Current implementation is not optional more made to not break the BC.Example of usage:
Main use cases: