In a Dev category discussion titled ‘Modifying style attribute dynamically on Topic List Item,’ merefield seeks to preserve critical customizations in their Theme Component (TLP), specifically dynamically setting background and grid-row-end styles on topic list items — currently done via deprecated modifyClass. Don and david clarify that while modifyClass isn’t deprecated, it’s risky and ineffective for Glimmer components like topic-list-item, which lack direct DOM access. david suggests mimicking the official d-topic-thumbnails approach: adding unique classes and injecting dynamic <style> via plugin-outlets. He also acknowledges the complexity and proposes a new valueTransformer to directly modify the style= attribute, submitting PR #30727 to address this. merefield also asks about hooking into Glimmer lifecycle events (e.g., didInsert), to which david responds that specific transformers may be added, but no general API for arbitrary element attachment is planned. merefield confirms the workaround functions well and eagerly awaits the PR. The thread concludes with merefield confirming the solution works ‘like a charm,’ thanking david for the fix.
Disclaimer: very happy with the direction here and thanks for all the work so far as there’s a lot of power in the new system. Just need to make sure we keep some equivalent capabilities? …
In my Component, TLP, I’m currently setting the style attribute of the Topic List Item outer tag dynamically:
setting the background: colour to a unique RGB value to match the dominant colour of the image. This should ideally be done in Ember loop.
I’m also setting setting grid-row-end to very quickly determine the size of the masonry element. This is very fast and efficient and avoids a lot of Javascript. However, for this I’m using Javascript as depends on the final sizes in the DOM.
So is modifyClass still valid? (Just updated syntax - might be good if so to reference that guide)
Can I still use that to access the style attribute of the enclosing tag?
Classic Components are different in that they historically provided access to enclosing tag level attributes outside of the template so they were straightforward to modify dynamically in code.
Ah, you’re right. There is a deprecated notice in console.
Deprecation notice: Modifying ‘component:topic-list-item’ with ‘modifyClass’ is deprecated. Use the value transformer ‘topic-list-columns’ and other new topic-list plugin APIs instead.
modifyClass itself is not deprecated. It’s a risky customization method, and you should take precautions when using it (as described in the doc @don linked), but we don’t have any imminent plans to remove it.
The reason we’re printing a deprecation message for component:topic-list and component:topic-list-items is that those components are the legacy implementation of the topic list, and are not used when the glimmer topic list is enabled. Now, we have a set of glimmer components like components/topic-list/item.
So, technically, you could use modifyClass on those new components. But, because they’re glimmer components, you won’t be able to modify the style tag via the JS class, so it won’t help with the problem in the OP.
We have a similar ‘masonry’ mode in the official d-topic-thumbnails theme component, so it’s worth looking at how that’s implemented. We add a unique class to each ‘row’ of the topic list:
Then we render a dynamic <style> tag in a separate plugin-outlet, which targets those class names:
That said… it is a little convoluted, so perhaps we should look at adding a specific valueTransformer to allow changing the style= attribute. It’s a little tricky because of Ember’s xss/htmlSafe protections on that attribute… but I’m sure we could get something working.
We could introduce specific transformers in certain places. But I don’t see us adding a general API which would allow you to attach to any element/component.
As for the style= attribute discussion, I made this PR. Will try to get it reviewed/merged:
Thanks. So far so good with your current technique, I’ve tailored it for TLP and it appears to function well. I’ll revert if I find any more potential gaps.
Awesome! I should be ready for it by the time that’s merged, looking forward to it! thanks David!