-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Refactor address state validation #3129
Refactor address state validation #3129
Conversation
7532102
to
47b207c
Compare
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 like this approach and I can understand the reasoning behind it 👌
That said, this is definitely a breaking change and should be included for Solidus v3.0+
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 really like this! Definitely a breaking change as @aitbw mentioned. Thanks!
Moved the PR back to WIP 🚧. It requires some more work. I'll try to make it less breaking. Besides this, by digging deeper into it I see I misinterpreted some state behaviours and also introduced a few bugs 😅 |
6fc26f2
to
b15ae65
Compare
b15ae65
to
f136357
Compare
8b49693
to
2d0c586
Compare
46cdfb3
to
104af58
Compare
80e110a
to
a771b33
Compare
a771b33
to
c7aded8
Compare
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 like how this is coming along and I left a couple of comments. I'm also curious how and if it makes sense to deprecate the old validation methods instead of removing them.
@address = address | ||
end | ||
|
||
def perform! |
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.
Personal preference, but I'd use def call
here. Did you have a specific reason to use perform!
instead?
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 have followed the convention of other service-like objects in Solidus that are using perform
as their main action method. I have no preferences though.
Probably it's worth defining a project-wise convention for this kind of objects
c7aded8
to
1e3eb5f
Compare
Ready for a second review 🙏 @kennyadsl I've researched a few methods to deprecate them by showing a warning message only if they have been monkey patched, but the final solution was quite hacky and not working in all cases since there're multiple ways to patch them. |
1727830
to
ea4a79b
Compare
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.
👍
@cedum we discussed this in the core meeting and we agreed that it would be much better if we have the fix for #2417 and #3098 in a different commit, just for documentation in case someone cannot update and wants to just understand what changed to backport that in their own application. Do you think it's doable? |
Yep, makes sense! I'm on it |
ea4a79b
to
5ff6913
Compare
The Address custom state validation methods are being extracted and refactored into a separate, configurable class.
5ff6913
to
6c89b24
Compare
I've extracted the fix for #3098 into a separate PR (merged into master), this way it should be easier to backport the fix on stores unable to upgrade. |
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 @cedum !
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.
@cedum just left a comment on a deprecation message, but other than that it's good to go!
Refactors and extract Address state normalization and validation logic into a separate and configurable service object. This enables the developers to customize the state validation in a more clean way by instead of monkey patching private methods.
When saving a credit card, pre-create the country and state as address attributes instead of passing the id "1". By having the objects pre-created explicitly, it will cause less surprises.
6c89b24
to
ada6fa3
Compare
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.
@cedum thank you 👍
Description
Deprecates and refactors state validation by extracting out the normalization and validation logic into a separate service-like object, which might be also user-provided, for example:
The following private methods have been deprecated from
Spree::Address
model:state_validate
validate_state_matches_country
This PR introduces the following configuration flag
Spree::Config.use_legacy_address_state_validator
that enables to switch from the old state validation behavior to the new in a smooth way.For newly generated applications, this flag is set to
false
, which means it will use the new state validator class.For existing applications upgrading to Solidus v2.11 it is set to
true
, hence keeping the same behavior as in the previous Solidus versions.Checklist: