This course has been updated! We now recommend you take the Complete Intro to React, v8 course.
Transcript from the "BrowserRouter vs HashRouter and Q&A" Lesson
[00:00:00]
>> So now, you have this thing in the middle here, and you can click on it and this will take you back to the home page, so you can go back and forth. So if you're seeing \like a useHref error, it's because your link is outside the browser.
[00:00:13] So let's take a look at what that would look like. So, if I just move this, so now this link tag is outside of the browser router. If I go back, and look at, now I have nothing here and I look at the console here, you can see useHref may only be used in the context of a router component, right.
[00:00:33] So this is what I was talking, too, about before is make sure that your links are always inside of the router. Let's put that back, cool. One more thing here, you're seeing browser router. There's actually multiple different types of routers you can use with React Router. So I think it's called #router, it is.
[00:00:59] Okay so let's just pop in #router for fun. And if I save that, and now I go to Details, look at my URL. So obviously in the homepage is fine but if I go to Luna, notice that there's this #/ thing. If you've ever done other websites where you are not in control of the server, or you have a back end team that you don't wanna work with cuz they're a bunch of jerks and maybe projecting a little bit right now?
[00:01:28] [LAUGH] Sometimes you don't have the ability to create firm routes on your server. So what this #router allows you to do, is it allows you to create basically a router that never leaves that one page, right? So this #/ will always route to the same page, so you can actually just do this without doing anything to your server.
[00:01:51] Whereas if you're doing browser router you have to make up make sure all of your routes from either Nginx or from Apache. Or whatever you're using for your kind of server ingress, all route to the same index HTML page, right? Does that make sense? So hash router allows you to not do that, it allows you to just be lazy and say, cool.
[00:02:13] Just send everyone to this one page and everything will just work, and we'll use the hash router here. Whereas browser router, Allows you, Now notice, the #/ there is gone. Where possible you use browser router. It's better for SEO, it makes more sense to users, the URLs are better.
[00:02:40] It's just overall better experience for both you and for them. Sometimes it's either not important, if it's like an internal website, who cares, right? It's not being indexed anyway. And screw the rest of your employees that work with you. Or, yeah, so it doesn't matter if it's something like that.
[00:03:00] So yeah, use browser router where possible though, for consumer facing applications. Okay, All right, any questions about that? That's about as much as I'm gonna get into React Router. It's a very deep pool that someone could come teach a course just on React Router if they wanted to, but that person's not me cuz I don't want to.
[00:03:39] Yeah, Mark?
>> If I wanted to post something from my app to my server, may I use the POST method in the reactor out?
>> That's not something I'm familiar with, if that's the case. I would just use a normal, either HTML form post which would go to a server.
[00:03:59] Or like a Ajax fetch with request with the post in the headers, but maybe I'm not understanding the question correctly. Or to restate that, I'm not familiar with React Router doing anything for posting. Remix does. So, Remix is basically the React Router people took React Router, and then built a server layer on top of that, right?
[00:04:31] That's basically the entire value prop of to me what Remix is. I actually built the course website here. I built it in Remix just for fun to see how different it was. It's a lot of fun. We'll talk maybe more about it a little bit at the end, but you can basically think of remix as a replacement for rails.
[00:04:56] But it's all React Router-y, it's like React Router-y rails. Yeah, I'm happy with that analogy. [LAUGH] I don't think about it. Yeah, question?
>> It was like expresses now you're writing express stuff on your front end, then you're kind of combining off that routing logic all into one?
[00:05:18]
>> You could think of it that way. It's more like Next or yeah, Remix and next are very similar in that capacity. Mark, you had a question?
>> How do you create protected routes?
>> Yeah, that's a good question. I'm gonna go ahead and say, read the docs, cuz it's a kind of an in-depth question, But it's not anything that's gonna surprise you.
[00:05:50] Yeah, I guess read the docs. I don't wanna go much further into it than that. I also can't do it off the top of my head, so that's another reason.
>> Is it best practice to have all the component files in their own folder?
>> Yeah, that flavor of question comes up every time I teach this course of like, how do I organize my react code?
[00:06:14] Cuz obviously this is just kind of spewing all of our components and styles, and index HTML and custom hooks into one directory. Is that the best way of organizing your code? Probably not. [LAUGH] I've tried different opinions over the years of how I like organizing react code, and I don't know if I've ever really been satisfied with any one particular way of doing.
[00:06:44] I've seen people say, are all routes go in one, all reusable components go in another, all utility is going to a different one, all my hooks go in one. That's certainly a way to do it, and I find that it never works out the way you want it to.
[00:06:57] Because then you get, well, this one's kind of component-y and hook-y, which one do I put it in? I'll put it in neither, I'll create a new directory, and then you have, all right, is this in the legacy components or the new Components directory? It never ended up the way that I wanted it to.
[00:07:13] Certainly organizing by route seems to make some sense to me. You could try that. I can show you one that I wrote some years ago. I think it's called Photo Gallery. Yeah, I was pretty happy with this one. You can see this is pretty old, this is five years old.
[00:07:29] But if you go to my source directory here, I had this Components directory and every component was a directory. And then if you click into one of these, the CSS is in it, the component is in it, the test for that component are all in the same directory.
[00:07:47] I was pretty happy with this. This seemed to work pretty well because then the entire world for one component lived in one directory. The issue is what happens if I have child components of these ones? Do I put it in the same directory? Do I put it in this sibling directory?
[00:08:05] I don't have a great answer for that either. So code organization always, especially for long-lived applications, always ends up messy. So embracing that fact and kind of leading into it instead of trying to dogmatically apply rules that'll never work. It seems to work best for me. It's like embrace the mess, right?
[00:08:28] Make it searchable and make it believable. If something's deletable, that's how you know you've done well. Cuz that means you understand your dependency tree enough that you can confidently delete things. That seems to be the best thing that I've ever optimized for. So I gave you a total non-answer.
[00:08:46] I'm aware that I did that, as, one, I'm kinda unsure of the answer myself, and two, it's highly contextual to you, your team, how you're writing things, what makes sense to you, and the problem that you're solving. Honestly, if you're writing an app this big that's fairly small, applying too many rules of organization is just wasteful.
[00:09:12] The least amount of process that works is probably the best idea. But make sure you have some process or else you're just gonna end up with something even worse. At the end of the day, I just said, I've seen some shit, right? [LAUGH] I've seen really great code bases.
[00:09:32] The Netflix one actually was a fairly large mess. It got better, it got worse. We had a bunch of rewrites that never ended up the way that we wanted them to. So, I don't know. I feel like I've kind of lost my way here, I'm just kind of rambling about all the things that I've done in my career that were a mistake.
[00:09:50] [LAUGH] Group therapy, we're going back to that.
>> Any route you want to have on the app or site, you need to have in the routes?
>> Yes, so anytime that you add a new route here you just stick another route here. Or you put like a child one if it's gonna live in a different part of the app, yeah.
[00:10:12] But it has to be inside of the routes.