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

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

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

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

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

Django веб‑разработка в центре кухни

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

Определение simple_tag в одном предложении

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

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

Границы традиционных подходов

Вставка в представлении: «основные данные страницы»

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

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

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

Context processor: «глобальные данные для всех шаблонов»

Примеры:

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

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

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

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

Критерии использования simple_tag

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

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

Главное:

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

Почему ORM всегда в представлении

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

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

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

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

Самый распространённый паттерн: комбинирование request + глобального контекста

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

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

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

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

Пример: перенос сложной логики в simple_tag

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

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

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

  • Сосредоточить шаблон на UI.
  • Тестировать и поддерживать логику в одном месте.
{% load ui_helpers %}
{% greeting_message %}

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

Ситуации, где simple_tag особенно полезен

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

Важность согласованных критериев в команде

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

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

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

Итоги

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

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

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

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