-
Notifications
You must be signed in to change notification settings - Fork 119
feat: New delete confirmation modal [FC-0083] #1906
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
base: master
Are you sure you want to change the base?
feat: New delete confirmation modal [FC-0083] #1906
Conversation
Thanks for the pull request, @ChrisChV! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1906 +/- ##
========================================
Coverage 93.82% 93.82%
========================================
Files 1147 1147
Lines 23973 23990 +17
Branches 5054 5167 +113
========================================
+ Hits 22492 22508 +16
- Misses 1413 1414 +1
Partials 68 68 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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 👍
Thank you for your work, @ChrisChV!
- I tested this using the instructions from the PR
- I read through the code
- I checked for accessibility issues
- Includes documentation
I left one non-blocking comment about moving some things around.
Let me know what you think!
const { client, indexName } = useContentSearchConnection(); | ||
const { | ||
hits: componentHit, | ||
} = useContentSearchResults({ | ||
client, | ||
indexName, | ||
searchKeywords: '', | ||
extraFilter: [`usage_key IN ["${usageKey}"]`], | ||
limit: 1, | ||
enabled: true, | ||
skipBlockTypeFetch: true, | ||
}); | ||
|
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 do you think about creating a useComponentUnits
hook for this?
Also, I believe that if you move the fetch call to the ComponentDeleter
, you will not need to replicate this on the LibraryUntiBlocks
.
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 added the useComponentsFromSearchIndex
in 917421d.
About moving the fetch all to the ComponentDeleter
, I think I would add more calls, in the case of the card component, that information is already available from the search index, and if we add it to the ComponentDeleter
, it would be called again
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.
@ChrisChV Can we move the call inside of ComponentMenu
while still accepting units
prop and only fetch if the prop is not passed?
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.
Or another solution would be to put it inside the ComponentDeleter
and change to render it conditionally, like {isConfirmingDelete && <ComponentDeleter usageKey={usageKey} isConfirmingDelete={isConfirmingDelete} cancelDelete={cancelDelete} />}
.
That way, the component is only rendered when the dialog opens, saving the extra calls.
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.
Refactored here: 6291f67
<ComponentMenu | ||
usageKey={usageKey} | ||
unitsData={(componentHit as ContentHit[])?.[0]?.units} | ||
/> |
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.
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.
Refactored here: 6291f67
@navinkarkera This is ready for another review. I asked Product about the final design: #1685 (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.
@ChrisChV Looks good 👍
- I tested this: (Verified units info in delete component)
- I read through the code
- I checked for accessibility issues
- Includes documentation
@bradenmacdonald This is ready for your review as CC |
Description
units
dict on the search document to verify the new state of the delete confirmation modal.Supporting information
Testing instructions
Other information
N/A