Here's what I learned from examining the Django official tutorial, after using the framework for 3 months

Learning the intricacy of a framework or language is hard. It is the art of using something that someone created years ago and make it do wonders. It means learning the tips and tricks of the framework and also the serious stuff: the must-dos that you should adopt early. After learning Django as a web development framework at the beginning of 2020, I had the chance to apply it in side projects and also during my first software development internship. Writing Python code is a pleasure, because of the batteries-included nature of the language. Django, therefore, is really easy to get used to and allows rapid prototyping.

In this article, I would like to pen down some of my thoughts and reflections after using Django on a day-to-day basis for 3 months straight. I made references to the Django official tutorial (making a polling app) as the idea of this article came to me when I was working through that tutorial.

Namespacing

This is a surprising find. Namespacing is something that I overlooked as a beginner coder. It may seem to be troublesome adding some sort of prefix in the naming of functions/templates etc. However, it turns out that it is really important. Trust me, you do not want to be stuck in a situation where your code looks alright but no matter how many times you press the F5 key, or ctrl + F5 (if you are on Windows, to hard refresh) to refresh, the web page just does not reflect your latest change. This issue is likely resulted from namespacing. It happens when you have two different files with the same name, though in different folders, are referred to arbitrarily.

Template namespacing

Instead of putting template HTML in the individual "templates" folder within each Django app, you should have another subdirectory within the "templates" folder, with the name of the app. After this, you will refer to the template together with the app name, and this will prevent incorrect referencing to templates living in another app.
e.g.

# Dont do this 
polls/templates/whatever.html
# Do this 
polls/templates/polls/whatever.html
# Refer to the template like this 
"polls/whatever.html"

According to the documentation itself

Now we might be able to get away with putting our templates directly in polls/templates (rather than creating another polls subdirectory), but it would actually be a bad idea. Django will choose the first template it finds whose name matches, and if you had a template with the same name in a different application, Django would be unable to distinguish between them. We need to be able to point Django at the right one, and the best way to ensure this is by namespacing them. That is, by putting those templates inside another directory named for the application itself.

URL namespacing

In the same vein, we need to enforce namespacing in URLs as well. This will avoid so much trouble down the road. With multiple components in a single Django project, we need to know how to refer to the correct URL. The first thing we need to do is to add an 'app_name' variable in the urls.py file within the app.
e.g.

app_name = 'polls'
urlpatterns = [
path('',views.index,name='index')
]

With the addition of app_name, the reference to the name of the path will no longer just be the name, 'index', in this case. Instead, to refer to the same path in the template, you now have to use 'app_name:pathname' structure.
e.g.

<!--Previously-->
<a href="{% url 'index' %}"></a>
<!--Now-->
<a href="{% url 'polls:index' %}"></a>

On the topic of URL, quick tips: avoid hardcoded URLs in your template HTML. You may be tempted to use absolute URL in 'href' attributes, but it will be a tech debt that you have to repay when you decide to change the top-level URLs.

Static namespacing

Last but not least, static files (images/videos, etc) are best put into a proper subdirectory, just like templates. This is quite crucial, especially because when you have Nginx to serve up your static files in the production environment, you have to first run the collect-static command and all the static files will be stored in the same folder if you do not make the effort to create subfolders. Django would not be able to tell them apart.

# Don't do this
polls/static/whatever.jpg
# Do this
polls/static/polls/whaever.jpg

Conclusion

Applying namespacing to your Django code may seem to be a minor detail at first, but it is an important practice that is necessary, to say the least. Do this early and do this right, you won't regret it!
(Stay tuned for part 2, where I discuss other learning points:) Also, feel free to leave comments below to share moments when you realize something that you didn't appreciate as a beginner but is actually critical to know.)