RxJS에서 신호까지: Angular 상태 관리의 미래

지난 몇 년 동안 중요한 Angular 앱을 출시했다면 아마도 BehaviorSubjects, 선택기 스트림 및 NgRx 슬라이스가 어디에나 있을 것입니다. 그리고 팀의 어느 누구도 이를 리팩터링하려고 하지 않습니다. 와 함께각도 19+신호는 더 이상 실험적이거나 “있으면 좋은” 것이 아닙니다. 그들은 안정적이고 성능이 뛰어나며 점점 더기본지역 상태를 모델링하는 방법. 결과적으로 많은 Angular 팀은 오랜 RxJS 및 NgRx 패턴을 적극적으로 재검토하고 때로는 완전히 다시 작성하고 있으며 커뮤니티 토론은 동일한 질문으로 가득 차 있습니다.이제 Angular 상태 관리는 어떤 모습이어야 할까요?

\ 이러한 혼란은 이해할 수 있습니다. 신호는 더 적은 상용구와 더 단순한 정신 모델을 약속하지만, RxJS와 NgRx는 하룻밤 사이에 간단히 교체할 수 없는 실제 애플리케이션에 깊이 내장되어 있습니다.

이것은 누구를 위한 것인가요?

로컬 상태를 단순화하기 위해 노력하는 RxJS가 많은 구성 요소를 갖춘 Angular 팀.
이미 사용 중인 애플리케이션NgRx전역 또는 도메인 상태의 경우.
기술 책임자는 리팩터링을 계획하고 신호가 어디에 적합한지 궁금해합니다.

\ Angular의 상태 관리 스토리는 여러 단계를 거쳤습니다. 초기 Angular는 모든 곳에서 RxJS에 크게 의존했습니다. 애플리케이션이 성장함에 따라 NgRx는 구조, 예측 가능성 및 규율을 글로벌 상태로 가져오기 위해 등장했습니다. 이제 Signals가 일류 시민이 되면서 더 이상 문제는 없습니다.~이든사용하지만 어디에 속해 있는지.

\ 정답은 “모든 것을 신호로 대체”가 아닙니다. 실제 진화는 더욱 미묘하고 실용적입니다. Angular는 이제 특정 종류의 문제에 최적화된 여러 상태 도구를 제공합니다. 문제는 의도를 가지고 올바른 것을 선택하는 것입니다.

1. 신호, RxJS 및 NgRx: 결정 방법

Angular 개발자가 수행해야 할 가장 큰 정신적 변화는 다음과 같습니다.

상태 관리는 API가 아니라 범위와 책임에 관한 것입니다.

\ 묻는 대신“Signals를 사용해야 할까요, 아니면 RxJS를 사용해야 할까요?”물어보세요:

이 상태는 얼마나 오래 지속되나요?
누가 소유하나요?
앱의 얼마나 많은 부분이 이에 의존하나요?
동기식인가요 아니면 시간 기반인가요?

실용적인 경험 법칙

신호 → 로컬, 동기 UI 상태
RxJS → 비동기 스트림 및 외부 이벤트
NgRx → 워크플로가 포함된 글로벌, 수명이 긴 도메인 상태

\ 이 규칙은 실제 응용 프로그램 전반에 걸쳐 놀라울 정도로 잘 적용됩니다.

결정 가이드

좋은 휴리스틱은폭발 반경:

상태 변경이 하나의 구성요소에 영향을 미치는 경우 → 신호
여러 기능에 영향을 미치는 경우 → NgRx
시간, 취소, 배압에 따라 달라지는 경우 → RxJS

2. 실제 마이그레이션 슬라이스

대부분의 팀은 상태 아키텍처를 처음부터 다시 작성하지 않습니다. 그들은 이주한다점진적으로한 번에 하나의 화면이나 기능을 사용합니다.

\
출발점

중간 규모의 Angular 앱에는 다음을 사용한 사용자 관리 화면이 있었습니다.

BehaviorSubject지역 매장으로서
선택기 스트리밍:map
async템플릿의 파이프

\ 코드는 기술적으로 정확했지만 새로운 개발자를 온보딩하는 데 시간이 걸렸습니다. 데이터 흐름을 이해하려면 스트림, 연산자 및 템플릿 간 이동이 필요했습니다.

\
결정

