From 20fad2508f4b06d2b88604a00e074ccbb8ebb831 Mon Sep 17 00:00:00 2001 From: qwreey Date: Thu, 6 Aug 2026 19:33:07 +0900 Subject: [PATCH] =?UTF-8?q?=EC=9D=B4=EB=B2=A4=ED=8A=B8=20store-bind?= =?UTF-8?q?=EB=A5=BC=20=EB=B6=80=EC=B0=A8=EC=A0=81=20=EC=98=B5=EC=85=98?= =?UTF-8?q?=EC=9C=BC=EB=A1=9C=20=EB=AA=85=EC=8B=9C=20=E2=80=94=20=EA=B8=B0?= =?UTF-8?q?=EB=B3=B8=20=ED=8C=A8=ED=84=B4=EC=9D=80=20=ED=95=B8=EB=93=A4?= =?UTF-8?q?=EB=9F=AC+=EB=82=B4=EB=B6=80=20=EB=B6=84=EA=B8=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 재고 결과: 저빈도 UI 이벤트의 조건부 처리는 Connect/Disconnect 없이 "핸들러 하나 계속 연결 + 내부 분기"로 이미 공짜로 되고 더 쌈 — 이걸 기본 권장 패턴으로 명시. store-bind(false 센티널)는 고빈도 신호/로직 자체가 바뀌는 드문 케이스를 위한 부차적 옵션으로 격하, 자주 재계산되는 State에 물리면 숨은 churn 비용이 생긴다는 캐비엇 추가. 메커니즘 자체는 일관성을 위해 그대로 유지(예외로 빼서 막을 근거는 약함). 향후 documentation-plan.md 3번 문서에 두 패턴 대조 예정으로 기록. Co-Authored-By: Claude Sonnet 5 --- .claude/base/bind-system-plan.md | 28 ++++++++++++++++++++++++++ .claude/research/documentation-plan.md | 7 +++++++ 2 files changed, 35 insertions(+) diff --git a/.claude/base/bind-system-plan.md b/.claude/base/bind-system-plan.md index 556fa6a..05f162d 100644 --- a/.claude/base/bind-system-plan.md +++ b/.claude/base/bind-system-plan.md @@ -301,6 +301,34 @@ per-instance 저장소에 기억해두고, `retract`에서 그걸 `:Disconnect() 이벤트인지 여부는 값이 아니라 키(리플렉션으로 판별)로 결정되므로, 다른 boolean 프로퍼티 핸들러와 `(k, false)` 매칭이 겹칠 위험 없음. +**quad가 미는 기본 패턴은 아님 — 부차적 옵션.** 저빈도 UI 이벤트(클릭류)를 +조건부로 켜고 끄고 싶은 흔한 케이스는 사실 이 메커니즘 없이도 됨 — 핸들러 +하나를 계속 연결해두고 안에서 분기하면 끝: + +```lua +MouseButton1Click = function() + if not store.enabled:Get() then return end + ... +end +``` + +이 "핸들러 하나 + 내부 분기" 패턴이 Connect/Disconnect 자체가 없어서 더 +싸고, Roblox/React 어디서든 이미 익숙한 관용구라 **기본 권장 패턴**. +store-bind 방식이 실제로 값어치 있는 지점은 고빈도 신호(Heartbeat/ +RenderStepped/마우스 무브처럼 안 쓸 때 Connection을 살려두는 것 자체가 +낭비인 경우)나, 단순 on/off가 아니라 로직 자체가 바뀌는 드문 케이스. +자주 재계산되는 State에 이벤트를 직접 물리면 매 재계산마다 Disconnect+ +Connect가 도는 숨은 churn 비용도 있음(Store Set은 dedup 안 함, +`store-semantics.md`) — 그래서 남용하지 말라는 캐비엇. + +**그래도 일관성 있게 지원은 해둠.** "저빈도엔 필요 없다"가 "그러니 예외로 +빼고 못 하게 막자"로 이어질 이유는 없음 — 프로퍼티/태그/어트리뷰트가 +전부 store-bind되는데 이벤트만 특별 취급해서 뺄 근거가 약하고, 구현 +비용도 낮으니(위 "엔지니어링 비용이 낮은 이유" 참고) 일관되게 지원해두는 +쪽을 택함. 그냥 "이런 것도 가능하다" 정도로 존재하고, quad가 이 패턴을 +적극 권장하진 않는다는 톤으로 문서화(`research/documentation-plan.md` +3번 "권장 이벤트 핸들링 패턴" 문서에 이 대조까지 반영 예정). + ## 여러 Store 값을 묶어 파생값 만들기 — `:With` + `:Compute`, 포지셔널 인자 지양 **사용자 확인 완료, 상세 방향 확정.** 후보로 검토했던 두 방식 모두 기각: diff --git a/.claude/research/documentation-plan.md b/.claude/research/documentation-plan.md index 29e643e..e940e7b 100644 --- a/.claude/research/documentation-plan.md +++ b/.claude/research/documentation-plan.md @@ -75,6 +75,13 @@ UICorner/UIPadding/UIScale 숏핸드가 만드는 자식)는 `_`나 `QUAD_` 같 - 일반화된 원칙("엔진이 네이티브로 콜백에 뭘 주든 그대로 호출해줘도 무방하다")을 quad-roblox 한정 설명으로 둘지, 다른 백엔드 구현자를 위한 일반 가이드로도 남길지는 미정. +- **조건부 이벤트 처리 — 기본 패턴 vs store-bind, 대조해서 보여줄 것** + (2026-08-06 추가). "핸들러 하나 계속 연결 + 내부에서 `store.enabled:Get()` + 분기"가 기본 권장 패턴이고, 이벤트 store-bind(`false`로 disconnect, + `bind-system-plan.md` "이벤트도 store-bind 가능" 절)는 고빈도 신호나 + 로직 자체가 바뀌는 드문 케이스를 위한 부차적 옵션이라는 점을 코드 + 대조로 보여줄 것 — quad가 미는 디자인은 전자, 후자는 "이럴 수도 있다" + 정도로만 소개. - 어느 문서에 넣을지 — 퀵스타트? 위 1번 네이밍 컨벤션 문서와 마찬가지로 아직 미정.