Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Modal component #6261
Adds a modal component. A more feature rich version of the one used in #6244.
Note: I've attempted to mimic the API from
Controlling whether the modal shows or not is the responsibility of the developer that implements the modal, using the
The modal mounts itself in the document body using
For accessibility reasons, when opening a modal all other elements in the body get an
How has this been tested?
To see an overview of its features go to
To test create a
Types of changes
Rather than relying on a bunch of inline styles it would make sense for such component to have at least some basic styling in place, as otherwise once plugins start to adopt this component we'd be left with a bunch of different looking modals rather than having consistency. If the concern is that the component would then be too limited in how it looks, then maybe a prop could be introduced where it would remove the CSS class which is applying those styles.
I have personally already built my own Modal component for a project which has a custom Map block with the ability to plot markers:
For the most part this modal pretty much matches all the modals already in WordPress Core. The overlay background colour, the shadow on the modal itself, etc.
I think a modal component should at the very minimum have a title prop whilst all of the body of the modal itself is left up to the plugin developer.
Here is the inner markup I've used for my modal:
@paulwilde Thank you for your review. I agree it needs some styling, but because in gutenberg it should not overlay the WordPress-menu I wanted to create a specific gutenberg implementation in
It also accepts classNames for both the content and the overlay. The style prop is mostly to keep it consistent with
Updated instructions to see this modal in action (readme and instructions in the first comment need to be updated):
First, import what is needed:
Then, after the
referenced this pull request
Jul 3, 2018
I also observed an unexpected behavior where multiple
div were created in the parent element. In a strange coincidence, I found this tracked back to another issue I discovered today with
StrictMode where apparently two copies of the component are being constructed, thus the extra node. This will only apply to development environments, not the plugin distributable. It's an issue we should sort through, but outside the scope of these immediate changes.
Jul 4, 2018
@Xyfi @atimmer @omarreiss, what are next steps planned? We still need to provide Plugins API integration with pinning support for easier consumption for plugin developers. I see that #6241 contains some logic in that area. Do you plan to continue working on it or should I put up some PR next week?
This should be discussed during a dev chat and preferably with @helen
Dev chat isn't really the appropriate venue for discussing Gutenberg design issues, that's what the design meetings are for, as well as the editor meetings. There's certainly a discussion to be had over ensuring consistency, but I'll leave it to @karmatosed as the Gutenberg Design Lead to expend on her thoughts here.
Given that Gutenberg introduces a whole pile of new design elements to WordPress, many of which are different to existing elements, it seems to me there's a reasonable argument that Gutenberg is introducing a new design language, so there will be some inconsistencies for a while, as the scope of Gutenberg expands beyond the editor page, to site customisation, and beyond.
I agree with @pento there is no need to have this discussed in a dev chat. This issue works for discussion. If it were to happen in any chat this would be for a design chat, not dev one also. This is talking about inconsistencies in design and would be something the design team (who meet every week) could discuss there. I still think that's the wrong approach and standby it should be within this issue.
In many patterns new design has been created within Gutenberg that doesn't exist in core. Some does, some doesn't. We don't and shouldn't limit everything to what came before. We can respect it but maybe we have a better option and that's to have an open mind about. On merge perhaps over time core will adopt the new modals.
Regarding the modal, ideally we do have one treatment but we don't have to be limited by what exists today in core. Therefore, I standby the work done here so far.
We agree we disagree