Controlling the URL & Redirection




Check out a free preview of the full HTMX & Go course

The "Controlling the URL & Redirection" Lesson is part of the full, HTMX & Go course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen demonstrates how to create a contacts page with the ability to delete contacts and update the URL accordingly. Additionally, they explain how to handle infinite scrolling and filtering using HTMX. They emphasize the engineering aspect of HTMX and encourage a step-by-step approach to problem-solving.


Transcript from the "Controlling the URL & Redirection" Lesson

>> There's a couple more things I want to just talk about. First off, practice makes perfect. You kinda gotta know and use these for a little bit and you'll discover new items. I made this really stupid example here for a quick second that is just like this really nice little, look at that.

And I used v.0, so look how pretty that is, I didn't design any of that. And when you click it, it does all that nice stuff. We did this all today, went over here made sure that you can't have a valid email. And when you hit subscribe it disables the button for a little bit of time while the the request is happening, and then gives you that nice little air, that's nice and pretty.

It feels pretty, it looks pretty. And I did that all with v.0 plus a little bit of htmx, so pretty easy. We could do in between swaps as well as we have these nice transition between scenes, just didn't do any of that stuff. And we're gonna go over a couple examples from the book to kinda show more of the engineering aspect of HTMX.

Okay, there's a lot more examples in here, go check them out. First off, current URL can be controlled by HTMX, which is really great. So as we make transitions through our app, if you wish to update the URL, you can do that. You can choose how you want it.

You can say, hey, don't update the URL. So when we do a body swap, you don't want to update the URL, then hey, don't update the URL, so we can do all those kind of things. So let's say we want to create a contacts page. So when you clicked on a contact it actually went to a page with all the information.

But we also wanted to be able to delete from the page. Our current delete endpoint wouldn't work that way, right? It will send down no contact or no content, what would happen? Well, the button would disappear. You wouldn't know that the contact has been deleted. We just wouldn't have an experience there.

So what should happen? Well, first we can create a very simple delete button. Which is a nice little indicator, we can push the URL. So when we do a change with the button, it will actually save that change and update our URL. We can target the body if we want to, but again, we're just sending down no content.

So it'd be kind of weird, we just make the page go blank. So what we can do is we can actually do a couple things. So first off we can always disable the button during the request. Here's a simple JavaScript function that I have that you can just attach the window called disableButton.

You pass any button that you create into it, and it will automatically listen to the request and disable it during the lifetime of a request. Pretty simple to make right? Not only that, but how do we do the Delete on the contacts page, how would that work? Well, you have to understand a 303.

And so first, what you're probably thinking is that if you were to delete on a contact page, you would press the delete button, it would go to the server, it would do a delete. And if you're in a modern front-end world, you'd need to tell your client, your front end to do a navigation to a separate page.

And make sure that the data is up to date and rehydrate your data and make sure that your local cache matches your server in more of this kind of like HTMX world. You do the standard which is to actually do a delete to the server, the server responds with a 302.

But if you do a 302, a 302 redirect carries forward the verb and so that would cause you to call delete on slash, so that wouldn't be good. What you would wanna do is a 303 view a 303, it won't care for the verb instead, it'll do a get on the slash or on whatever kind of 303 next thing.

Like we said earlier, if we push the URL and do the Delete, we'll get the indicator to show up. We'll disable the button when the risk response happens and it does a 303, our URL will be updated to make sure it's now at slash, and we will have that context deleted and everything we've done.

And so another thing I'd like to kinda de confuse if you're doing inline or not inline, you can just literally add a redirect tool, right? You can kinda go back to the old days where you don't have to come up with super generalized solutions for every single problem, just come up with the solution for the problem at hand.

This would make the whole thing just simply work, right? So I like that you can make it a link and do a boost. There's all sorts of different kinds of tricks you can do. I actually really like that approach. I feel like it's very engineering, right? I know how to set up a problem to do that for any type of content and it's very simple to follow the logical steps throughout your application.

All right, next problem, you have too many contacts, right? This would definitely happen to the point where you couldn't just send down a page full of contacts. It would absolutely just destroy your experience. So there are nonstandard events in HTMX trigger, which include load, reveal, and intercept. If you're doing some CSS fancy magic, you Intersect allows for a scroll y scroll x kind of offset.

