getRouteApi() Best Practices
Hey everyone, I am new to learning Router and have a potentially dumb question. In going through this example, I noticed the usage of
getRouteApi('route/here') to access the router from outside the route definition. My concern here is if used incorrectly (outside of the route/here route tree), wouldn’t we see this not work/throw an error? I understand that this is more of a code quality/user error concern rather than a bug, similar to trying to access a React Context from outside of its Provider. Are there any guard rails you can set up to prevent this from happening?
I saw a few similar posts about getting the errors I am talking about, but wondering if there is a better guardrail than shouldThrow: false2 Replies
robust-apricot•2w ago
This isn't used to access the router/route outside of react, it's specifically used to provide you with 5-10 of the hooks that are normally available on the route, but being pre-bound to their route.
For example, normally you might do one of two things
Both of these infer your return type based on the route you provided, and will throw if they are called others.
shouldthrow does exist, but in my companies ~250 route application, we have not needed this once
---
With this in mind, you cannot do Route.useParams by importing the route into another file, because you will very likely end up with a circular import, since you are importing the route, and then the route imports your file. To get around this, the getRouteApi function exists, which purely creates your useParams, useSearch, etc. but pre-binding from to the route you gave it. This is the primary purpose of this (to avoid imports)
---
Tanstack router also firmly believes in assertions - effectively crashing the application as early as possible during development so that you can find bugs before they go out. Since all of these would immediately crash with an extremely straight forward message:
"invariant failed: could not find match for X", you will immediately be notified when you use this incorrectly.
---
TLDR; the guard rails is the application immediately crashing 😉
I also think it's worth keeping in mind, that generally, you have two kinds of components "route specific" and "shared". Shared components in your application shouldn't ever really be concerned about routing - they often accept onX callbacks and behave agnostic to the router, bar some things like global loaders or breadcrumbs, etc.
You will generally use getRouteApi when you know exactly what route you are on (generally a component that is in the routes folder), and for something that is shared, you will lean for useX({ strict: false }) if you really cannot determine where you are in the application.\typical-coralOP•2w ago
@ViewableGravy thank you for the detailed response, this is all super helpful. Yeah I was aware this isn't supposed to give you access to the route outside of React, I meant outsite of the route definition with
createFileRoute(), sorry if that wasn't clear. I was more concerned about the crashing part, which you confirmed. And to your point about crashing as early as possible, I suppose that isn't the worst thing. I can certainly create a code structure that promotes containing those components within the route, I agree.
I am a newer team lead and am trying to find ways to prevent misuse that I don't have to always catch in code review, so I am trying to avoid a scenario where someone sees an example using getRouteApi() and think they can use it anywhere. But regardless this was very helpful, thanks again!