While writing an example, there are many annoying stuff inherited from the render API.
Of course, the core idea of this module is to build render array in the YML, but we may need shortcuts which are resolved by ui_examples before sent to the render API.
Issue: html_tag allows only strings in #value, so we need to create "fake" keys
"#type": html_tag
"#tag": div
html_tag_content_1:
"#type": pattern
"#id": button_group
html_tag_content_2:
"#type": html_tag
"#tag": small
"#value": 9 mins
Proposal: a #element key with a #content key
"#element": div
"#content":
- "#type": pattern
"#id": button_group
- "#element": small
"#value": 9 mins
Issue: styles from ui_styles are not declared in #attributes which is the resolved form.
"#type": pattern
"#id": jumbotron
"#attributes":
class:
- text-center
Proposal: introduce a #style property:
"#type": pattern
"#id": jumbotron
"#styles":
- text-center
Issue: component from ui_patterns needs to be written in the developed form (with #fields & #settings) instead of the compact form, to be understood by the render API
"#type": pattern
"#id": carousel
"#settings":
with_indicators: true
with_controls: true
"#fields":
slides: {}
captions: {}
Proposal: introduce a #pattern property which accept the compact form:
"#pattern": carousel
with_indicators: true
with_controls: true
slides: {}
captions: {}
Closed: works as designed
1.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
In facts for front dev, it is hard to "learn" the render API in YAML, will this new render API addition be even more stuff to learn? Also this would be valid only in ui_examples that would even more be confusing.
Agreeing with you.
So maybe in a first time do it in ui_examples then is possible in a dedicated module so it will be a real render_api addition? (let's go for render API v2! :p)
That's tempting :)