Whereas reveal simply has if an element is visible onto the viewport, I want you to trigger an action. And so it's kind of a cool way to be able to load content more. Kinda when you're on Twitter and you're scrolling down. I want to add in a final element that's like, hey, when I show up, do something.

You could also be pretty clever about that. You could put that element maybe further into the list and then do two updates. A no content update to delete that thing, plus an out of bands update to add more things to the list so that way you can trigger a request earlier before the content all runs out.

A lot of little strategies here, but I made a little program called blocks, remember blocks? We talked about it about blocks earlier at the very beginning of the course. I can kinda show you what that looks like. Here we go, very, very simple. We have our template right here that does infinite scrolling.

And all blocks does is it will simply make a block with the ID that was added to the block. And if there are more to reveal, then I'll do a trigger on reveal, swap the outer HTML of this div element. So meaning what comes back from the server, this div will be replaced with, and I already have effectively the cursor right here.

Blocks start equals the next place to start at. So I can generate the URL I need to continue to go through my list of whatever it is. And that would look something like command that's Cmake, don't [SOUND] Let's not do any of that. That's just the worst stuff in the universe.

All right, so if we did that, we go to, did I do it at 68? What did I do it at? Yeah, I did it at 69 slash blocks. So if we look at the network, we'll see that it made two requests right off the rip because when this page landed, 10 was already in the viewport.

That little thing was revealed so then it added the next 10 and then that thing was still in the view port and made that third request. And as I scroll down, it's gonna just start making requests, making it feel like there's more content coming. You could do an HTMX Indicator.

You could have little spinner at the bottom so that way you know more content's coming. There's all sorts of interactions you can do. And this is a relatively unfun thing to program, generally, which has been made relatively simple, especially for a tool. Like, how many times have you used a stupid build tool where you just wanna see more things and, like, that process just totally sucks.

It just doesn't have to suck, right? It just, it really doesn't have to suck. You can make pretty simple servers to manage to do all this stuff, very simple. So contacts are the exact same thing, add a reveal more at the end, scroll down, what about filtering? Well, filtering is the same problem as the previous one.

Besides for the very simple case where you have ten items, you don't need to make a server request, and I'm sure you could add some fancy JavaScript for this. But in general, you have many items. And so when you start filtering, you have to make a server request.

Because you have to filter your 10,000 items down to some small match that you can display on the screen, and then also add an active reveal if you need to. And so this is called active search. And here's a very simple example of an active search. You have a form that you can submit to search for contacts.

But while you're typing, the input field is actually making requests and updating the element below. So id search, you can fill it in with the previous value if you want to. So in case you already have a search going and the page refreshes, you maintain all the same stuff.

So you have a trigger on key up delay for 200 milliseconds. In other words throttling and if the contents been changed, make a request to the server. You add some cached headers, add some sort of list to it, add some sort of key values. So if the contacts haven't changed, you can just use cached values from within your actual like browser cache, all sorts of good ways to do stuff here.

And it's just a very simple method to do active searching. And so again, kind of engineering in a way. So I want you to feel that. Its whole goal is to return to more of what feels like a computer science-y or a very engineering way to approach problems.

It doesn't feel like how do you want to solve this? What ways can you envision? Do you want to write your own? Do we wanna use redux? What can we explore? It's like no, there's actually a really defined way to do these things that's existed for a long time.

Let's just don't to do step-by-step procedures for everything because anyone can memorize these 10 patterns and be pretty successful at building tools. You're probably asking yourself how many URLs can be represented or how many states can be represented by URLs and HTTP codes. Well, quite a bit. You can do quite a bit of things with HTMX.

Here's some obvious examples that you would never use HTMX for, maps, it wouldn't make any sense. The Chrome could totally be HTML, but maps itself. You obviously need that spreadsheet. Why would you ever do Compute Side stuff instead of client side stuff? Conway's game of life, the actual game can be played, but if you wish to have something that can save states of Conway's game of life and all that, you could use HTML to actually.

Trigger all those events and do all the saving and loading and giving you a list of different games you've played before. I actually built this once just to kind of test it out to see if I can do a really nice rich client-side experience where you have a game where you can select different items and draw your own Conway's life and then play Conway's life.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now