전체 리팩터링 대신 팀이 마이그레이션했습니다.UI 수준 상태만신호에:

선택된 사용자
필터
파생된 개수

\ HTTP, 페이지 매김 및 오류 처리는 RxJS에 그대로 유지되었습니다.

\
즉각적인 혜택

구성 요소는 일반 TypeScript처럼 위에서 아래로 읽습니다.
추적하거나 정리할 구독이 없습니다.
디버깅이 쉬워졌습니다(신호 값 기록).
새로운 팀원은 코드를 훨씬 더 빨리 이해했습니다.

\
무엇이 잘못됐나요?

처음에 팀은 HTTP 호출을 Signals로 옮기려고 했습니다.

\ 이로 인해 다음이 발생했습니다.

중복된 네트워크 요청
입력이 변경되면 취소되지 않습니다.
더 어려운 오류 전파

\ 이는 안티 패턴의 구체적인 예입니다. 디바운싱, 재시도, 폴링 또는 기타 시간 기반 오케스트레이션을 RxJS에 유지하는 대신 신호에 푸시하려고 합니다.

\
수정 사항

그들은 HTTP용 RxJS를 복원하고 신호를 다음과 같은 용도로만 사용했습니다.국가 보유자.

핵심 교훈: 신호는 비동기식 오케스트레이션이 아닌 상태 소유권을 단순화합니다.

\ 이러한 분리(시간은 RxJS, 상태는 신호)는 Angular가 추구하는 핵심 정신 모델입니다.

\ 정신적 모델 전환:이전에는 모든 것이 스트림이었습니다. 이후 – 에지에서는 비동기, 코어에서는 신호.

3. 복사하여 붙여넣을 수 있는 미니 리팩터링

이전: RxJS 전용 로컬 스토어

users.store.ts

// users.store.ts

private usersSubject = new BehaviorSubject<User[]>([]);
users$ = this.usersSubject.asObservable();

readonly activeUsers$ = this.users$.pipe(
  map(users => users.filter(u => u.active))
);

loadUsers() {
  this.http.get<User[]>('/api/users')
    .subscribe(users => this.usersSubject.next(users));
}

\
users.component.html

<!-- users.component.html -->

<ul>
  <li *ngFor="let user of activeUsers$ | async">
    {{ user.name }}
  </li>
</ul>

시간이 지날수록 고통스러워지는 이유

단순한 상태에도 스트림, 연산자 및 템플릿 간접 참조가 필요합니다. 코드 크기보다 정신적인 비용이 더 빨리 증가합니다.

\
이후: 상태에 대한 신호, 그것이 속한 RxJS

users.store.ts

// users.store.ts

users = signal<User[]>([]);

activeUsers = computed(() =>
  this.users().filter(u => u.active)
);

loadUsers() {
  this.http.get<User[]>('/api/users')
    .subscribe(users => this.users.set(users));
}

\
users.component.html

<!-- users.component.html -->

<ul>
  <li *ngFor="let user of activeUsers()">
    {{ user.name }}
  </li>
</ul>

이것이 더 나은 이유

상태는 동기식이며 자동으로 종속성을 추적하고 직접 읽을 수 있습니다. 반면 RxJS는 비동기 동작을 계속 담당합니다.

\
중요한 설명

이것은 “RxJS 대 신호”가 아닙니다.

\ 경계에는 RxJS, 핵심에는 Signal이 있습니다.

\
예: 실시간 검색(시간은 RxJS, 상태는 신호)

Signals와 RxJS가 서로 보완하는 일반적인 경우는 실시간 검색입니다.

신호는 현재 쿼리와 결과를 보유합니다.
RxJS는 디바운싱, 취소 및 HTTP를 처리합니다.

\ 개념적으로:

사용자 입력은 쿼리 신호를 업데이트합니다.
RxJS 파이프라인은 쿼리를 디바운싱하고 요청을 수행합니다.
결과는 결과 신호에 다시 기록됩니다.

\
이것이 잘 작동하는 이유

RxJS는 시간과 취소를 관리하는 반면, Signals는 렌더링 및 파생된 UI 로직을 위한 간단한 동기식 상태 모델을 제공합니다.

4. NgRx가 여전히 확실히 승리하는 곳

신호는 NgRx를 대체하지 않습니다. 그들은 다른 문제를 해결합니다.

