첫번째 커스텀 훅스의 확장자에 대한 질문의 답은 "상관없다." 입니다. 간혹, 테이블 컴포넌트의 column 구조를 정의할때 jsx문법이 필요한데 이 때문에 ts가 아닌 tsx형태로 커스텀 훅을

첫번째 커스텀 훅스의 확장자에 대한 질문의 답은 "상관없다." 입니다. 간혹, 테이블 컴포넌트의 column 구조를 정의할때 jsx문법이 필요한데 이 때문에 ts가 아닌 tsx형태로 커스텀 훅을 만들어야 할때가 있습니다. ts 던 tsx 던 똑같은 타입스크립트를 읽어들이는 파일이고 단지 tsx 확장자가 html의 태그와 같은 문법을 조금 더 쉽게 작성할 수 있을 뿐이에요 :) 두번째 질문은 공통된 로직을 언제 추상화(혹은 분리) 시킬것인지에 대한 고민이시군요 🤔 해당문제는 저도 개발하면서 항상 신경쓰이는 문제입니다. 보통 아래의 두가지 상황에서 해당 문제를 고민하는 편인데요. 1. 추후에 다른 컴포넌트에서 재사용이 될것 같아서 미리 추상화를 해두고 싶은 마음에 2. 특정 컴포넌트에서만 사용되는 훅 혹은 비즈니스 로직이 복잡하여 UI 로직과 분리하고 싶을때 질문자님께서 주신 상황은 (2)번에 해당할것 같네요 ㅎㅎ 제가 많이 존경하는 개발자님께서 미래를 예측해서 코드를 분리하는건 많은 경험과 노하우가 있어도 어렵다고 하셨습니다. 그만큼, 해당 코드가 다시 사용될지 예측하기 어렵다는 이야기에요. 그래서 그분께서는 나중에 필요할때 코드를 분리해도 늦지 않는다. 재 사용이 될 때 분리해도 괜찮다고 하셨습니다. 물론, 개발에 있어서 정론은 없겠지만 커스텀 훅이라고 해서 무조건 비즈니스 로직을 별도로 분리해야할 필요는 없습니다. 프로젝트 디렉토리 관리 방법에 따라 무조건적인 커스텀훅으로의 분리는 오히려 유지보수를 어렵게 만들수도 있거든요. 만약, hooks 파일을 src하위에 만들고 모든 커스텀 훅을 모아서 관리중인 상황이 좋은 예시가 될것 같습니다. 무분별하게 쌓여버린 훅들은 어떤 파일에서 어떻게 활용되는지 구분도 어려워지고, 더이상 사용되어지지 않게된 훅들에 대한 관리도 잘 안되어지거든요. (누군가가 해당 훅의 출처 및 의존된 파일을 찾아보기 전까지 외롭게 묵혀가는 훅들이 생겨납니다 😂) 만약 비즈니스 로직 자체가 너무 복잡하여 코드 이해 및 가독성을 위해 분리가 필요한 시점으로 왔다면..! 아래의 방법을 시도해 볼 수 있을것 같아요. 1. 복잡한 로직 자체를 개선해본다. 2. 선언된 함수들을 index.fn.ts를 만들어 분리해본다. (ComponentA/index.tsx, ComponentA/index.fn.ts) 3. 만들어진 커스텀 훅을 src/hooks 경로가 아닌 ComponentA/hooks 경로에 생성한다. 가끔 원활한 코드 관리를 위해 특정로직을 별도의 파일로 분리하고 싶은 충동이 왕왕 듭니다. 그럴때 제일먼저 분리가 의미 있을지 고민해보고, 의미가 있는데 다른곳에서 활용이 안된다면 비슷한 도메인들끼리 폴더로 만들어서 사용및 관리를 하는것도 방안이 될 수 있어요. 이러한 개발방법 관련 키워드로 "도메인주도개발(DDD)"이 있으니 함께 찾아보시면 도움이 되실듯합니다 : )