Sorry for the reply below with many quotes, but there’s a lot to respond to!
To be honest I’ve never been fully comfortable supporting that kind of snippet, as it’s not importing our modules the correct way and depends highly on our internals. Having said that, I will try my best not to break it until we can offer something that solves the use case.
There should probably be some way of auto detecting the plugin being disabled. I haven’t had to face this case myself but would be open to PRs or suggestions for how to do this.
Well I don’t think it takes us two years to add hook points! Generally we’ll add them very quickly once people ask for them and provide a use case. For reference, our discourse-tagging plugin is barely two years old!
Monkey patching is always risky. We do it in some plugins but the long term goal is to create APIs that handle most of the things people need to patch in. Having said that, if you are adding a new computed property to topic or post, chances are that will work forever.
No, nothing will happen if there is no
Rather than think of whether you’re in the composer or the post stream, you should just account for sometimes having a model or not. For example, the user stream also applies decorators.
Yes I agree that’s a bit funky. In this case,
showRating is a property on the controller right? Is it there because people can enable/disable it on the topic?
The reason I ask is because it’s much more complicated to add a topic controller attribute into the post stream without modifying the handlebars template
topic.hbs, but if it’s an attribute on the topic model itself it would be pretty straightforward to add it.
Also in your code, I would recommend using
includePostAttributes to add rating to
attrs rather than calling
getModel. I’d also recommend creating a new widget for the rating, but I haven’t written up how to do that yet because I’ve been quite busy –
rawHTML will work but the widget would be nicer and faster.