Spike: evaluate adopting React Router Data mode (createHashRouter + RouterProvider)
- Dominant language
- TypeScript
- Stars
- 481
- Forks
- 108
- Avg merge
- 6d 8h
- Merged PRs (30d)
- 5
Description
## Goal
Determine whether moving from declarative mode (`` + ``) to Data mode (`createHashRouter` + `RouterProvider`) is worth it. `createHashRouter` keeps hash URLs and stays client-only, so existing users are unaffected. Data mode unlocks `useNavigation` (pending UI), `useBlocker` (warn on unsaved connection/settings edits), `useRevalidator`, and route-level error elements (`useRouteError`) — none available in declarative mode.
**Key tension:** GE already uses TanStack Query for data fetching and Jotai for state, so RR loaders/actions would overlap with an established, working data layer. The main standalone win is `useBlocker` for guarding unsaved edits — but that alone forces the whole app into Data mode.
## Expected Outcome
A recommendation (adopt / don't / partial), the concrete migration cost, and whether `useBlocker` for unsaved-edit guarding justifies the switch on its own. Task out an epic if we proceed.
> [!IMPORTANT]
> Internal only — this issue is maintained by the core team and is not accepting external contributions.
Contributor guide
Research direction
Review the current declarative routing setup using HashRouter and Routes, along with the existing TanStack Query and Jotai data layers. Compare the migration cost of createHashRouter and RouterProvider with the benefits of useBlocker, useNavigation, useRevalidator, and route-level errors; done means a recommendation, concrete migration cost, and a decision on whether unsaved-edit guarding justifies the switch.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 15/100