feat: delete confirm modal#3024
Conversation
openedx-webhooks
added
the
open-source-contribution
|
Thanks for the pull request, @jesperhodge! 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. DetailsWhere 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 Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3024 +/- ##
========================================
Coverage 95.47% 95.47%
========================================
Files 1383 1384 +1
Lines 32645 32652 +7
Branches 7472 7246 -226
========================================
+ Hits 31168 31176 +8
- Misses 1408 1420 +12
+ Partials 69 56 -13 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mgwozdz-unicon
left a comment
mgwozdz-unicon
left a comment
There was a problem hiding this comment.
I tested this locally and I believe it works as intended. However, please see comments regarding PR split and recommended code comments.
| row.original as unknown as TagListRowData | ||
| ); | ||
|
|
||
| export const getTagWithDescendantsCount = (rowData: TreeRowData): number => { |
There was a problem hiding this comment.
I think it would be good to add a comment explaining in more detail how the Descendant count is being calculated as I could see this potentially being confusing to someone who's picking this code up for the first time.
| @@ -0,0 +1,33 @@ | |||
| import { getTagWithDescendantsCount } from './utils'; | |||
|
|
|||
| describe('getTagsWithDescendantCount', () => { | |||
There was a problem hiding this comment.
I think it would be good to add a comment explaining in more detail how the Descendant count is being calculated as I could see this potentially being confusing to someone who's picking this code up for the first time.
| /> | ||
| <> | ||
| <div className="d-flex justify-content-end mb-3"> | ||
| {/* TODO: remove after testing */} |
There was a problem hiding this comment.
If the Open edX Core Contributor reviewers disagree with me here, then I defer to their preference. However, I don't think this PR is safely functionally separate from #3025 . Personally, I don't consider it okay to merge code with testing artifacts visible in the frontend because I believe that a merged PR should be ready for prod. Either this PR should have been in the Draft state until the testing artifact is removed or these 2 PRs should be combined back together. Additionally, I don't like submitting PRs dependent on each other that don't have to be. As much as possible, each PR should be able to function in production on its own with no dependencies, and to me, those things are a higher priority than shrinking PR size.
There was a problem hiding this comment.
I agree with you, though in this case I think the simplest approach is to review and test this PR with the test button in place and then delete it before merging the PR. That can be done by adding the button with a separate commit that uses the temp: prefix and keeping the PR in a draft state until that's removed.
By the way, I wish we had a storybook-like "guide to available UX patterns" page for developers in the app somewhere, which would be a another way of solving this problem. I did this on a past project and I really liked the approach.
Alternately, this could be incorporated into the other PR and just try to use commits to keep things separate for reviewers.
There was a problem hiding this comment.
That makes sense. I agree that the simplest approach is to revert the PR to draft or treat it as if it's in draft until the test button is removed.
brian-smith-tcril
added
the
create-sandbox
brian-smith-tcril
left a comment
brian-smith-tcril
left a comment
There was a problem hiding this comment.
Overall I like the direction this is heading, but it's not ready to merge.
I started by reading through the code and left a few comments. I then created a sandbox and I found a few issues when testing.
| import React from 'react'; | ||
| import userEvent from '@testing-library/user-event'; | ||
| import { IntlProvider } from '@edx/frontend-platform/i18n'; | ||
| import { fireEvent, render, screen } from '@testing-library/react'; |
There was a problem hiding this comment.
It's generally best practice to use userEvent instead of fireEvent. See https://testing-library.com/docs/user-event/intro/#differences-from-fireevent
| cancelLabel: string; | ||
| X: string; | ||
| // any additional context that the caller wants to pass to the onConfirm callback; not a React context. | ||
| context?: Record<string, any> | null; |
There was a problem hiding this comment.
The fact that this needs a descriptive comment makes me think we could probably use a better name here, maybe something like callbackParams?
There was a problem hiding this comment.
I decided to go with confirmPayload since that's where this context is getting passed.
| <ModalDialog.Footer> | ||
| <Button variant="tertiary" onClick={handleCancel}> | ||
| {cancelLabel} | ||
| </Button> | ||
| <Button onClick={handleConfirm} disabled={!confirmedByTyping} variant="danger"> | ||
| {confirmLabel} | ||
| </Button> | ||
| </ModalDialog.Footer> |
There was a problem hiding this comment.
The spacing in here is off, the examples in https://paragon-openedx.netlify.app/components/modal/modal-dialog/ have the footer buttons in an ActionRow, I think that'll likely fix the spacing.
| const messageText = intl.formatMessage(messages.typeToConfirmInstruction, { X }); | ||
| const parts = messageText.split(X); | ||
| return ( | ||
| <> | ||
| {parts[0]} | ||
| <strong>{X}</strong> | ||
| {parts[1]} | ||
| </> | ||
| ); | ||
| })()} |
There was a problem hiding this comment.
Is there a time when we'd use the "Type X to confirm" without <strong>? The "with rich text formatting" example in the formatjs api docs https://formatjs.github.io/docs/react-intl/api/ has
const messages = defineMessages({
greeting: {
id: 'app.greeting',
defaultMessage: 'Hello, <bold>{name}</bold>!',
description: 'Greeting to welcome the user to the app',
},
})
intl.formatMessage(messages.greeting, {name: 'Eric', bold: str => <b>{str}</b>})and in the live code editor there I tested
const messages = defineMessages({
greeting: {
id: 'app.greeting',
defaultMessage: 'Hello, <strong>{name}</strong>!',
description: 'Greeting to welcome the user to the app',
},
})
intl.formatMessage(messages.greeting, {name: 'Eric', strong: str => <strong>{str}</strong>})and it worked
| if (e.key === 'Enter') { | ||
| onConfirm(context); | ||
| } |
There was a problem hiding this comment.
This isn't closing the modal.
Screencast.From.2026-04-27.14-52-35.mp4
There was a problem hiding this comment.
I guess the other question is, "do we want this functionality?" Should hitting enter while in the input box count as confirmation? I'd think needing to tab over to the "Delete Tags" button would be reasonable (and less likely to result in unexpected behavior)
There was a problem hiding this comment.
Good point. Since the acceptance criteria do not require Enter from the text input to confirm, I’m going to remove that shortcut and require users to explicitly activate the enabled Delete Tags button. Keyboard users can still tab to the button and press Enter, and this keeps the destructive action a little more intentional.
Co-authored-by: Copilot <[email protected]>
|
This is superseded by #3033 |
brian-smith-tcril
removed
the
create-sandbox
* feat: delete confirm modal * docs: add todo to remove code * fix: lint * fix: address comments on PR #3024 Co-authored-by: Copilot <[email protected]> * feat: Remove testing artifacts * fix: Remove unused variable --------- Co-authored-by: Jesper Hodge <[email protected]> Co-authored-by: Copilot <[email protected]>
7 participants
Description
This is part of openedx/modular-learning#260 - a split-out so that it's smaller PRs to review.
The intention is to have a type confirm modal for deletions, but keep the actual deletion logic separate.
Important
The test button needs to be deleted before merging this.
Testing instructions
Use of AI
Best Practices Checklist
We're trying to move away from some deprecated patterns in this codebase. Please
check if your PR meets these recommendations before asking for a review:
.ts,.tsx).propTypesanddefaultPropsin any new or modified code.src/testUtils.tsx(specificallyinitializeMocks)apiHooks.tsin this repo for examples.messages.tsfiles have adescriptionfor translators to use.../in import paths. To import from parent folders, use@src, e.g.import { initializeMocks } from '@src/testUtils';instead offrom '../../../../testUtils'