 Thank you. So today we will be talking about leveraging the power of Django REST framework with HEMX. So I am Emma. I've been doing open source in Python and Django for a long time. Probably not Django for 20 years. So 20 years ago Django didn't exist. But I do use a lot of Django REST framework and I'm a member of the PSF and the PSF. I also maintain a few open source libraries including the REST schema adapter. And I recently started working with Torchbox. So Torchbox is an employee on agency. It is responsible for creating Wagtail and its purpose is to empower positive change makers. If you want to copy the link and you're looking for a good job Torchbox is hiring for now. And so here we're to talk about Django. So I hope everybody is familiar with Django. If you have never used Django please raise your hand. OK so strap in your info for right. But Django is a web framework and a lot of people like Django for its admin. The admin in Django is great for creating proof of concept to whenever you have to manage a list of anything like accounting software in the hotel booking software anything that where you got a list and you have to sort it and paginate it and filter it. Django admin is really great at doing that. And with Django there is also Django REST framework and as the name implies it's there for helping you building REST APIs and who has never used Django REST framework here except for the people who've never used Django. OK so just a few. So Django REST framework helps you build APIs. It comes with something called use view set that gives you a single place to create a whole crud API end point. So it also has pagination filtering and all that built in. It uses Django filters for that. And now finally HTMX. So I'm expecting that maybe I will see more hands who has never used HTMX before. OK so that's a lot of you. So HTMX is advertised as the JavaScript LEST front end framework. And it is a library that lets you do things like this piece of code where you just add parameters to your HTML. And with those HX dash attributes you can tell the browser to do something. And so here you have an HX dash get and that will say a make an HX request to the back end. And when you get the response well replace some part of my HTML with that response. So it's not expecting JSON it's expecting HTML. And with various different attributes like here we have HX swap that tells it how to swap thing. And HX target that tells it what to replace. And also HX push URL which tells it A also replace the URL in the browser. So when I click on that link the URL is going to change and I'm going to be able to just hit refresh and have that same page show up. But you probably all seen this quote. Server less is a lie. It's someone else's computer JavaScript less is a lie. It's just somebody else's JavaScript. The library itself is written in JavaScript. And but back to Django a little bit right now. So I told you it was great Django admin to build MVP proof of concepts and so on. But once you have to deliver your application to the client. Often they will want a different look than the Django admin because maybe they don't have the same test as us. Who think that the Django admin looks great or maybe because they want you to do some branding on it. And they want to put their logo or they they want to to give it a better you X. And so there's been a lot of packages have been doing that. So this is Django admin bootstrap that's maintained by Douglas Miranda. And he's doing a great job of maintaining it because this is really complicated to mean to maintain because the Django admin HTML template is it doesn't really have an API and it changes a lot. So for every release of Django almost you have to make change to that sort of packages. And this is another one that changes the look of Django admin. This is Django Gapeli. It's probably the oldest risk in of Django that I've ever seen. You know it's not just a risk in it does other things to you. But it's it's another one. And here's yet another one. And this one is interesting for us because this is Django admin to and it is class based views. And so since it's class based views it's really easily extendable and customizable. And with that you can when you need something from the admin that's not in the admin it's easy for you to add it in because it's just regular Django classes. While in the admin the admin not everything API is documented in the admin and you might struggle finding your way around. And here we can do that with Django admin to accept while Django admin to is now maintained by jazz band that maintains the legacy applications that nobody else wants to maintain. And so newer versions of Django are not supported by Django admin to. And to come back to Django rest framework. This is Django rest framework attempt at changing the admin. And this is the DRF admin renderer that uses the RF to render an admin like interface. And it is seldom used as far as I can tell. But this is something that you can get out of the box from Django rest framework. And you just have to change some configuration and you get something that looks like this. But that brings us to the question what are renters for Django rest framework. So Django rest framework is this framework that lets you create views and view sets and things like that. And you produce a response. And that response a lot of the time you will want to make it appear as JSON because you want your React application to load it or something like that. But JSON is not the only way that you can render that. You can use another renderer. You can format whatever comes out of your views as you want. And you can format that to make it available to the particular application that is going to use it. If your particular application that is going to use it is not React but is written in Java, you probably want XML instead of JSON. And that's where renders come in. You can use renders to specify exactly the format that you want. And if you've been using Django rest framework at all, you've been using renders. The two most common renders that you've been using is the JSON renderer and the plausible API renderer. The plausible API renderer takes exactly the same output as the JSON renderer but it outputs it in HTML and lets you interact with it in a nice way. But there are lesser known Django DRF renders. There is the form renderer and it's counterpart for multi-port forms. And you probably know it too because if you're in the plausible API and you try to post a form, you can have either raw HTML or a form-like thing. The form-like thing uses that renderer. But you have XML renderer, like we said. There's also CSV renders exporting things to CSV, something that we are asked all the time more often that we'd like. And there's a renderer for that. You can just use your DRF API to do that. But there's an even lesser known DRF renderer and this is the template HTML renderer. And this one just uses a template, like regular Django class-based views are using a template. You can use this to take a template and render whatever is outputted from your view. And you can use it alongside with other renders, like with the JSON renderer and the XML renderer. And you can have your HTML renderer that lives alongside with it. So why would you want to use that compared to Django's regular class-based views? Well, if you're using this, this means that with the same code, the same view code, you can render both HTML and JSON or whatever your API needs to render. And that way, you only need to write your code once, which if you're using Django class-based views and DRF, well, you have to write your code twice, so you will do something. Maybe you will create a service that creates the thing and the views are going to call that service or something. But with Django REST framework, you only need to write your code once. And also, Django REST framework provides things that the class-based views in Django don't provide. It has pagination, sorting, filtering, ordering. And once again, you write one view set and you have a whole thread application. The issues, though, is using Django REST framework to render HTML. The view or the view set in Django REST framework, usually they spit out a dictionary that is intended to be transformed into JSON. But it's not an object. So you cannot say, like, my list dot count to have the count of record, in that list. You cannot say record dot category dot name, because record dot category is just going to be a string. This can be annoying, but this also prevents you from doing N plus 1 queries by mistake. But still, JSON types are really limited. We only have a few types in JavaScript. We have string, numbers, dates, booleans, and I'm forgetting, but they're there. So what would a template look like for a list, for example, if you were to write that for DRF using the HTML template renderer? Well, it would look like this, which is basically exactly the same as it would look for Django. And if you have that code and you look at the result, you get something like this, which is exactly like what you would have in Django at last best view. Switching tabs is not going to be easy for me. But yeah, so we need a break. This is my cat. Her name is Shell, and she's clearly not impressed with that, because while we've been talking for a while now, and this is just simple Django, so how can we impress Shell? It would be more impressive if there was a way to build that automatically. Right now, the code I showed you, it was just taking the fields that we knew, and that meant that you had to write that list view for every single different thing. But the template can know about the fields automatically for different reasons. First of all, because we're still in Django while we're running the renderer. And second of all, because somebody wrote something that's called the DRF Schema Adapter, and that's a library that has two focus. One, it allows you to create endpoints that trap view sets and serializers, so you just create your endpoint, and it will create the other classes for you. And the second focus of that library is to create some metadata about your class, and usually you would do an option call on a regular JSON rendered DRF view to have that data, but you can inject that data directly into the template thanks to a specific HTML renderer, and so we could just do that. And if we do that, I have to switch screen again, and if we do that, we can have something like this from the code that was on the screen that just it gives this display. So if I look here at my template and toggle the context, you see that in the metadata, we have things that are provided by Django REST framework by default, but if we scroll down and down and down, we can see that now we have a list of fields and we also have somewhere down there, this display, yeah. We have list display that I declared in my endpoint, and now we have this list display available in the template, and so I can just loop over the list display and I can show that. And this is my other cut fruit, and he's still not impressed, so we need to fix that. But because we're inside Django REST framework, we can quite easily impress him because now we can do searching directly, and we can do pagination also. And going back to the other screen, can somebody see my mouse? Yes, good. So now if I reload this, I'm going to hide the debug toolbar, or there is a search bar, and if I type something, oh, this works. I've got search, I just had one line of code to write to half search, and I have it, and it's working. And I also have pagination, and that works out of the box because this is Django REST framework in the back, and so Django REST framework allows us to do that. And so since this is Django REST framework, why stop there? We could do other things, and look, this is Ella, this is not really my cat, this is my roommate's cat, but she looks very interested. She wants to know more, so let's do more, let's add some other things, like filter fields and ordering fields, and so I lost my pointer again. If I go back here now, I've got more things, and I can filter, and I say I want to only see videos, why is this not working? Because this is a demo, so why would it work? Of course it doesn't work. Let me refresh the page. Okay, so we have filtering, and there is nobody that's using that one, and nobody else using that one, so let's try that one again. Yes, now that works. So that was a demo effect. So now I've got filtering, and what else did I add? Oh, I added sorting, and so now I can do sorting, and that's all just Django REST framework in the back end. And you might have seen, because I put my internet connection as slow 3G, so you probably have had the time to notice that, in fact, when I'm doing something, it does a request. And only the center of the screen changes, only my list changes. Depending what you are doing, you might need to refresh different parts of the screen. If I'm changing a filter, I'm going to not only have to change the list of records, but I'm also going to have to change the number of pages in the number of records. Now if I'm just changing the ordering, I don't need to change the number of records, it's the same number of records. So there are all these little parts of the template that are changing that I need to get some or more of them. And this is something that is clearly not built in to Django REST framework or HTMLX, and so we need to tell the renderer which parts we need to have. And if you, for the ones that are in the front, you might have seen that in the URLs, when I'm clicking in the URLs, there is a parameter that says partials equals and gives the list of partials because right now this is the only trick I found to do that. It's a bit hacky, but it works. And another problem that we might have is when we are doing something in Django, in regular Django, when we are updating a record or when we are deleting a record, we are expected to be redirected after that to the list of records. But Django REST framework doesn't do that. When you do a put request on Django REST framework, it replies with 200 OK. And that's it. It updates your thing. So you do have to find a trick to do that. And if I want to do that, I can try to do that. Okay, come on. So my presenter, my room manager speaks Dutch, so I'm not going to delete Dutch. I'm going to delete French. Oh, it's asked me, am I sure that I want to delete French? Yes, I'm sure that I want to delete French. I know French is deleted. And it thinks it's refreshed automatically. And if I go and I'm going to keep being nice, and I'm going to go and edit that, and I'm going to enable Dutch. And no, I am redirected. And this is magical. And this is not Django REST framework, because Django REST framework doesn't do that. But with HTMX, we can add directly in the response adders. We can add HX location that will redirect your browser. And it will not redirect the whole page. It will redirect whatever thing you say is a target that you want to redirect. So once again, it will only load the part of the page that you're interested in. And by doing that in the renderer, you can intercept and say, okay, I know that I deleted the update and whatever else you want. And you say, okay, I want to redirect those when they're successful. But there's yet another issue. There's error message in Django REST framework. If you try to do a put on a record, to update a record, and the values you said there are not valid, what's going to happen? You're going to get a 400 error, and you're just going to get your errors. And if you replace your form with errors, that's not going to work really well. But it turns out that HTML actually can be configured to read two things other than 200. And the template, the default template in Django REST frameworks, HTML template renderer, can be customized. So we are able to render those after all. So if I go back here and I'm trying to say that English actually is not a thing, and I try to update, well, I get an error message here at the bottom. That's not a really nice UX. It would be better if the name field was the one appearing in red and so on. And remember when I said that HTML was JavaScript less? Well, if you want to have a nice UX, you're going to have to write JavaScript. But you can intercept the error message and you can write for JavaScript. And maybe you can try another JavaScript less JavaScript framework, which is Alpine.js. But I'm not going to talk about Alpine.js other than just mentioning really small at the bottom of the screen. And so this brings us into the bonus content. So I managed to do it. So there's something, when you look at those things, the form there, there's two ways to render the form that you just saw. There is the DRF form serializer that I mentioned in the beginning. And to use the DRF form serializer, you just say, I don't remember what you say. But it's something like you pass in the serializer and there is a template tag to transform that serializer directly into a form. And that gives you a form. But oftentimes when you want to make pretty forms and things like that, you would like to be able to change that. And Django doesn't encourage you to do that. Django usually does you, yeah, you can just put form. And if you want to do something better than that, well, use crispy forms. And then with crispy forms, you can do fields and things like that. But if we think about differently, we have, remember the meta information I showed you when I scrolled and I scrolled and I scrolled, it was a list of fields. So we have fields, we can include templates. So we could have widgets, we could have form widgets. And once we have form widgets, then when we just have to say, hey, this field after all, it's not that type of widget, it's another widget. And then you can make something really advanced with just HTML, HTML makes Django Django REST framework. And also it's really easy to customize something like that because if you do Django REST framework, you might know that if you create a method on a view set, you can say, you can put the decorator at action or if you'll do this in the REST scheme adapter, you have custom actions and you have quizzes that have serializer linked to them and things like that. And in the meta, you also have a list of all the actions and so on. So you could have easily add buttons for each row in the list, for example, or add more button than just update on a form. So this is all things that are possible to do. But now I feel like I've been talking a lot. So this is my last cat, Curry, and he's fallen asleep. So if I don't want you to fall asleep, I should stop talking. But if you found this interesting and you want to either help make it a library or if you want to try it for yourself, come see me during this print and we can work into making that, well, more public than it is right now. Thank you. Thank you very much. You're welcome. Although maybe your own cats weren't very interested, I was very, at least. Thank you. Do we have some questions in the room? Because I think we still have one room for one. All right. How would you convince your client or boss why should you include HTMX into Django admin? In other words, which business need does it solve? Why is it why it's something which is not possible with normal Django admin? So it depends what your boss wants you to do. If your boss says, oh, we should invest in this brand new React application because there are things that need to happen dynamically and Django doesn't do that out of the box, then you can tell your boss that creating a new React application for their needs is going to cost them two, three, five months of development while adding HTMX can be done just bit by bit and you can add the piece that you need right now for just half a day of development, maybe. So money. Great summary. Then with that, if you have any further questions, please DM me directly or put it on the Discord. Please take also your litter with you and enjoy the rest of the conference. Another round of applause.