Conversation
74c1949 to
f80a70a
Compare
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~480 bytes added 📈 [gzipped]) DetailsCommon code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~122 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 (~3899 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. |
d8d7248 to
fc0a010
Compare
There was a problem hiding this comment.
By looking at how this prop is used, we probably want keys to be typed as plan slugs.
There was a problem hiding this comment.
Non-blocker: Not a big deal just me being picky, but we could move this into the above selector to avoid repeating the selector.
.go-back-button__focused-launch {
//...
&:hover {
opacity: 0.7;
}
}There was a problem hiding this comment.
If domain is null or undefined you will get these values assigned to hasPaidDomain and it'll be coerced into a falsely value.
If you changed const hasPaidDomain = domain && ! domain.is_free; to const hasPaidDomain = domain?.is_free === false; then you'll get a more predictable boolean returned.
Not a blocker though, as it'll be coerced into a falsely value anyway.
There was a problem hiding this comment.
Great idea but Typescript won't like because is_free is typed wrong.
There was a problem hiding this comment.
If we export the CTAVariation values, we can use them here instead of hard coding 'NORMAL'
There was a problem hiding this comment.
I think exporting the type is enough. The IDE won't let you set an invalid value.
There was a problem hiding this comment.
If we export the popularBadgeVariation values, we can use them here instead of hard coding 'ON_TOP'
There was a problem hiding this comment.
If we export the popularBadgeVariation values, we can use them here instead of hard coding 'NEXT_TO_NAME'
There was a problem hiding this comment.
If we export the popularBadgeVariation values, we can use them here instead of hard coding 'NEXT_TO_NAME'
There was a problem hiding this comment.
I don't think we need to maintain another variation of the PlansGrid in a non-accordion mode. However, it's non blocking for this PR.
Just pinging @ollierozdarz to confirm so we can clean up later. Here is the old table version with badge on top and CTA non full-width.

|
Should we be able to "Deselect" a plan? |
No, once we click Select on a plan, the modal is closed and we land back on the Summary View with that plan highlighted. |
There was a problem hiding this comment.
Can we use Back Button from @automattic/onboarding? Seen here
There was a problem hiding this comment.
An idea would be that GoBackButton should use BackButton and then reuse here and in DomainDetails View. See also #47497 (comment)
There was a problem hiding this comment.
Great idea. Didn't know about this one.
There was a problem hiding this comment.
Out of curiosity, what are the benefits of import * as React over import React ?
There was a problem hiding this comment.
I thought this. Looks like it's being used for the functional component typings but not sure the benefit of *
There was a problem hiding this comment.
I thought it would work anyway
There was a problem hiding this comment.
I know we used this way of importing for a while for performance reasons. I believe now we have webpack configured so this isn't necessary anymore. Pinging @sirreal to confirm though 🙏
There was a problem hiding this comment.
If you do import React... you need allowSyntheticDefaultImports = true in tsconfig. import * as React is more semantically accurate and makes TypeScript happy. But don't quote me on this. I think (not sure) I saw @sirreal do it, and he is my TypeScript prophet.
There was a problem hiding this comment.
There were some perf concerns and I don't know whether they're relevant. Either way, I think we have conclusive evidence that import * as React from 'react'; is "right": facebook/react#18102
[
import * as React from "react";] is the correct way to import React from an ES module since the ES module will not have a default export. Only named exports.I'm doing some changes to named exports and this will stop working. For open source ES modules we'll probably publish some default object that warns as an upgrade path but we can't use that in our own code.
We could add a lint rule for this and/or codemod it, but I don't know whether there is significant impact beyond consistency.
There was a problem hiding this comment.
Thank you for the explanation! I learnt something new
There was a problem hiding this comment.
If you do
import React...you needallowSyntheticDefaultImports = truein tsconfig.import * as Reactis more semantically accurate and makes TypeScript happy.
Yes, I think this is right. Note, this isn't really about TypeScript but about ECMAScript modules which are quirky. I wrote a bit here (p4TIVU-8Lf-p2).
|
Addressed all. Thanks everyone! |
196aac6 to
02997af
Compare
|
If you look at the linked issue which contains the designs and compare to the below screenshot the back button is missing some CSS lovin'
@ciampo are we sticking with the standard |
Good finds!
What do you think? |
|
@ciampo I think we can address the chevron issue by including the <BackButton onClick={ goBack }>
<Icon icon={ chevronLeft } />
<span>{ __( 'Go back', __i18n_text_domain__ ) }</span>
</BackButton>As for the margin, we should address this with a shared CSS class so it's consistent and leaving the color as it is I think makes sense as you said. |
@alshakero we reached a conclusion on this here 27382-pb |
tjcafferkey
left a comment
There was a problem hiding this comment.
I can't approve as it's my original PR but this LGTM!
wp-desktop
left a comment
There was a problem hiding this comment.
WordPress Desktop CI Failure for job "wp-desktop-mac".
@alshakero please inspect this job's build steps for breaking changes at this link. For temporal failures, you may try to "Rerun Workflow from Failed".
Please also ensure this branch is rebased off latest Calypso.

Changes proposed in this Pull Request
Testing instructions
yarn && yarn start. In a separate terminal window, runcd apps/editing-toolkit && yarn dev --sync.wp.data.dispatch('automattic/launch' ).openFocusedLaunch().Fixes #46867