<div id="readability-page-1" class="page"><div>몇몇 프레임워크들은 <code>signals</code>라는 용어 아래 Vue Composition API의 <code>refs</code>와 유사한 반응성 기본 요소를 도입했다.<ul><li id="5816"><a href="https://www.solidjs.com/docs/latest/api#createsignal" rel="noopener ugc nofollow" target="_blank">Solid Signals</a></li><li id="00a2"><a href="https://github.com/angular/angular/discussions/49090" rel="noopener ugc nofollow" target="_blank">Angular Signals</a></li><li id="9678"><a href="https://preactjs.com/guide/v10/signals/" rel="noopener ugc nofollow" target="_blank">Preact Signals</a></li><li id="1075"><a href="https://qwik.builder.io/docs/components/state/#usesignal" rel="noopener ugc nofollow" target="_blank">Qwik Signals</a></li></ul>기본적으로 <code>signals</code>는 Vue 의 <code>refs</code>와 동일한 종류의 반응성 기본 요소이다. 액세스에 대한 종속성 추적 및 변경에 대한 트리거를 제공하는 컨테이너이다. 이 반응성 기본 기반 패러다임은 프런트엔드 세계에서 특별히 새로운 개념은 아니다. 이는 10여 년 전 <a href="https://knockoutjs.com/documentation/observables.html" rel="noopener ugc nofollow" target="_blank">Knockout Observable</a> 및 <a href="https://docs.meteor.com/api/tracker.html" rel="noopener ugc nofollow" target="_blank">Meteor Tracker</a>와 같은 구현으로 거슬러 올라간다. Vue의 Options API와 React 상태 관리 라이브러리 <a href="https://mobx.js.org/" rel="noopener ugc nofollow" target="_blank">MobX</a>도 동일한 원칙을 기반으로 하지만 객체 속성 뒤에 원시값을 숨긴다.<code>signals</code>로서 필수적인 특성은 아니지만 오늘날 이 개념은 세분화된 구독을 통해 업데이트가 수행되는 렌더링 모델과 함께 종종 논의된다. 가상돔의 사용으로 인해 Vue는 현재 <a href="https://vuejs.org/guide/extras/rendering-mechanism#compiler-informed-virtual-dom" rel="noopener ugc nofollow" target="_blank">유사한 최적화를 달성하기 위해 컴파일러에 의존한다</a>. 그러나 우리는 가상돔에 의존하지 않고 Vue에 내장된 반응성 시스템을 더 많이 활용하는 새로운 Solid 기반 컴파일 전략(Vapor 모드)도 모색하고 있다.<h2 id="672f">API 설계 절충안</h2>Preact와 Qwik의 <code>signals</code> 설계는 Vue의 <a href="https://vuejs.org/api/reactivity-advanced#shallowref" rel="noopener ugc nofollow" target="_blank">shallowRef</a>와 매우 유사하다. 세 가지 모두 .value 속성을 통해 가변 인터페이스를 제공한다. 우리는 <a href="https://www.solidjs.com/docs/latest/api#createsignal" rel="noopener ugc nofollow" target="_blank">Solid의 Signals</a>와 <a href="https://github.com/angular/angular/discussions/49090" rel="noopener ugc nofollow" target="_blank">Angular의 Signals</a>로 논의를 집중할 것이다.<h2 id="6d9c">Solid Signals</h2>Solid의 createSignal() API 설계는 읽기/쓰기 분리를 강조한다. signals는 읽기 전용 getter와 별도의 setter로 노출된다:<pre>const [count, setCount] = createSignal(0)count() // access the value setCount(1) // update the value</pre>카운트 신호가 어떻게 세터 없이 전달될 수 있는지 주목하라. 이렇게 하면 세터가 명시적으로 노출되지 않는 한 상태를 절대로 변경할 수 없다. 이러한 안전한 상태 관리 방식이 더 복잡합 문법을 사용하는 것을 정당화할 수 있는지의 여부는 개별 프로젝트의 필요성과 개발자의 개인적인 취향에 따라 달라질 수 있다. 이 API 스타일을 선호한다면 쉽게 Vue로 구현해 볼 수 있다:<pre>import { shallowRef, triggerRef } from 'vue'export function createSignal(value, options) { const r = shallowRef(value) const get = () =&gt; r.value const set = (v) =&gt; { r.value = typeof v === 'function' ? v(r.value) : v if (options?.equals === false) triggerRef(r) } return [get, set] }</pre><h2 id="8a56">Angular Signals</h2>Angular는 더티 체크를 포기하고 반응성 기본 요소(reactivity primitive)의 자체 구현을 도입함으로써 몇 가지 근본적인 변화를 겪고 있다. Angular Signals API는 다음과 같다:<pre>const count = signal(0)count() // access the value count.set(1) // set new value count.update((v) =&gt; v + 1) // update based on previous value// mutate deep objects with same identity const state = signal({ count: 0 }) state.mutate((o) =&gt; { o.count++ })</pre>(*더티 체크 : 데이터 모델의 상태 변화를 주기적으로 검사하여 변경사항을 감지하고 뷰를 업데이트하는 앵귤러 프레임워크 초기 버전의 매커니즘. <a href="https://yceffort.kr/2020/07/change-detection-in-angular-react#change-detection%EA%B5%AC%ED%98%84" rel="noopener ugc nofollow" target="_blank">참고자료</a>)역시 Vue 로 쉽게 구현해볼 수 있다.<pre>import { shallowRef, triggerRef } from 'vue'export function signal(initialValue) { const r = shallowRef(initialValue) const s = () =&gt; r.value s.set = (value) =&gt; { r.value = value } s.update = (updater) =&gt; { r.value = updater(r.value) } s.mutate = (mutator) =&gt; { mutator(r.value) triggerRef(r) } return s }</pre>Vue의 <code>refs</code>와 비교하여 Solid와 Angular의 getter 기반 API 스타일은 Vue 구성 요소에서 사용될 때 몇 가지 흥미로운 절충점을 제공한다:<ul><li id="7c20"><code>()</code>는 <code>.value</code>보다 약간 덜 장황하지만 값을 업데이트하는 것은 더 장황하다.</li><li id="2448">ref-un-rapping이 없다: 값에 접근하는 것은 항상 <code>()</code> 이 필요합니다. 따라서 값 접근은 어디에서나 일관적이다. 이는 또한 원시 값을 컴포넌트의 props로 전달할 수 있음을 의미한다.</li></ul>이러한 API 스타일이 여러분에게 적합한지 여부는 어느 정도 주관적이다. 이 글의 목표는 이러한 다양한 API 디자인 간의 근본적인 유사성과 균형을 보여주는 것이다. 또한 Vue가 유연하다는 것을 보여주고 싶었다: Vue는 유연성을 가진 프레임워크이기에, 반드시 Vue의 기존 API 사용만을 고집할 필요는 없다. 즉, 필요하다면, 개별 프로젝트의 요구사항에 맞는 자체 반응성 기본 요소(reactivity primitive) API를 만들어 사용할 수 있다.</div></div>

