Contrib.social

[1.0.0-beta2] Reverse renderable order?

Open on Drupal.org →
Created on 13 September 2024, about 1 year ago
Updated 18 September 2024, about 1 year ago

Problem/Motivation

On beta1, we have IconDefinition::getRenderable() whcih is building:

[
    '#type' => 'inline_template',
    '#template' => $template,
    '#context' => $context + $options,
];

Most of integration plugins (and the render element itself !) are calling this public method.

Only ui_icons_patterns IconRenderableSource is calling the render element:

[
     '#type' => 'ui_icon',
     '#icon_pack' => $icon_pack_id ?: '',
    '#icon' => $icon_id ?: '',
    '#settings' => $value['icon_settings'][$icon_pack_id] ?? [],
];

This maybe be an issue because:

  • this is not the expected "Drupal way", people which will analyse the module or extends it with new integrations expects the specific render element to be used. When we print the full render tree, we don't see the ui_icon render elements but the inline_template render element instead
  • most icons are rendered without traversing the ui_icon render element, if someone is extending ui_icons by adding a pre_render callback, it will not be triggered

Proposed resolution

2 proposals.

  1. IconDefinition::getRenderable() logic move to Drupal\ui_icons\Element\Icon render element
  2. integration plugins are calling the render element instead of IconDefinition::getRenderable()

or:

  1. IconDefinition::getRenderable() logic stay here and Drupal\ui_icons\Element\Icon render element is the only one to call this method
  2. integration plugins are calling the render element instead of IconDefinition::getRenderable()
📌 Task
Status

Closed: duplicate

Version

1.0

Component

Code

Created by

🇫🇷France pdureau Paris

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024