#custom elements

I did not know this code yet, and/so could not make out from the discussion, what to do... so I needed to just tinker with it myself.

End conclusion: yes, this solution is already good. (Updated issue summary, with my understanding of what we are doing.) It just needed bugs fixed:

Another issue I get now is that markup format is producing an error:

That's because the controller was still doing $custom_element->setSlotFromNestedElements('rows', VALUE);, while VALUE was changed from $custom_element to $custom_element->toRenderArray(). The setSlotFromNestedElements() is now fixed.

the pager is now (again) producing errors on pre-view:

The preexisting code in the row style plugin just put an array of values into $result['pager']. That is not OK / not a valid render array.

I moved the code into the CustomElementsPage display plugin, because it's only needed there. Now we're not setting $result['pager'] anymore -- error is gone.

From a quick check the MR looks mostly good, except for my remark related to PluginException being the wrong exception is not yet addressed.

> It works if I don't transform rows in render arrays but leave them as custom elements objects here. The issue is that render transforms render array into markup, but then the value is not string or MakupInterface which it expects.

hm, not sure I get that. You mean custom elements produces an invalid render array, that cannot be correctly rendered? If so, we should open an issue for fixing that and get that fixed. Returning Markup instead of a plain string would make sense to me. Please work with roderik as necessary to get it addressed.

@fago I've followed your advice, but the pager is now (again) producing errors on pre-view:

 	User error: "current" is an invalid render array key in…
        User error: "total_pages" is an invalid render array…

Another issue I get now is that markup format is producing an error:
https://admin--example.ldp-project.localdev.space/admin/test-ce?_content...

The website encountered an unexpected error. Try again later.<br><br><em class="placeholder">TypeError</em>: strlen(): Argument #1 ($string) must be of type string, array given in <em class="placeholder">strlen()</em> (line <em class="placeholder">395</em> of <em class="placeholder">core/lib/Drupal/Component/Utility/Unicode.php</em>). <pre class="backtrace">Drupal\Component\Utility\Unicode::validateUtf8(Array) (Line: 65)
Drupal\Component\Utility\Xss::filter(Array, Array) (Line: 830)
Drupal\Core\Render\Renderer-&gt;ensureMarkupIsSafe(Array) (Line: 427)
Drupal\Core\Render\Renderer-&gt;doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer-&gt;doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer-&gt;render(Array) (Line: 475)
Drupal\Core\Template\TwigExtension-&gt;escapeFilter(Object, Array, &#039;html&#039;, NULL, 1) (Line: 48)
__TwigTemplate_f87dc8cf16e7d60f6d3486e533c81d7b-&gt;doDisplay(Array, Array) (Line: 394)
Twig\Template-&gt;displayWithErrorHandling(Array, Array) (Line: 367)
Twig\Template-&gt;display(Array) (Line: 379)
Twig\Template-&gt;render(Array) (Line: 38)
Twig\TemplateWrapper-&gt;render(Array) (Line: 39)
twig_render_template(&#039;modules/contrib/custom_elements/templates/custom-element.html.twig&#039;, Array) (Line: 348)
Drupal\Core\Theme\ThemeManager-&gt;render(&#039;custom_element&#039;, Array) (Line: 480)
Drupal\Core\Render\Renderer-&gt;doRender(Array, 1) (Line: 240)

Changing that would be an API break. Why would we do that? Are there issues with the pager?

Because of #9 🐛 When editing a custom elements page view php errors are produced by renderer Needs work .

I'll try out the proposal.

replied in drupal issue, but I think the problem is that view's renderer doesn't know how to render custom elements.

This rendering is good, it's correctly rendering the custom element using markup serialization:

<div class="preview-section"><drupal-view title="" view-id="te" display-id="custom_elements_page" :pager="{&quot;total_pages&quot;:2,&quot;current&quot;:0}"><template #rows="">
<teaser-wide href="http://devblog.ldp-project.localdev.space/drupal/custom-elements-our-solution-soft-decoupled-drupal-57" title="Custom Elements: A solution for soft-decoupled Drupal!" category="Thunder core" excerpt="When it comes to decoupling, it turns out there are many options on how to decouple. Not only are there many technology choices in choosing the right frontend framework and APIs involved, the questions become also more foundational: Which system should be in charge for handing different aspects of the applicaiton, e.g. routing, placing blocks or authentication?" :image="{&quot;aspect-ratio&quot;:133.33000000000001,&quot;src&quot;:&quot;http:\/\/admin--example.ldp-project.localdev.space\/sites\/example\/files\/styles\/300_225\/public\/2024-09\/chocolate-brownie-umami.jpg?itok=jcNG8O0W&quot;,&quot;srcset&quot;:null,&quot;alt&quot;:&quot;Alt Placeholder&quot;,&quot;title&quot;:&quot;\u00a9 GPL v2+\nSource: Drupal core umami installprofile&quot;}" published-at="27. March 2021"></teaser-wide>
...
</template>
</drupal-view>
</div>

So all seems fine to me. Yes, it's not a frontend rendering, but that's another story.

That's why I converted array to string, pretty print it and show it as markup.

Why are you dumping the literal object when the above rendering is already good? Imo, we should simply add <pre> tags around the above custom element rendering (e.g. with #prefix #suffix) to make he markup readable / visible in the browser.

Yes, that's not a visual preview rendered in the frontend, but that would be a bit more complex and require iframes to correctly go via the decoupled frontend. There is code doing so in the issue 📌 Frontend-rendered layout-builder previews Needs work , so that would be a great addition, but that is clearly out of scope here. Let's have correctly rendered markup shown in the preview for now. We could open a follow-up for a nicely rendered preview via iframes though!

Also I'm a bit unsure what to do with the pager. So far, I translated it into the custom element, and slot on the view, but I guess we could also leave it as attribute.

So far the code did:

$custom_element->setAttribute('pager', $result['#rows']['pager'] ?? []);

Changing that would be an API break. Why would we do that? Are there issues with the pager?

Generally speaking, a slot should be used for nested content that may be composed for any kind of content, not for passing data - use attributes for that. So the pager being an attribute is good, so the drupal-view component stays in control of how to render the pager.