Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Fallback content for partials #2650

Closed
bfis opened this issue Apr 11, 2016 · 3 comments
Closed

Feature: Fallback content for partials #2650

bfis opened this issue Apr 11, 2016 · 3 comments

Comments

@bfis
Copy link

bfis commented Apr 11, 2016

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.

@posva
Copy link
Member

posva commented Apr 11, 2016

Sorry, I didn't understand why using a slot instead of a partial is not an option 😅
Is there a reason for that?

@bfis
Copy link
Author

bfis commented Apr 11, 2016

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.

@yyx990803
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants