Question
createBrowserRouter Object Routes vs JSX Route Components for Data Loading
Ash Maple
0 reputation · 03 Nov 2022, 01:28 UTC
72.9K views1
Loading…
0 reputation · 03 Nov 2022, 01:28 UTC
When architecting a scalable application with React Router v6, there is a fundamental choice between defining routes as a JavaScript object array via createBrowserRouter or using a declarative JSX tree with and components.
The primary constraint is the requirement for optimized data fetching and error handling. Object-based routing enables the use of Data APIs, such as loaders and actions, which allow the router to fetch data in parallel before the component renders. In contrast, JSX-based routing typically relies on component-level hooks like useEffect, which can lead to "loading waterfalls" as nested components fetch data sequentially.
Additionally, the errorElement property in object routes provides a mechanism to isolate failures to specific route branches without crashing the entire application tree.
34775 reputation · 03 Nov 2022, 07:41 UTC
Use object-based routes with createBrowserRouter for applications with deeply nested asynchronous data dependencies. React Router v6.4+ Data APIs let loader functions resolve before components render, and sibling loaders can run in parallel. JSX <Route> trees typically fetch data inside useEffect after mount, which often produces sequential loading waterfalls in nested routes.
reactrouter
javascriptcreateBrowserRouter, loader, action, and errorElement are part of React Router v6.4+.errorElement isolates loader or action failures to a single route branch; sibling routes remain mounted.<Route> definitions have no built-in data-loading hook; data fetching usually starts in useEffect after the component mounts.The router can schedule loaders for nested and sibling routes before committing the UI, whereas useEffect runs after commit and after child components mount. That ordering difference is the most probable cause of sequential waterfalls in JSX route trees. Measure your own loader start and end times to confirm.
Object routes make it easier to type loader return values explicitly and use TypeScript helpers so mismatched data is caught at compile time. JSX components rely on props and runtime shape checks unless you add interfaces manually. Type inference is not automatic: you must declare loader types, and a changed loader shape can still reach the client if the component type is not updated.
Object routes are plain JavaScript arrays, so they can be generated from JSON, build-time manifests, or API responses using standard array methods. JSX route trees are harder to generate programmatically without React.createElement or a JSX transform. The risk is that a generated hierarchy may not match expected nesting or path conventions, so generated routes need navigation and data-loading tests.
npm ls react-router-dom. You need 6.4 or later.<BrowserRouter> and <Routes> tree with createBrowserRouter and RouterProvider.useEffect into loader functions on the route objects.errorElement to routes that need branch-level error isolation.Are you already using React Router v6.4 or later? If not, the recommendation changes: you must upgrade before loader and errorElement are available.
Use comments to ask for clarification. Post a solution as an answer.
5,550 reputation · 03 Nov 2022, 09:28 UTC
While createBrowserRouter solves the loading waterfall problem, it introduces a specific challenge regarding type safety. Because the useLoaderData hook returns unknown by default, the transition from JSX-based routing often requires a shift in how types are handled to avoid any casts.
To maintain strict typing in a scalable application, consider these patterns:
const data = useLoaderData() as MyDataType;This is a critical detail for teams moving from JSX routes, where data is often fetched via typed hooks or state management libraries that provide built-in type inference.