Sure. But most if not all of that logic is on the server anyways. So to actually make it work that way would be (IME) a duplication of effort.
Then you have to deal with the fact that some of these second-order effects may be dealing with thousands of options. Do you really want to be calculating cartesian products on the client in JS? Ignoring the performance concerns, you could be talking about preloading a ton of data.
And then you're addressing complexities on the client side, coming up with potentially inconsistent solutions for because you're evaluating these on a case by case basis, and you've already solved these problems on the server.
While there might be some UX cost to round-tripping to the server, the client solution to approaching such problems is then consistent, and arguably far simpler. And you generally have much much better tooling to tackle these problems on the server, and more flexibility in applying your logic across web, mobile, batch processing scenarios, etc.
I mean, you could make your same argument for WebControls in ASP.NET. And it's my impression everyone mostly agrees it was a bad idea (at least I haven't noticed any competitors thinking it was an idea worth stealing). Except now it's on the client, with much weaker tooling, multiple runtimes it has to work with, etc.
We could go back and forth all day I'm sure. It's just a POV I felt like putting out there as someone who survived the two-way-data-binding wars of the early 2000's and isn't eager to see that idea rise to prominence again.
If that logic is on the server, you wouldn't use Angular for it...
But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so it doesn't need to fire that call again.
And of course you want that calculation to happen on the client, for 2 reasons:
1. In sparse-use sets (like pick a state, then pick a city, then pick a district) you will only really need to use 10% of the data, you can save a ton on bandwidth here.
2. In situations where the render patterns get complicated, it's really just a PRESENTATION issue. The server may validate that you're not using noncompatible dropdowns, but it otherwise should not care what happens in the browser related to that.
Binding a select-box to an event that makes that request and fills it in is trivial. And that data comes from the server.
If you're saying that you bring back a coarse interface (of school -> (state, city, district)), well that seems like a reasonable way to tackle it to me. But then that's not really what the other poster was suggesting (at least as I understood it), and Angular really does practically nothing for you in this scenario. You still have to specify your endpoint. You're still binding the data. And the two-way aspect of it is at best useless since the selected value is right there in the Form to be serialized, and at worst harmful because you're building and keeping large objects in JS for... no practical advantage I can think of at the moment.
Even stepping into the territory of calling something like this a "pattern", something that's been really common and fairly trivial beginning from the very earliest examples of Prototype.js really serves to add needless complexity to something that's actually very simple IME.
Comments
Sure. But most if not all of that logic is on the server anyways. So to actually make it work that way would be (IME) a duplication of effort.
Then you have to deal with the fact that some of these second-order effects may be dealing with thousands of options. Do you really want to be calculating cartesian products on the client in JS? Ignoring the performance concerns, you could be talking about preloading a ton of data.
And then you're addressing complexities on the client side, coming up with potentially inconsistent solutions for because you're evaluating these on a case by case basis, and you've already solved these problems on the server.
While there might be some UX cost to round-tripping to the server, the client solution to approaching such problems is then consistent, and arguably far simpler. And you generally have much much better tooling to tackle these problems on the server, and more flexibility in applying your logic across web, mobile, batch processing scenarios, etc.
I mean, you could make your same argument for WebControls in ASP.NET. And it's my impression everyone mostly agrees it was a bad idea (at least I haven't noticed any competitors thinking it was an idea worth stealing). Except now it's on the client, with much weaker tooling, multiple runtimes it has to work with, etc.
We could go back and forth all day I'm sure. It's just a POV I felt like putting out there as someone who survived the two-way-data-binding wars of the early 2000's and isn't eager to see that idea rise to prominence again.
If that logic is on the server, you wouldn't use Angular for it...
But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so it doesn't need to fire that call again.
And of course you want that calculation to happen on the client, for 2 reasons:
1. In sparse-use sets (like pick a state, then pick a city, then pick a district) you will only really need to use 10% of the data, you can save a ton on bandwidth here.
2. In situations where the render patterns get complicated, it's really just a PRESENTATION issue. The server may validate that you're not using noncompatible dropdowns, but it otherwise should not care what happens in the browser related to that.
I think we're talking about the same thing.
Binding a select-box to an event that makes that request and fills it in is trivial. And that data comes from the server.
If you're saying that you bring back a coarse interface (of school -> (state, city, district)), well that seems like a reasonable way to tackle it to me. But then that's not really what the other poster was suggesting (at least as I understood it), and Angular really does practically nothing for you in this scenario. You still have to specify your endpoint. You're still binding the data. And the two-way aspect of it is at best useless since the selected value is right there in the Form to be serialized, and at worst harmful because you're building and keeping large objects in JS for... no practical advantage I can think of at the moment.
Even stepping into the territory of calling something like this a "pattern", something that's been really common and fairly trivial beginning from the very earliest examples of Prototype.js really serves to add needless complexity to something that's actually very simple IME.
IMO.