Partials should support fallback content - just as slot do. This would greatly improve readability of templates when using them in a specific way:
There is a base component with some logic (e.g. a Dialog), from which other components (e.g. a PromptDialog) need to be derived that share the same logic and (outer) template. This is achieved by using partials similar as slots are used - but on a component basis and not with instances.
Such a template would look like this:
<div>
<div class="header">
<partial name="header">
<i class="fa-whatever"></i>
{{title}}
</partial>
</div>
<div class="body">
<partial name="body">
{{{body}}}
</partial>
</div>
<div class="footer">
<partial name="footer">
<!-- some stuff for button rendering -->
</partial>
</div>
</div>
Without this feature, I need to put the content of all the partial nodes outside of the template - and it becomes worse with nested partials.
Approaching the problems by using the base component in the template of the derived ones - thus having nested instances is not practical, because I would need to redirect the majority of the data/props and API from the outer (pseudo-derived) to the inner (base) instance.
Sorry, I didn't understand why using a slot instead of a partial is not an option :sweat_smile:
Is there a reason for that?
When using slots, a pseudo-derived _PromptDialog_ would have the following template.
<dialog
:foo.sync="foo"
>
<input
v-model="thePromptedValue"
slot="body"
>
</dialog>
For every attribute _foo_ on the original _Dialog_ component, I would need to have the same attribute on the outer _PromptDialog_ and pass the on to the inner. The same goes for all methods defined on _Dialog_: I need to define proxies that pass on the call to the inner. This is bothersome and defeats the idea behind component extension/class inheritance.
I'd say that's abusing partials. It's a bad idea to do this because your partial snippets are from the parent while aware of the data context of the child. This is tight decoupling.
The dialog component should not hold any own state because it's purely presentational. Do not pass the state down. Both the state and displayed content should belong to the parent component that uses the dialog.
Most helpful comment
I'd say that's abusing partials. It's a bad idea to do this because your partial snippets are from the parent while aware of the data context of the child. This is tight decoupling.
The dialog component should not hold any own state because it's purely presentational. Do not pass the state down. Both the state and displayed content should belong to the parent component that uses the dialog.