Skip to content
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

Dynamically change color scheme from color_scheme query param #96557

Merged

Conversation

moon0326
Copy link
Contributor

Related to woocommerce/woocommerce#52875

Proposed Changes

  • Support changing the color scheme based on the color_scheme query parameter when the user is using the new passwordless Jetpack connection

Testing Instructions

  1. Checkout this branch locally and run yarn start
  2. Once the build is ready, visit this link
  3. Confirm the color scheme is sunrise
  4. Copy the link and search for color_scheme
  5. Change it to one of the supported color schemes and revisit the link.
  6. Confirm the color scheme change.

Supported color schemes:

  • default
  • light
  • modern
  • blue
  • coffee
  • ectoplasm
  • midnight
  • ocean
  • sunrise

Pre-merge Checklist

  • Has the general commit checklist been followed? (PCYsg-hS-p2)
  • Have you written new tests for your changes?
  • Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
  • Have you checked for TypeScript, React or other console errors?
  • Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
  • Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

@moon0326 moon0326 requested review from a team, chihsuan and adrianduffell November 19, 2024 20:00
@matticbot matticbot added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Nov 19, 2024
@matticbot
Copy link
Contributor

matticbot commented Nov 19, 2024

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~36 bytes added 📈 [gzipped])

name           parsed_size           gzip_size
entry-stepper       +956 B  (+0.0%)      +36 B  (+0.0%)
entry-main          +956 B  (+0.0%)      +36 B  (+0.0%)
entry-login         +956 B  (+0.0%)      +36 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~10 bytes added 📈 [gzipped])

name              parsed_size           gzip_size
purchase-product        +29 B  (+0.0%)      +10 B  (+0.0%)
jetpack-connect         +29 B  (+0.0%)      +10 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

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.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

Copy link
Member

@chihsuan chihsuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested well! 👍 I have some comments on the code.

export function getColorSchemeFromCurrentQuery( currentQuery ) {
return currentQuery?.color_scheme
? currentQuery?.color_scheme
: new URLSearchParams( currentQuery?.redirect_to ).get( 'color_scheme' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If redirect_to is null, undefined, or an invalid URL, URLSearchParams will throw an error. Should we add a fallback for cases where redirect_to is not a valid URL?

let colorScheme = null;

// Try to get the color scheme from `color_scheme` query param if we're in the WooCommerce Passwordless JPC flow.
if ( isWooPasswordlessJPC ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about using the ternary operator here to simplify the logic?

let colorScheme =
    isWooPasswordlessJPC
        ? getColorSchemeFromCurrentQuery(currentQuery)
        : getColorScheme({
              state,
              isGlobalSidebarVisible,
              sectionName,
          });

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was tempted to use ternary at first.

When color_scheme query param is missing for some reason, I think we should call getColorScheme to get the user's preference instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should call getColorScheme to get the user's preference instead.

That sounds good. I noticed there doesn't seem to be a global user preference on WPCOM anymore. We could perhaps also just default the standard WPCOM colors 🤔

wpcom global color scheme

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adrianduffell Good catch! Let's use the default color scheme in that case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -153,6 +156,10 @@ const LayoutLoggedOut = ( {

let masterbar = null;

useEffect( () => {
refreshColorScheme( 'default', colorScheme );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we check if isWooPasswordlessJPC before calling the function? If it's only needed for Woo.

Copy link
Contributor Author

@moon0326 moon0326 Nov 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chihsuan FIxed it in c184c35

@@ -185,7 +185,7 @@ $breakpoint-mobile: 660px;

.progress-bar__progress {
border-radius: 0;
background-color: var(--wp-admin-theme-color);
background-color: var(--color-primary);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice fix!

// Color scheme 'blue' fix
// The 'blue' theme color from wp-calypso does not match the 'blue' color from the local WordPress admin color scheme.
// Fix the color scheme 'blue' to match the local WordPress admin color scheme on the new JPC page.
body.is-blue {
Copy link
Contributor

@adrianduffell adrianduffell Nov 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What color does wp-calypso render for the 'blue' scheme? I wonder if we might have it wrong on the WC core side -- I noticed when 'blue' is applied, WordPress renders buttons in a tan #d9aa59 color, but in core profiler they are #2a63a1.

Screen Shot 2024-11-20 at 10 48 25 pm Screen Shot 2024-11-20 at 10 54 01 pm

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adrianduffell Good catch. I think the core profiler has incorrect color. We've been using --wp-admin-theme-color for the button color, but it should be --color-pirmary. I'll double check and open a PR in WC repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adrianduffell

Good catch. I think the core profiler has incorrect color.

I take it back 😄

Without this change, wp-calypso renders the exact same color as the core profiler.
Screenshot 2024-11-20 at 12 56 33 PM

I've removed it in Remove blue color fix change -- no longer needed

Copy link
Contributor

@adrianduffell adrianduffell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @moon0326, it is testing nice and smooth! Pre-approving once the comments are resolved 🚀

@matticbot
Copy link
Contributor

matticbot commented Nov 20, 2024

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

  • notifications

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/52876-persist-user-admin-color-scheme-on-wpcom-jpc on your sandbox.

Copy link
Member

@chihsuan chihsuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM!

@moon0326 moon0326 merged commit 6142a40 into trunk Nov 21, 2024
11 checks passed
@moon0326 moon0326 deleted the update/52876-persist-user-admin-color-scheme-on-wpcom-jpc branch November 21, 2024 15:43
@github-actions github-actions bot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Nov 21, 2024
okmttdhr pushed a commit that referenced this pull request Nov 22, 2024
* Change color theme by color_scheme query param

* Use --color-primary for the primary button and the progress bar

* Fix blue theme color to match the local WordPress

* Apply color_scheme from query

* Refresh color scheme when if it is woo passwordless JPC

* Return 'default' color scheme

* Remove blue color fix change -- no longer needed

* Fix error with isWooPasswordlessJPC access
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants