# Когда стоит использовать simple_tag в шаблонах Django

В Django передача данных в шаблон обычно начинается двумя способами.

* **Вставка через контекст в представлении**: явно передаём данные, необходимые для рендеринга страницы.
* **Глобальная вставка через context processor**: добавляем данные, которые нужны во всех шаблонах.

Есть ещё один способ – **`simple_tag` (пользовательский тег шаблона)**.

Правильно использованный `simple_tag` делает представление более лёгким, а шаблон – более чистым. Неправильно – данные теряют источник, и поддержка становится труднее.

![Django веб‑разработка в центре кухни](/media/editor_temp/6/40788e2b-5858-409e-b359-d9788aaa0233.png)

В этой статье я не претендую на «правильный» ответ, а просто делюсь тем, когда я обычно использую `simple_tag`.

---

## Определение simple_tag в одном предложении {#sec-76501177fcc9}

**Функция, принимающая уже существующие значения в шаблоне и возвращающая «легко обработанный» результат**.

* Можно вызывать в нужный момент, как `pull`.
* Логика форматирования/сочетания/преобразования вынесена из шаблона.

---

## Границы традиционных подходов {#sec-3b60f622e31a}

### Вставка в представлении: «основные данные страницы» {#sec-d514bca42e56}

Если данные критичны для рендеринга страницы, я всегда оставляю их в представлении.

* Список/детали, составляющие структуру страницы.
* Результаты условных веток.
* Данные, полученные через ORM‑запросы.

Переносить это в тег шаблона затрудняет отслеживание.

### Context processor: «глобальные данные для всех шаблонов» {#sec-c66a30ba1780}

Примеры:

* `request`
* Информация о вошедшем пользователе
* Глобальные настройки/меню/конфигурация
* Общие UI‑данные, как количество уведомлений

Но context processor имеет свои недостатки.

* Автоматически добавляется везде, что усложняет отслеживание.
* Тяжёлый код повышает стоимость каждой страницы.

Поэтому я ограничиваю глобальные данные и обрабатываю их через `simple_tag`.

---

## Критерии использования simple_tag {#sec-c7f07728cfc9}

Мои правила просты:

1. **Ключевые данные страницы? → представление**
2. **Есть ли хотя бы 1% ORM‑запросов? → представление**
3. **Можно ли собрать/преобразовать данные из `request` и context processor? → simple_tag**
4. **Отделённая от основной логики? → simple_tag**

Главное:

* Ответственность за «получение» данных (особенно из БД) – в представлении.
* Ответственность за «подготовку к отображению» – в `simple_tag`.

---

## Почему ORM всегда в представлении {#sec-5b9da70ad6d4}

Использование ORM в тегах шаблона часто приводит к:

* N+1‑запросам при итерации.
* Задержке в обнаружении источника проблемы.
* Неясности в применении кэширования/префетчинга.

Поэтому я придерживаюсь:

* Логика работы с БД – в представлении (или сервис‑слое).
* `simple_tag` обрабатывает только уже полученные данные.

---

## Самый распространённый паттерн: комбинирование `request` + глобального контекста {#sec-80c112ad2db5}

Я делаю так, чтобы `request` и значения из custom context processor были доступны во всех шаблонах, а `simple_tag` использует их для:

* Составления строк.
* Изменения формата по условию.
* Преобразования типов.
* Формирования структуры, удобной для шаблона.

Преимущества:

* В представлении нет «кода только для вывода».
* В шаблоне можно быстро вызвать короткую функцию.
* Нет обращения к БД – только к уже переданным данным.

---

## Пример: перенос сложной логики в simple_tag {#sec-ed85f27527c2}

В шаблонах удобно использовать `{% if %}` и `{% for %}`, но при росте условий и вложенности код становится нечитаемым.

Например, при комбинировании глобальных данных и `request` часто возникает длинный блок условий.

Перенос логики в `simple_tag` позволяет:

* Сосредоточить шаблон на UI.
* Тестировать и поддерживать логику в одном месте.

```django
{% load ui_helpers %}
{% greeting_message %}
```

Внутри тега выполняется вся сложная проверка, а шаблон остаётся чистым.

---

## Ситуации, где `simple_tag` особенно полезен {#sec-5972b56959fc}

* **Повторяющееся форматирование** (даты, суммы, надписи) в нескольких шаблонах.
* **Определение UI‑состояния** на основе `request` (активные пункты меню, переключатели).
* **Преобразование глобального контекста** в структуру, удобную для шаблона.
* **UI‑помощники**, не связанные с основной логикой представления (выбор CSS‑классов, генерация текста бейджей, простые проверки прав).

---

## Важность согласованных критериев в команде {#sec-5f9c78060000}

Мои правила – не абсолютная истина, но наличие критериев:

* Сохраняет объяснимость кода.
* Упрощает отладку и поддержку.
* Снижает споры при код‑ревью.

Я доволен этим подходом и продолжаю его использовать.

---

## Итоги {#sec-f059f0d4c5aa}

Как вы разделяете ответственность?

* Как далеко допускаете глобальный контекст?
* Как далеко встраиваете логику в теги шаблона?
* Где заканчивается «обязанность представления»?

Независимо от подхода, наличие чётких критериев – ключ к долгосрочной поддержке.

---

**Связанные статьи**

-  [Извлечение URL в шаблонах Django: path vs path_info vs get_full_path vs build_absolute_uri](/ko/whitedec/2026/1/23/django-template-url-extraction/)