Show HN: Proxy 상태 튜플로 기존 DOM을 반응형으로 묶는 약 80줄 라이브러리 Mador
- Mador는 약 80줄의 Proxy 기반 상태 튜플
[r, w]로 기존 DOM 요소를 CSS 선택자에 연결하는 소형 반응형 DOM 런타임임 - 상태를 읽는 함수가 초기 실행 중 접근한 값을 추적해 의존성을 자동 등록하고, 상태 변경 뒤 DOM effect를 마이크로태스크로 배치 실행함
- 라이브러리는 npm 또는 CDN에서 쓰는 네이티브 ES 모듈이며, 빌드 단계와 외부 의존성 없이 사용한다는 방향임
- 작성자는 갱신 기준이 참조 동등성이라고 답했으며,
=대입이 effect를 실행함 - HN 댓글에서는 Preact Signals와 Vue reactivity, TC39 Signals 제안과의 차이, Proxy 성능,
read와writeAPI의 가독성 및 로컬 HTML 파일 사용 제약을 지적함
Hacker News opinions
주말에 현대 자바스크립트 Proxy를 어디까지 밀어붙일 수 있는지 보려고 만들었음. 프레임워크 없이 CSS 선택자, 자동 의존성 추적, 마이크로태스크 배칭으로 DOM을 반응형으로 바꾸는 약 80줄짜리 실험임.
예제 API는 사람이 읽기 좋게 read와 write를 분리하는 편이 낫다고 봄. 초기 read 실행 때 의존성을 잡고, write는 즉시 실행하거나 이벤트 핸들러로 쓸 수 있게 하면 됨.
갱신 판정이 깊은 동등성인지 참조 동등성인지 궁금함. Proxy 기반 구현은 대입 연산이 effect를 일으키는 기준이 무엇인지 분명해야 함.
참조 동등성 기준임. =로 대입하면 effect가 실행됨.
자바스크립트 신호 구현은 이미 Preact Signals, Vue reactivity, TC39 proposal-signals처럼 많음. 이 라이브러리가 다른 점이 있는지, 기존 것을 다시 만든 것인지 궁금함.
재미로 만들었고, 얼마나 작고 단순하게 만들 수 있는지 확인하려던 목적이 컸음. Preact나 Vue가 좋더라도 의존성 없는 작은 스크립트만 필요한 경우가 있다고 봄.
성능 수치가 궁금함. Proxy는 성능이 나쁘다는 기억이 있는데 지금도 그런지, 변수와 의존성 수가 늘 때 어떤지 알고 싶음.
성능은 변수와 의존성 수에 좌우됨. Proxy 자체보다 Proxy와 원시값을 Set이나 객체 키에서 섞어 써서 동일성을 혼동하는 문제가 더 큼.
read와 write라는 이름은 역할을 잘 설명하지 못하고 문법도 장황해 보임. proxy 상태와 단일 bind 함수로 DOM 갱신을 연결하는 방식이 더 직관적일 듯함. ES 모듈이라 로컬 파일에서 바로 열 수 없고 단일 HTML 파일 배포도 어렵다는 제약도 있음.