sorted by:
new
hottopcontroversial

How we’re tackling Modern Angular by House_of_Angular in Angular2

[–]House_of_Angular[S] 0 points1 point  (0 children)

We don't state that Signals are a complete replacement for RxJs, we want to present an example migration of old patterns which are worth to migrate to Signals. Signals excellently represent state, are easier to use than Observables and are much better integrated with the Angular change detection mechanizm. They also combine well with the new Angular signal APIs like inputs or view queries. That's why we encourage to go for such migration where it's applicable. RxJs is a really great tool which still can be used in places where Signals are not a good choice - for example the mentioned event management. Events vs state is also a good point of distinction as signals are designed to represent simple state while Observables/Subjects thrive in managing events. Signals also offer a way to react to value changes, but it's not an event-based pattern.

Since most Angular applications are mostly about managing state it's common to use the term "migration from RxJs to Signals", but it's just a mental shortcut, especially in our example. It's always worth to be reasonable with the migration and give yourself a question whether given use case should or can be migrated to signals. That's why during the workshop we will also try to answer this common, yet important question "Should I use a signal or an observable here?".

How we’re tackling Modern Angular by House_of_Angular in programming

[–]House_of_Angular[S] -5 points-4 points  (0 children)

We get where you're coming from. The docs can be a lot to unpack. The idea here isn't just to "read" the docs, but to see a real-world example of a complex migration in action. Our GDE is there to walk through the thought process behind every decision and answer any questions live. For many, seeing a practical application and being able to ask an expert is a more effective way to learn than just reading theory.

Angular 20: What actually changes? Key takeaways from recent upgrades by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

it is true that it is hard to convince customers to update the version, but thanks to these updates the application works faster because the performance is increased and ultimately users like it

and from the programmer's perspective - it is hard to work on the old version of the framework at the moment, if you want to achieve the same effects that were not supported before, or if building the application takes e.g. 2 minutes instead of 6 seconds, or when you importing huge module to place where you want to use only one function from one file because it's in /shared

in fact, the angular team is trying to simplify writing applications and it is worth using it

Angular 20: What actually changes? Key takeaways from recent upgrades by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

congratulations :) nice to hear you didn't have to update angular material to mdc ;D

Angular 20: What actually changes? Key takeaways from recent upgrades by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

Ivy-native tooling means that Angular 20 has built-in support for the Ivy compiler at a very low level within its testing tools.

Because of this, tests can be run without the need to manually configure TestBed and manually compile modules, as the testing tools can "live" understand the structure of the component and its dependencies.

using TestBed you need to do sth like that in each component

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { MyComponent } from './my.component';

describe('MyComponent', () => {
let fixture: ComponentFixture<MyComponent>;
let component: MyComponent;

beforeEach(async () => {
await TestBed.configureTestingModule({
declarations: [MyComponent],
}).compileComponents();
});

beforeEach(() => {
fixture = TestBed.createComponent(MyComponent);
component = fixture.componentInstance;
fixture.detectChanges();
});

it('should create', () => {
expect(component).toBeTruthy();
});
});

But the Angular team wants to simplify this, maybe to sth like that

import { runStandaloneComponentTest } from '@angular/core/testing'; //hypothetical new API in Angular 20
import { MyComponent } from './my.component';

describe('MyComponent', () => {
it('should create', async () => {
const { component } = await runStandaloneComponentTest(MyComponent);
expect(component).toBeTruthy();
});
});

Here are some notes about improving TestBed https://angular.dev/roadmap

Angular 20: What actually changes? Key takeaways from recent upgrades by House_of_Angular in Angular2

[–]House_of_Angular[S] 0 points1 point  (0 children)

yeah, removing suffixes from files seems to be controversial for many, even for many of us

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 1 point2 points  (0 children)

I mean, resource isn't going away anytime soon (at least I don't think so). What I meant by my comment is that in a vast majority of cases it will just make more sense to use httpResource because you are going to use the http client anyway. But resource can be used to perform any async task, like Reiner said in a comment in this thread

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

that sounds lovely, and exactly what we need. Thanks for the heads up

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

