•
custom hooks는 컴포넌트간 state를 공유하는게 아닌 state가 들어간 로직을 공유하는 것 → 같은 hook을 쓰더라도 당연하게 내부 state는 공유되지 않는다.
◦
컴포넌트간 state 공유는 props drilling이나 zustand, zotai와 같은 전역 상태 관리 라이브러리를 사용해야한다.
custom hook 이름짓기
•
“이름짓기가 어렵다” → 이미 사용하려는 로직이 작은 edge cases에 너무 결합 되어있어 그럴 수 있다. 아직 Custom Hooks으로 분리하지 말아보자.
•
컨벤션으로 컴포넌트는 대문자로 시작하고 hook은 use로 시작한다.
◦
해당 컨벤션으로 덕분에 custom hooks를 사용할 때(내가 만들었거나 남들이 만들었던) 내부 코드 확인 없이 state, effects가 사용 여부를 확인 할 수 있다. → lint 기본 설정
좋은 custom hooks 이름의 기준
코드를 자주 작성하지 않는 사람이 봤을 때 무슨일을 하는지 유추가 가능한 이름
useData(url) useImpressionLog(eventName, extraData) useChatRoom(options) useMediaQuery(query) useSocket(url) useIntersectionObserver(ref, options)•
위와 같이 좀더 기술적이고 해당 시스템에 연관된 이름도 좋다.
useMount(fn) useEffectOnce(fn) useUpdateEffect(fn)•
편의성을 위한 react의 lifecycle API의 wrapper 훅의 생성은 자제하자. → lifecycle API를 직접 사용하는게 관리하기, 이해하기 좋은 코드
•
linter는 컴포넌트에서 직접 불러오는 effect만 검사할 수 있다. lifecycle API를 wrapping 하여 사용할 경우 lint 직접검사는 힘들어진다.
Custom hook으로 나누기
•
“이거 프로젝트 전역 공통 컴포넌트로 빼야할까?”와 같은 질문 과 해답이 존재한다.
◦
모든걸 custom hook으로 나누기 시작하면 너무 많은 custom hook으로 인한 코드의 유지 보수성 저하, 컴포넌트에서 필요한 로직의 이해를 위하여 custom hook으로 이동 하여 코드를 확인하고 수정함으로 인한 가독성 저하
•
너무 추상적인 일을 하거나 이름을 가지고 있다면 장기적으로 봤을때 문제 해결보다는 문제 발생을 야기하는 custom hook이 될 가능성이 높다.