Allow registrations of components as plugin outlets


(Sam Saffron) #1

I am hitting an issue extending outlets in solved.

At the moment in core we have:

<ul>
    <li>{{#link-to 'userActivity.likesGiven'}}Likes Given{{/link-to}}</li>
   ...
   {{plugin-outlet "user-activity-bottom"}}
</ul>

Which we can easily change to:

<ul>
    <li>{{#link-to 'userActivity.likesGiven'}}Likes Given{{/link-to}}</li>
   ...
   {{plugin-outlet "user-activity-bottom" tagName='li'}}
</ul>

This helps somewhat as the outlets will be injected as LI elements but has a big flaw.

For my case I only want to show the “solved” link IF the user has more than 1 solution. However our current design allows no control over the “wrapping” element, nor no way to conditionally render.

@eviltrout perhaps we should allow components for plugin-outlets as well, eg:

export default Em.Component({
   pluginOutlet: 'user-activity-bottom'
}) 

Then when we sweep through outlets we can either render a templates or explicitly defined components?


Plugin-outlet incorrectly handles multiple plugins at the same outlet
Conditionally rendering a plugin outlet
(Robin Ward) #2

This is somewhat tricky. It wouldn’t be hard to auto discover components by name or something, but that wouldn’t let you conditionally render, because components have to render. You can hide them of course by using a hidden class or something but they’ll always end up in the DOM.

I could adjust my plugin-outlet helper to have some kind of callback function it could use to determine if a connector should be included in an outlet, but if I did that it wouldn’t be bound, so if you changed some property that would make it appear or not it wouldn’t toggle. That’s not ideal either.