\ NgRx는 다음이 필요할 때 여전히 올바른 선택입니다.

여러 경로에 걸쳐 단일 정보 소스입니다.
명시적인 워크플로(로드 → 성공 → 실패)
액션 히스토리 및 재생.
대규모 팀을 위한 강력한 규칙.
DevTools를 통한 예측 가능한 디버깅.

\ NgRx가 최선의 선택으로 남아 있는 예:

인증 및 승인.
장바구니 및 결제 흐름.
기능 플래그 및 권한 부여 논리.
오프라인 가능 또는 캐시된 도메인 데이터.

\ 대규모 앱에서 일반적이고 효과적인 패턴은 다음과 같습니다.도메인 상태에 대한 NgRx, 구성 요소의 신호. 예를 들어 인증 상태(사용자, 역할, 토큰, 새로 고침 수명 주기)는 NgRx 인증 슬라이스에 존재하는 반면 구성 요소는 가시성, 레이아웃 및 상호 작용 상태와 같은 로컬 UI 결정을 위해 해당 상태를 신호로 사용합니다.

\ 둘을 연결하기 위해 팀은 종종 다음과 같은 도우미를 사용합니다.toSignal/toObservable또는 NgRx를 정식 진실 소스로 유지하는 선택기 주변의 작은 신호 기반 저장소 래퍼입니다.

\ 실제로 Signal은 NgRx를 만드는 경우가 많습니다.더효과적입니다. 그곳에 거주해야 하는 주의 양을 줄임으로써 가능합니다.

5. 자신이 주장하는 해야 할 일과 하지 말아야 할 일

하다

구성요소-로컬 UI 상태에 신호를 사용합니다.
상태가 동기일 때 선택기 스트림 대신 계산된 신호를 사용합니다.
비동기 워크플로, 스트림 및 취소를 위해 RxJS를 유지하세요.
비즈니스에 중요한 글로벌 상태에는 NgRx를 사용하세요.
도구 간의 명확한 경계를 정의합니다.

\
하지 않다

RxJS를 완전히 대체하려고 하지 마세요.
신호를 사용하여 시간 기반 문제를 모델링하지 마세요.
상용구를 줄이기 위해 NgRx를 포기하지 마십시오. 이미 실제 워크플로와 공유 도메인 상태를 잘 모델링하고 있다면 그대로 유지하세요.
의도 없이 신호와 Observable을 혼합하지 마세요.
성급하게 최적화하지 마세요. 명확성을 위해 최적화하세요.

현대 각도 상태 흐름을 위한 간단한 정신 모델

현대 Angular 상태를 다음과 같이 생각하십시오.단방향 파이프라인명확한 경계가 있는 경우:

\
데이터 흐름:

백엔드 → RxJS 스트림 → 서비스 → 시그널 저장소 → 컴포넌트 → 템플릿

백엔드데이터를 비동기식으로 생성합니다.
RxJS시간 기반 문제(디바운스, 재시도, 취소)를 처리합니다.
서비스데이터 가져오기 및 부작용을 조율합니다.
신호UI의 현재 동기 상태를 저장합니다.
구성요소신호를 직접 읽어보세요.
템플릿구독이나 비동기 파이프 없이 렌더링됩니다.

\
핵심 아이디어:RxJS는가장자리시간이 존재하는 곳; 신호는핵심상태를 읽고 파생하는 곳입니다.

3단계 마이그레이션 전략

로컬 UI 상태로 시작: 한 번에 하나의 화면이나 구성 요소를 마이그레이션합니다. 바꾸다BehaviorSubject 신호를 기반으로 UI 상태(필터, 선택, 토글)를 계산하고 계산합니다. 처음에는 공유 또는 교차 경로 상태를 피하세요.
RxJS를 가장자리에 유지: HTTP, 디바운싱, 폴링 및 스트림을 RxJS에 그대로 둡니다. 신호는 결과 상태를 유지하고 노출하는 데에만 사용하세요. 신호를 사용하여 시간 기반 논리를 모델링하지 마세요.
마지막으로 NgRx 재방문: UI 상태가 신호로 이동한 후 NgRx 사용량을 재평가합니다. 남은 것은 실제 워크플로 또는 공유 요구 사항을 갖춘 실제 도메인 상태여야 합니다.