WTF는 반응성입니까!?

반응성 모델 설명

머리말

애플리케이션과 웹사이트 개발을 시작한 지 (벌써) 10년이 지났지만 JavaScript 생태계가 지금보다 더 흥미로웠던 적은 없었습니다!

2022년 커뮤니티는 대부분의 JavaScript 프레임워크가 이를 자체 엔진에 통합할 정도로 '시그널' 개념에 매료되었습니다. 2022년 9월부터 구성요소 수명주기에서 분리된 반응형 변수를 제공한 Preact에 대해 생각하고 있습니다. 또는 최근에는 2023년 5월에 신호를 실험적으로 구현한 후 공식적으로 버전 18부터 시작한 Angular입니다. 다른 JavaScript 라이브러리도 접근 방식을 재고하기로 결정했습니다...

2023년부터 지금까지 다양한 프로젝트에서 Signals를 꾸준히 사용해 왔습니다. 기술 워크숍, 교육 세션 및 컨퍼런스 중에 이 기능의 이점을 전문 네트워크와 공유할 정도로 구현 및 사용이 간편하다는 사실에 완전히 확신을 갖게 되었습니다.

그러나 최근에는 이 개념이 정말로 "혁명적"인지/신호에 대한 대안이 있는지 자문하기 시작했습니다. 그래서 저는 이 반성을 더 깊이 파고들어 리액티브 시스템에 대한 다양한 접근 방식을 발견했습니다.

이 게시물은 다양한 반응성 모델의 개요와 작동 방식에 대한 이해를 담고 있습니다.

NB: 이 시점에서 아마도 짐작하셨을 것입니다. 저는 Java의 "Reactive Streams"에 대해 논의하지 않을 것입니다. 그렇지 않았다면 이 게시물의 제목을 "WTF Is BackPressure!?"로 정했을 것입니다 ?

이론

반응성 모델에 관해 이야기할 때 (무엇보다도) "반응형 프로그래밍"에 대해 이야기하지만 특히 "반응성"에 대해 이야기합니다.

반응형 프로그래밍은 데이터 소스의 변경 사항을 소비자에게 자동으로 전파할 수 있는 개발 패러다임입니다.

따라서 반응성을 데이터 변경에 따라 실시간으로 종속성을 업데이트하는 기능으로 정의할 수 있습니다.

NB: 간단히 말해서, 사용자가 양식을 작성 및/또는 제출할 때 이러한 변경 사항에 반응하고 로드 구성 요소 또는 어떤 일이 발생하고 있음을 지정하는 기타 모든 것을 표시해야 합니다. .. 또 다른 예를 들어, 데이터를 비동기적으로 수신할 때 이 데이터의 전체 또는 일부를 표시하고 새로운 작업을 실행하는 등의 반응을 해야 합니다.

이러한 맥락에서 반응형 라이브러리는 자동으로 업데이트되고 효율적으로 전파되는 변수를 제공하므로 간단하고 최적화된 코드를 더 쉽게 작성할 수 있습니다.

효율성을 위해 이러한 시스템은 값이 변경된 경우에만 이러한 변수를 다시 계산/재평가해야 합니다! 마찬가지로, 브로드캐스트된 데이터가 일관되고 최신 상태로 유지되도록 하려면 시스템에서 중간 상태(특히 상태 변경을 계산하는 동안) 표시를 피해야 합니다.

NB: 상태는 프로그램/애플리케이션의 전체 수명 동안 사용되는 데이터/값을 나타냅니다.

알겠습니다. 그런데… "반응성 모델"이 정확히 무엇인가요?

PUSH, 일명 "Eager" 반응성

첫 번째 반응성 모델은 "PUSH"(또는 "열심히" 반응성)이라고 합니다. 이 시스템은 다음 원칙을 기반으로 합니다.

• 데이터 소스 초기화("Observables"라고도 함)
• 구성요소/기능은 이러한 데이터 소스를 구독합니다(이것이 소비자입니다)
• 값이 변경되면 데이터가 즉시 소비자("관찰자"라고도 함)에게 전파됩니다.

짐작하셨겠지만 "PUSH" 모델은 "Observable/Observer" 디자인 패턴을 기반으로 합니다.

첫 번째 사용 사례: 초기 상태 및 상태 변경

다음과 같은 초기 상태를 생각해보자

let a = { firstName: "John", lastName: "Doe" };
const b = a.firstName;
const c = a.lastName;
const d = `${b} ${c}`;

반응형 라이브러리(예: RxJS)를 사용하면 이 초기 상태는 다음과 같습니다.