Stories by Jeong Woo Ahn on Medium

Jeongwoo Ahn

원문 Vue.js — The Progressive JavaScript Framework
뷰의 반응성에 대해 정리된 글이 있고 한글로도 번역이 되어있다. 그런데 이 글의 한 꼭지로 Connection to signals 라는 꼭지가 새로 생겼는데 이런, 한글 번역은 없더라. 최근 Signals 라는 개념에 대해 이런저런 얘기에 관심이 생겨서 겸사겸사 번역을 해보았다.
몇몇 프레임워크들은 signals라는 용어 아래 Vue Composition API의 refs와 유사한 반응성 기본 요소를 도입했다.
Solid Signals
Angular Signals
Preact Signals
Qwik Signals
기본적으로 signals는 Vue 의 refs와 동일한 종류의 반응성 기본 요소이다. 액세스에 대한 종속성 추적 및 변경에 대한 트리거를 제공하는 컨테이너이다. 이 반응성 기본 기반 패러다임은 프런트엔드 세계에서 특별히 새로운 개념은 아니다. 이는 10여 년 전 Knockout Observable 및 Meteor Tracker와 같은 구현으로 거슬러 올라간다. Vue의 Options API와 React 상태 관리 라이브러리 MobX도 동일한 원칙을 기반으로 하지만 객체 속성 뒤에 원시값을 숨긴다.
signals로서 필수적인 특성은 아니지만 오늘날 이 개념은 세분화된 구독을 통해 업데이트가 수행되는 렌더링 모델과 함께 종종 논의된다. 가상돔의 사용으로 인해 Vue는 현재 유사한 최적화를 달성하기 위해 컴파일러에 의존한다. 그러나 우리는 가상돔에 의존하지 않고 Vue에 내장된 반응성 시스템을 더 많이 활용하는 새로운 Solid 기반 컴파일 전략(Vapor 모드)도 모색하고 있다.
API 설계 절충안
Preact와 Qwik의 signals 설계는 Vue의 shallowRef와 매우 유사하다. 세 가지 모두 .value 속성을 통해 가변 인터페이스를 제공한다. 우리는 Solid의 Signals와 Angular의 Signals로 논의를 집중할 것이다.
Solid Signals
Solid의 createSignal() API 설계는 읽기/쓰기 분리를 강조한다. signals는 읽기 전용 getter와 별도의 setter로 노출된다:
const [count, setCount] = createSignal(0)
count() // access the value
setCount(1) // update the value
카운트 신호가 어떻게 세터 없이 전달될 수 있는지 주목하라. 이렇게 하면 세터가 명시적으로 노출되지 않는 한 상태를 절대로 변경할 수 없다. 이러한 안전한 상태 관리 방식이 더 복잡합 문법을 사용하는 것을 정당화할 수 있는지의 여부는 개별 프로젝트의 필요성과 개발자의 개인적인 취향에 따라 달라질 수 있다. 이 API 스타일을 선호한다면 쉽게 Vue로 구현해 볼 수 있다:
import { shallowRef, triggerRef } from 'vue'
export function createSignal(value, options) {
  const r = shallowRef(value)
  const get = () => r.value
  const set = (v) => {
    r.value = typeof v === 'function' ? v(r.value) : v
    if (options?.equals === false) triggerRef(r)
  }
  return [get, set]
}
Angular Signals
Angular는 더티 체크를 포기하고 반응성 기본 요소(reactivity primitive)의 자체 구현을 도입함으로써 몇 가지 근본적인 변화를 겪고 있다. Angular Signals API는 다음과 같다:
const count = signal(0)
count() // access the value
count.set(1) // set new value
count.update((v) => v + 1) // update based on previous value
// mutate deep objects with same identity
const state = signal({ count: 0 })
state.mutate((o) => {
  o.count++
})
(*더티 체크 : 데이터 모델의 상태 변화를 주기적으로 검사하여 변경사항을 감지하고 뷰를 업데이트하는 앵귤러 프레임워크 초기 버전의 매커니즘. 참고자료)
역시 Vue 로 쉽게 구현해볼 수 있다.
import { shallowRef, triggerRef } from 'vue'
export function signal(initialValue) {
  const r = shallowRef(initialValue)
  const s = () => r.value
  s.set = (value) => {
    r.value = value
  }
  s.update = (updater) => {
    r.value = updater(r.value)
  }
  s.mutate = (mutator) => {
    mutator(r.value)
    triggerRef(r)
  }
  return s
}
Vue의 refs와 비교하여 Solid와 Angular의 getter 기반 API 스타일은 Vue 구성 요소에서 사용될 때 몇 가지 흥미로운 절충점을 제공한다:
()는 .value보다 약간 덜 장황하지만 값을 업데이트하는 것은 더 장황하다.
ref-un-rapping이 없다: 값에 접근하는 것은 항상 () 이 필요합니다. 따라서 값 접근은 어디에서나 일관적이다. 이는 또한 원시 값을 컴포넌트의 props로 전달할 수 있음을 의미한다.
이러한 API 스타일이 여러분에게 적합한지 여부는 어느 정도 주관적이다. 이 글의 목표는 이러한 다양한 API 디자인 간의 근본적인 유사성과 균형을 보여주는 것이다. 또한 Vue가 유연하다는 것을 보여주고 싶었다: Vue는 유연성을 가진 프레임워크이기에, 반드시 Vue의 기존 API 사용만을 고집할 필요는 없다. 즉, 필요하다면, 개별 프로젝트의 요구사항에 맞는 자체 반응성 기본 요소(reactivity primitive) API를 만들어 사용할 수 있다.

Signals 와 Vue

댓글