Next.js/React/Typescript - Context API file naming rule

개발할 때 파일 이름과 관련된 규칙이 있습니다. 

이 룰에 대해 파악하고 있으면 좋습니다.

하지만 이는 필수적인 문법 규칙이라기보다는, 

**개발의 효율성과 협업을 위해 많은 개발자가 따르는 강력한 관례(컨벤션)**에 

가깝습니다.

---

---

1. 파일 이름 네이밍 규칙 (관례)

---

React와 TypeScript, 그리고 Context API를 사용할 때 일반적으로 준수하는 네이밍 규칙은 다음과 같습니다.

---

Context 파일 네이밍

[Context이름]Context.tsx

가장 표준적인 방식입니다. 

이 파일이 React Context를 정의하고 관리하는 파일임을 명확히 나타냅니다. 

(예: DetailContext.tsx, AuthContext.tsx)

use[Context이름].ts

Context 파일이 커지거나 재사용성이 중요할 때, Context Provider와 Custom Hook(use...)을 분리하여 저장하기도 합니다.

 

index.ts

Context 관련 파일들이 여러 개일 경우, context 디렉토리 내의 진입점 파일로 사용되기도 합니다.

---

---

컴포넌트/훅 네이밍 규칙

---

파일 내부에 정의된 컴포넌트나 훅 이름도 관례를 따르는 것이 중요합니다.

Provider 컴포넌트

[Context이름]Provider

이 컴포넌트가 Context의 공급자 역할을 한다는 것을 명확히 보여줍니다. 

(예: DetailProvider)

Custom Hook

use[Context이름]

React의 내장 훅(useState, useEffect)처럼 **use**로 시작하여, 이 함수가 React의 훅이며 규칙을 따른다는 것을 알려줍니다. 

(예: useDetail)

---

---

개발자 마음대로 정해도 되는가?

---

기술적으로는 개발자 마음대로 정할 수 있습니다. 파일 이름이 abc.tsx라고 해서 코드가 동작하지 않는 것은 아닙니다.
하지만 협업과 유지보수를 위해 반드시 관례를 지키는 것이 좋습니다.

---

가독성 및 검색: 

DetailContext.tsx 파일을 보는 순간, 다른 개발자나 미래의 내가 "아, 이 파일은 상세 정보를 제공하는 Context가 들어있겠구나"라고 즉시 알 수 있습니다.

도구의 지원: 

ESLint, Prettier 등의 개발 도구, 그리고 IDE(VS Code 등)가 이러한 네이밍 규칙을 기반으로 더 정확하게 구문 분석, 자동 완성, linting을 제공합니다.

통일성: 

한 팀에서 일관된 규칙을 사용하면, 수백 개의 파일 속에서도 원하는 파일을 쉽게 찾고 코드를 이해할 수 있습니다.

---