Шаблонизация и представления

Шаблонизаторы: Blade vs “PHP‑шаблоны” в Битриксе

Шаблонизация — это про две вещи одновременно:

• как удобно писать HTML (структура, переиспользование, инклюды, компоненты),
• как безопасно и предсказуемо выводить данные (экранирование, политика вывода, минимизация логики в шаблоне).

Ключевой философский контраст:

• Laravel предлагает Blade как “тонкий” слой над PHP: директивы, наследование, компоненты, автоэкранирование.
• Битрикс исторически использует обычный PHP в шаблонах, но поверх него строит “каркас страницы” через компоненты, их параметры, шаблоны, кэш и соглашения платформы.

Laravel: где живут view и как они рендерятся

Где лежат шаблоны

Обычно это resources/views. Файл resources/views/posts/index.blade.php вызывается так:

        return view('posts.index', [
    'posts' => $posts,
]);

    

Имя posts.index — это путь внутри resources/views без расширения, где слэш заменён на точку.

Blade “как PHP, но дисциплинированнее”

Blade компилируется в PHP и кешируется в storage/framework/views. Это значит:

• Blade сам по себе не делает страницу быстрее, он делает её удобнее и безопаснее.
• Производительность решается архитектурой (кэш, запросы, объёмы данных), а не выбором синтаксиса.

Автоэкранирование: {{ }} vs {!! !!}

Самая важная привычка:

• {{ $title }} — экранирует HTML (безопаснее по умолчанию).
• {!! $html !!} — выводит “как есть” (опасно, если это не ваш доверенный HTML).

        <h1>{{ $post->title }}</h1>
<div class="content">{!! $post->trusted_html !!}</div>

    

Практическая мысль: в Laravel безопасность “подталкивается” в правильную сторону дефолтом. Если вы везде пишете {{ }}, XSS ловится реже.

Bitrix: шаблон — это PHP, а “структура UI” чаще строится компонентами

Где живут шаблоны

В Битриксе “шаблон” — это не только файл страницы (/catalog/index.php). Главная единица UI — компонент и его шаблон.

Типовой путь (упрощённо):

• общий шаблон сайта: /local/templates/<имя_шаблона>/
• шаблоны компонентов: /local/templates/<имя_шаблона>/components/<vendor>/<component>/<template>/
• файл вывода: template.php

Смысл: вы не “рендерите view”, вы подключаете компонент, который сам:

• получает параметры ($arParams),
• строит результат ($arResult),
• рендерит HTML через template.php,
• (часто) кэширует результат.

Передача данных в шаблон: $arResult

Внутри шаблона компонента вы обычно используете:

• $arParams — входные параметры,
• $arResult — данные для вывода,
• $this — объект шаблона (для служебных методов).

Ключевой “битриксовый” приём: не держать подготовку данных в template.php.

При этом архитектурно лучше, чтобы трансформация была явной и контролируемой:

• основной путь: вся подготовка/нормализация данных — в логике компонента (в class.php), где это видно, сопровождаемо и не “всплывает” как скрытая стадия обработки;
• result_modifier.php лучше не использовать как стандартный слой, потому что он добавляет неочевидный этап трансформации. Его можно оставить как компромиссный инструмент, если вы используете чужой компонент/шаблон и вам нужно сделать небольшой “view‑тюнинг”, не вмешиваясь в логику компонента.

Экранирование и безопасность: дисциплина важнее синтаксиса

В Битриксе шаблон — это PHP, а значит легко написать небезопасный вывод “по привычке”.

В простом виде:

        <h1><?= htmlspecialcharsbx($arResult['TITLE']) ?></h1>

    

Практическая мысль: Битрикс позволяет написать очень быстрый и гибкий шаблон, но безопасность и чистота кода — это ваша дисциплина и правила команды.

Компонентный подход: Blade Components vs компоненты Битрикса

Слово “компонент” в двух стеках означает похожее, но “вес” у понятия разный:

• В Laravel Blade Components — это в основном про переиспользование UI‑фрагментов.
• В Битриксе компонент — это зачастую мини‑приложение: выборка данных, кэш, параметры, шаблоны, ЧПУ/ссылки, события.

Laravel: Blade Components (и почему это хороший стандарт UI)

Простой (анонимный) компонент

resources/views/components/alert.blade.php:

        @props(['type' => 'info'])

<div class="alert alert-{{ $type }}">
    {{ $slot }}
</div>

    

Использование:

        <x-alert type="warning">
    Проверьте данные перед сохранением.
</x-alert>

    

Класс‑компонент (когда нужна логика)

app/View/Components/Price.php:

        namespace App\View\Components;

use Illuminate\View\Component;

final class Price extends Component
{
    public function __construct(
        public int $value,
        public string $currency = 'RUB',
    ) {}

    public function render()
    {
        return view('components.price');
    }
}

    

resources/views/components/price.blade.php:

        <span class="price">
    {{ number_format($value / 100, 2, '.', ' ') }} {{ $currency }}
