Разбор типовых ошибок #1. Вебинар по отложенным функциям и кешированию в компонентах

Урок 14 из 14


Вебинар по отложенным функциям и кешированию в компонентах. 

Мы рассмотрели две популярные технологии, не правильное использование которых приводило к типовым ошибкам. Часто не выполняются такие требования: 
  • При кастомизации компонентов, новый функционал обязательно должен корректно работать с включённым кешированием.
  • При создании своего компонента бизнес-логика должна работать верно и при кешировании, выборка данных - кешируется
  • В кеш компонента сохраняются значения только тех переменных, которые будут использоваться далее в некешируемой части компонента. 

Запись вебинара




Отложенные функции

Простая идея, но не всегда очевидная. Отложенная функция просто ставит "метку" в  HTML, которая дальше по коду может быть заменена на нужное значение.
Чаще всего для реализация будет достаточно стандартных API. Упрощенно, решение сводится к вызову API которое "ставит метку", например ShowProperty в хедере шаблона сайта. И к вызову API который подставит значение в метку, например SetPageProperty в компоненте. 

Чтобы разобраться в теме глубже чем рассмотрено на вебинаре, создавать свои отложенные функции - обратитесь к соответствующему видео-уроку этого курса и уроку в курсе разработчика 


Схема работы компонента и кеширование 

1. Очень полезно понимать какие объекты, их методы, переменные доступны в файлах компонента и его шаблона. Смотрите доку.

2. Схема, демонстрирует порядок выполнения файлов (и какие файлы вообще исполняются) компонента при кешировании, доступность данных из arResult .
Из нее очевидно что нет смысла вызывать отложенные функции в template.php, result_modifier.php или в кешируемой области компонента, так как  они просто не исполняются при попадании хита в кеш :)

Схема_v3.4.png


схема в полном размере
up, схема версия 3, после обсуждений, предыдущая версия схемы


Немного пояснений:
- $arResult(**) – в кеше сохраняется не весь arResult, а только те данные, которые используется в некешируемой части! Иначе растет файл кеша и нагрузка от его парсинга. В component_epilog.php будет доступен именно этот arResult, а не «полный», как в template.php 
- result_modifier.php – нужен чтобы дополнить arResult типового компонента нужными вам данными для использования в шаблоне. В template.php поступит дополненный массив $arResult(*)
- result_modifier.php и template.php – не исполняются когда хит попадает в кеш, сразу берется итоговый HTML, а значит нет смысла вызывать в них отложенные функции, они не исполнятся. 
- component_epilog.php – не кешируется, можно расширить логику типового компонента, необходимую на каждом хите, но будет не верно реализовывать в нем ресурсоемкий код, все «тяжелое» должно кешироваться. 
- $arResult (**) – если вам нужные данные в component_epilog.php, но их там нет (компонент не кеширует), то их можно добавить в кеш из result_modifier.php  
templateData  – есть и такой массив, который позволяет пробросить данные из template.php в component_epilog.php с поддержкой кеширования. 


3. Есть нюансы с подключением языковых файлов в component_epilog.php
Система автоматом не подключает файл .../lang/ru/component_epilog.php. Размещать текстовые фразы в .../lang/ru/template.php для component_epilog.php нет смысла, так как при попадании в кеш языковый файл не подключится.
Решение: создавать файл .../lang/ru/component_epilog.php и подключить его самому, use \Bitrix\Main\Localization\Loc; Loc::loadLanguageFile(__FILE__); Loc::getMessage("MY_MESS");



Ядро D7
- Кеширование в компонентах работает одинаково, будь это реализация через component.php или class.php.