beforeLoad() vs loader()

[mrlubos]

As far as I can tell, there isn't a dedicated section for comparison between these two lifecycle methods. It would be nice to have a mention of recommended usage for both, which method is better for x and which one is better for y.

[gabrielvsantana]

In the meanwhile, it may help to look at the real implementation on this file.

[mrlubos]

Can you provide an overview of the differences?

[caweidmann]

Also not sure which one to use and in which scenario.

[jjhiggz]

I'm not sure 100%, but it seems like it's exactly what it sounds like... It runs the beforeLoad function before the loader function.

The main use case that they are using it for is just to dump auth into the context so that way you can reference the user every time the loaders do run.

If I'm reading this right basically you can think of every request being handled by the router something like this:

req
   |> function beforeLoader({context})
   |> function loader({context}) // but the context in here is modified by the beforeLoader

So in the case of this example for DIY Auth...

in __root.tsx

const Route = createRootRoute({
  beforeLoad(){
     const user = getUserFromSession()
     return {
         user, // <-- the new context
     }
  }
})

Now in this route, or any route nestled inside of this route (because technically you can do this not on the root route too), you can access that user in your loader.

in posts/$postId

const Route = createFileRoute("posts/")({
    // pretty mindboggling that `user` is typesafe here
    loader: ({ user }) => { 
         return getPostsForUser(user)
    }
})

Trying to think of other use cases, but currently can't. There's gotta be some though. In the case of something like queryProvider, you can just pass that in at the top level without a beforeLoad, but I think maybe the hint on when to use beforeLoad, is if you have some data that fetches asynchronously that you need for all of your loaders in some part of your app to work smoothly.

[chinmareno]

I hope this information is helpful:

I have beforeLoad, and loader in my "/signup" Route.
I have Link to="/signup" from tanstack router, which placed on component in "/login" Route.

When i click the Link (now i'm in page "/login") the flow is:

• MouseDown: beforeLoad in "/signup" executed. So when i hold the left click then move the cursor to other place then release it, it's ofc doesn't redirect me to "/signup", but it still the execute the beforeLoad in "/signup" Route.
• MouseUp: loader executed cause i'm alr in "/signup", but beforeLoad doesn't execute again.

U might wondering what if i redirect to "/signup" by manually write in url and enter, well it will count as hard refresh. So both beforeLoad and loader will executed on server in this order ( 1. beforeLoad, then 2. loader).

And if u put the beforeLoad/ loader on the layout of both "/login" and "/signup" it would trigger both beforeLoad, and loader at MouseDown, i assume it because they see u alr on the route layout (loader executes), but u also prepare to go to route layout (beforeLoad executes).

[michaelboyles]

@jjhiggz "Trying to think of other use cases, but currently can't. There's gotta be some though"

I think I have one. Imagine a layout like a github's repo: one RepoLayout, which renders the top tab view, and within that say 2 child pages: RepoCode and RepoSettings.

RepoLayout loads a Repo from the API, so that you can populate the tab bar with the name etc, which also includes some property .areSettingsEditable.

Before you load the RepoSettings page, you want to check if the settings are editable by the current user. If they're not editable, you want to 404 (that's what github does).

RepoSettings could query the Repo from the API itself, but that's already been loaded by the layout, and . If you use beforeLoad in RepoLayout then you can pass down the areSettingsEditable property.

So, I suppose considering auth as well, more generally the use-case for beforeLoad is for when you're loading some data which will be used to control access to a child route.