wp-calypso
wp-calypso copied to clipboard
Automattic
Update dataviews package version to latest
Fixes https://github.com/Automattic/jetpack-manage/issues/337
Proposed Changes
- Update dataviews package version.
- Remove locks on the version changes.
- Downstream changes to use the new package version on the Hosting Dashboard (/sites), the A4A Dashboard, and the Add Site > Via WordPress.com modal.
Why are these changes being made?
- To update to the latest version of
DataViewsin Core. See pe7F0s-21J-p2
Status
| Status | DataViews instance | URL |
|---|---|---|
| 🟢 | Dotcom Sites | <calypso>/sites |
| 🔴 | A4A Sites | <agencies>/sites |
| 🟢 | A4A Sites Modal | <agencies>/sites ("add new site" modal) |
| 🟢 | A4A Referrals Overview | <agencies>/referrals |
| 🟢 | A4A Referrals Details | <agencies>/referrals (with an item selected) |
| 🔴 | A4A Referrals for clients | Unidentified |
| 🟢 | A4A Team (in development, not in production) | <agencies>/team |
| 🔴 | Jetpack Cloud Sites (legacy, not in production): one, two. | <jpcloud>/sites |
Dotcom Sites
- Nothing to fix in this PR.
A4A Sites
- Table header is not aligned to the column's content.
- Favorite stars aren't immediately updated.
- Row notice for sites whose status is "Backup failed".
- Filter Toggle doesn't represent open/close status via color.
A4A Sites Modal
- Nothing to fix in this PR.
A4A Referrals Overview
- Nothing to fix in this PR.
A4A Referrals Details
- Nothing to fix in this PR.
A4A Referrals for clients
- Unidentified. This requires an agency to invite a client that hasn't registered as an agency. After signup and introducing a valid credit card, the client will be able to see a list of referrals.
A4A Team
- Nothing to fix in this PR.
Jetpack Cloud
- These are not in use, they should be removed from the codebase.
Testing Instructions
- Check out this branch locally, or use the Calypso live links below.
- Open /sites. Verify that:
- the list of sites loads and has pagination.
- you can click on a site and open the fly out panel, and the table collapses into a list. The sidebar collapses into a rail.
- you can search and filter the sites.
- the table loads only Site and Actions on mobile (you'll need to re-load at a mobile size).
- Open the Agencies dashboard. Verify that:
- the list of sites loads and has pagination.
- you can click on a site and open the fly out panel, and the table collapses into a list.
- you can search and filter the sites.
- you can favorite sites.
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)?
Jetpack Cloud live (direct link)
|
|
https://calypso.live?image=registry.a8c.com/calypso/app:build-118256&env=jetpack |
Automattic for Agencies live (direct link)
|
|
https://calypso.live?image=registry.a8c.com/calypso/app:build-118256&env=a8c-for-agencies |
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:
App Entrypoints (~2217 bytes removed 📉 [gzipped])
name parsed_size gzip_size
entry-main +3814 B (+0.2%) -358 B (-0.1%)
entry-stepper +2684 B (+0.1%) -486 B (-0.1%)
entry-subscriptions -755 B (-0.0%) -1819 B (-0.4%)
entry-login -308 B (-0.0%) -223 B (-0.1%)
entry-domains-landing -308 B (-0.0%) -223 B (-0.1%)
entry-browsehappy -308 B (-0.2%) -223 B (-0.4%)
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.
Sections (~33718 bytes added 📈 [gzipped])
name parsed_size gzip_size
a8c-for-agencies-team +534854 B (+125.5%) +128125 B (+96.8%)
a8c-for-agencies-overview +533131 B (+108.4%) +127576 B (+83.4%)
jetpack-cloud-agency-sites-v2 +461401 B (+27.7%) +113341 B (+24.1%)
a8c-for-agencies-sites +461371 B (+26.8%) +114202 B (+23.8%)
a8c-for-agencies-client +398759 B (+43.8%) +83721 B (+30.4%)
a8c-for-agencies-referrals +394820 B (+57.6%) +82311 B (+38.2%)
github-deployments +389724 B (+35.6%) +80559 B (+23.7%)
hosting +388766 B (+26.8%) +81195 B (+18.6%)
staging-site +388602 B (+31.9%) +80479 B (+21.5%)
sites-dashboard +388579 B (+40.8%) +80344 B (+26.8%)
site-monitoring +388463 B (+35.6%) +80365 B (+23.1%)
site-logs +388463 B (+35.5%) +80365 B (+23.1%)
hosting-features +388463 B (+38.4%) +80356 B (+25.3%)
update-design-flow -2695 B (-0.2%) -958 B (-0.3%)
link-in-bio-tld-flow -2409 B (-0.1%) -741 B (-0.1%)
signup -1880 B (-0.7%) -165 B (-0.3%)
readymade-template-flow -1309 B (-1.0%) -1086 B (-3.5%)
with-theme-assembler-flow -1113 B (-1.6%) -139 B (-1.2%)
update-options-flow -1113 B (-2.2%) -142 B (-2.4%)
trial-wooexpress-flow -1113 B (-2.1%) -142 B (-2.0%)
tailored-ecommerce-flow -1113 B (-2.1%) -140 B (-2.0%)
site-setup-wg -1113 B (-1.3%) -145 B (-0.8%)
site-setup-flow -1113 B (-1.3%) -148 B (-0.9%)
site-migration-flow -1113 B (-1.8%) -138 B (-1.5%)
migration-signup -1113 B (-2.0%) -133 B (-1.7%)
migration-flow -1113 B (-1.5%) -138 B (-1.0%)
import-flow -1113 B (-1.8%) -133 B (-1.4%)
hosted-site-migration-flow -1113 B (-1.8%) -140 B (-1.5%)
free-post-setup-flow -1113 B (-2.2%) -139 B (-2.4%)
free-flow -1113 B (-1.9%) -145 B (-1.6%)
entrepreneur-flow -1113 B (-0.9%) -144 B (-0.5%)
assembler-first-flow -1113 B (-1.4%) -141 B (-1.0%)
ai-assembler-flow -1113 B (-1.4%) -140 B (-1.0%)
import +798 B (+0.1%) -81 B (-0.0%)
hundred-year-plan -735 B (-2.1%) -112 B (-1.1%)
domains -650 B (-0.0%) -2853 B (-0.5%)
home +643 B (+0.0%) +2128 B (+0.5%)
import-hosted-site-flow -608 B (-0.1%) -1337 B (-0.5%)
reader -493 B (-0.1%) -1253 B (-0.4%)
design-first-flow -478 B (-2.0%) -76 B (-1.3%)
patterns +477 B (+0.0%) -477 B (-0.1%)
sensei-flow -430 B (-0.1%) -1083 B (-0.6%)
settings +395 B (+0.0%) +14 B (+0.0%)
newsletter-flow -368 B (-1.9%) -96 B (-1.8%)
link-in-bio-flow -368 B (-2.0%) -97 B (-1.9%)
reblogging-flow -367 B (-6.5%) -122 B (-6.7%)
onboarding-flow -367 B (-1.2%) -114 B (-1.1%)
site-purchases +330 B (+0.0%) -825 B (-0.2%)
a8c-for-agencies-settings +302 B (+0.2%) +329 B (+0.6%)
a8c-for-agencies-plugins +302 B (+0.2%) +281 B (+0.6%)
a8c-for-agencies-migrations +302 B (+0.2%) +319 B (+0.5%)
activity +289 B (+0.0%) +468 B (+0.2%)
videopress-flow -275 B (-0.0%) -873 B (-0.3%)
start-writing-flow -262 B (-1.2%) -64 B (-1.2%)
a8c-for-agencies-marketplace -259 B (-0.0%) -372 B (-0.2%)
settings-podcast +257 B (+0.1%) +69 B (+0.0%)
media +250 B (+0.0%) +646 B (+0.2%)
plans +246 B (+0.0%) +996 B (+0.2%)
subscribers -241 B (-0.0%) +99 B (+0.0%)
jetpack-cloud-plugin-management -235 B (-0.0%) -35 B (-0.0%)
gutenberg-editor +232 B (+0.0%) +40 B (+0.0%)
copy-site-flow -217 B (-0.0%) -2479 B (-1.2%)
marketplace -207 B (-0.0%) -638 B (-0.2%)
a8c-for-agencies-purchases +206 B (+0.0%) -122 B (-0.1%)
a8c-for-agencies-landing +196 B (+0.2%) +415 B (+1.4%)
jetpack-cloud-pricing -193 B (-0.0%) -746 B (-0.3%)
jetpack-cloud-features-comparison -193 B (-0.0%) -842 B (-0.4%)
stats +177 B (+0.0%) -154 B (-0.0%)
themes -169 B (-0.0%) -748 B (-0.3%)
woocommerce +147 B (+0.0%) +48 B (+0.1%)
people +141 B (+0.0%) +4 B (+0.0%)
jetpack-connect -141 B (-0.0%) -665 B (-0.2%)
plugins -132 B (-0.0%) -166 B (-0.0%)
backup -113 B (-0.0%) +926 B (+0.3%)
write-flow -107 B (-0.0%) -288 B (-0.1%)
build-flow -107 B (-0.0%) -299 B (-0.1%)
promote-post-i2 -100 B (-0.0%) +9 B (+0.0%)
jetpack-cloud-overview -100 B (-0.0%) -47 B (-0.0%)
earn -100 B (-0.0%) +491 B (+0.2%)
jetpack-cloud +96 B (+0.0%) +889 B (+0.7%)
notification-settings -92 B (-0.0%) -36 B (-0.0%)
account -92 B (-0.0%) -22 B (-0.0%)
settings-writing -90 B (-0.0%) -601 B (-0.4%)
comments -90 B (-0.0%) -749 B (-0.4%)
switch-site +78 B (+0.0%) -88 B (-0.2%)
checkout -77 B (-0.0%) -628 B (-0.1%)
a8c-for-agencies-partner-directory -77 B (-0.0%) -663 B (-0.5%)
purchases -72 B (-0.0%) -414 B (-0.1%)
settings-security -62 B (-0.0%) +13 B (+0.0%)
jetpack-cloud-partner-portal -61 B (-0.0%) -1389 B (-0.5%)
jetpack-search +59 B (+0.0%) +96 B (+0.1%)
theme +54 B (+0.0%) +1413 B (+0.6%)
accept-invite +52 B (+0.0%) +27 B (+0.1%)
scan +44 B (+0.0%) +299 B (+0.1%)
settings-performance +41 B (+0.0%) +34 B (+0.0%)
posts-custom +41 B (+0.0%) +31 B (+0.0%)
posts +41 B (+0.0%) +31 B (+0.0%)
marketing +41 B (+0.0%) +34 B (+0.0%)
devdocs +36 B (+0.0%) +33 B (+0.1%)
jetpack-app +25 B (+0.0%) -34 B (-0.0%)
a8c-for-agencies-signup +25 B (+0.0%) +84 B (+0.3%)
email +16 B (+0.0%) +543 B (+0.3%)
site-blocks +13 B (+0.0%) -26 B (-0.0%)
security +13 B (+0.0%) +169 B (+0.1%)
privacy +13 B (+0.0%) -12 B (-0.0%)
me +13 B (+0.0%) -22 B (-0.0%)
help +13 B (+0.0%) -18 B (-0.0%)
developer +13 B (+0.0%) -12 B (-0.0%)
account-close +13 B (+0.0%) -19 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 (~10652 bytes removed 📉 [gzipped])
name parsed_size gzip_size
async-load-automattic-design-preview +817 B (+0.0%) +615 B (+0.1%)
async-load-design -642 B (-0.0%) +154 B (+0.0%)
async-load-signup-steps-domains -523 B (-0.1%) -1810 B (-1.1%)
async-load-comment-block-editor +477 B (+0.0%) -538 B (-0.1%)
async-load-automattic-global-styles-src-components-global-styles-variations +477 B (+0.0%) -440 B (-0.1%)
async-load-signup-steps-theme-selection -457 B (-0.1%) -936 B (-0.8%)
async-load-calypso-post-editor-editor-media-modal +247 B (+0.0%) +598 B (+0.2%)
async-load-calypso-post-editor-media-modal +209 B (+0.0%) +569 B (+0.2%)
async-load-calypso-my-sites-checkout-modal +209 B (+0.0%) +953 B (+0.3%)
async-load-calypso-blocks-editor-checkout-modal +209 B (+0.0%) +1026 B (+0.3%)
async-load-signup-steps-design-picker +108 B (+0.2%) +27 B (+0.2%)
async-load-signup-steps-site-picker -105 B (-0.1%) -7 B (-0.0%)
async-load-signup-steps-difm-site-picker -105 B (-0.1%) -7 B (-0.0%)
async-load-calypso-components-sites-popover -105 B (-0.1%) -7 B (-0.0%)
async-load-signup-steps-woocommerce-install-step-store-address +103 B (+0.2%) +22 B (+0.1%)
async-load-masterbar-launchpad-navigator -103 B (-0.2%) -12 B (-0.1%)
async-load-automattic-whats-new -103 B (-0.5%) -14 B (-0.2%)
async-load-calypso-jetpack-cloud-sections-sidebar-navigation-manage-selected-... +93 B (+0.1%) +866 B (+2.5%)
async-load-calypso-layout-command-palette +78 B (+0.0%) -88 B (-0.2%)
async-load-design-playground +75 B (+0.0%) +104 B (+0.0%)
async-load-design-wordpress-components-gallery -62 B (-0.0%) -168 B (-0.1%)
async-load-store-app-store-stats-listview +59 B (+0.0%) -85 B (-0.1%)
async-load-store-app-store-stats +59 B (+0.0%) -85 B (-0.0%)
async-load-signup-steps-user +52 B (+0.0%) +7 B (+0.0%)
async-load-signup-steps-subscribe-email +52 B (+0.0%) +25 B (+0.1%)
async-load-design-blocks -39 B (-0.0%) +293 B (+0.0%)
async-load-calypso-reader-sidebar +38 B (+0.0%) +11 B (+0.0%)
async-load-calypso-my-sites-stats-summary +38 B (+0.1%) +12 B (+0.1%)
async-load-calypso-my-sites-current-site-notice +38 B (+0.1%) +13 B (+0.1%)
async-load-calypso-blocks-jitm-templates-sidebar-banner +38 B (+0.1%) +12 B (+0.1%)
async-load-calypso-blocks-jitm-templates-notice +38 B (+0.1%) +10 B (+0.1%)
async-load-calypso-blocks-jitm-templates-default +38 B (+0.1%) +10 B (+0.1%)
async-load-signup-steps-plans-theme-preselected +25 B (+0.0%) -14 B (-0.0%)
async-load-signup-steps-plans +25 B (+0.0%) -11 B (-0.0%)
async-load-automattic-help-center -23 B (-0.0%) -679 B (-0.4%)
async-load-signup-steps-page-picker +19 B (+0.0%) +23 B (+0.0%)
async-load-purchase-modal-wrapper +19 B (+0.0%) +21 B (+0.0%)
async-load-my-sites-checkout-purchase-modal-is-eligible-for-one-click-checkou... +19 B (+0.0%) +24 B (+0.0%)
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.
For consistency and predictability, I'd recommend updating @wordpress/dataviews to the version that corresponds to the current monorepo package versions, and then update all packages together in https://github.com/Automattic/wp-calypso/pull/92571. Let me know if you need any help with that.
I agree that that would be better in terms of process but in this case, I think it's fine to make an exception because otherwise we'll do two big migrations and I'd rather do it once into a fully typed package. (And most of the work is already done)
I'm documenting Dotcom regressions to work on / make decisions on:
| This branch | Production |
|---|---|
| Pagination is not fixed | Pagination is fixed |
| Site column font weight is bold | Site column font weight is normal |
On the A4A dashboard, the site error status, Stats column, and Favorites column are missing:
| This branch | Production |
|---|---|
@youknowriad I'm struggling to find a futureproof way to hide the Plan column responsively on mobile screen widths (<960px). I tried changing the column width / maxWidth / minWidth to 0px in the view layout, but that didn't hide it. It seems like overkill to hide and show it as the window width changes. Is there a DataViews way to do this?
@allilevine Maybe the best way is to update the fields property of the view prop passed to DataViews dynamically based on useBreakpoint calls.
@allilevine I see that you styled back the search input to how it was in trunk. I agree that it's a better design personally but IMO we should try to be consistent. I don't see why .com's search input should be different from .org's one. Why don't we update the design in .org directly instead?
cc @jameskoster as there might be reasons for the current design in .org.
I don't see why .com's search input should be different from .org's one.
I agree.
Iirc the current design was optimised for the Inserter, which was one of the only SearchControl instances at the time. As we implement more instances it may be time to revisit the design. Let's do that in core, keeping mind the ongoing work around the design system.
@allilevine I see that you styled back the search input to how it was in trunk. I agree that it's a better design personally but IMO we should try to be consistent. I don't see why .com's search input should be different from .org's one. Why don't we update the design in .org directly instead?
Sounds good! I prioritized that regression because it's inconsistent with Domains and Plugins. But Themes is also currently inconsistent, and if our first priority is consistency with core, it makes sense to make the update there. cc'ing @davemart-in @lucasmendes-design on this decision.
I've noticed the "Add filter" button styles don't communicate well the disabled state:
| core | dotcom |
|---|---|
I've pinpointed the issue to this dotcom override of the core wp-components. To be fair, it's not the "same color", as an tertiary active button gets the --color-accent while the tertiary disabled button gets the slightly different --color-accent-60. These are too similar to communicate different states, in my view:
| Active | Disabled |
|---|---|
--color-accent: #3858e9 |
--color-accent-60: #2145e6 |
 |
 |
