Setting up Nested Routes in a Note-taking App (pt 1)
I’ve been obsessed for a while with the prospect of making a note-taking app. On the surface that seemed fairly straightforward but as I got into it I realized a sleek simplistic UI belied a fairly complex relationship of nested routes.
Combined with having to pass data between components, and needing different types of components invoking different React Router components, it got complicated quickly. Hopefully showing how I’m thinking through the logic here will also be helpful to someone else working on a similar routing problem.
To begin, what I’m working to implement is called a master-detail pattern, which is probably the most common form of nested route. This is a common UI of note-taking apps like Evernote as well as email apps like Microsoft Office: one sees an individual message/note on the right side of the screen, while on the left side one sees a column of all recent/related messages/notes, which stays regardless of what individual note/email is currently open in the right side.
For my app, the proportions and names of the things I am splitting into the two halves of the screen are slightly idiosyncratic but the logic should be the same.
At a granular level, we can think about the 3 primary categories of components of React Router, which are, according to the documentation on React Router — Primary Components:
- routers, like <BrowserRouter> and <HashRouter>
- route matchers, like <Route> and <Switch>
- and navigation, like <Link>, <NavLink>, and <Redirect>
React-Router Hooks can also help in more advanced/nested set ups; these hooks are:
- useHistory
- useLocation
- useParams
- useRouteMatch
I want to get more abstract so I can think about how some of these components interact to form a nested routing architecture. These are my own fudgey labels so take them with a big old grain of salt.
I think about nested route app structures being comprised of:
- container components (e.g., app.js where you wrap everything in BrowserRouter) — official terminology is: Routers
- NavBar-like components: we could call them Menus or TableOfContents — React-Router docs official terminology is: “Navigation (or Route Changers)”
- Presentational switchboards — React-Router docs official terminology is: “Route Matchers.”
A container component contains both NavBar-like components and presentational components.
A NavBar-like component holds Link or NavLink components whose ‘to’ prop points to a url that will become the browser’s url when that link is clicked.
A presentational switchboard is supposed to contain a Switch component with Routes as child components. Each Route component has a ‘path’ prop whose value specifies what URL path will trigger the Route’s child component to render to the page. Thus, the route component functions just like a case keyword within a typical JS switch statement:
Comparing the W3 Schools JS Switch Statement docs and a React Router nesting example you can see that the syntax is essentially the same.
I think to consider how your app should be set up, or how mine should be, it makes sense to think about the levels of hierarchy by drawing it out and seeing how everything fits together, what components’ rendering depends on another’s / a particular URL.
While this all makes sense to me right now, my app feels currently a bit more complicated than the example apps on the React Router docs. In addition, I still haven’t gotten into the whole wirebox of routerProps. I’ll leave that for next week. Here’s a picture of my app’s component hierarchy for you to ogle. Have a nice week.
https://www.figma.com/file/mSrOHiu6MXObz1KcQdYIYQ/?node-id=97%3A0
QUESTIONS TO COVER
- ✅ different types of components/parts in a nested route architecture
- ❌️ how is this different from just having navbars at multiple levels?
- ❌ routerProps (match, other properties)