Услуги по разработке компонентов 1С-Битрикс

Разработка компонентов Битрикс

result_modifier.php — самый недооценённый файл в Битрикс

Начнём с того, о чём большинство битриксоидов узнают через год работы. result_modifier.php сидит в папке шаблона компонента и выполняется между логикой компонента и отрисовкой template.php. Он получает заполненный $arResult и может его дополнить, перегруппировать, обогатить — и при этом при обновлении самого компонента файл остаётся нетронутым.

Реальные задачи, которые через него решаем постоянно:

• Компонент bitrix:catalog.section не выбирает свойства торговых предложений — дотягиваем через CIBlockElement::GetList прямо в modifier, складываем в $arResult['OFFERS_PROPS']
• Группировка элементов по разделам или произвольным свойствам — штатный компонент отдаёт плоский массив, а дизайн требует табы по категориям
• Расчёт скидок, рейтингов, сроков доставки — всё, что зависит от бизнес-логики, которой в стандартном компоненте нет
• Подготовка JSON-массивов для JavaScript — $arResult['JS_DATA'] = json_encode(...) прямо в modifier, а в шаблоне просто <script>var data = <?=$arResult['JS_DATA']?></script>

Главное правило: тяжёлые запросы к БД в result_modifier допустимы, потому что он работает внутри зоны кэширования. А вот в component_epilog.php — нет.

component_epilog.php — вне кэша, и в этом сила

Выполняется после отрисовки шаблона и вне зоны кэширования. Каждый хит, даже закэшированный. Сюда кладём:

• Проверку авторизации и персонализированные элементы: «Добавить в избранное», «Купить в 1 клик»
• Установку мета-тегов и заголовков через $APPLICATION->SetTitle()
• Подключение JS/CSS через Asset::getInstance()->addJs()
• Навигационную цепочку

Критично: никаких тяжёлых SQL здесь. CIBlockElement::GetList в epilog — прямой путь к деградации, потому что запрос будет выполняться на каждом показе страницы, минуя кэш.

Архитектура компонента

Компонент — самодостаточный модуль:

• class.php — ООП-класс, наследующий CBitrixComponent. Бизнес-логика, выборка данных, валидация параметров. В новых компонентах используем только его, component.php — процедурный пережиток.
• template.php — чистый HTML + $arResult. Никакой бизнес-логики.
• .parameters.php — описание входных параметров для админки.
• .description.php — метаданные: название, категория, иконка.

Всё на ядре D7, ORM-классах и событийной модели. CIBlockElement::GetList — только когда D7 ORM не покрывает кейс.

Кастомные компоненты

Стандартных хватает для типовых сценариев. Но нестандартная бизнес-логика появляется на каждом втором проекте:

• Калькуляторы стоимости с многопараметрическими формулами
• Интеграционные компоненты для внешних API (CRM, ERP, логистика)
• Мультишаговые конфигураторы товаров и системы бронирования
• Дашборды для административной панели

Принцип: компонент переиспользуемый — параметризация вместо хардкода. Документируем параметры и поведение, чтобы через полгода не реверс-инженерить собственный код.

Ajax: контроллеры D7

Встроенный ajax-режим каталожных компонентов (AJAX_MODE = Y) закрывает базу — пагинация, фильтры, сортировка без полной перезагрузки.

Для кастомной логики — контроллеры Bitrix\Main\Engine\Controller. Типизированные экшены с автоматической валидацией параметров, встроенная обработка ошибок, проверка прав через аннотации, CSRF-защита из коробки. Endpoint через ajax.php или кастомный роутинг. Ответ в JSON. Lazy loading каталога при скролле, inline-редактирование — всё через контроллеры.

Кэширование — определяет скорость сайта

Разница между 200 мс и 3 секунды — это стратегия кэширования.

Управляемый кэш — автоинвалидация при изменении данных. Добавили товар в инфоблок — кэш пересоздался. Самый надёжный вариант для контентных компонентов. Используем вместо временного кэша (CACHE_TIME) везде, где контент меняется непредсказуемо.

Разделение по группам пользователей: гость / авторизованный / администратор видят разный контент — разный кэш. Персональные данные — строго в component_epilog, вне кэша.

Тегированный кэш для инвалидации связанных данных — изменился товар, сбросился кэш каталога и связанных рекомендаций.

Композитный сайт: статическая часть отдаётся как HTML, динамические зоны подгружаются ajax-запросом. TTFB < 100 мс. Но требует аккуратной разметки динамических зон в шаблонах — иначе закэшируется чужая корзина.

Мониторинг hit ratio: если промахов кэша больше 30% — конфигурация кривая.

Сроки разработки

Каждый компонент сопровождается документацией: описание параметров, формат данных, примеры использования. Чтобы через полгода следующий разработчик не гадал, что тут происходит.