v11.0.0

⚠️⚠️⚠️ BREAKING CHANGE ⚠️⚠️⚠️

DO NOT UPDATE WITHOUT READING FIRST!!!

This release is a major update. It's a breaking change only if you are using reactive variables in your templates. If you are not using reactive variables, you can proceed with the update without changing your configuration and this release should not bring any issue for you.

Reactive variables are not placed under js_variables anymore, but under js_refs

Reactive variables have been refactored to make their usage simpler and more intuitive. Thanks to @dcapslock for bringing the idea of making these kinds of variables easier to use. ♥

The first change is that reactive variables are now placed under js_refs instead of js_variables and they need are declared in the same way as js_variables (this means that to declare them, they cannot be wrapped in a ref method anymore). The second change is that it's now possible to access the value of a reactive variable through the refs object (e.g. refs.xxx).

This is an example of a migration of a configuration using reactive variables (but you can also consult the reactive variables section in the documentartion):

Old code using reactive variables

js_variables:
  clicks: 'ref(0)'
title: |
  [[[ return `Clicked ${ref('clicks').value} times` ]]]
order:
  - new_item: true
    item: 'Example'
    icon: 'mdi:gesture-tap'
    on_click:
      action: 'javascript'
      code: |
        ref('clicks').value++;

New code using reactive variables and the new js_refs option

js_refs:
  clicks: 0
title: |
  [[[ return `Clicked ${refs.clicks} times` ]]]
order:
  - new_item: true
    item: 'Example'
    icon: 'mdi:gesture-tap'
    on_click:
      action: 'javascript'
      code: |
        refs.clicks++;

Note: after this change, it is still possible to access the value of a reactive variable using ref('xxx').value but the new syntax is recommended because it's simpler and more readable.

Refactored the logic to select a sidebar item

The logic that is used to select the correct sidebar item depending on the path in the URL has been simplified. This logic is to override the default Home Assistant behaviour, which, for example, selects the Settings item if any URL starts by /config (e.g. /config/integrations). The logic has been improved reducing the code involved in doing this process and location.pathname has been used instead of the route.path variable inside the panelResolver. At the same time, if the analytics option is enabled, the panel_visited log will use this path instead of the previous one.

Fixed a bug with sidebar loading functionality

Since some time, Home Assistant has a functionality to load the frontend user settigs related to the sidebar. During this loading, the sidebar displays a loading spinner in a white background and the sidebar items are not present. If this loading process takes a bit long, the plugin was failing because it tried to process the sidebar items without them being present. This has been fixed in this release.

Fixed a bug related to missing config

In certain scenarios, in which the config takes too long to load, the plugin was throwing an error related to missing config when checking if the analytics option was true. This is not happening anymore in this release and if the config is missing, the plugin waits for it before trying to check the analytics option.

---

🛠 Fixes

• Fix some bugs related to loading delays
  • PR: #520 by @elchininet

🧩 Dependencies

• [Dependencies]: Bump typescript-eslint from 8.48.0 to 8.48.1 in the dependencies-dev group
  • PR: #517 by @dependabot[bot]
• Refactor refs management
  • PR: #518 by @elchininet

📦 Other

• Simplify the logic to select a sidebar item
  • PR: #519 by @elchininet