Part 2 · 2 chapters · ~20 min

Internal Frameworks

What a company builds over React and why each layer is a policy (routing and the shell, data, cross-cutting services, rendering mode), the cost and the signals for build, wrap or adopt, and how a policy changes: compatibility, codemods, a dashboard, bots, a deprecation date, and what it costs compared with a memo.

5

What an internal framework adds over React

a policy engine over a rendering library
  1. Routing and the shell: a route is a declaration (its code-split boundary, data requirements, auth, layout); the shell (navigation, auth, error boundaries, telemetry) is the framework's; a product team adds a route and inherits splitting, preloading, loading states and a 404. Policy: no ad-hoc routers.
  2. Data: a fetch may happen only where the framework allows (a loader, a fragment, a server component) and the rest fails a lint or a type; the framework owns the cache, error and loading states, retries and deduplication (part 3). An effect with a fetch in it fails the build: the React course part 7's "one owner per kind" as a compiler error.
  3. Cross-cutting services: i18n through one catalogue extracted at build; telemetry through one client with session, release, route and locale attached automatically (the Architecture course part 3); flags typed and bootstrapped; one error pattern; one form pattern.
  4. Rendering mode (SSR, streaming, hydration, server components; the React course part 13) chosen per route by one team; everyone inherits, which is how a company changes mode with one migration rather than a thousand.
  5. The cost: a team of twenty to fifty; a migration with a codemod per policy change; a framework bigger than React to learn; a gap from the open-source ecosystem where libraries and advice stop applying; the risk that the framework becomes a reason not to adopt a better outside idea.
  6. The signals: it pays when there are three routers, four fetch patterns, hardcoded strings and flags read five ways; it has gone wrong when the framework team is the bottleneck, lags React by two majors, or new engineers take a quarter to ship. Next.js and similar are open-source policy sets: adopt, wrap, or build, depending on which policies you need that the open one does not encode.
WHAT AN INTERNAL FRAMEWORK ADDS OVER REACT
the layers a company builds on top, and the policy each one encodes
swipe the figure sideways, or tap expand for full screen
1/6
routing, shell
Routing and the shell: a route is a file or a declaration in a registry with its code-split boundary, its data requirements, its auth requirements and its layout; the shell (navigation, auth, error boundaries, telemetry) is owned by the framework; a product team adds a route and gets code splitting, preloading, a loading state and a 404 without writing any of it. The policy: no ad-hoc routers.
6

Changing a policy: the migration

the framework's real product
  1. Compatibility first: the new pattern ships while the old keeps working through an adapter; nobody is blocked; the migration is a background process with a removal date on the adapter.
  2. The codemod: an AST transform converts the mechanical cases (typically 70 to 90%), flags the rest for a human, opens one PR per OWNERS directory, and reports the rate before the migration is announced.
  3. The dashboard: routes by pattern by team over time, the manual cases with owners, and a completion date projected from the current rate. The deprecation date comes from the projection, not from hope.
  4. Bots and owners: a bot opens the PRs, pings, refreshes stale ones, escalates after N days; owners review mechanical changes quickly; the framework team pairs on or does the manual cases. The product team's cost is review time.
  5. The deprecation: a lint warning from day one with the date and the guide; an error for new code on the date; an error for all code later; the compatibility layer removed when the dashboard reads zero. The date is the forcing function; the adapter is the humane part.
  6. The cost: weeks of codemod and compatibility, days of dashboard and bots (reused across migrations), a quarter of the framework team's attention. By memo instead: every team a sprint, two years, and a half-migrated codebase forever. The machinery is how a company changes its mind.
the transferable part
A team of thirty does not need a framework team, but every policy change it makes can still ship with a compatibility layer, a codemod for the mechanical cases, a count of what remains and a date. The machinery is the scale; the shape is the discipline.
CHANGING A POLICY: THE MIGRATION
how a framework team moves a thousand routes from one pattern to another without stopping the company
swipe the figure sideways, or tap expand for full screen
1/6
compatibility
Compatibility first: the new pattern ships while the old keeps working; a route may use either; the framework runs both (an adapter that makes a loader look like a server component to the shell, or the reverse). No team is blocked; the migration is a background process, not an event.