Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Disputes: Allow merchant to respond to inquiries from transaction detail page #7298
Disputes: Allow merchant to respond to inquiries from transaction detail page #7298
Changes from all commits
0f6c3d7
20889d6
9d5edad
5d45406
7f24785
8a6166c
24d86f5
a6ae0f3
e5e2c42
4556951
b3c605c
5cb3447
f33745d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Splitting off the key bits of content to another helper function is making this harder to understand IMO. This component is tightly coupled to
getAcceptDisputeProps
.I don't fully understand the different conditions needed here (e.g. how many combinations are needed). It might be possible to simplify this code by having a single component with inline conditionals, or various components hard-coded for the common scenarios, and one conditional to choose which to render.
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.
Hunch… if we made a component for inquiries and a component for disputes, would that make this more readable and reduce the amount of data we need to pass down as props?
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 was kind of the approach I explored in #7339.
I am tackling a similar problem with the inquiry steps to resolve PR (#7292) and I think separate components might help.
I don't think we should risk pushing back the project timeline for this, however. Can we ship this with 6.6 as-is and do a small tidy-up refactor once all of the code is in place?
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.
Yeah totally, I don't want any of this to slow us down. We can always maintain, refactor, tidy in future :)
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.
Reviewing this again as I register tracks events. I really want to refactor this,
AcceptDisputeProps
is an abomination!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 started on this refactor in #7339, which may help or may not. I will close it if not.
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.
Awesome! @Jinksi Do you recall where you got to / if this was feeling like positive improvement? Great to have work-in-progress to build on, though I'm happy for you to keep moving on it.
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 wrote up further in this thread that I was unsure if it was an improvement. I'll have to revisit this with fresh eyes and see.
#7298 (comment)
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 find the nested
isInquiry
ternaries a bit hard to follow. This might benefit from separate components, e.g.DisputeActions
&InquiryActions
.This is not a major concern, however.
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 sold on splitting the Dispute / Inquiry paths. But agree that it's not easily readable.
I'll have a go at breaking this up into something more manageable.
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 think this is quite subjective, so feel free to leave as-is!
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 tried to split it off but it was challenging given the
isModalOpen
,setModal
and,onModalClose
that had to be passed on.I have opted instead for a function that returns the various properties rather than all the ternaries.
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 PR works as intended, so I don't think my uncertainties below should hold up this PR being shipped. This is a tricky subject that I struggle to find the correct answers for (see a very similar discussion in #7047 (comment)).
I do think you've improved the readability of this code by the mapping of the labels etc – this more clearly separates what is for inquiries and what is for disputes.
However, I still find this entangled a bit and hard to follow. There are still some
isInquiry
ternaries outside of the modal, e.g. clickingissue refund
/accept
will do different things – inquiries probably wants to be aButton href={orderUrl}
rather thanButton onClick={window.location.orderUrl}
.I've explored another way to write this in #7339, the pseudocode TLDR is:
I'm unsure if this is more or less readable as a whole than the existing solution.
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.
Having to parameterise the button names and the tracks events is a signal that the UI is too generic. It's ok to implement a simple component with hard-coded content and single purpose.
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 really generic and tightly coupled to
disputeAcceptAction
– to understand this code, requires reading whole file. How can we reduce that load?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's like an interface for generically rendering a modal. I don't think we need that capability, we can hard-code each modal we want as a self-contained component.
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 side effect of this is that the tracks events both fire the same props, even though they are not relevant for both events. The tracks event name and the props should be nearby in the code (i.e. inline in the
recordEvent()
call) 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.
I think we should consider if we need a new tracks event here.
wcpay_dispute_accept_click
doesn't seem like it is a suitable event for tracking when the merchant clicksView Order to Issue Refund
.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.
Is your concern here for the naming? Or the use of the same event?
I agree the naming is off, maybe something like
wcpay_dispute_modal_accept
While it may not be super clear that the button says something different for Inquiries, we can note this and as the dispute status is passed through with this event it is distinguishable
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.
Reading the "event or props" part of the tracks cheat sheet ( PdjTHR-2FU-p2 ) helped to clarify my thoughts here:
In this case, I think the user intention that we are tracking is different:
wcpay_dispute_accept_click
is fine here I think.wcpay_inquiry_view_order_click
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 added a new event for both. I see them as simple UI, the user clicks
button
or the user clicksmodal button
. The actual acceptance or viewing of the order can be tracked separately.I don't think it hurts at all to keep the tracking for inquiries/disputes separate 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.
Nice! I've updated the event names to what I think you intended (feel free to correct me if I'm mistaken). 5cb3447