Magento 2: правильне використання помічників

9

Я починаю бачити все більше людей, які декларують класи помічників, щоб мати можливість використовувати наступне у файлах шаблонів:

$this->helper('Path/To/Helper/Class')->customMethod();

Цей вид коду дозволяє людям уникати прямого обмеження не використовувати об'єкт диспетчера, але я схильний бачити код, який повинен бути блоковим кодом у цих помічниках.

Тож ось мої запитання:

що слід писати на уроках помічників?
в яких випадках доречно використовувати допоміжні методи в шаблонах?

— Рафаель у цифровому піанізмі
джерело

20

Не варто.
Це як використовувати ObjectManager::getInstance()->create()в шаблоні!
Використовуйте користувацький блок, який отримує помічник як залежність від конструктора, і додайте метод проксі, який викликає хелперний метод.

У шаблоні:

$block->customMethod()

У блоці:

public function __construct(Path/To/Helper/Class $helperClass, ...other dependencies...)
{
    $this->helper = $helperClass;
    // ...other assignments and call to parent::__construct()
}

public function customMethod()
{
    return $this->helper->customMethod();
}

У принципі ООП говорять, що це дозволяє уникнути порушення "Закону про деметер". Він інкапсулює бізнес-логіку в блоці замість шаблону. Як побічний ефект це також робить логіку більш випробуваною, оскільки логіка переміщується в блок.

Що стосується того, яку логіку вкладають у допоміжні класи, я вважаю, що в Magento 2 помічники мають сенс для сервісів, як щось, що не є моделлю, але містить багаторазовий код, наприклад формат цін (який міститься в ядрі, але я можу зараз не думаю про кращий приклад).

— Вінай
джерело

Я погоджуюся з принципом, однак виглядає так, що, використовуючи перевагу di.xmlдля блоків типу класу, не зберігайте деяку конфігурацію макета. Я спробував, наприклад, зробити це для класу \Magento\Catalog\Block\Product\View\Type\Simple, шаблон, default.phtmlякий використовувався в нашому шаблоні, ігнорується. Немає поняття, чому на даний момент

— Sylvain Rayé,

2

Стрибки сюди для отримання більш актуальної інформації. Станом на 2.2 розширення класових блоків не рекомендується. Замість цього, якщо потрібна спеціальна логіка презентації, слід визначити ViewModel і оголосити його як аргумент Блоку в layout.xml. Оскільки ViewModels побудовані за допомогою Менеджера об'єктів, ви можете підключити свій власний графік залежності, не піддаючи себе BC, що порушує зміни у майбутніх випусках Magento 2.

— Джон Холл

1

Я бачу помічників як глобальних функцій всередині вашого модуля (вибачте за слово "глобальний"), а менеджерів / контрактів на обслуговування як глобальних функцій, які дозволено використовувати як всередині, так і поза вашим модулем.

Якщо ви дотримуєтесь цього принципу, ви побачите, що для помічників є мінімальне використання, я використовую їх лише як обгортку конфігурації у своїх модулях.

$this->configHelper->get(Config::PATH_TO_XML_PATH);
$this->configHelper->isEnabled();

Такі речі. Якщо у вас є якісь інші функціональні можливості, які можуть бути практичними поза вашим модулем, створіть замість цього менеджера.

В ідеальному світі сторонні розробники, які потребують функціональності інших модулів, повинні лише шукати доступні інтерфейси для сховищ та менеджерів та інше в Apiпапці.

— Гіль Беркерс
джерело