Django Templates: Best Practices

Django Templates: Best Practices
We may receive commissions for purchases made through links on our website. We appreciate your support.

Introduction to Django templates

Django, as a web framework, uses templates as a way of producing static HTML from the output of a Django view. In practice, Djangos templates are simply HTML files, with some special syntax and a set of tools which lets Django render the HTML page on-the-fly for the visiting user. Templates are highly customizable, but are meant to be simple, with most of the heavy logic going into the view. Lets dive deeper and learn some standard ways of dealing with common problems.

Simple start with Django templates

By default, Django comes with a ton of built-in templatetagsandfiltersthat help us perform repeatable template tasks throughout our apps.

Tags:Tags provide arbitrary logic in the rendering process. Django leaves this definition fairly vague, but tags are able to output content, grab content from the database (more on this later), or perform control operations like if statements or for loops.

Examples of tags:

{% firstof user.is_active user.is_staff user.is_deleted %}

Thefirstoftag will output the first provided variable which evaluates toTrue. This is a good replacement for a largeif/elif/elif/elif/elifblock thats just evaluating on truthiness within your Django templates.

ul>
{% for product in product_list %}
    li>{{ product.name }}: ${{ product.price }}li>
{% endfor %}
ul>

Thefortag in Django will loop over each item in a list, making that item (product, in this case) available in the template context before the tag is closed withendfor. This is a widely used pattern when working with lists of Django model instances which have been returned from the view.

Filters:Filters transform the values of variables and arguments. Filters would be used in tasks like rendering a string in uppercase or formatting a date string into a users region.

Examples of filters:

{{ value|date:'D d M Y' }}

Thedatefilter will format a date (value, in the example) given a string with some format characters. The example would output the string:Mon 01 Apr 2019.

{{ value|slugify }}

Theslugifyfilter will convert the spaces of a string into hyphens and convert the string to lowercase, among other things. The output of this examplewould-look-something-like-this.

Project structure

Django, by default, will make some assumptions about the structure of our project when its looking for templates. Knowing this, we can set up our project with atemplate directoryandapplication template directories.

Imagine a project, cloud,with the following structure:

cloud/
accounts/
urls.py
models.py
views.py
templates/
accounts/
login.html
register.html
blog/
urls.py
views.py
models.py
templates/
blog/
create.html
post.html
list.html
config/
settings/
base.py
local.py
urls.py
manage.py
templates/
includes/
messages.html
modal.html
base.html
logged_in.html

How inheritance works for Django templates

An important aspect of Djangos templating system istemplate inheritance. Django applications are meant to be reusable, and we can apply the same methodology to our templates by inheriting common HTML from other templates.

A typical pattern is to have a common base template for common aspects of your application, logged-in pages, logged-out pages, or in places where significant changes are made to the underlying HTML. From our example above,base.htmlwould contain most of the core structure that would make up each page, withblocksdefined for app or page-specific customizations.

For example,base.htmlmay contain:

{% load static %}

