Conditionally rendering a plugin outlet

Development

AI-generated summary

Conditionally rendering a plugin outlet: sam proposes a mechanism for conditionally rendering outlets, starting with an unbound solution. They want to add a “solutions” tab to the summary page, but only if the solution count is greater than 0 and need to add a linked-stat CSS class to the enclosing LI.

sam suggests adding a shouldRender function to the outlet’s JavaScript file to achieve this. vinothkannans shares a similar use case, and Mittineague inquires about using Ember’s handlebar helper files for conditional rendering.

@eviltrout explains that implementing conditional rendering is challenging due to Ember’s stream-based dependencies and lack of access to the keyword’s scope. However, eviltrout later announces that support for conditionally rendering a connector is now available, as discussed in another thread.

1

I would like to introduce a mechanism for conditionally rendering outlets, I think for the time being even an unbound solution will go a reasonable distance.

The problem:

I am looking at adding a “solutions” tab to the summary page.

Pasted image666×112 4.86 KB

I can easily add it by creating a plugin outlet in the UL per:

<ul>
   <li>...</li>
   {{plugin-outlet "users-stats" tagName="li"}}
</ul>

However

  • I don’t want to display anything if the solution count is 0

  • I need to push up a class linked-stat CSS class to the enclosing LI.

My suggestion:

We currently define the behavior in

discourse-solved/assets/javascript/discourse/connectors/users-stats/some_file.hbs

{{#link-to 'userActivity.solved'}}
  {{user-stat value=model.solved_count label="solved.solution_summary"}}
{{/link-to}}

I would like to add support for:

discourse-solved/assets/javascript/discourse/connectors/users-stats/some_file.js.es6

export default {
    shouldRender: function() {
        return this.get("model.solved_count") > 0;
    },
    classes: function() {
        return "linked-stat";
    }
};

@eviltrout what are your thoughts on this, clearly getting full binding here is going to be much trickier, but for unbound decisions this seems pretty straight forward.

Thoughts?

See also

Allow registrations of components as plugin outlets which is a far heavier suggestion.

2

I am also facing the same situation in many places. For example

Here I am displaying the banner only if all three conditions are passing.

3

Does Ember still support handlebar helper files?

I had a very alpha plugin I was working on that worked OK using a helper.

But after the switch to Virtual DOM I abandoned it and I don’t know if that might still be a way to approach the conditional rendering.

4

I spent a couple of hours on this and it’s unfortunately not easy either.

The plugin outlet is implemented as keyword that basically does the same thing as the partial tag in ember that hoists a block into the upper template, except I hoist a template we’ve declared as a connector.

Now of course I can conditionally do that, however it seems that I can’t access the scope of the keyword (or I can’t figure out how to anyway) because everything in ember is based on streams of dependencies that are passed into things.

There doesn’t seem to be any easy way in a keyword handler to call this.get('model.solved_count') :frowning:

If you’re feeling adventurous and think you can figure out something in Ember’s API to do this, here’s my work:

https://github.com/discourse/discourse/commit/7b8e4a7110df1c40fa952df5fe216d844fbecc9d

5

There is now support for conditionally rendering a connector: