-
Notifications
You must be signed in to change notification settings - Fork 104
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
chore: [PE-678] CGN partner detail change go to website from button to list item #6300
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6300 +/- ##
==========================================
- Coverage 48.42% 47.01% -1.42%
==========================================
Files 1488 1803 +315
Lines 31617 36547 +4930
Branches 7669 8652 +983
==========================================
+ Hits 15311 17181 +1870
- Misses 16238 19309 +3071
+ Partials 68 57 -11
... and 1420 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
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 little summary of request changes:
- Update sentences
- Simplify the conditional rendering for better readability
- Replace array index with unique identifiers
- Remove redundant fragment that contain only one (line 132 to 197)
locales/it/index.yml
Outdated
@@ -2717,7 +2717,7 @@ bonus: | |||
description: Descrizione | |||
contactInfo: Contatti e informazioni | |||
cta: | |||
website: Vai al sito del partner | |||
website: Visita al sito del partner |
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.
Update the string to: Visita il sito del partner
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.
OMG such a typo, thanks!
locales/en/index.yml
Outdated
@@ -2717,7 +2717,7 @@ bonus: | |||
description: Description | |||
contactInfo: Addresses | |||
cta: | |||
website: Go to partner's website | |||
website: Visit to partner's website |
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.
Update the string to: Visit the partner's website
@@ -188,7 +139,7 @@ const CgnMerchantDetailScreen = () => { | |||
snapToEnd={false} | |||
contentContainerStyle={{ | |||
flexGrow: 1, | |||
paddingBottom: safeBottomAreaHeight | |||
paddingBottom: bottomMargin |
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.
Rename it to paddingBottom and pass it as shorthand
{showGotToWebsite && showAddresses ? <Divider /> : null} | ||
{merchantDetail.value.addresses?.map((address, index) => ( | ||
<CgnAddressListItem | ||
item={address} |
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.
Using array indices as keys in React can lead to issues with component state and performance, especially when the list can change. Instead, you should use a unique identifier for each item.
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.
unfortunately address is as embedded value, no unique identifiers available from backend as of now
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 saw we had installed the uuid library. In that case I suggest you to use it to generate unique keys for each item instead of relying on array indices
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.
that would be using random keys, index is just as good as a random value
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.
Oh correct. Could the address serve as a unique identifier for each merchant, or do you think that could be problematic due to multiple businesses sharing the same location?
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 don't have a strong opinion on this, but since there can only be up to 3 addresses, performance edge cases are not a concern here. Especially since the backend doesn't provide an ID, I think using the index or a UUID would be equally fine in this case. However, I would avoid using the address name as a key, because—even though it's unlikely—there's still a very small chance that a merchant could enter duplicate addresses (even by mistake).
What do 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.
Both using the index or a UUID would work, but I would lean toward UUID for flexibility and to avoid potential issues with reordering or modifying the address list
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.
At the moment, there is no action involving modifying, reordering, or expanding the data (there will always be a maximum of 3 addresses), so using the index is not incorrect. However, to be future-proof, in case at some distant point we decide to introduce a more dynamic way of handling these addresses, like reordering or similar changes, we could consider using UUIDs. What do 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.
We are on the same page
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.
Should be the same. Good catch! I think we can move on now!
merchantDetail.value.addresses, | ||
merchantDetail.value.allNationalAddresses | ||
)} | ||
{showAddresses || showGotToWebsite ? ( |
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 suggest to replace the ternary operator (? :) with the logical AND (&&) operator in our conditional renderings for better readability and simplicity.
Short description
CGN partner detail change go to website from button to list item.
List of changes proposed in this pull request
How to test