TC/Plugin architecture: should we have more control over classes?

dev
1

I recently moved a small component over to .gjs on Locations Plugin. It adds an alternative form of Location to the website and locations outlet on the user profile. At the same time it hides the redundant location information that is superseded by the plugins code.

I re-assessed the value of the code that had been written before against modern standards.

Now, using plugin outlets is all well and good, but should we also have the ability to influence the parent class of wrapping div above the outlet?

Because currently, in this instance, I’m having to manipulate the Dom in order to hide redundant information of its sibling:

I’d prefer to make that change with explicit modification of a component than with Dom manipulation?

Perhaps I missed a trick here.

1 Like
2

Can you sketch out how you imagine an API like this would work on the core and plugin/theme side?

One similar thing we have is the {{body-class "blah"}} helper. If you put that in any outlet, it’ll apply the “blah” class to the <body>.

4 Likes
3

One other idea is to use a fancier CSS selector. For example, all of Discourse’s target browsers now support :has()

(but it’s important to consider performance when using it)

2 Likes
4

Ah, so I have missed a trick :sweat_smile:

Yes prefer that over the has option.

Oh that might do it for me in this case, very helpful, let me give that a go!

4 Likes
5

FYI, that appears to have worked nicely:

many thanks David!

1 Like