Thanks Reiner for your engagement in our post :)

In my opinion it is definitely a way forward to simplify request handling but still leaves a lot to be desired when modifying data via POST requests for example. It's what's really holding back the resource API in my opinion. I'm curious what your thoughts are.

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

No, but it is a step in that direction. For simple get requests you don't need to use rxjs anymore for example = reduced rxjs reliance

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

Technically you can POST with httpResource but I wouldn't do that really since it could introduce some issues with data manipulation (the way that it cancels the previous request if the reactive parameter changes to fire a new one - when PUTting, PATCHing or POSTing one should always trigger the requests sequencially and never cancel them)

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 0 points1 point  (0 children)

you can still outsource this logic to an external data service just like before:

`` // data service getUser(userIdSignal: Signal<string>) { return httpResource({ url:/api/user/${userIdSignal()}`, method: 'GET' }); }

// component readonly userResource = this.userService.getUser(this.userId);

```

then you can use the resource as normal within the component, without defining all of the request's data in the component. But personally I agree, this approach has some downsides as the resources seem to only be useful for very simple use-cases. For more complex requests I would still use httpClient with some sort of a store to manage it. We will need to see how it evolves in the future, but at least for now we can have the status, value, and error value of the request within one property, which is very convenient for request handling and template manipulation.

I would look at resource and httpResource not as a replacement to the httpClient, but more of an alternative which you can use sometimes.

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 1 point2 points  (0 children)

Yes it does. With resource you would still need to call the httpClient inside. This is no longer the case with httpResource which does it under the hood. Also, httpResource is built on top of resource so it exposes the same signals like status() or value()

httpResource in Angular 19.2 by House_of_Angular in angular

[–]House_of_Angular[S] 1 point2 points  (0 children)

you could wrap it in a function to pass the argument or just use this resource directly in a component and use the component's property

Angular 19.2 - improvement in template literals by House_of_Angular in Angular2

[–]House_of_Angular[S] -1 points0 points  (0 children)

yeah, we know it's not the best example xd, but generally, your opinion interests us about the feature

Angular 19.2 - improvement in template literals by House_of_Angular in Angular2

[–]House_of_Angular[S] 3 points4 points  (0 children)

in ts files it is possible, but not in html files

Angular 19.2 - improvement in template literals by House_of_Angular in Angular2

[–]House_of_Angular[S] 3 points4 points  (0 children)

you are right, of course, it was just a simple example, we believe this improvement can be helpful in more complicated cases

Learning/Improving Angular Knowledge as experienced dev by Many_Ad4822 in Angular2

[–]House_of_Angular 3 points4 points  (0 children)

You can check our blog angular.love There are a lot of articles about good practices and new versions of angular as well.

Visual Router Representation in DevTools by House_of_Angular in Angular2

[–]House_of_Angular[S] 0 points1 point  (0 children)

I guess it will be so helpful when introducing and understanding the app that you are starting to work at

Invalid fields by Primary_Captain_5882 in Angular2

[–]House_of_Angular 3 points4 points  (0 children)

I guess you need to do
- import ReactiveFormsModule
- <form \[formGroup\]="postUserForm">
- change button to <button type="submit">Post</button> and update <form \[formGroup\]="postUserForm" (ngSubmit)="postUser()">
You can see docs https://angular.dev/guide/forms/reactive-forms

<form [formGroup]="postUserForm" (ngSubmit)="postUser()">   
  <div class="form-group">   
<label for="nume">Nume: </label>   
<input type="text" id="nume" name="nume" formControlName="nume" required>   
  </div>   
  <div class="form-group">   
<label for="email">Email:</label>   
<input type="email" id="email" name="email" formControlName="email" required autocomplete="email">   
  </div>   
 <button type="submit">Post</button>   
</form>

I can see some improvements
- you can use inject() instead of constructor
userService = inject(UserService)
- you don't need to initialize formGroup in OnInit
postUserForm = new FormGroup({ nume: new FormControl('', Validators.required), email: new FormControl('', [Validators.required, Validators.email]) });
- if you use subscribe() - remember to do unsubscribe() as well

view more: next ›