Nested Routing Q&A

[00:00:00]
>> Is there any reason we need to duplicate the loader code from index.tsx instead of just exporting the loader from dot?
>> Yeah, okay, so we have our admin that has a loader. And that loader looks suspiciously like the loader in our index, in fact, it looks identical.

[00:00:24]
Except yeah, this one is a const declaration too. Okay, now it's identical. So yes, you actually could, if you wanted to, export { loader } from '.'. And that would work, this will work. I do not advise this. Because in practical situations, it's actually quite rare that you'd ever be able to to do that, that it would work.

[00:00:48]
Also because the type of loader, now you have to import that loader. I really don't typically advise importing things from route modules, that is not your job. So if you have some code that you need to share, put it somewhere else and import it in both, just general practice.

[00:01:08]
In fact, in the Advanced Remix Workshop, we do have one situation where we do import from a route module and I'll explain why. But for the most part, you don't wanna be importing from other modules or from route modules. That is the job of the Remix framework. Again, actually in practical situations, this is very uncommon to have a loader that is exactly the same as a sibling, and so I wouldn't worry too much about this.

[00:01:37]
But if you did, then just put it in a separate module and import it from both.
>> Will each route turn into a separate edge function when deploying to edge or will the whole Remix app be deployed to the edge?
>> Great question, the whole Remix app, on the edge, in serverless environments, in particular, you typically have a limit to how big a JavaScript file you can ship up there.

[00:02:02]
And typically, you also have to compile all of your code into a single file before you upload it. And so there's a limit to how big that file can be. And so, yes, this can be a concern in a large application, especially one that's using a lot of dependencies and things.

[00:02:18]
Typically, one megabyte worth of JavaScript is like, wow, that's a lot of JavaScript. But it can totally happen in sizable apps. And currently Remix does not have anything built in to chunk that out to separate individual functions that will integrate seamlessly or whatever. However, actually just today, I saw somebody share a tool that they are using to split up a Remix app into multiple Cloudflare functions.

[00:02:46]
So it is possible, it's just not built into Remix.
>> Will Remix add auth in the future similar to remix-auth?
>> Great question, will Remix add auth? Remix may in the future add built-in authentication. The challenge is, so there's remix-auth, a package created by Sergio, and it's great, I've used it and it works pretty nicely.

[00:03:16]
So if Remix were to build in auth, it might resemble something like that package, but this app has auth and here is the auth for it. It's like 100 lines of code that you can change. And, I don't know, to me, this is a pretty simple cookie API.

[00:03:40]
That's the only API in here that is Remix specific, everything else is just general JavaScript stuff. I kinda like that. If my auth can be written by myself, then I'm going to do it that way. So I'm not sure even if Remix could build it in or would, I'm not sure that it'd be my preference anyway.

[00:04:03]
But I understand that some people want to just have everything built in out of the box, it's gonna be all taken care of for you. And that's why we have the stacks, it's already built for you. So I don't think, I guess I can say that's not a priority currently for the Remix team, yeah?

[00:04:25]
>> Could you have /posts/admin.tsx instead of moving that code into /posts/admin/index.tsx?
>> Yeah, so couldn't I just take this stuff and put it inside of here? So there's a really important difference. So this file is the parent route, it's the layout route, the one responsible for rendering what shows up when the admin route is available or showing.

[00:05:00]
This is what's responsible for when there are no other children routes being rendered. And this is what's responsible for showing when the /new route is currently being rendered. And so depending on what you want to have show up and where, that's where you're gonna be putting your code.

[00:05:17]
And so we couldn't just take all of this stuff and put it in the index. Because then when we go to the new route, none of this stuff will be here, and I want this list of links to show up even when I'm on the create new post route.

[00:05:32]
So, yeah, where you put it depends highly on where you want that UI to show up based on the routes. And there's an argument to be had for sharing code. You could just put all this in a component and render it in both of these routes. And there may be a situation or a use case for that.

[00:05:53]
I should also mention, we don't really get into this in today's workshop. But if you wanted to have a /post/admin/something else that was not wrapped by the admin route, that didn't have this UI, there are use cases for that, and I can show you one here in a sec.

[00:06:11]
If you wanted to do that, then you'd say, admin.whatever.tsx. And that dot says, I want to be a slash in the URL, but I don't wanna be nested inside of the admin parent, okay? And so now I can say, oops, let's do a rmx component, return "admin whatever";.

[00:06:32]
And now if I go to admin/whatever, then it just shows admin whatever. So it's not gonna be a part of that parent route even though it's that way in the URL segments, and that's just a part of the convention. If we look at the npx remix routes now, we'll get this route here that you can see is not a nested route inside of the admin section.

[00:06:56]
So that is possible, and what is the use case? I've got a use case on my blog, actually. So my blog is the parent route. Every one of these blog posts is a child of that parent. So it's /blog/useuemo-and-usecallback. But I don't really want that nested under my big listing of all my blog posts, that wouldn't really make sense.

[00:07:15]
And so I have a blog.$ slug to make that work.
>> Is it possible to nest admin.whatever into admin/.whatever to keep the folder structure consistent with nested routes regarding layout choices?
>> Yeah, it is possible. Not with the built-in convention, but as I was saying earlier, you can build your own convention in the Remix config.

[00:07:40]
And you could say routes, I can't remember, it's an async function. And then you get a defineRoutes thing here. And you do all your async stuff, and oops, and then you return defineRoutes, and there's a whole API for this. But yes, you could define your own structure to be whatever you want it to be.

[00:08:05]
But currently, no, there's no way for you to say, I wanna have an admin.whatever, but actually still put it inside of the admin directory or whatever. Yeah, there's no way to do that.