Signup: Use new search for domains signup#51718
Conversation
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~9 bytes removed 📉 [gzipped]) DetailsCommon code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~12076 bytes added 📈 [gzipped]) DetailsSections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Async-loaded Components (~5370 bytes added 📈 [gzipped]) DetailsReact components that are loaded lazily, when a certain part of UI is displayed for the first time. 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. |
| import { domainAvailability } from 'calypso/lib/domains/constants'; | ||
| import { getAvailabilityNotice } from 'calypso/lib/domains/registration/availability-messages'; | ||
| import Search from 'calypso/components/search'; | ||
| import Search from '@automattic/search'; |
There was a problem hiding this comment.
Let's move this to external dependencies.
| <CompactCard className="register-domain-step__search-card"> | ||
| <Search | ||
| additionalClasses={ this.state.clickedExampleSuggestion ? 'is-refocused' : undefined } | ||
| className={ this.state.clickedExampleSuggestion ? 'is-refocused' : undefined } |
There was a problem hiding this comment.
There seems to be a initialValue prop that the search package doesn't support.
Also, we're passing a ref, but we also create new refs in our component. Could that cause a regression?
There was a problem hiding this comment.
There seems to be a initialValue prop that the search package doesn't support.
Ah yes I think this was renamed to defaultValue, good catch, thanks.
Also, we're passing a ref, but we also create new refs in our component. Could that cause a regression?
What do you mean by this? The ref that is passed get's handled by useImperativeHandle and duplicates the methods that were being used on the old component by the contexts where refs were being passed (mostly focus to be honest).
There was a problem hiding this comment.
Scratch that, I don't think it's a concern anyway.
|
@noahtallen e2e failures are definitely related 🙂 |
|
E2e failures fixed as well as the focus styles. Everything should be tip top shape now 😁 |
noahtallen
left a comment
There was a problem hiding this comment.
lgtm! There's a flaky e2e test related to gutenboarding domains, but it seems to be passing for a lot of the commits here... so probably unrelated
|
I'm requesting from @Automattic/cobalt just for good measure 😁 |
klimeryk
left a comment
There was a problem hiding this comment.
Thanks for the ping! (and sorry for the late reply, we've had a lot of organizational changes recently).
I've tested as many flows as I could:
/domains- signup
- launch flow
And looks good!
I've only noticed a very small issue, probably with the component itself. The X button does not have a focus style in the new component.
Compare the old one:
Screen.Recording.2021-04-14.at.17.21.47.mov
With the new one:
Screen.Recording.2021-04-14.at.17.22.05.mov
Definitely not a blocker.
One flow that seemed to have a slight regression is the reskinned signup (see the reskinSignupFlow A/B test), but that has been paused (#46477), so probably not a blocker (cc @aneeshd16)
It's a minor visual regression, so either way should be fine to merge as-is.





Changes proposed in this Pull Request
Testing instructions
/start/domainsand ensure that search continues to work as expected.Note: there's a usage of the ref that is assigned to the search to try to focus the element... however, I could never get this to work. It seems like the example suggestions is fully disabled so I'm going to open another PR to remove it.