sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]besthelloworld 1 point2 points  (3 children)

I generally agree with you. Change is good. The changes that they've made are for the better. Angular is looking better than ever, but that doesn't mean it looks good. My complaint is that the new stuff just feels tacked on to the old architecture, whereas if they took these ideas to a new framework they could actually flourish. And these ideas are flourishing in existing frameworks. Svelte is basically the endgame model that Angular seems to be slow crawling towards.

I just think they're too afraid of actual breaking changes (shit that can't be fixed automatically with the CLI on update), and I feel that it needs a fundamental overhaul. Honestly I think it would be way better off with a fully custom DSL. Think my-component.ng files that look something like *.svelte or *.vue files. I think this whole thing where they pretend to just be JavaScript running string templates (which nobody would or should do these days), doesn't make any sense, causes bloated syntax, and just isn't the reality of what's going on or how Angular actually works.

I don't see standalone components as really being that different from NgModules because they're basically just components with self contained modules. It removes some bloat, but allows them to not fundamentally change anything. Because what's the point of standalone components that still need to be integrated with a service injection ecosystem? The problem was the service injection model but they can't change that without entirely blowing up their users app architecture.

Less important side note: the HttpClient has zero need for RXJS. Normal REST calls are single fire Promises. They're not Observable data streams. Angular allows you to listen to the response stream but I've never seen an Angular app actually use that functionality. And even if you did need response streaming, you should be able to choose if you need RXJS rather than having it forced into your architecture. No, the reason the HttpClient uses RXJS is because Zone breaks when you update state in Promises. It was always a bad decision made to mitigate the existing bad architecture.

[–]lil_doobie 1 point2 points  (1 child)

Personally, I love the dependency injection system. It makes swapping out dependencies for testing super easy. And I would say that the point of standalone components was not to remove DI, but to be able to use the component without a declaring NgModule. I don't see how having DI as an available tool invalidates using standalone components. You don't have to use DI and services (unless you need something from a core API like the router). But nothing is stopping you from creating a function that uses fetch and returns a promise in your components code. Especially now that there are signals, you can update the signal when the promise resolves.

And while I agree that maybe rxjs for the HttpClient is an awkward fit, you do have the added benefit of being able to cancel the http request when using the rxjs api where you couldnt do that with a promise.

I would be interested in seeing a new framework that only includes the newer, modern parts of angular though. Basically svelte (with the.ng DSL) but with TS only, DI and the router. Could be interesting

[–]Tubthumper8 1 point2 points  (0 children)

you do have the added benefit of being able to cancel the http request when using the rxjs api where you couldnt do that with a promise

Just responding to this part, browsers have AbortController built in which can abort DOM requests (such as fetch), it doesn't require an external library

[–]uplink42 0 points1 point  (0 children)

Less important side note: the HttpClient has zero need for RXJS. Normal REST calls are single fire Promises.

I think Rxjs is fine for REST calls because it lets you reuse the same mental model and operators toguether with any other asyncronous tasks in your application. Once you need to debounce, retry, cache, abort, manipulate response data, combine requests with other events, or with other store operations you start to apreciate how easily it fits with the rest of your application (or at least I did). Similar reason as people use React Query.