refactor(frontend): improve stability of data providers

[jog1t]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[railway-app]

🚅 Deployed to the rivet-pr-4768 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
kitchen-sink	❌ Build Failed (View Logs)	Web	Apr 24, 2026 at 10:51 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	Apr 24, 2026 at 10:47 pm
website	✅ Success (View Logs)	Web	Apr 24, 2026 at 10:45 pm
frontend-cloud	❌ Build Failed (View Logs)	Web	Apr 24, 2026 at 10:44 pm
mcp-hub	✅ Success (View Logs)	Web	Apr 24, 2026 at 10:43 pm
ladle	❌ Build Failed (View Logs)	Web	Apr 24, 2026 at 10:43 pm

[jog1t]

• feat(frontend): better ux when loading actors #4769
• refactor(frontend): improve stability of data providers #4768 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

Code Review: refactor(frontend): improve stability of data providers

Overview

This PR fixes a real TanStack Router footgun: useRouteContext returns a snapshot taken at match creation time and never reflects beforeLoad results. The fix is to:

1. Move dataProvider setup into context() (sync, captured at match creation)
2. Re-export it from each route's loader so consumers can use useLoaderData
3. Update all consumer hooks to call useLoaderData instead of useRouteContext

The core approach is correct and the CLAUDE.md documentation update accurately captures the new convention.

---

What Is Good

• Root cause is correctly diagnosed. useRouteContext snapshots context before beforeLoad runs; useLoaderData reads post-loader data and will be properly reactive.
• BillingUsageGauge cleanup is safe. The features.billing and route-match guards were redundant. layout.tsx lines 213 and 237 already wrap both render sites in features.billing && matchRoute(...). Removing the duplicate guards in the component is correct.
• useDataProviderCheck is untouched. It only checks route presence via useMatchRoute, not reading loader data, so it does not need changing.
• useEngineCompatDataProvider refactor to the explicit if/else pattern with per-branch biome-ignore comments is consistent with how useDataProvider is already written.
• useCloudDataProvider simplification removes the from parameter override safely; all callers used the default route ID.

---

Concerns

1. orgs.$organization.tsx — data provider created before org validation

Before, the old beforeLoad awaited authClient.organization.getFullOrganization, threw notFound() on error, and only then created the data provider with org.data.slug (the API-validated slug).

After, context() creates the data provider synchronously with params.organization (the raw URL slug), before the org is validated in beforeLoad.

If beforeLoad throws notFound(), TanStack Router aborts navigation and the loader does not run, so there is no risk of a component rendering with a bad provider. However, the slug passed to getOrCreateOrganizationContext changed from org.data.slug to params.organization. These should be identical in practice, but if the auth service normalizes slugs (e.g., case-folding), the context cache key could differ. Worth confirming that getOrCreateOrganizationContext is slug-case-insensitive, or that the auth API always returns the slug in the same casing as the URL.

2. ns.$namespace.tsx — recordRecentVisit placement

The side effect moved from a combined beforeLoad (that also created the data provider) into a dedicated beforeLoad. This is fine functionally, but worth confirming that recordRecentVisit should still fire on every navigation to this route and not just on first provider creation. The old behavior fired it on every beforeLoad call, and the new code preserves that — just flagging as intentional.

3. CLAUDE.md bullet length

The new convention bullet is accurate but long. CLAUDE.md says to keep additions concise. Consider tightening: "Data providers: set up in context() (sync) or beforeLoad (async), always re-exported from loader as { dataProvider: context.dataProvider }. Consumer hooks use useLoaderData, never useRouteContext."

---

Summary

The refactor is sound. Two things worth a second look before merging:

1. Confirm getOrCreateOrganizationContext is slug-insensitive or that the auth API always echoes back the same casing as the URL param.
2. Confirm the recordRecentVisit call in ns.$namespace.tsx beforeLoad still fires at the correct time for your UX intent.

No blocking issues — the core fix is correct and the code is cleaner than what it replaces.

[jog1t]

Merge activity

• Apr 24, 10:51 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Apr 24, 10:52 PM UTC: @jog1t merged this pull request with Graphite.