Replace site-settings snackbar with My Site connectivity banner#22834
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 124559 124574 +15
Branches 16921 16926 +5
=======================================
+ Hits 46484 46498 +14
+ Misses 74319 74315 -4
- Partials 3756 3761 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
30db3cf to
185341e
Compare
185341e to
2d6b663
Compare
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. |
@nbradbury – yeah, good feedback. The slice now only shows for failed requests, not connectivity issues. There's some possibility of overlap/transient connectivity failures, so it's a little best-effort, but I think there's a bigger effort to be done here to rework the offline experience in a unified way instead of each widget/feature handling it differently. WDYT about ecfe476? |
Much better! I'll approve this. |
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.
Review feedback from @nbradbury: enabling airplane mode immediately after login surfaces three overlapping connectivity warnings. The global "No connection" indicator already conveys the offline state, so the slice's banner adds noise rather than information when the device itself has no network. Inject NetworkUtilsWrapper and suppress the banner emission when isNetworkAvailable() is false. The fetch still runs (and fails) unchanged — failed fetches don't populate the per-session dedup, so onResume retries naturally when the user comes back online. The banner remains useful in the partial-failure case it was designed for: the device has connectivity but the site's REST endpoint is unreachable (DNS, captive portal, JPC site offline, etc.).
ecfe476 to
320d2b8
Compare



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