html lang="en">
head>
  meta charset="utf-8">
  meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  {% block page_meta %}
  {% endblock %}

  {# Vendor styles #}
  {% block vendor_css %}
    link rel="stylesheet" type="text/css" media="all" href="{% static 'css/vendor.css' %}" />
  {% endblock %}

  {# Global styles #}
  {% block site_css %}
    link rel="stylesheet" type="text/css" media="all" href="{% static 'css/application.css' %}" />
  {% endblock %}

  {# Page-specific styles #}
  {% autoescape off %}
    {% block page_css %}{% endblock %}
  {% endautoescape %}

  {% block extra_head %}
    {# Extra header stuff (scripts, styles, metadata, etc) #}
  {% endblock %}

  title>{% block page_title %}{% endblock %}title>
head>
body class="{% block body_class %}{% endblock %}">
{% block body %}
    {# Page content will go here #}
{% endblock %}

{# Modal HTML #}
{% block modals %}
{% endblock %}

{# Vendor javascript #}
{% block vendor_js %}
  script src="{% static 'js/vendor.js' %}">script>
{% endblock %}

{# Global javascript #}
{% block site_js %}
  script src="{% static 'js/application.js' %}">script>
{% endblock %}

{# Shared data for javascript #}
script type="text/javascript">
  window._sharedData = {
    {% autoescape off %}
      {% block shared_data %}
        'DEBUG': {% if debug %}true{% else %}false{% endif %},
      {% endblock %}
    {% endautoescape %}
  }
script>

{# Page javascript #}
{% autoescape off %}
  {% block page_js %}
  {% endblock %}
{% endautoescape %}
body>
html>

There are a few things done in this example specifically for the sake of inheritance. Most notably, this base template has blocks defined for nearly every customizable aspect of the underlying HTML. Blocks for including CSS, JavaScript, an HTML title, meta tags, and more are all defined.

We use Djangosautoescapetemplate tag surrounding blocks where we dont want Django to autoescape our HTML tags or JavaScript, but rather treat the contents of the block literally.

Ourshared_datablock allows us to populate a global JavaScript object with variables and data which we may want to share between Django and any running JavaScript on the page (populating React or Vue.js components, for example.)

For example, if we wanted to pass a Django URL to one of our JavaScript files, we could do something like this:

{% extends 'base.html' %}

{% block shared_data %}
  {{ block.super }}
  'USERS_AUTOCOMPLETE_ENDPOINT': '{% url 'api:users:autocomplete' %}',
{% endblock %}

Django loads the page and returns in a JavaScript object that you can then use within the JavaScript files on the page:

script type="text/javascript">
    window._sharedData = {      
    'DEBUG': false,
    'USERS_AUTOCOMPLETE_ENDPOINT': '/api/users/autocomplete/',
    }
script>

The inside of a JS console once the page has loaded:

>> window._sharedData.DEBUG
false
>> window._sharedData.USERS_AUTOCOMPLETE_ENDPOINT
'/api/users/autocomplete/'

Handling querysets

Properly handling querysets within your templates can be a performance bottleneck for Django depending on the complexities of your model definitions.

Djangos templating system is tightly coupled with Djangos object-relational mapping layer which returns us data from the database. Without proper consideration of this coupling you may, inadvertently, cause the number of queries run on each page load to jump to unmaintainable amounts. In some cases, this can cause the database to become too sluggish to operate certain pages on your site, or worse, crash and need to be restarted.

Thankfully, Django provides mechanisms and patterns which we can use to make sure our templates are running as fast as possible and were not killing the database server.

Consider this common Django pattern:

accounts/views.py

class UserListView(ListView):
    template_name = 'accounts/list.html'
    model = User
    paginate_by = 25
    context_object_name = 'users'
    queryset = User.objects.all()

accounts/templates/accounts/list.html

...
table>
  thead>
  tr>
    th>Usernameth>
    th>Emailth>
    th>Profile photo URLth>
    th>Joinedth>
  tr>
  thead>
  tbody>
  {% for user in users %}
    tr>
      td>{{ user.username }}td>
      td>{{ user.email_address }}td>
      td>{{ user.profile.avatar_url }}td>
      td>{{ user.created_at }}td>
    tr>
  {% endfor %}
  tbody>
table>
...

Can you spot the problem? It may not be obvious at first, but look at this line:

td>{{ user.profile.avatar_url }}td>

When Django is processing and rendering our template (line by line), it will need to do an additional query to grab information from theprofileobject as its a related field. In our example view, were paginating by 25 users, so this one line in the template could account for an additional 25 queries (on each page request as the profile object, as with all related objects and models in Django) which arent included in the original query for the 25 users. You can imagine how this could become a very slow page if we were including fields from other related objects in our table, or if we were paginating by 100 users instead of 25.

To resolve this, well change one line in our view,accounts/views.py, toselect relatedobjects when were running our original query for users:

class UserListView(ListView):
    template_name = 'accounts/list.html'
    model = User
    paginate_by = 25
    context_object_name = 'users'
    queryset = User.objects.select_related('profile')

By replacing ourUser.objects.all()withUser.objects.select_related(profile), were telling Django to include related profile instances when its performing its query for our users. This will include theProfilemodel on eachUserinstance, preventing Django from needing to run an extra query each time we ask for information from the profile within the template.

Djangosselect_relatedfunctionality does not work with many-to-many model relationships, or with many-to-one relationships. For this, wed want to use Djangosprefetch_relatedmethod.

Unlikeselect_related,prefetch_relateddoes its magic in Python, as opposed to SQL select statements, by joining related objects into instances which can be accessed in templates as weve done above. It doesnt perform things in a single query likeselect_relatedis able to, but its much more efficient than running a query each time you request a related attribute.

A prefetch for relatedprojectsandorganizationsand one-to-many relationships off of theUsermodel would look like this:

class UserListView(ListView):
    template_name = 'accounts/list.html'
    model = User
    paginate_by = 25
    context_object_name = 'users'
    queryset = User.objects.prefetch_related('projects', 'organizations')

You can use tools likedjango-debug-toolbarto investigate templates and views in your Django application which may benefit from usingselect_relatedandprefetch_related. Once installed, django-debug-toolbar is able to show which queries are run when a view is executed and a template is loaded. This is incredibly useful for debugging slow pages, a template youve written may be running hundreds of queries.

URL namespacing

While not technically a Django templating system-specific best practice, using namespaces with your Django URLs makes developing inside templates much simpler.

I find example 2 (below) to be much easier to quickly understand than example 1.

Example 1

a href="{% url 'news-year-archive' year %}">{{ year }} Archivea>li>

Example 2

a href="{% url 'news:archive:year' year %}">{{ year }} Archivea>li>

URL namespacesallow us to have unique URL names, even if another application uses the same URL name (create,detail, andedit, for example.) Without using URL namespaces, a Django project couldnt have two URLs namedcreate. With namespacing, were able to name and reference our URLs simply, without needing long complex names for each URL in our application.

A URL namedblog-article-create,would becomeblog:articles:create, orusers:profile:createsincecreateis no longer reserved by a single application in our project. Setting this up is fairly straightforward.

Aurls.pyfile for example 1(above) would look something like this:

blog/urls.py

from django.urls import path

from . import views

urlpatterns = [
    #...
    path('articles//', views.year_archive, name='news-year-archive'),
    #...
]

If we introduce namespacing, well end up with a project setup like this:

blog/urls.py

from django.urls import path

from . import views

archive_patterns = [
    path('/', views.year_archive, name='year'),
]

urlpatterns = [
    #...
    path('', include(archive_patterns, namespace='archive')),
    #...
]

urls.py

from django.urls import include, path

urlpatterns = [
    path('articles/', include('blog.urls', namespace='blog')),
]

This allows us to traverse from theblognamespace of URLs, into thearchivenamespace where we can designate URLs which will behave just inside thearticles/path, inside theblogapplication. Rendering the URL using theurltemplate tag is also just as easy and intuitive (seen in example 2above.)

Takeaways

Django templates arent difficult to work with, but as weve seen above, there are a number of ways we can make working in Django templates even easier:

  • Learning and knowing which tags and filters are built-in and can help us out
  • Structuring our template folders in ways which are predictable for Django and other developers
  • To optimize page speeds and database connections, select and prefetch related objects before accessing attributes that span relationships
  • Namespacing URLs makes referencing them in your templates predictable and accessible for people developing on your application or project

This article originally appeared onKite.com