your not necessarily a PIA
just need more time to understand that this
will never happen in HA stock frontend. and this is essentially the same:
so we need custom cards like this to fix it for us.
as for your other questions about the why, just take a bit more time to read it and understand this new integration (thatās new in itself, and offers a lot of functionality) is now in serious active development (which card-mod didnt see in a long time until Darryn came along).
As HA keeps changing Frontend, and does that in an accelerated momentum, it was no longer feasible to update someone elseās code/card and keep up with that.
Lastly, itās of course up to you, which tool you prefer to use, always good to have choice.
Even if Frontend added a style config item to cards, I doubt it would then support templates. So this is where Uix would always be superior.
As far as what you can styled with Uix, āalmostā is part of the description to cover things which may change in Frontend, or are quirky stand alone elements or custom cards, aka inbuilt energy dahsboard date selector which recently was a quirky standalone element as a hui-root sibling which was not touchable by Uix (well not easily until ha-drawer was added in 5.0.0). Thankfully the energy dashboard will be updating to use the new dashboard footer which means it will be loaded by hui-card and thus stylable with Uix.
As for a major difference that Uix has over card_mod, is that āalmostā is far wider spreading out of the box given that the Uix Frontend resource is loaded as an extra module without any fuss to the user.
ha-nunjucks is great for custom cards, but Iām not sure if itās worth switching away from the default engine for this project. It may give it a tiny performance bump, but ha-nunjucks is better when a custom card has custom template variables or functions that change over time like a feature value in my projects. I do think (of course I do Iām biased) itās a better option than JavaScript templates since itās 99% the same syntax as the default jinja2 engine, outside of Python vs JavaScript syntax hiccups.
I took a quick look at ha-nunjucks. Reviewing in isolation from adaption to any project, I note the following:
ha-nunjucks needs performance improvements similar to what was added to auto-entities 2.0.0. Currently ha-nunjucks looks up config entries like labels, integrations, groups etc using find() which is inefficient for large number of objects.
ha-nunjucks does not reload labels, config entries etc. when changed in backend, which was also added in auto-entities 2.0.0. So if you add a new label ha-nunjunks wonāt see it until you refresh the page.
As it stands the performace aspect would make ha-nunjunks not suitable for Uix which needs high performance at all times. Also, adding/adapting ha-nunjunks, as well as preserving current template support would mean differet ānunjucksā which would likley be confusing for little gain.
As for any gain from having templates run on client rather than server, recent changes in Uix (card_mod v4.x heritage) brought in performance gains in that tenplates have a cooldown period of 20s, meaning that if the same template is used on different dashboard views, it is reused from cache - or similarly if you go to a different view and back to the same view within 20s, the templates on that view will be used from cache.
Regarding using javascript, testing (thanks @Mariusthvdb) showed that expectation is to be able to use a JS template in a Jinja template, whereas the implmentation was one or the other. This could be done but tracking, updating the javascript result would be inefficient (same as variables not below). The underlying wish is to mimise written code and have variables available in Jinja/JS. Jinja variables (e.g. have a variables: config that allows for Jinja templates for variables) would also be inefficient as the templates using the variables would need to updated whenever the variables being tracked changed, becoming even more inefficient if nested variables are supported. So at the moment if you wish to try and reduce/simplify code, the CSS var approach is a good middle ground (guide on this to be published soon).
Going through the testing of the javascript implementation with @Mariusthvdb showed that implmenting an idea without understanding the expected use case is not good use of development time. So I would ask for use cases for any functional change like adopting ha-nunjucks.
Thank you for your feedback and great to have these conversations which may lead to the next best feature for UIX.
Iām open to feature requests and PRs . I havenāt noticed any issues with performance in real world use and have made a few optimizations over time. Thereās always room for improvement though, and I wouldnāt be against a v2 that rearchitected things to be even more efficient.
yep, that feature is pretty cool, and though I found it a bit daunting at first, it makes for pretty clean configs, and prevents the endless repetition of setters, if one needs those I more than 1 target of the modification .
been looking for a long time to do that, declaring a global variable for the full config, and injecting that at any level in that config.
Speaking of instructions, I remember my early days when I was struggling at DOM selector and how to find the correct path to the element. This helper helped me a lot and thanks to it I slowly found out how everything works. I think that many people have the same problemā¦ I was wondering if you could create a similar helper for UiX.
Yes, I would like to cerate a DOM tree discovery tool of some sort. I was thinking along the lines of a console helpers, something like window.uix_tree($0) and window.uix_path($0). So you would go to the element inpsector, like you need to do for existing tool, but rather than copying a path and going external, you would run one of the commands:
window.uix_tree($0) - general helper
report of closest UIX parent (element having a non-child uix-node)
report on current UIX children (elements with uix-node which have the parent node as parent)
report on all possible paths e.g. if you run this on a card, then its likely that ha-card $ will be an available yaml target path
report depth will be up to next UIX parent (element with a non-child uix-node)
window.uix_path($0) - specific helper
report on closest UIX parent (element having a non-child uix-node)
report on path to target element ($0). This will stop at shadow Root that contains the element. The path will contain any specific selectors for multiple elements of same type/class, otherwise omit these as they are superfluous in majority of cases
report on class / id / element for CSS target within the sahdow Root
perhaps generate some boilerplate uix config yaml
I believe these would be super handy in this format, and take away a lot of guess work that still exists with the external helper due to the smarts of constraining to uix parent nodes.
There are a lot of changes with ha-dialog in the beta. If you donāt have any mods for it, you wonāt know. But uix mod is already ready for these changes
. I havenāt noticed any issues with performance in real world use and have made a few optimizations over time. Thereās always room for improvement though, and I wouldnāt be against a v2 that rearchitected things to be even more efficient.