Stats: Store date range shortcut and chart period by site

[dognose24]

Related to p1736489258690049-slack-C82FZ5T4G

Proposed Changes

• Store the applied date range shortcut ID to LocalStorage by site
• Store the applied chart period to LocalStorage by site

Why are these changes being made?

• The current stored date range shortcut and chart period are shared between all sites, which might not be adaptable to users having many sites.

Testing Instructions

• Spin this change up with the Calypso Live branch.
• Navigate to Stats > Traffic page.
• Ensure the previous stored date range shortcut is still applied.
• Choose and apply another date range shortcut.
• Ensure the shortcut works well after refreshing the Traffic page.
• Go to the Traffic page of another site on Calypso.
• Choose and apply another date range shortcut.
• Ensure the applied shortcut does not change the stored date range shortcut of the last step.
• Test for stored chart period as well by the steps above.

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 UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• 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)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-129695

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-129695&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-129695&env=a8c-for-agencies

[matticbot]

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

Sections (~115 bytes added 📈 [gzipped])

name   parsed_size           gzip_size
stats       +447 B  (+0.0%)     +115 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.

Async-loaded Components (~42 bytes added 📈 [gzipped])

name                                       parsed_size           gzip_size
async-load-store-app-store-stats-listview       +174 B  (+0.1%)      +42 B  (+0.1%)
async-load-store-app-store-stats                +174 B  (+0.1%)      +42 B  (+0.1%)

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.
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.

[matticbot]

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

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

• notifications
• odyssey-stats

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/stats_store_date_range_shortcut_by_site on your sandbox.

[a8ck3n]

Tests well for me! 👍

I think personally, I'd prefer to use the slug over the site ID as it makes it easier to manage if someone wants to manually remove the key from local storage. Seeing multiple of the same key with different IDs doesn't help in that scenario. It's not really a common use-case though.

[dognose24]

if someone wants to manually remove the key from local storage

As you said, that might be a rare path, especially for users rather than developers. On the other hand, considering the site slug complexity, using site ID would keep the key length limited and easy to identify. What do you think? cc @kangzj