-
Notifications
You must be signed in to change notification settings - Fork 2k
Fixed plan selector alignment and plan blocks size on tablet screen sizes #101994
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
Conversation
Jetpack Cloud live (direct link)
Automattic for Agencies live (direct link)
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Sections (~1 bytes added 📈 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Async-loaded Components (~1 bytes added 📈 [gzipped])
React 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. |
@@ -404,7 +404,7 @@ const WrappedFeaturesGrid = ( props: FeaturesGridExternalProps ) => { | |||
} | |||
|
|||
// we want to fit 3 plans per row in this breakpoint | |||
const mediumBreakpoint = isInSiteDashboard ? 667 : 741; | |||
const mediumBreakpoint = 669; |
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.
What's the reason behind this change? If we want to customize this further, then we'll likely need a prop, otherwise it will break other pages, no?
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.
What's the reason behind this change?
We want to match the breakpoint with the max-width break-small defined here.
So that will generate this behavior:
Screen.Recording.2025-03-27.at.16.52.07.mov
Without setting it, we'll have this weird behavior where a single plan is shown after the break-small:
Screen.Recording.2025-03-27.at.16.53.31.mov
If we want to customize this further, then we'll likely need a prop
The original value was introduced here.
I don't think we want to keep customizing it since it's hard-coded to this screen. @fushar can you confirm that?
otherwise it will break other pages, no?
I tested that feature locally (which has the flag isInSiteDashboard
true) to ensure the value chance of 2px (before was 667) wouldn't change their behavior, and it looks good.
I also tested other flows where we show the plans screen, like /plans, and the new change (669 instead 741) looks good as well.
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 looks good on my end, too! Yeah, it would be good to have a single value here.
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.
Cool 👍🏻
.plans-wrapper { | ||
margin: 0; | ||
padding: 0; | ||
.step-container-v2 { |
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.
Why did we need this change? Specificity? Can we do it without? I don't like the idea of targeting step-container-v2
directly.
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.
Good question. The .step-container-v2--plans
selector won't allow us to update the subtitle, so for that we need to start on a parent element. That's why I used the .step-container-v2
.
We could implement it outside of the current CSS, something like this:
But it feels more organized to keep everything inside the same parent, since all these changes are specific for the new step container .step-container-v2
.
I don't like the idea of targeting step-container-v2 directly.
Interesting, can you elaborate more on why?
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 @zaguiini concern is that by making the inner contents tightly coupled to the step container can lead to unintended style inheritance in other components of the step container and cause unintended side-effects.
I think having outside as it's own class is the safer approach.
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.
Well this is fine. It's going to be reworked anyway. Let's move forward.
This PR modifies the release build for the following Calypso Apps: For info about this notification, see here: PCYsg-OT6-p2
To test WordPress.com changes, run |
Not sure if this PR is final not, but did a few smoke tests, did not find any problems. https://www.awesomescreenshot.com/video/38132998?key=91a00235af747350ae7f23d329da2b6c |
@paulopmt1 Tested this and it looks good! |
Related to #101964
Slack thread: p1743085286744789-slack-C04H4NY6STW
Proposed Changes
Testing Instructions
?flags=onboarding/step-container-v2
on staging)Pre-merge Checklist