You have an interesting concept of separations of concerns
And this will be the case most of the time: every time you change your markup file, you'll have to make a corresponding change in your JavaScript/Typescript, and vice versa.
Of course when someone changes the name of a reactive property or a command method on the view model that is referenced by the view, you have to update that view too. The only way I can imagine this to not be true (changing a method name in code and not having to update it in markup) is if there was another mapper/layer of abstraction between them, but that would just move your concern to a different file.
If you can name a UI framework that does do well on seperations of concerns based on your definition, I'm all ears.
As far as I understand seperation of concerns in the case of ui components and views, is that a view needs to work only on display logic (it needs to insert data from the viewmodel into html, it needs to display/hide different parts of the ui based on data in the viewmodel, it needs to bind different buttons to commands in the viewmodel) and a viewmodel needs to work only on fetching and massaging that data (without having any knowledge of the view or it's components, for the sake of being easy to unittest and modify).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You have an interesting concept of separations of concerns
Of course when someone changes the name of a reactive property or a command method on the view model that is referenced by the view, you have to update that view too. The only way I can imagine this to not be true (changing a method name in code and not having to update it in markup) is if there was another mapper/layer of abstraction between them, but that would just move your concern to a different file.
If you can name a UI framework that does do well on seperations of concerns based on your definition, I'm all ears.
As far as I understand seperation of concerns in the case of ui components and views, is that a view needs to work only on display logic (it needs to insert data from the viewmodel into html, it needs to display/hide different parts of the ui based on data in the viewmodel, it needs to bind different buttons to commands in the viewmodel) and a viewmodel needs to work only on fetching and massaging that data (without having any knowledge of the view or it's components, for the sake of being easy to unittest and modify).