-
Notifications
You must be signed in to change notification settings - Fork 197
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
Add reusable modal component. #5367
Conversation
- Implementation based on the same concept of sensei-modal used in Contact Teacher. -
Codecov Report
@@ Coverage Diff @@
## trunk #5367 +/- ##
============================================
+ Coverage 42.85% 42.86% +0.01%
Complexity 8687 8687
============================================
Files 412 412
Lines 31040 31053 +13
Branches 232 234 +2
============================================
+ Hits 13301 13311 +10
- Misses 17568 17569 +1
- Partials 171 173 +2
Continue to review full report at Codecov.
|
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.
Was there any cross-talk between the development of this PR and #5361? Maybe there is a need for completely separate components, but it seems like there is some amount of overlap.
I suppose maybe not, since #5361 is a confirmation dialog meant for the editor and this is a modal meant to be shared between the editor and the frontend. But I think it is at least worth a look to make sure we're not duplicating efforts.
Hey there. No, there was no cross-talk between the development of this PR and #5361, mainly because #5361 just uses a modal instead of reimplementing it. With this said, I don't see any overlap between this PR and #5361. I see an opportunity for improvement for #5361, though, where we could use this modal instead of the one provided by Gutenberg. However, I think it's only worth doing this if the confirmation dialog was going to be also shown on the frontend, which I don't think it's the case. |
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 am using the @wordpress/icon components – it is working (as you can see in the linked pull request video) but maybe we should avoid that? @renatho ?
I think that's fine! I checked it, and it's not enqueued by WP, but added to the bundle, and it's super small.
When you need. to check it, you can just run the npm run build:analyzer
and check the dependencies.
And about the WP enqueues, you can see the dist files, like this one for this case: assets/dist/interactive-blocks/interactive-blocks-frontend.asset.php
. (Check here if you want more details).
overflow: hidden; | ||
z-index: 2000; | ||
width: 700px; | ||
max-width: 96%; |
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.
Maybe it could be fullscreen for mobile. WDYT?
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.
Yeah, maybe? Let's keep an eye on this thread p6rkRX-3VB-p2 and let's confirm with Andrei how it should look like. I am also a little concerned about the "actions" available in the modals in the latest designs.
- Add jsdoc. - Simplify hidden modal by returning `null` instead of hiding with css class. - Receive close callback because modal won't be ever open from the modal itself. - Fix css for height.
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.
Added some minor changes.
Still pending to decide what the design should look like for mobile and if we need to implement something special for "actions".
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.
Hey there, nice PR overall!
I found an issue while testing this component with 1572-gh-Automattic/sensei-pro with the Twenty Twenty One theme that I think might be worth taking a look.
Basically, this is how the modal appears to me while on Twenty Twenty One (notice that the background also changes while hovering over the modal vs. hovering on the overlay, besides the weird close button):
modal.mp4
At first, I thought it was Firefox being weird, but the same issue also happens on Chrome.
It's worth mentioning that this issue doesn't occur on the editor, and neither occurs when using the theme Twenty Twenty:
modal-other-theme.mp4
The only thing a little weird about this modal on Twenty Twenty theme is that the close button looks...misaligned? Maybe it's worth checking, too, considering that on your video here 1552-gh-Automattic/sensei-pro that doesn't happen.
Apart from that, I left some small comments about the close callback.
Also, it's worth asking: Should this modal still be open if the user presses ESC? Usually, when the user press ESC, the Gutenberg modal calls onClose
and so the modal is closed properly, so that's why I'm asking. :)
I tested with Twenty Twenty after the latest changes in CSS and I don't see the misalignment anymore :)
I added support for ESC here: ccb8fe1 :D thanks! Let me know if you see any other strange thing @fjorgemota |
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.
Nice work! Just a few additional comments. =)
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.
Thank you for the improvements, Aarón! I did a new round of review, and added some extra suggestions here. 😉
<div className={ 'sensei-modal' }> | ||
<button | ||
className="sensei-modal sensei-modal__overlay" | ||
aria-label="Close" |
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 need to add the __
here to make it translatable.
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.
Oops! Now that I noticed it's the overall. I think it's not very good from an accessibility perspective. Maybe we could try to use the same as Gutenberg modal? The __experimentalUseFocusOutside
.
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.
Reimplemented modal using your suggestions here: 0c029ec
* @param {Function} props.onClose Callback to run when trying to close the modal. | ||
* @param {string} props.title The title for the modal. Empty by default. | ||
* @param {Object} props.children The content of the modal. | ||
* @return {JSX.Element} The modal component or null (if not open). |
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 think we don't need the return
here. At some point, we had decided to not add @return
to the React components. But if think it's especially important here, feel free to keep 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.
Removed in here: 1d4574a
* @param {Object} props.children The content of the modal. | ||
* @return {JSX.Element} The modal component or null (if not open). | ||
*/ | ||
const Modal = ( { onClose, title = '', children } ) => { |
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.
Another thing that I realized while checking the Gutenberg Modal is that we're not using Portals here. I think it's important for modal implementations, in order to make it work in any place (if it's in a position relative, in a overflow hidden, or any other weird context).
See it here: https://github.com/WordPress/gutenberg/blob/v13.7.3/packages/components/src/modal/index.js#L124
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.
Added portals in here too: 0c029ec
Co-authored-by: Fernando Jorge Mota <fjorgemota@users.noreply.github.com>
- Reimplemented following a similar approach to the Gutenberg original Modal component. - Modal is focused when component is loaded so that keypress events are handled throw the `onKeyDown` attribute. - Modal is closed when unfocused – replacing the overlay as a button with a normal div.
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.
Looks good and works well! I just needed to tweak a little the original Sensei Pro branch to test. haha 🙂
I just left a final comment, but if has a purpose, feel free to just ignore it. 😉
I was doing some testing and I found that the new implementation breaks when opening the Media Library modal when adding, for example, an Image. It breaks because, when the Media library our modal is unfocused (and closed) making the content of the Media Library modal not appear (not completely sure why). I am now wondering if maybe we should go back to the overlay... what do you think, @renatho ? In order to test the issue:
|
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 to document our recent conversation while approving this:
As we talked, I think we should ignore this problem since we shouldn't have more than one modal open at the same time.
And on the editor side, we'll probably use the Popover component to keep aligned with the new design and avoid this issue.
Fixes: 1446-gh-Automattic/sensei-pro
Changes proposed in this Pull Request
Testing instructions
Discussion
@wordpress/icon
components – it is working (as you can see in the linked pull request video) but maybe we should avoid that? @renatho ?