ארכיטקטורת TC/Plugin: האם עלינו לקבל שליטה רבה יותר על מחלקות?

מפתח

סיכום מבוסס בינה מלאכותית

The discussion revolves around whether the TC/Plugin architecture should allow more control over component classes, particularly in modifying parent elements around plugin outlets. merefield initially faced challenges hiding redundant DOM elements in a plugin, resorting to direct DOM manipulation. david suggested using the `{{body-class

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.

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>.

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)

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!

5

FYI, that appears to have worked nicely:

https://github.com/paviliondev/discourse-locations/pull/112

many thanks David!