# Templates with Jinja2
In Phase 2 your views returned HTML by hand - strings like `f"
{notes[note_id]}
"`. That works for one
line, but falls apart the moment a note page needs a real ``, a nav bar, a loop, and a footer. Stuffing
that into a Python f-string is how you end up with unreadable views and HTML you can't see the shape of.
This phase hands that job to **Jinja2**, the template engine that ships inside Flask.
Hold this mental model: **a view's job is to gather data; a template's job is to turn that data into HTML.**
The view talks to your data (the `Note` objects), bundles up what it found, and passes it to a template that
knows how to lay it out. The view never builds HTML by hand; the template never reaches into the database.
Keeping those jobs apart is why the same list of notes can render as a web page today and (in
[Building a JSON API](08-building-a-json-api.md)) as JSON tomorrow without rewriting your data logic.
## Why templates - getting HTML out of your views
📝 You don't import Jinja2 or wire it up. It's built into Flask, and you reach it through one function:
`render_template`. You give it a template filename and the data it needs; Flask finds the file, runs it with
your data available inside, and returns a finished response full of HTML.
```python
from flask import Flask, render_template
app = Flask(__name__)
notes = [
{"id": 1, "title": "Buy milk", "content": "2 liters, oat"},
{"id": 2, "title": "Call dentist", "content": "reschedule cleaning"},
]
@app.route("/notes")
def notes_list():
return render_template("notes.html", notes=notes)
```
*What just happened:* the view fetched its data (here a throwaway list - a real database arrives in
[Working with a Database](05-database-with-sqlalchemy.md)) and handed it to `render_template("notes.html",
notes=notes)`. Flask finds `notes.html`, runs it with `notes` available inside, and returns the rendered HTML.
The view contains **zero HTML** - it only decides *what* to show, not *how* it looks.
📝 Where does `notes.html` live? In a folder named `templates/` next to your app file. Flask looks there
automatically - you don't configure the path:
```
your-app/
app.py
templates/
notes.html
note_detail.html
base.html
```
## The Jinja language
A Jinja template is mostly plain HTML with three special markers sprinkled in - the entire language:
- `{{ value }}` - **output** a value. `{{ note.title }}` prints the title.
- `{% tag %}` - **logic**: loops and conditionals like `{% for %}`, `{% if %}`, plus helpers like `{% url ... %}`.
- `{{ value|filter }}` - **transform** a value on its way out: `{{ note.title|upper }}`.
Here's `notes.html` looping over the notes the view passed in:
```html
{% endif %}
```
*What just happened:* `{% for note in notes %}` walks the list, and for each one `{{ note.title }}` prints the
title while `{{ note.content }}` prints the body. `{% if notes %}` / `{% else %}` shows a friendly message
when the list is empty, and `{{ url_for('note_detail', note_id=note.id) }}` builds the link by the view
function's *name* - the same `url_for` from Phase 2 - instead of hardcoding `/notes/1`, so a route change
propagates automatically.
⚠️ Jinja is **deliberately limited** - you can't call arbitrary Python, run a database query, or do heavy
computation from inside a template. That's a feature: real logic belongs in the **view**, where it's visible
and testable. Fighting the template to compute something is a sign the work belongs in the view instead.
## Context - what the template can see
📝 The keyword arguments you pass to `render_template` have a name: the **context**. It is the *entire* world
the template can see - if a name isn't in the context, the template doesn't have it at all, and there's no
reaching back into the view or the database for more.
```python
@app.route("/notes")
def notes_list():
return render_template(
"notes.html",
notes=notes,
page_title="My Notebook",
)
```
*What just happened:* the view passed two things into the context - `notes` and `page_title`. Inside
`notes.html`, both `{{ notes }}` and `{{ page_title }}` are now available, *and nothing else from the view is*.
Rename the keyword (`notes=` becomes `items=`) and `{{ notes }}` silently goes blank, because the template's
name must match the key you passed. That tight boundary is what makes templates predictable: to know what a
template can use, you only have to read the context.
## Template inheritance - write the layout once
Every page on your site shares chrome - the same ``, nav bar, footer. Copy-pasting that into
`notes.html`, `note_detail.html`, and every other template is how you end up updating the nav in five files
and forgetting one. Jinja's answer is **template inheritance**: a `base.html` defines the skeleton with
`{% block %}` holes, and child templates fill them.
```html
{% block title %}Notebook{% endblock %}
{% block content %}{% endblock %}
```
```html
{% extends "base.html" %}
{% block title %}Your Notes - Notebook{% endblock %}
{% block content %}
Your Notes
{% for note in notes %}
{{ note.title }}
{% endfor %}
{% endblock %}
```
*What just happened:* `base.html` lays out the page once and marks two spots - `{% block title %}` and
`{% block content %}` - as overridable holes. The child's `{% extends "base.html" %}` says "start from that
skeleton," then its own `{% block %}` tags pour content into the matching holes, never repeating the `