상태를 변경하는 컴포넌트라면 반드시 ...

[pumpkiinbell]

안녕하세요!
코드 관련 고민이 있어 FF Discussion 에 질문 남깁니다.
저는 상태를 변경하는 컴포넌트라면 반드시 value와 onChange prop을 사용해야 한다는 입장인데요.
여러분은 컴포넌트를 구현할 때 어떻게 정하시는지 궁금해요.

---

예를 들어, 저는 아래처럼 작성하는 걸 선호해요.

// ✅ 선호하는 방식
type Props = {
  value: Array<Term | TermGroup>;
  onChange?: (value: Array<Term | TermGroup>) => void;
}

// ❌ 지양하는 방식
type Props = {
  terms: Array<Term | TermGroup>;
  onTermsChange?: (value: Array<Term | TermGroup>) => void;
}

// ❌ 지양하는 방식
Context API

---

제가 value / onChange 를 선호하는 이유는 다음과 같아요.

1. 인지 부담이 줄어든다.
   코드베이스에 대한 사전 지식이 없어도, 해당 prop이 어떤 역할을 하는지 쉽게 파악할 수 있어요.

2. 암시적인 동작을 줄일 수 있다.
   Context API를 사용하지 않으므로 특정 컨텍스트에 종속되지 않아 재사용성이 높아져요.

3. 컴포넌트의 책임을 명확히 할 수 있다.
   prop 이름이 다양해지거나 Context API를 활용하면, 해당 컴포넌트가 자체적으로 상태를 가지는지, 외부에서 상태를 주입하는지 모호해진다고 생각해요.
   value / onChange 를 사용하면 "이 컴포넌트는 상태를 관리하는 게 아니라, 주어진 상태를 UI에 반영하는 역할" 이라는 점이 명확해져요.

---

저는 요구 사항을 받으면 항상 아래처럼 구성하려고 해요.

• 부모 컴포넌트 1개 → 자유로운 설계 가능, 너무 무거워지면 1~2개 더 추가
• 자식 컴포넌트 N개 → value / onChange prop

혹시 다른 기준이나 의견이 있으신지 공유해주시면 감사하겠습니다!

[kickbelldev]

// ✅ 선호하는 방식
type Props = {
  value: Array<Term | TermGroup>;
  onChange?: (value: Array<Term | TermGroup>) => void;
}

// ❌ 지양하는 방식
type Props = {
  terms: Array<Term | TermGroup>;
  onTermsChange?: (value: Array<Term | TermGroup>) => void;
}

// ❌ 지양하는 방식
Context API

작성해주신 예시를 보면 해당 props가 들어가는 컴포넌트가 왠지 terms를 조작하는 컴포넌트일 것 같아요... 🤔
예를 들어 TermsEditor 같은 컴포넌트요!

그렇다고 하면 TermsEditor라는 이름에 이미 terms를 다루는 게 명시되어 있으니 필요 없는 중복이 발생한 느낌이에요.
그래서 props에서까지 terms라는 정보를 안 줘도 되지 않을까 싶어요.

한 발 더 나아가서..

저는 컴포넌트 props뿐만 아니라 다른 곳에서도 비슷한 논리로 이름을 짓는 편이에요.
예를 들어 객체를 구성할 때 속성명에서는 단순히 중복되는 객체명 덧붙임을 빼는거죠.

물론 domain specific한 용어들은 적용하면 안되겠고, '일반적인' 속성일 경우는 이렇게 이름 짓는 게 좋은 것 같아요.

그런 '일반적인' 속성명이 중복되는 상황이 발생하면, 객체의 계층 구조가 올바르지 않다는 걸 알려주기도 해요.
대표적으로 각종 id 값이 한 객체 안에 다른 prefix를 달고 있는 상황이 있을 것 같아요.

// ✅
type Post = {
  id: string
  // ...
  author: Author
}

type Author = {
  id: string
  // ...
}

// ❌
type Post = {
  postId: string
  // ...
  authorId: string
  // ...
}