-
Notifications
You must be signed in to change notification settings - Fork 357
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
change: [M3-7813] - Allow the disabling of the TypeToConfirm input #10251
Conversation
@@ -64,8 +66,9 @@ export const TypeToConfirmDialog = (props: CombinedProps) => { | |||
const [confirmText, setConfirmText] = React.useState(''); | |||
|
|||
const { data: preferences } = usePreferences(); | |||
const disabled = | |||
const isPrimaryButtonDisabled = |
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.
Just changing the const name to make things clearer what element is meant to be disabled by those conditions
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 there ever a case where we would want isPrimaryButtonDisabled
to be false
when the disableTypeToConfirmInput
prop is true
?
I’m imagining a scenario where a user who has disabled type-to-confirm in their preferences is able to proceed with some action while a user who has type-to-confirm enabled gets blocked by the disabled input field, but I might not be understanding the logic fully
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.
hmmm - trying to wrap my head around this - I don't think so? It feels to me like if the user has type-to-confirm disabled, we'd just need to rely on API errors as it is currently? Hope that answers this concern - what's implemented here really merely a visual helper so I am trying to think of it in the simplest way possible. Do you have any other suggestion as to how handling 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.
You're changes look good.
On a side note (for another ticket), I find it odd that I can't manually disable the "Delete" button in the dialog. I would imagine that if there's still Linodes assigned to the PG and type-to-confirm is disabled, the Delete
button should be disabled and we shouldn't rely on the API to deny the user.
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.
Yup, i hear that. This component was breaking a few things so I fixed things in 53ffd9f
Mostly, the issue is that the disabled
prop was broken. Please see my comments on this commit
inputProps={{ | ||
disabled: isDisabled, | ||
}} | ||
disableTypeToConfirmInput={isDisabled} |
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.
Making this update for the Placement Group delete modal since we want to prevent the use trying to type to confirm considering it will not enable the submit button
/** | ||
* Chidlren are rendered above the TypeToConfirm input | ||
*/ | ||
children?: React.ReactNode; | ||
/** | ||
* Props to be allow disabling the input | ||
*/ | ||
disableTypeToConfirmInput?: boolean; | ||
/** | ||
* The entity being confirmed | ||
*/ | ||
entity: EntityInfo; |
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.
++ for all these awesome doc comments!
@@ -64,8 +66,9 @@ export const TypeToConfirmDialog = (props: CombinedProps) => { | |||
const [confirmText, setConfirmText] = React.useState(''); | |||
|
|||
const { data: preferences } = usePreferences(); | |||
const disabled = | |||
const isPrimaryButtonDisabled = |
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.
You're changes look good.
On a side note (for another ticket), I find it odd that I can't manually disable the "Delete" button in the dialog. I would imagine that if there's still Linodes assigned to the PG and type-to-confirm is disabled, the Delete
button should be disabled and we shouldn't rely on the API to deny the user.
Coverage Report: ✅ |
/** | ||
* Props to be allow disabling the submit button | ||
*/ | ||
disableTypeToConfirmSubmit?: boolean; |
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 to replace the disabled
prop (which I omitted from the types) so the nomenclature is very clear as to what element we're looking to disabled
@@ -68,12 +72,13 @@ interface TypeToConfirmDialogProps { | |||
|
|||
type CombinedProps = TypeToConfirmDialogProps & | |||
ConfirmationDialogProps & | |||
Partial<TypeToConfirmProps>; | |||
Partial<Omit<TypeToConfirmProps, 'disabled'>>; |
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 leads to confusion since we may want both the input & and the button to be disabled for different reasons
@@ -103,7 +87,6 @@ const CloseAccountDialog = ({ closeDialog, open }: Props) => { | |||
subType: 'CloseAccount', | |||
type: 'AccountSetting', | |||
}} | |||
disabled={!canSubmit} |
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 has 0 effect
setCanSubmit(false); | ||
} | ||
}, [inputtedUsername, profile]); | ||
|
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 dunno why this code was here, but it was trying to do the same thing the TypeToConfirmDialog does by default (I fixed it cause the e2e was failing)
|
||
await findByTestId('textfield-input'); | ||
|
||
const input = getByTestId('textfield-input'); | ||
fireEvent.change(input, { target: { value: 'this-cluster' } }); | ||
|
||
expect(button).toHaveAttribute('aria-disabled', '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.
this was a false positive!
This is much better - 🚢 |
It appears the e2e failures (volume) are unrelated |
…eature/namespace-create * 'develop' of https://github.com/vrajesh73/manager: (89 commits) fix: [M3-7269] - Display parent email in user menu when no company name is available for restricted parent user (linode#10248) fix: [M3-7817] - Show correct status of Child Account Enabled column for parent users (linode#10233) upcoming: [M3-7616] - Add Placement Groups Events and Notifications (linode#10221) upcoming: [M3-7816-v2] - Adjust logic for when to show Switch Account button (linode#10266) fix: [M3-7831] - Persisting error messages in ACLB delete dialogs (linode#10254) upcoming: [M3-7842] - Update Assign Linode Drawer and improve query skipping (linode#10263) upcoming: [M3-7704] - Disable Cloning, Private IP, Backups for edge regions (linode#10222) test: Fix test flake for Images landing page test (linode#10267) fix: [M3-7824] - ACLB TCP Rule Creation and other fixes (linode#10264) refactor: [M3-7687] - Linodes Restricted User Experience 2/2 (linode#10227) test: Resolve OBJ create and delete E2E test flake (linode#10245) upcoming: [M3-7723] - Placement Group feature flag as object (linode#10256) chore(deps): Bump sanitize-html from 2.11.0 to 2.12.1 (linode#10247) change: [M3-7813] - Allow the disabling of the TypeToConfirm input (linode#10251) upcoming: [M3-7839] - Change Business Partner to Parent User (linode#10259) upcoming: [M3-7835] - Adjust user table column count (linode#10252) upcoming: [M3 7738] - Update Placement Group Create & Edit Drawers (linode#10205) refactor: [M3-7437] - Use `@lukemorales/query-key-factory` for Profile Queries (linode#10241) fix: React Query `updateInPaginatedStore` helper function not working as expected (linode#10249) test: [M3-7497] - Add tests for child user verification banner (linode#10204) ... # Conflicts: # packages/manager/src/MainContent.tsx # packages/manager/src/dev-tools/FeatureFlagTool.tsx
Description 📝
We currently don't have the possibility of disabling the TypeToConfirm input (only its submit button).
In the case of a TypeToConfirm Modal where an action needs to be taken before being abled to delete the entity, we want to be able to disable the input in order for the user to not fill and then to realize they still can't delete it.
This is the case for the
PlacementGroupDeleteModal
for which we need to delete all attached Linodes in order to delete the PlacementGroupChanges 🔄
disableTypeToConfirmInput
prop to allow disabling the inputPreview 📷
Include a screenshot or screen recording of the change
How to test 🧪
Prerequisites
Verification steps
linodes
arrayAs an Author I have considered 🤔
Check all that apply
Commit message and pull request title format standards
<commit type>: [JIRA-ticket-number] - <description>
Commit Types:
feat
: New feature for the user (not a part of the code, or ci, ...).fix
: Bugfix for the user (not a fix to build something, ...).change
: Modifying an existing visual UI instance. Such as a component or a feature.refactor
: Restructuring existing code without changing its external behavior or visual UI. Typically to improve readability, maintainability, and performance.test
: New tests or changes to existing tests. Does not change the production code.upcoming
: A new feature that is in progress, not visible to users yet, and usually behind a feature flag.Example:
feat: [M3-1234] - Allow user to view their login history