Yes, you are definitely missing the point of component based frameworks. That strategy is not even remotely scalable when you have nested complex state chains that vary slightly across multiple implementations of the same component, as well as 2-way communication with the original source of the state (from form inputs, and other parts of the UI).
Each UI action in google analytics affects some other part of the UI. If you change a filter in one area, it might disable sorting in another, and simultaneously change the calendar to be only < 1 year. It might also disable some setting portion of the UI, reset the chart, change the input option on the chart axis, and then show a text input you can type in, and when you type in it, ALL THE previously mentioned states now react to the input box that appears.
You want the logic for those components to be IN THE COMPONENT. With your strategy youre putting all NON business logic and trying to account for "every possible scenario" which is the exact purpose of what reactivity does. You're not writing 1000 extra lines of code to account for every single possible combination (which can be hundreds in complex apps). Instead you quite literally write 0 lines of code, because the reactivity is handled (both ways)
document.querySelector('#carsDropdown').innerHTML=droppy(cars);
Where droppy is a HandleBars template that on page load has been initialized with the html that makes your fancy dropdown menu.