</span>

    

Практическая мысль: UI‑компоненты Blade удобно держать “глупыми” (dumb): минимальная логика, понятные входы, максимум переиспользования.

Bitrix: компоненты (простые/комплексные) и их шаблоны

Компонент как “контроллер+view” в одном

Когда вы подключаете компонент (например, список новостей/каталога), вы фактически говорите:

• что выводить (параметры),
• как получать данные (логика компонента),
• и как это отображать (шаблон компонента).

Простой пример подключения компонента в странице:

        <?php
$APPLICATION->IncludeComponent(
    'bitrix:news.list',
    'cards',
    [
        'IBLOCK_ID' => 5,
        'NEWS_COUNT' => 12,
        'CACHE_TYPE' => 'A',
        'CACHE_TIME' => 3600,
    ]
);

    

Где готовить данные: явная подготовка в компоненте (и почему это важнее “удобных хуков”)

Если вы пишете свой компонент, самый устойчивый вариант — готовить “view model” в самом компоненте:

• class.php — выборка и подготовка данных,
• template.php — только вывод.

Так трансформация данных остаётся явной: её проще читать, дебажить и поддерживать в команде.

Наследование UI и “layout” в Битриксе

Blade предлагает наследование шаблонов (@extends, @section, @yield) как базовую механику.

В Битриксе роль “layout” обычно играет шаблон сайта:

• header.php / footer.php,
• файлы включаемых областей,
• и общие структуры страницы (шапка/меню/подвал) вокруг компонентов.

Практическая мысль: в Laravel layout — часть системы views. В Битриксе layout — часть системы “шаблона сайта”.

Assets (CSS, JS): Vite в Laravel vs Asset Manager в Битриксе

Фронтенд‑ассеты — это не “как подключить файл”, а:

• как собрать и версионировать (cache busting),
• как организовать зависимости,
• как не словить конфликт библиотек,
• как сделать производительный вывод (минимум блокирующих ресурсов).

Laravel: Vite как стандартный пайплайн

В Laravel 12 стандартный способ подключать ассеты — Vite.

В layout‑шаблоне:

        @vite(['resources/css/app.css', 'resources/js/app.js'])

    

Дальше Vite даёт:

• сборку,
• hot reload в dev,
• версионирование файлов в production,
• нормальную работу с современным фронтенд‑стеком.

Практическая мысль: если в проекте есть JS “серьёзнее пары скриптов”, Vite — это не роскошь, а нормальная база.

Bitrix: Asset Manager и расширения (и почему важно “не подключать как попало”)

В Битриксе классический механизм подключения ресурсов — Asset Manager:

        use Bitrix\Main\Page\Asset;

Asset::getInstance()->addCss(SITE_TEMPLATE_PATH . '/assets/app.css');
Asset::getInstance()->addJs(SITE_TEMPLATE_PATH . '/assets/app.js');

    

Также встречаются “расширения” и зависимости через ядро (исторически — CJSCore, в современном виде — UI‑модули/расширения).

Реальность проектов:

• часть ресурсов подключается в header.php шаблона сайта,
• часть — в шаблонах компонентов,
• часть — из модулей.

Именно поэтому в Битриксе важны правила:

• где подключаем глобальные ассеты,
• где подключаем ассеты компонента,
• и как не подключать одну и ту же библиотеку 3 раза разными способами.

Практическая мысль: Asset Manager — полезная “точка сборки” ресурсов, но порядок и дисциплина подключения в Битриксе заметно сильнее влияет на стабильность, чем в “чистом” Laravel‑проекте.

Типовые ошибки в представлениях (в обоих стеках)

Кейс A Бизнес‑логика в шаблоне

Если вы видите в шаблоне:

• SQL/ORM вызовы,
• вызовы внешних API,
• сложные расчёты/условия,
• и “если пользователь такой — то так, а если другой — то иначе” на 100 строк,

то UI перестаёт быть UI.

Кейс B Непредсказуемое экранирование (XSS)

• Laravel помогает дефолтом ({{ }}).
• Битрикс требует дисциплины (htmlspecialcharsbx, фильтры, строгие правила “что можно выводить как HTML”).

Кейс C “Склеивание” layout и бизнес‑части

В Laravel лучше держать общий layout отдельно и не превращать app.blade.php в монстра.
В Битриксе важно не превращать header.php в место, где живёт всё (условия, запросы, ветвления по доменам/пользователям и т.д.).

Кейс D Кэш: включили — и забыли про актуальность

В UI‑слое часто есть “живые” элементы:

• корзина,
• счётчики,
• персональные рекомендации,
• данные пользователя.

В Laravel вы чаще кэшируете данные/результаты (Cache facade, HTTP cache, reverse proxy).
В Битриксе очень легко включить кэш компонента и затем удивляться, почему “у всех один и тот же блок”.

Сравнительная таблица: шаблонизация и представления

Шкала (как и раньше): от -2 до +2.