let a = observable.of({ firstName: "John", lastName: "Doe" });
const b = a.pipe(map((a) => a.firstName));
const c = a.pipe(map((a) => a.lastName));
const d = merge(b, c).pipe(reduce((b, c) => `${b} ${c}`));

NB: 이 게시물을 위해 모든 코드 조각은 "의사 코드"로 간주되어야 합니다.

이제 소비자(예: 구성 요소)가 이 데이터 소스가 업데이트될 때마다 상태 D의 값을 기록하려고 한다고 가정해 보겠습니다.

d.subscribe((value) => console.log(value));

우리 구성 요소는 데이터 스트림을 구독합니다. 여전히 변화를 촉발해야 합니다.

a.next({ firstName: "Jane", lastName: "Doe" });

여기서 'PUSH' 시스템이 변화를 감지해 소비자에게 자동으로 방송한다. 위의 초기 상태를 기반으로 발생할 수 있는 작업에 대한 설명은 다음과 같습니다.

• 데이터 소스 A에서 상태 변경이 발생합니다!
• A의 값이 B로 전파됩니다(데이터 소스 B의 계산).
• 그런 다음 B의 값이 D로 전파됩니다(데이터 소스 D 계산).
• A의 값이 C로 전파됩니다(데이터 소스 C의 계산).
• 마지막으로 C의 값이 D로 전파됩니다(데이터 소스 D의 재계산).

이 시스템의 과제 중 하나는 계산 순서에 있습니다. 실제로 우리의 사용 사례에 따르면 D가 두 번 평가될 수 있다는 것을 알 수 있습니다. 처음에는 이전 상태의 C 값으로 평가됩니다. 그리고 두 번째로 C의 값을 최신 상태로 유지합니다! 이런 종류의 반응성 모델에서 이 과제를 "다이아몬드 문제" 치라고 합니다.

두 번째 사용 사례: Next Iteration

이제 상태가 두 가지 주요 데이터 소스에 의존한다고 가정해 보겠습니다.

let a = { firstName: "John", lastName: "Doe" };
const b = a.firstName;
const c = a.lastName;
const d = `${b} ${c}`;

E를 업데이트할 때 시스템은 전체 상태를 다시 계산하므로 이전 상태를 덮어써서 단일 정보 소스를 보존할 수 있습니다.

• 데이터 소스 E에서 상태 변경이 발생합니다!
• A의 값이 B로 전파됩니다(데이터 소스 B의 계산).
• 그런 다음 B의 값이 D로 전파됩니다(데이터 소스 D 계산).
• A의 값이 C로 전파됩니다(데이터 소스 C의 계산).
• E의 값이 C로 전파됩니다(데이터 소스 C의 재계산);.
• 마지막으로 C의 값이 D로 전파됩니다(데이터 소스 D의 재계산).

다시 한번 "다이아몬드 문제"가 발생합니다... 이번에는 잠재적으로 2번 평가된 데이터 소스 C에서 항상 D에 있습니다.

다이아몬드 문제

'다이아몬드 문제'는 '열심히' 반응성 모델에서 새로운 문제가 아닙니다. 일부 계산 알고리즘(특히 MobX에서 사용하는 알고리즘)은 "반응적 종속성 트리의 노드"에 태그를 지정하여 상태 계산을 평준화할 수 있습니다. 이 접근 방식을 사용하면 시스템은 먼저 "루트" 데이터 소스(이 예에서는 A와 E)를 평가한 다음 B와 C, 마지막으로 D를 평가합니다. 상태 계산 순서를 변경하면 이러한 종류의 문제를 해결하는 데 도움이 됩니다.

PULL, 일명 "게으른" 반응성

두 번째 반응성 모델은 "PULL"입니다. "PUSH" 모델과 달리 다음 원칙을 기반으로 합니다.

• 반응형 변수 선언
• 시스템이 상태 계산을 연기합니다
• 파생 상태는 종속성을 기반으로 계산됩니다
• 과도한 업데이트를 방지하는 시스템

기억해야 할 가장 중요한 것은 이 마지막 규칙입니다. 이전 시스템과 달리 이 마지막 규칙은 동일한 데이터 소스에 대한 여러 평가를 피하기 위해 상태 계산을 연기합니다.

첫 번째 사용 사례: 초기 상태 및 상태 변경

이전 초기상태를 유지하자...

이런 종류의 시스템에서 초기 상태 구문은 다음과 같은 형식입니다.

let a = observable.of({ firstName: "John", lastName: "Doe" });
const b = a.pipe(map((a) => a.firstName));
const c = a.pipe(map((a) => a.lastName));
const d = merge(b, c).pipe(reduce((b, c) => `${b} ${c}`));

