-
Notifications
You must be signed in to change notification settings - Fork 69
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
Show a loading UI when accepting a dispute is in progress #7476
Conversation
Test the buildOption 1. Jetpack Beta
Option 2. Jurassic Ninja - available for logged-in A12s🚀 Launch a JN site with this branch 🚀 ℹ️ Install this Tampermonkey script to get more options. Build info:
Note: the build is updated when a new commit is pushed to this PR. |
Size Change: +36 B (0%) Total Size: 1.43 MB
ℹ️ View Unchanged
|
FYI, I've requested a review but am yet to change the button text to Feel free to review aside from this change. |
@nikkivias I've requested a review from you if you want to take a look. It is probably easiest to review the screen recordings I've added. FYI, I am yet to change the button text to |
@Jinksi The transition has improved significantly as it no longer jumps into the next screen. I'm noticing other parts that don't quite match the Figma design though. Particularly the accept button which is outlined with only little side paddings (instead of Text only version), and the size of the modal is quite wide. ![]() ![]() ![]() ![]() |
Thanks for your feedback @nikkivias.
This button uses the text-only Screen.Recording.2023-10-23.at.15.41.02.mov
✅ I've fixed the max-width of the modal to match the design (600px). ![]() ✅ I've also updated the button label to |
Thank you for actioning on those last 2 @Jinksi everything looks good! |
Thanks @nikkivias! Requesting a code review from @Automattic/helix before merging. |
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.
Tested and the new UI and submitting progress state is a vast improvement 🚀
I added some comments about renaming and/or refactoring the code to simplify (TLDR – make the code a closer match for what the merchant experiences). None of this is blocking, though renaming isLoading
is probably safe and impactful.
}: { | ||
dispute: Dispute; | ||
isLoading: boolean; | ||
} ): AcceptDisputeProps { |
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.
getAcceptDisputeProps
is pretty strange to read and reason about. I think this code would be a lot clearer if it just had a dedicated modal for each case (inquiry vs dispute). AcceptDisputeProps
is a domain-specific interface for a semi-generic modal (e.g. modalLines
); I don't see a benefit to that over using the React components we have (i.e. a powerful, readable, flexible modal API).
That said, I don't know if it's safe/worthwhile to refactor this for this change. I would be tempted 😁
Mentioning because this PR reads as very decoupled – can't really see what changed. Specifically, the button Submitting…
label should be an implementation detail inside a modal component. I find it strange (and complex) that this is delegated to a function (that now needs a new param).
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.
Yes, I agree and I began a refactor of this code in #7339, but it became low-priority and out-of-scope due to time constraints.
I think a refactor should be handled in a separate PR, as it is a more significant quantity of work and is separate from this PR's goal.
client/payment-details/dispute-details/dispute-awaiting-response-details.tsx
Outdated
Show resolved
Hide resolved
client/payment-details/dispute-details/dispute-awaiting-response-details.tsx
Outdated
Show resolved
Hide resolved
@@ -346,7 +358,7 @@ const DisputeAwaitingResponseDetails: React.FC< Props > = ( { | |||
'transaction_details', | |||
} | |||
); | |||
setModalOpen( false ); |
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.
Curious why we didn't use onModalClose
before.
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.
Same! I don't have an answer.
@@ -171,6 +177,9 @@ const DisputeAwaitingResponseDetails: React.FC< Props > = ( { | |||
} = useContext( WCPaySettingsContext ); | |||
|
|||
const onModalClose = () => { | |||
if ( isLoading ) { | |||
return; | |||
} |
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.
More renaming suggestions 😁
onModalClose
reads strange to me – what is its purpose? Currently the name is based on where it is bound (a kind of coupling?). With the addition of the early return, it's becoming abstract, e.g. onModalClose() { if isLoading don't close }
.
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've renamed it to handleModalClose
in 27e7621 – does this make more sense?
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.
A tiny bit!
Fixes #7473
Changes proposed in this Pull Request
This PR improves the "Accept dispute" merchant flow by showing a loading state within the Accept dispute modal when the accept dispute fetch request is in progress.
Before:
After:
TODO
Accepting...
when in progress.Testing instructions
Dispute: Needs response
4000000000000259
at checkout.Disputed: Lost status
.This dispute was accepted and lost on {date}
.Inquiry: Needs response
4000000000001976
at checkout.Screen recordings
Screen recording of before without loading state
Accept.dispute.before.mov
Screen recording of happy path (with a slow network to demonstrate loading state)
Accept.dispute.loading.state.mov
Screen recording of network error
Accept.dispute.network.error.mov
npm run changelog
to add a changelog file, choosepatch
to leave it empty if the change is not significant. You can add multiple changelog files in one PR by running this command a few times.Post merge