-
Notifications
You must be signed in to change notification settings - Fork 50
Hide dangerous operations behind configuration option #1025
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
Conversation
🦙 MegaLinter status: ✅ SUCCESS
See errors details in artifact MegaLinter reports on CI Job page MegaLinter is graciously provided by OX Security |
kostko
commented
Sep 24, 2022
821766f to
3838d62
Compare
Codecov Report
@@ Coverage Diff @@ ## master #1025 +/- ## ========================================== - Coverage 88.75% 87.20% -1.55% ========================================== Files 102 108 +6 Lines 1778 1852 +74 Branches 411 436 +25 ========================================== + Hits 1578 1615 +37 - Misses 200 237 +37
Flags with carried forward coverage won't be shown. Click here to find out more.
|
csillag
commented
Sep 24, 2022
Obviously, some tests need to be added, but first I wanted to get some feedback on the basics.
@lukaw3d
lukaw3d
left a 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 love the UX flow
- there's instructions on why confirm button is missing
- opening settings as modal doesn't destroy the unfinished transaction
- there's wait time on the button
3838d62 to
cdf1ccb
Compare
csillag
commented
Sep 27, 2022
@lukaw3d I have addressed all the feedback. Thanks.
109cd65 to
d1f488e
Compare
We have discussed the design with @donouwens. His main feedback was that it would be nice if the settings dialog could be opened directly from within the dangerous modal dialogs. However, @lukaw3d has explained that Grommet has an obscure issue with pop-ups being opened from pop-ups.
So I have created an implementation which supports opening the settings dialog, but in a way that first it closes the existing modal, then it brings up the settings dialog, and when we close that, it brings up the original modal dialog again.
I'm not fully satisfied with the implementation, because I feel that the logic and APIs for dealing with the modal are now so complex that they should be implemented in a redux store, via proper actions, instead of locally managed react hooks state, passed along in a react context.. I will refactor that after we have confirmed that this behavior is what we want from the UI/UX POV.
lukaw3d
commented
Oct 19, 2022
popup in popup issue reference: #863
Also, in modals, improve handling of danger, and add delays.
- The state is handled in Redux - No more ModalProvider - pop-up in pop-up is now supported (recursively)
39da44e to
8f4da1e
Compare
csillag
commented
Oct 20, 2022
I'm not fully satisfied with the implementation, because I feel that the logic and APIs for dealing with the modal are now so complex that they should be implemented in a redux store, via proper actions, instead of locally managed react hooks state, passed along in a react context..
I have refactored Modal so that
- The state is stored in Redux
- It now be opened recursively. (When opening a new one, we always close the previous one and stash it, to be re-opened later.)
I like it better now, however there is one drawback: the handleConfirm functions (which are part of the modal definition) are now also stored in the Redux store. Redux doesn't like non-serializable data in the store, so I had to add specific instructions to make it stop complaining.
lukaw3d
commented
Oct 24, 2022
one drawback: the handleConfirm functions (which are part of the modal definition) are now also stored in the Redux store. Redux doesn't like non-serializable data in the store, so I had to add specific instructions to make it stop complaining.
This will probably cause problems with redux-saga, webext-redux, redux-state-sync, or future libraries we may want. I don't think this simple settings shortcut is worth breaking redux's best practice
To reduce complexity I'd rather have any of:
- remove settings shortcut
- or ignore accessibility bug for this rare feature
- or fix accessibility bug upstream
This PR adds the following things:
Implement a settings dialog, accessible from the sidebar, currently with a single setting: the "danger mode". (For background, see here)
dialog
Updates the behavior of the modal dialogs, when the
isDangerousflag is specified. The new behavior is as follows:modal