"Component was authored using gjs" - but it is not

Dev
1

On stable, 3.4.1.

I have this in my plugin

/assets/javascripts/discourse/controllers/user-feedback.js

and then
/assets/javascripts/discourse/templates/user-feedback.hbs contains

{{feedback-stream stream=this.model}}

And then these files:

/assets/javascripts/discourse/components/feedback-stream.js
/assets/javascripts/discourse/templates/components/feedback-stream.hbs

This was is the error I am getting in my browser console.

/discourse/templates/components/feedback-stream] feedback-stream was authored using gjs and its template cannot be overridden. Ignoring override. For more information on the future of template overrides, see https://meta.discourse.org/t/247487 But, as you can see, it wasn't written using gjs.

Now I decided to ignore this error for now and continued modernizing the plugin. As soon as I colocated the templates (so mv templates/components/* components) the error went away. But the template is still ignored.

2 Likes
2

Ok, the pieces of the puzzle seem to be connecting.

The component does

export default class FeedbackStream extends UserStream {

and UserStream is written using gjs.

The incorrect error message aside, how would I go on modernizing this and getting things back to work?

1 Like
3

What is the purpose of your changes? So we can understand the context.

I believe with gjs, you can only rely on plugin outlets. :thinking:

4

The purpose of my current changes is getting the plugin back to work on latest stable :slight_smile:

The purpose of this specific part of the plugin is to show feedback on a users profile page, while heavily reusing existing components.

5

If you use gjs for your FeedbackStream, then I think it should work. So it would be something like

export default class FeedbackStream extends UserStream {
  <template>
    Your custom template here 
  </template>
}

I think mixing hbs/gjs in the same component inheritance chain is unlikely to work too well.

3 Likes
6

BTW @Arkshine I see your :exploding_head: - so just clarifying here. Template overrides are deprecated, regardless of the original authoring format. We’ll be removing them completely in the next few months. For those cases, you’re 100% right that Plugin Outlets are the solution.

But what @RGJ is doing here is not a template override, it’s using Ember’s component inheritance system. Instead of doing

class Foo extends Component

you can do

class Foo extends SomeOtherComponent

In that case, your component will inherit the template of SomeOtherComponent, or you can choose to replace the template yourself. Your template replacement only applies to Foo, and won’t affect the parent SomeOtherComponent.

This kind of inheritance is a fairly seldom-used feature though. We tend to lead towards “composition” instead, where you wrap components in each-other within a template. (e.g. that’s how DModal is used)

5 Likes
7

Oh, I see; thanks for clarifying! I failed to see the inheritance here. It makes sense.

3 Likes
8

Thank you for the quick help and clear explanation David!

4 Likes