Replace site-settings snackbar with My Site connectivity banner#22834
Replace site-settings snackbar with My Site connectivity banner#22834jkmassel wants to merge 1 commit into
Conversation
|
|
|
|
🤖 Build Failure AnalysisThis build has failures. Claude has analyzed them - check the build annotations for details. |
17973a8 to
5d99212
Compare
5d99212 to
873cc18
Compare
84c2e15 to
10236eb
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## trunk #22834 +/- ##
=======================================
Coverage 37.31% 37.32%
=======================================
Files 2319 2320 +1
Lines 124558 124571 +13
Branches 16920 16924 +4
=======================================
+ Hits 46484 46496 +12
+ Misses 74319 74315 -4
- Partials 3755 3760 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
30db3cf to
185341e
Compare
185341e to
2d6b663
Compare
Follow-up to #22785. The snackbar from a failed editor capabilities fetch is non-actionable and disappears, leaving the user with no way to recover. On a cold launch with flaky network, it pops up before the user has done anything. Move the fetch into a new SiteConnectivityBannerViewModelSlice that posts a persistent SingleActionCard banner into the My Site header (last position, below the reauth banner) when the fetch fails AND there's no cache. Tapping the banner retries the fetch (bypassing the per-session dedup). Successful fetch — or a cached value — clears the banner. The slice cancels the in-flight fetch on site switch and on each new fetchCapabilities call, and discards results whose site no longer matches the active selection — postValue isn't a suspension point, so cancellation alone won't catch a fetch that has already returned but not yet posted. Banner taps are no-ops while a retry is in flight, so rapid tapping doesn't queue concurrent network calls.
2d6b663 to
ac1833c
Compare
|
@jkmassel This is an improvement, but if I enable airplane mode immediately after logging in, I see three separate warnings about connectivity.
Is there any way we can reduce the number of warnings? Perhaps skip showing the slice when the problem is lack of connectivity, since we know the "No connection" banner will appear. |



Description
Follow-up to #22785 (review feedback from @nbradbury). The snackbar from a failed editor capabilities fetch is non-actionable and disappears, leaving the user with no way to recover. On a cold launch with flaky network, it pops up before the user has done anything.
This PR moves the fetch into a new
SiteConnectivityBannerViewModelSlicethat posts a persistentSingleActionCardbanner into the My Site header (last position, below the reauth banner) when the fetch fails AND there's no cache. Tapping the banner retries the fetch (bypassing the per-session dedup). Successful fetch — or a cached value — clears the banner.The banner copy is generic — "Unable to connect to your site. Some functionality might be limited." — because the apiRoot fetch failure signals broader site reachability problems, not just editor issues.
Why a slice?
MySiteViewModelalready carriesLargeClass/LongMethod/LongParameterListsuppressions. The fetch is logically self-contained (takes aSiteModel, posts a card or null), so it makes sense to extract. The slice owns the per-site session dedup that #22833 introduced inline — same behavior, dedicated home, dedicated tests.Testing instructions
Covered by 9 new unit tests in
SiteConnectivityBannerViewModelSliceTest:clearBanner()clearsManual:
Related