-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Gutenboarding: Domain Picker Modal #41212
Conversation
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~5802 bytes added 📈 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
@dubielzyk Yes, that's possible. However, that doesn't solve the issue where user cannot exit the modal. |
Clicking confirm closes the screen so it should :) |
Ah okay, I made some decisions based on some assumptions, e.g. |
onDomainConfirm removed. Temporary close button on modal removed. |
Oops, I didn't foresee that gutenboarding content longer than the domain modal will coz the content behind the show. Need to rethink modal/scrollbar implementation. It's actually not a bad idea if domain is a page by itself, just need to know which route to go back to? Or quick and dirty is to css limit the height of page content when modal is rendered. |
This seems relevant; #40885 — i.e. ensuring that something is always selected before hitting "confirm". Can be separate PR. |
Another (perhaps simpler?) option could be signal the container to freeze scrollers underneath e.g. by applying wrapper |
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.
A first round of feedback to work on.
/** | ||
* External dependencies | ||
*/ | ||
import React, { FunctionComponent } from 'react'; |
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.
Let's start using this form everywhere:
import React, { FunctionComponent } from 'react'; | |
import * as React from 'react'; |
Some context: https://twitter.com/sebmarkbage/status/1250284377138802689
This also seems to be the TypeScript convention.
client/landing/gutenboarding/components/domain-picker-modal/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/gutenboarding/components/domain-picker-popover/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/gutenboarding/components/domain-picker-popover/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/gutenboarding/components/domain-picker/index.tsx
Outdated
Show resolved
Hide resolved
return ( | ||
<div className="domain-picker-popover"> | ||
<Popover | ||
focusOnMount={ isMobile ? 'container' : 'firstElement' } |
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 seem to get the input focused on mobile now. Is that a regression?
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.
Fixed. useViewportMatch
returns false on initial mount, causing the popover to focus on the search input, then after that, it updates itself to true, which at this point, the search input was already in focused. The solution was to keep the DomainPickerPopover component warm, mounted but renders nothing until isOpen
flag is set to true. f81559a#diff-3acfaab9099bccb32e73498b4be055a4R41-R46
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.
Oh, that's a shame. It looks like something that could be improved in useMediaQuery
:
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.
Created an issue WordPress/gutenberg#21676.
@@ -2,18 +2,16 @@ | |||
* External dependencies |
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.
It might be time to organize all these under a domain-picker
directory:
domain-picker/
- index - re-exports whatever makes sense (modal, popover, the contents?)
- modal
- popover
- …
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.
Created an issue for this. #41221
client/landing/gutenboarding/components/domain-picker-modal/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/gutenboarding/components/domain-picker-modal/index.tsx
Outdated
Show resolved
Hide resolved
Turns out to be an easy fix. |
Alright, these are fixed and we're ready for 2nd round of review:
|
From this PR, we'll branch out 3 other PRs for:
|
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.
Love this! I left a few minor comments. And I found one issue regarding persistence that might be a bit complicated to fix, can be in another PR.
When you pick a domain and refresh the page, the domain is persisted alright, but the picker modal doesn't seem to be aware of this information and does a new search based on the site title. I'm not sure how can we go about fixing this.
client/landing/gutenboarding/components/domain-picker-modal/style.scss
Outdated
Show resolved
Hide resolved
client/landing/gutenboarding/components/domain-picker-modal/style.scss
Outdated
Show resolved
Hide resolved
.domain-picker-modal-overlay { | ||
// Absolute positioning allows the modal | ||
// to reuse the <body> element's scrollbar. | ||
position: absolute; | ||
|
||
// This positions the domain picker modal | ||
// right below the gutenboarding header, | ||
// keeping the header clickable. | ||
top: 64px; | ||
left: 0; | ||
|
||
// Using min-height lets the overlay cover | ||
// the entire viewport ensuring nothing behind | ||
// it can be seen. | ||
// | ||
// When the domain picker's content is taller | ||
// than the viewport height, it will expand taller | ||
// than the provided min-height, triggering | ||
// the appearance of the <body> element's scrollbar. | ||
min-height: calc( 100vh - 64px ); | ||
width: 100%; | ||
|
||
background: var( --studio-white ); | ||
} |
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.
Beautiful comments. Thanks!
.domain-picker-modal { | ||
|
||
.domain-picker__panel-row-main { | ||
padding: 64px 88px; |
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.
These numbers seem a bit magical. Can comment on what they are and maybe use variables.
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.
Thanks! They are intended to mimic onboarding block's margins and header margins. All ambigous numbers have been replaced with variables or proper mixins. e608b09
return ( | ||
<div className="domain-picker-popover"> | ||
<Popover | ||
focusOnMount={ isMobile ? 'container' : 'firstElement' } |
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.
Created an issue WordPress/gutenberg#21676.
Created a follow-up issue. #41228 |
Changes proposed in this Pull Request
This PR introduces Domain Picker Modal which is enabled via the
gutenboarding/domain-picker-modal
feature flag.There are some architectural decisions being made here so feel free to review & discuss them in this PR.
The component tree looks like this:
Here are the list of changes:
This new component uses the
react-modal
component and reuses theDomainPicker
component. It reuses<html>
element's scrollbar to scroll down modal's content while keeping the gutenboarding header visible. https://github.com/Automattic/wp-calypso/pull/41212/files#diff-3b763db88828368a2cd772bdcb184e7bR1-R24This is refactored from the existing code in
DomainPickerButton
component.The parent component DomainPickerPopover and DomainPickerModal decides what to show and what to hide. https://github.com/Automattic/wp-calypso/pull/41212/files#diff-9fb3f50c91d02f132bfab858e87cb792R74-R93
These 2 buttons are specific to DomainPickerPopover, therefore it make sense that DomainPickerPopover component should play the role of decorating the DomainPicker component with these 2 additional buttons. https://github.com/Automattic/wp-calypso/pull/41212/files#diff-3acfaab9099bccb32e73498b4be055a4R55-R72 This also fixes the accessibility issue with close button needing a
tabIndex={ -1 }
to fix incorrect autofocusing. p1586489720342200-slack-gutenboardingOther changes:
onClose is basically the same as onClick. It was removed to prevent typing issues as
onClose
did not accept undefined values. This component is only used by DomainPicker component so far.Testing instructions
Note: You need to test this locally. Can't access the modal via the live test page as this is hiding behind a feature flag.
/new
and enter your site name.Screenshot
Fixes #41081