주의: React 매니아라면 이 구문을 인식할 것입니다 ?

반응형 변수를 선언하면 튜플이 "탄생"됩니다. 한쪽은 불변 변수입니다. 이 변수의 다른 함수를 업데이트합니다. 나머지 문(이 경우 B, C, D)은 해당 종속성을 "수신"하므로 파생 상태로 간주됩니다.

d.subscribe((value) => console.log(value));

'게으른' 시스템의 특징은 변경 사항을 즉시 전파하지 않고 명시적으로 요청한 경우에만 전파한다는 것입니다.

let a = { firstName: "John", lastName: "Doe" };
const b = a.firstName;
const c = a.lastName;
const d = `${b} ${c}`;

"PULL" 모델에서 effect()(구성 요소에서)를 사용하여 반응 변수(종속성으로 지정됨)의 값을 기록하면 상태 변경 계산이 트리거됩니다.

• D는 종속성(B 및 C)이 업데이트되었는지 확인합니다.
• B는 종속성(A)이 업데이트되었는지 확인합니다.
• A는 해당 값을 B에 전파합니다(B 값 계산).
• C는 종속성(A)이 업데이트되었는지 확인합니다.
• A는 해당 값을 C에 전파합니다(C 값 계산)
• B와 C는 각각의 값을 D에 전파합니다(D 값 계산).

종속성을 쿼리할 때 이 시스템을 최적화할 수 있습니다. 실제로 위 시나리오에서는 A가 업데이트되었는지 확인하기 위해 두 번 쿼리됩니다. 그러나 첫 번째 쿼리는 상태가 변경되었는지 정의하는 데 충분할 수 있습니다. C는 이 작업을 수행할 필요가 없습니다. 대신 A는 해당 값을 브로드캐스트할 수만 있습니다.

두 번째 사용 사례: Next Iteration

두 번째 반응 변수 "root"를 추가하여 상태를 다소 복잡하게 만들어 보겠습니다.

let a = observable.of({ firstName: "John", lastName: "Doe" });
const b = a.pipe(map((a) => a.firstName));
const c = a.pipe(map((a) => a.lastName));
const d = merge(b, c).pipe(reduce((b, c) => `${b} ${c}`));

한 번 더 시스템은 명시적으로 요청될 때까지 상태 계산을 연기합니다. 이전과 동일한 효과를 사용하여 새 반응 변수를 업데이트하면 다음 단계가 트리거됩니다.

• D는 종속성(B와 C)이 업데이트되었는지 확인합니다.
• B는 종속성(A)이 업데이트되었는지 확인합니다.
• C는 종속성(A 및 E)이 업데이트되었는지 확인합니다.
• E는 그 값을 C에 전파하고 C는 메모를 통해 A의 값을 가져옵니다(C의 값 계산) ;
• C는 자신의 값을 D에 전파하고 D는 메모를 통해 B의 값을 가져옵니다(D의 값 계산) ;

A의 값은 변경되지 않았으므로 이 변수를 다시 계산할 필요가 없습니다(B의 값에도 동일하게 적용됨). 이러한 경우 메모이제이션 알고리즘을 사용하면 상태 계산 시 성능이 향상됩니다.

PUSH-PULL, 일명 "세밀한" 반응성

마지막 반응성 모델은 "PUSH-PULL" 시스템입니다. "PUSH"라는 용어는 변경 알림의 즉각적인 전파를 반영하는 반면, "PULL"은 요청 시 상태 값을 가져오는 것을 의미합니다. 이 접근 방식은 다음 원칙을 준수하는 "세밀한" 반응성과 밀접한 관련이 있습니다.

• 반응 변수 선언(반응 프리미티브에 대해 이야기하고 있음)
• 종속성은 원자 수준에서 추적됩니다
• 변경 사항 전파는 고도로 표적화되어 있습니다

