-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Domain Management: Implement add new freestanding domain flow #21979
Conversation
# Conflicts: # WordPress/WordPress.xcodeproj/project.pbxproj
Generated by 🚫 dangerJS |
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
...elated/Domains/Domain registration/RegisterDomainSuggestions/RegisterDomainCoordinator.swift
Show resolved
Hide resolved
|
||
// MARK: Public Functions | ||
|
||
func createCart(_ domain: FullyQuotedDomainSuggestion, |
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's the difference between the passed-in domain
param and the property self.domain
?
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.
Good question!
No difference, really. It makes sense to remove this param and depend on the property for consistency.
Resolved in 42c5b70
...elated/Domains/Domain registration/RegisterDomainSuggestions/RegisterDomainCoordinator.swift
Show resolved
Hide resolved
let canOpenNewURL = newURL.absoluteString.starts(with: Constants.checkoutWebAddress) | ||
|
||
guard canOpenNewURL else { | ||
onCancel() |
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.
[Suggestion] There is a critical bug in this implementation. Many times when I was testing, the default account authentication would fail and the Log In page shows up instead of the Checkout page. And since the Log In url doesn't start with Constants.checkoutWebAddress
, the web view is dismissed immediately.
I'm still not sure exactly why the webview authentication fails, but sometimes I could reproduce it when using the proxy ( and other times happens without proxy ). Here is the Sentry issue associated with this error.
I'm not sure exactly how to handle this edge case. In SiteCreationPurchasingWebFlowController
, I haven't thought too much about this issue because the Domain Purchasing during Site Creation
project was just an experiment.
Let me know what you think! 🙇
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.
Interesting! Any idea how I can reproduce this?
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.
@hassaanelgarem I couldn't figure out a way to consistently reproduce that issue, but I remember it happened to many times during development ( using proxy ) and a fewer times in production ( without proxy ).
What do you say we start by logging this event on Sentry or Tracks instead of silently dismissing the Checkout screen?
We can iterate on this later if we see that this happens very frequently.
Also, when logging this event, we should also include the URL that caused the web view to be dismissed.
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.
As discussed on Slack, we suspect this to be a proxy issue. I am hesitant to add error tracking for this, as this is not technically an error. It's only an error if the user is redirected to log in, but in other cases, it is an expected behavior. What do you think?
|
||
let webViewController = WebViewControllerFactory.controllerWithDefaultAccountAndSecureInteraction( | ||
url: url, | ||
source: "domains_register", // TODO: Update source |
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.
Don't forget to follow up on this @hassaanelgarem 👍
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 created this issue to track this: #21996 👍
|
||
let domainPurchasedCallback = { (domainViewController: UIViewController, domainName: String) in | ||
allDomainsViewController.reloadDomains() | ||
} |
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.
[Suggestion] @hassaanelgarem This closure is capturing allDomainsViewController
. I'm not sure if that's going to cause a memory leak or not, what do you think of adding [weak allDomainsViewController] to be safe?
Feel free to ignore this suggestion if you think this is not going to a cause a memory leak.
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 raising this! I don't think it's needed because allDomainsViewController
doesn't have a strong reference to this closure. I've confirmed this using the Memory graph 👍
shouldPush: true) | ||
} | ||
|
||
func presentWebViewForCurrentSite(on viewController: UIViewController) { |
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 curious if we should have a single presentCheckoutWebView
method that handles site vs no-site logic based on whether self.site
is nil
or not. Because right now, it is programmatically possible to:
- Call
presentWebViewForCurrentSite
even thoughself.site
isnil
. Which would result in an error. - Call
presentWebViewForNoSite
even thoughself.site
is notnil
. This wouldn't result in an error, but it might be confusing. We are presenting the Checkout web view for no-site even though the coordinator has a site?
I'm wondering whether it's possible to have an API design where it's programmatically impossible to misuse this coordinator.
Update
Please reply to this comment instead.
|
||
func handleExistingSiteChoice(on viewController: UIViewController) { | ||
print("handleExistingSiteChoice") | ||
} |
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.
Regarding my earlier comment, I just saw these handleNoSiteChoice
and handleExistingSiteChoice
. So basically the coordinator has 5 public methods:
- createCart
- presentWebViewForNoSite
- presentWebViewForCurrentSite
- handleNoSiteChoice
- handleExistingSiteChoice
In my opinion, it is not clear when to use which, and I think there is room for improvements here, for example:
- Cart creation is an implementation detail and should be called internally. Similar to what you did in
handleNoSiteChoice
. So I thinkcreateCart
method should beprivate
. presentWebViewForNoSite
andpresentWebViewForCurrentSite
can also be private and called withinhandleNoSiteChoice
andhandleExistingSiteChoice
.- Maybe
handleNoSiteChoice
andhandleExistingSiteChoice
can be merged into a single public method and handle site vs no-site internally depending on nullability ofself.site
.
I'm not suggesting to make any changes right now, because that would break the existing "My Site > Domains" implementation. But I just wanted to hear you thoughts.
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 taking the time to make these thoughtful suggestions!
I do agree with most of this. And I have tried to address these suggestions in #21998, which builds on this PR, specifically in af5cf72. I did this to avoid causing conflicts.
I didn't merge handleNoSiteChoice
and handleExistingSiteChoice
because I think it would complicate things. But I applied your other suggestions.
Let me know what you think! Either here or in #21998 🙇
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 didn't merge handleNoSiteChoice and handleExistingSiteChoice because I think it would complicate things.
To clarify, there is what I meant by merging those 2 methods:
- Mark
handleNoSiteChoice
andhandleExistingSiteChoice
as private. - Add a new public method that decides whether to call
handleExistingSiteChoice
orhandleNoSiteChoice
based onself.site
func handleDomainPurchasing() {
if let site {
handleExistingSiteChoice(site)
} else {
handleNoSiteChoice()
}
}
private func handleNoSiteChoice() {
...
}
private func handleExistingSiteChoice(_ site: Blog) {
...
}
But I don't have a strong opinion on this, so feel free to decide whether you want make the change.
@hassaanelgarem I've dropped a few more comments but the feature works as described in the test instructions. 👍 |
# Conflicts: # Podfile.lock
Generated by 🚫 Danger |
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.
LGTM!
Closes #21778
Closes #21780
WPKit PR: wordpress-mobile/WordPressKit-iOS#644
Description
This PR adds the first steps for adding a domain which is searching for a new domain. It also integrates with the already implemented "Choice" screen and hooks up the freestanding domain purchase flow.
Recording
Simulator.Screen.Recording.-.iPhone.14.Pro.-.2023-11-06.at.08.30.18.mp4
Testing Instructions
Other than the above flow, please testing the existing domain purchasing flows for regressions:
Regression Notes
Other places where a domain can be purchased:
Testing manually
N/A
PR submission checklist:
RELEASE-NOTES.txt
if necessary.UI Changes testing checklist: