there is still a separation of concerns for HTML and JS code in Angular, especially in comparison to the React architecture.
Seriously? I thought that this one had been laid to rest years ago. It seems not.
Okay, try this little experiment for me: go into your HTML file and change (click)="toggleSearch()" to (click)="toggleSearchNew()", then run your app again. What happens? Nothing, right? Or you get an error of some kind? That's because the toggleSearchNew method doesn't exist in your ResourcesComponent class. You need to open your JS (or TS) file and add it there.
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. Sound like separation of concerns to you? To me it looks like those files are joined at the hip!
And really, that's always been the case. What devs have referred to as "separation of concerns" actually meant separation of files and of technologies. The HTML and JS has always been completely interdependent, which ever framework du jour you happened to be using. JSX simply makes explicit what we've all really been doing all along.
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.
Seriously? I thought that this one had been laid to rest years ago. It seems not.
Okay, try this little experiment for me: go into your HTML file and change
(click)="toggleSearch()"to(click)="toggleSearchNew()", then run your app again. What happens? Nothing, right? Or you get an error of some kind? That's because thetoggleSearchNewmethod doesn't exist in your ResourcesComponent class. You need to open your JS (or TS) file and add it there.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. Sound like separation of concerns to you? To me it looks like those files are joined at the hip!
And really, that's always been the case. What devs have referred to as "separation of concerns" actually meant separation of files and of technologies. The HTML and JS has always been completely interdependent, which ever framework du jour you happened to be using. JSX simply makes explicit what we've all really been doing all along.
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).