이런 종류의 반응성은 "PUSH-PULL" 모델에만 국한되지 않습니다. 세분화된 반응성은 시스템 종속성을 정확하게 추적하는 것을 의미합니다. 그래서 이런 방식으로 작동하는 PUSH 및 PULL 반응성 모델도 있습니다(저는 Jotai나 Recoil을 생각하고 있습니다.

첫 번째 사용 사례: 초기 상태 및 상태 변경

여전히 이전 초기 상태를 기반으로 합니다... "세밀한" 반응성 시스템에서 초기 상태 선언은 다음과 같습니다.

let a = { firstName: "John", lastName: "Doe" };
const b = a.firstName;
const c = a.lastName;
const d = `${b} ${c}`;

NB: 여기서 시그널 키워드의 사용은 단지 일화만은 아닙니다 ?

구문 측면에서 "PUSH" 모델과 매우 유사하지만 한 가지 주목할 만한 중요한 차이점이 있습니다. 종속성! "세분화된" 반응성 시스템에서 , 파생 상태를 계산하는 데 필요한 종속성을 명시적으로 선언할 필요는 없습니다. 이러한 상태는 사용하는 변수를 암시적으로 추적하기 때문입니다. 우리의 경우 B와 C는 A 값의 변경 사항을 자동으로 추적하고 D는 B와 C의 변경 사항을 모두 추적합니다.

let a = observable.of({ firstName: "John", lastName: "Doe" });
const b = a.pipe(map((a) => a.firstName));
const c = a.pipe(map((a) => a.lastName));
const d = merge(b, c).pipe(reduce((b, c) => `${b} ${c}`));

이러한 시스템에서는 반응 변수를 업데이트하는 것이 기본 "PUSH" 모델보다 더 효율적입니다. 변경 사항이 해당 변수에 의존하는 파생 변수에 자동으로 전파되기 때문입니다(알림으로만 전파되며, 값 자체).

d.subscribe((value) => console.log(value));

그런 다음 요청 시(로거 예를 들어 보겠습니다) 시스템 내에서 D를 사용하면 관련 루트 상태(이 경우 A)의 값을 가져오고 값을 계산합니다. ​파생된 상태(B와 C)에 대해 알아보고 최종적으로 D를 평가합니다. 직관적인 작동 방식이 아닌가요?

두 번째 사용 사례: Next Iteration

다음 상태를 생각해보자

a.next({ firstName: "Jane", lastName: "Doe" });

다시 한 번 PUSH-PULL 시스템의 "세밀한" 측면을 통해 각 상태를 자동으로 추적할 수 있습니다. 따라서 파생된 상태 C는 이제 루트 상태 A와 E를 추적합니다. 변수 E를 업데이트하면 다음 작업이 트리거됩니다.

• 반응형 프리미티브 E의 상태 변화!
• 대상 변경 알림(C를 통해 E에서 D로)
• E는 그 값을 C에 전파하고 C는 메모를 통해 A의 값을 검색합니다(C의 값 계산).
• C는 자신의 값을 D에 전파하고 D는 메모를 통해 B의 값을 검색합니다(D의 값 계산).

이 모델을 매우 효율적으로 만드는 것은 반응적 종속성의 사전 연결입니다!

실제로 고전적인 "PULL" 시스템(예: React의 Virtual DOM)에서는 구성 요소의 반응 상태를 업데이트할 때 프레임워크에 변경 사항이 통보됩니다(" 차이' 단계). 그런 다음 요청 시(및 지연) 프레임워크는 반응적 종속성 트리를 순회하여 변경 사항을 계산합니다. 변수가 업데이트될 때마다! 종속성 상태를 "발견"하려면 상당한 비용이 듭니다...

"세밀한" 반응성 시스템(예: 신호)을 사용하면 반응 변수/기본 요소의 업데이트가 자동으로 연결된 모든 파생 상태에 변경 사항을 알립니다. 따라서 연관된 종속성을 (재)검색할 필요가 없습니다. 상태전파가 타겟입니다!

결론(.value)

2024년에는 대부분의 웹 프레임워크가 작동 방식, 특히 반응성 모델 측면에서 다시 생각해 보기로 결정했습니다. 이러한 변화로 인해 일반적으로 효율성과 경쟁력이 향상되었습니다. 다른 사람들은 (여전히) 하이브리드(여기서 Vue를 생각하고 있습니다)를 선택하여 여러 상황에서 더 유연하게 만듭니다.

마지막으로 어떤 모델을 선택하든 (좋은) 반응형 시스템은 다음과 같은 몇 가지 주요 규칙을 기반으로 구축된다고 생각합니다.

1. 시스템은 일관되지 않은 파생 상태;
를 방지합니다.
2. 시스템 내에서 상태를 사용하면 반응성 파생 상태;
가 발생합니다.
3. 시스템으로 과도한 업무를 최소화 ;
4. 그리고 "주어진 초기 상태에 대해 상태가 따르는 경로에 관계없이 시스템의 최종 결과는 항상 동일합니다! "

선언적 프로그래밍의 기본 원칙으로 해석될 수 있는 이 마지막 요점은 (좋은) 반응형 시스템이 결정적이어야 한다고 보는 방식입니다! 이것이 바로 알고리즘의 복잡성에 관계없이 대규모 기술 프로젝트에서 반응형 모델을 신뢰할 수 있고 예측 가능하며 사용하기 쉽게 만드는 "결정론"입니다.

위 내용은 WTF는 반응성입니까!?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!