While I don't consider these blockers for this PR (because we hack around them), Here's the list of follow-ups that we should be proposing for the Core package:
- Support labels as components https://github.com/Automattic/wp-calypso/pull/93503/files#r1718386064
- Support shortcut for supported layouts https://github.com/Automattic/wp-calypso/pull/93503/files#r1718386544
- Some CSS that needs to be moved to the core package:
- Consider fixing the default width of the dataviews https://github.com/Automattic/wp-calypso/pull/93503/files#r1718388671
- mixing border-box style https://github.com/Automattic/wp-calypso/pull/93503/files#diff-9950890eeef134bd0b0662a983b25d3f1f9c99747b74d853ea1fde9b88f54d0cR84
- Hide the "properties" section of the view config dropdown if no properties available https://github.com/Automattic/wp-calypso/pull/93503/files#diff-9950890eeef134bd0b0662a983b25d3f1f9c99747b74d853ea1fde9b88f54d0cR205
- Improve the design of the search input https://github.com/Automattic/wp-calypso/pull/93503/files#diff-0a2d26e9c72c1b5146ddf171c67adb7bdcab7f6e2482e0b8a3c322a1c610c871L238
- Consider removing the too specific link styles in the DataViews component. It prevents users from styling links as they wish https://github.com/Automattic/wp-calypso/pull/93503/files#diff-ba0c07f485e2b3dbcdcd72d38e35766aa3725de863b517175ff786bd681c0c0cR25
One follow-up that I think should be done in calypso instead is the untangling of the "site preview" and the "site title" fields and using primaryField and mediaField configs instead https://github.com/Automattic/wp-calypso/pull/93503/files#r1719527938
Other than that, this PR is in a decent state, we need a bit more testing in order to land it.
I've started working on some of the Core follow-ups while this PR is waiting for review/merge.
Here's the first one: Add support for components to the field labels. https://github.com/WordPress/gutenberg/pull/64642
Some feedback:
- Mobile needing a refresh to hide the column is fine.
- I also think it's fine to keep the pagination at the very bottom of the page.
- Should we hide the "Add filter" button since it doesn't do anything?
- When you go to the site management panel, or when you view the dataViews component on mobile, the search box width is just too small. We should manually override that so that it's wider:
- Can we clean up the alignment here so that the search box vertically aligns with everything else on the left and the cog aligns with the stuff on the right?
Nice to see that we're following on consistency between Dotcom, A4A and Core :)
Some thoughts:
-
We need to fix the proportions of the filter. You can see that our filters are much bigger than those of Core.
-
Since we have enough white space alongside the search field, I wondering why we're placing the filters above.
Hi @davemart-in and @lucasmendes-design there's some things that I suggest not doing in this PR:
- Should we hide the "Add filter" button since it doesn't do anything?
- When you go to the site management panel, or when you view the dataViews component on mobile, the search box width is just too small. We should manually override that so that it's wider:
- We need to fix the proportions of the filter. You can see that our filters are much bigger than those of Core.
- Since we have enough white space alongside the search field, I wondering why we're placing the filters above.
These are all good questions, and require a conversation between designers in dotcom/jetpack/dotorg. Until that happens, my understanding is that we should be able to ship features using the core's defaults.
The current DataViews in use here is outdated — core has moved faster than dotcom/jetpack. We cannot use the newer core tools quickly in dotcom/jetpack because of the "tweaks" done in the past. If we want to be fast, we need to avoid falling into the same issues. Core releases a new version every 2 weeks, and I think we should aim to update DataViews in this codebase every 2 weeks without efforts.
I don't know about this one, perhaps it's some styles added in this codebase that can be fixed? Haven't looked into it but core looks nice:
Can we clean up the alignment here so that the search box vertically aligns with everything else on the left and the cog aligns with the stuff on the right?
These are all good questions, and require a conversation between designers in dotcom/jetpack/dotorg. Until that happens, my understanding is that we should be able to ship features using the core's defaults.
Sorry, having a "Add filter" button that literally does nothing feels like a blocker for me.
These are all good questions, and require a conversation between designers in dotcom/jetpack/dotorg. Until that happens, my understanding is that we should be able to ship features using the core's defaults.
The current DataViews in use here is outdated — core has moved faster than dotcom/jetpack. We cannot use the newer core tools quickly in dotcom/jetpack because of the "tweaks" done in the past. If we want to be fast, we need to avoid falling into the same issues. Core releases a new version every 2 weeks, and I think we should aim to update DataViews in this codebase every 2 weeks without efforts.
My proposal:
Can we have a single CSS file that loads after the dataViews component with a few specific overrides? This file can be outside the package, so it shouldn't conflict with regular updates, but it would allow us to make a few minor updates based on our needs.
Can we have a single CSS file that loads after the dataViews component with a few specific overrides? This file can be outside the package, so it shouldn't conflict with regular updates, but it would allow us to make a few minor updates based on our needs.
Having CSS overrides is fine, it's already the case. That said, there's a difference between:
- Providing a CSS style for some field because it's a branded field or because it has a very specific style.
- We don't like the shape of the search form, or filter button or something, so we change it for .com.
I think for the latter we should aim to instead discuss between the designers of .com and .org and come to agreement on the right design for all instead.
I think for the latter we should aim to instead discuss between the designers of .com and .org and come to agreement on the right design for all instead.
Yep. I think that makes sense. Thoughts on the best place to start that conversation?
@davemart-in My recommendation would be to create an issue on the Gutenberg repository and ping the designers and group in #dotorg-design channel. @jameskoster is already on this PR as well.
We need to remove all the hacks and overwrites on data views as soon as possible. It's blocking being able to keep up with significant updates coming from upstream.
What I'm hearing is: Fix things upstream rather than adding hacks downstream.
👍 Understood. Thanks for clarifying. I brought up one issue in Slack just now.
@youknowriad I opened two Gutenberg issues:
- https://github.com/WordPress/gutenberg/issues/64689
- https://github.com/WordPress/gutenberg/issues/64690 -- I don't think this one had been discussed yet on this PR, but was raised here: p1724253058727239/1724191497.496709-slack-C06ELHR6L9J
Another upstream PR here https://github.com/WordPress/gutenberg/pull/64711 to remove some of the opinionated styles and add the missing ones.
Should we hide the "Add filter" button since it doesn't do anything?
I've realized there's a DataViews way to make this work for this particular case. We can make it a "primary filter". I've pushed https://github.com/Automattic/wp-calypso/pull/93503/commits/323506342699ec5ff0464d9bdc9ab4252c9305e9 for this. A primary filter:
- is not listed as part of the filter toggle, but they are listed always in the view (docs for field.filterBy.isPrimary)
- on loading the page, the filter will be visible – this is part of an unreleased version, not the one we're using in this PR https://github.com/WordPress/gutenberg/pull/64651
Here's the interaction/visual differences:
- as a normal filter
https://github.com/user-attachments/assets/012c9d03-91d3-4197-ae52-ab0122653d0a
- as primary filter
https://github.com/user-attachments/assets/9089cdcd-9400-4fe2-b106-cc6b715a55e1
After the filter UI refactoring that happened in the last release, I'm not sure the "primary filter" concept has as much weight as it had before (see conversation). We may want to iterate on this upstream. In the meanwhile, we can use that configuration to hide the "add filter" button.
Going back to the issue I brought before about disabled button states not having a representative color. This no longer happens for the "add filter" because it's removed, but it still happens for "reset".
Notice how the "reset" button always uses the blue color, even when disabled (no filter or search string):
https://github.com/user-attachments/assets/37d9f323-9d9d-48a4-9428-3ae99ace6fd5
The reason it happens is a dotcom override for wp-components.
| Active | Disabled |
|---|---|
--color-accent: #3858e9 |
--color-accent-60: #2145e6 |
|
|
We should revisit those overrides and make sure the disabled state is visually different than the active one. Changing that in this PR can have unintended side-effects, so I'd rather do it separately. To unblock this PR, the only way I see to fix it is adding more overrides. Do you have any thoughts @allilevine ?
We should revisit those overrides and make sure the disabled state is visually different than the active one. Changing that in this PR can have unintended side-effects, so I'd rather do it separately. To unblock this PR, the only way I see to fix it is adding more overrides. Do you have any thoughts @allilevine ?
I've ended up pushing https://github.com/Automattic/wp-calypso/pull/93503/commits/b2e2a6de2867b3b299a6ec34c07c2db8e59cd021. It's scoped to dataviews, so no unintended side-effects. Used the same color for disabled states as core. Given this is an override, let me know if it needs to be different or you'd rather do a different approach.
This is the result:
https://github.com/user-attachments/assets/e46bed15-6d95-478a-bcf9-a447f8713493
I've been testing the sites in the hosting screen and I don't see anything misbehaving. Filed a report https://github.com/Automattic/wp-calypso/issues/93815 for something I ran into but also happens in the current experience so it needs to be investigated separately.
I'll review the agencies screen later.