New feature: Components (essentialy functions that also work like a block)

[Ninili]

Sometimes I really miss the functionality of a "Component". A little bit like what's possible with VueJs.

That would look like this:

{component inputBlock}
<div class="input-block">
   <label for="{$id}">{$label}</label>
   <div>{$slot}</div>
   <div class="hint">{$slot.hint}</div>{* maybe even named slots? *}
</div>
{/component}

And just use it like:

{inputBlock label="Enter Name" id="name"}
<input type="text" name="{$id}" id="{$id}"/>
{#hint}
if you enter nothing, there will be no name!
{/#hint}
{/inputBlock}

Right now the workaround would be to use {capture} and forward the captured content as a variable to a {function}

[wisskid]

Couldn't you just use a combination of subtemplate that extends another template here?

[Ninili]

Yes that can be done, but it would more complicated and not so easy to see what is happening there as much has to be done "indirectly" by extending and overwriting the block.

Keep also in mind that this is not for short labels or anything that could be a short string, but mostly longer HTML-Content that you want to "enclose" with a surrounding structure.

With template inheritance, I would have to do this:

fancyframe.tpl:

<div class="fancy-frame">
   <div class="other-class">
      {block name="content"}
   </div>
</div>

fancyframe_content1.tpl:

{extends "fancyFrame.tpl"}
{block name="content"}Content in a fancy frame <div>and a div</div>{/block}

fancyframe_content2.tpl:

{extends "fancyFrame.tpl"}
{block name="content"}Content in another fancy frame <div>and a div</div>}{/block}

fileWithFancyFrames.tpl:

{include "fancyframe_content1.tpl"}
...
{include "fancyFrame_content2.tpl"}

...but it wouldn't be so easy to see what's going on there.

Another workaround (which I mentioned) would be to do this:

{function name="fancyFrame" slot=""}
<div class="fancy-frame">
   <div class="other-class">
      {$slot}
   </div>
</div>
{/function}

{capture assign="content1"}
Content in a fancy frame <div>and a div</div>
{/capture}

{capture assign="content2"}
Content in another fancy frame <div>and a div</div>
{/capture}

{fancyFrame slot=$content1}
...
{fancyFrame slot=$content2}

...this would just have the overhead of capturing the slot-content in a variable.

The {Component} would just be kind of syntactic sugar to be able to place longer, HTML-content into the output of another function and to make the relation of the component and it's inner content a bit clearer, so the inner content is "enclosed" by the {Component}

This would be the {component} approach:

{component fancyFrame}
<div class="fancy-frame">
   <div class="other-class">
   <div>{$slot}</div>
</div>
{/component}

{fancyFrame} Content in a fancy frame <div>and a div</div>{/fancyFrame}

{fancyFrame} Content in another fancy frame <div>and a div</div>{/fancyFrame}

So it's essentially the same as "function", only, that it is also called as a block-tag and forwards it's content to the function as a special variable (let's say, $slot).

[wisskid]

I see. That would indeed be an interesting idea!

[tzoor-rozental]

i see its been a while since this has been proposed, but i would love seeing this feature implemented!

includes, functions, blocks and plugins are mostly sufficient for ui composition but non of them behave in the currently dominant component mindest. perhaps block is the closest, but it has exactly the opposite semantics. i believe this use case can have a more familiar behavior for new smarty users that first learned a more dominant front end framework, while truely simplifying composability.

i would consider however to exclusively use # to designate slots with the "slot" keyword being reserved for the default slot using {#slot}, this will serve two purposes, first we distinguish variables from slots, second we prevent compatibility with existing variables of this name, and absolutely support named slots via {#slot.<name>} for more granular control. so when using the component as a block, its content will replace the {#slot} tag in the component, and content wrapped in the named slot name will replace the named slot in the component.

also this means the # prefix is locally scoped to the component definition and the component block, as opposed to the global nature of template variables.

so all in all this could look like:

{component inputBlock  id label=""} // declare block props as mandatory without a default value, or as optional with a default value
  <div class="input-block">
     {if $label}<label for="{$id}">{$label}</label>{/if}
     {#slot}
     {if #slot.hint}<div class="hint">{#slot.hint}</div>{/if}
  </div>
{/component}

And use it like:

{inputBlock id="name"}
  <input type="text" name="{$id}" id="{$id}"/> // will be injected in the default slot {#slot}
  {#hint}this is a good hint{/#hint} // will be injected in the named slot {#slot.hint}
{/inputBlock}

{inputBlock id="email" label="Email"}
  <input type="text" name="{$id}" id="{$id}"/> // will be injected in the default slot {#slot}
  {#hint}this is a good hint{/#hint} // will be injected in the named slot {#slot.hint}
{/inputBlock}