이 부분에서 직접 이벤트를 할당해주신 이유가 있을까요?

event를 직접 할당한 이유는 mousedown 이벤트 객체를 활용하기 위해서예요!

더 자세히 설명하면,

1. event.target을 확인하기 위해서
   : event.target은 사용자가 클릭한 HTML 요소를 참조해요.

2. 타입 안정성을 위해서 event에 MouseEvent 타입을 명시했어요.

따라서, event를 명시적으로 사용하지 않으면 클릭된 요소를 알 수 없어서 외부 클릭 감지 기능이 제대로 작동되지 않을 수도 있어요!

설명 감사합니다! 코드를 리뷰하면서 onBlur를 활용할 수 있지 않을까 생각도 해봤는데 onBlur를 포커싱이 불가능한 요소에 적용했을 때는 별도로 추가 처리가 필요해져서 onBlur의 의도와는 다르게 억지로 활용하는 느낌이라 다현님께서 구현한 방식이 더 괜찮겠다는 생각을 했습니다! 👍👍👍

오옹 감사합니다! 답변드리며 저도 더 공부되는 느낌이라 너무 좋습니다 👍🏻✨

요 형식도 rafce 형식으로 볼 수 있나요? 궁금해서 질문드렸습니다!

위 사진의 코드가 rafce (화살표 함수 + export default 컴포넌트명 형태) 스니펫이고, Pagination 컴포넌트도 동일한 형태로 작성했는데, rafce 형식으로 볼 수 있냐는 게 어떤 의미이실까요?

위처럼 컴포넌트명을 index 로 작성하지 않아서일까요?
Pagination 으로 하는 게 컴포넌트명을 명확히 할 수 있을 것이라 판단해서 index 로 작성했는데, 혹시 별로이실까요?

제가 질문이 모호했습니다..! React.FC가 활용된 컴포넌트들이 rafce 스니펫을 활용하는 것과 무관한 것인지 여쭤봤습니다!

React.FC 활용을 잘 안해봐서 일반 화살표함수로 활용하는 것과 React.FC로 선언하는 것에는 어떤 차이가 있는지도 궁금합니다!

const Comp1: React.FC<{ count : number }> = ({ count }) => {
  return ...
}

const Comp2 = ({ count } : { count : number}) => {
   return ...
}

아아 React.FC 사용하면 VS Code 내에서 타입 자동 완성과 타입 추론이 좀 더 정확하게 작동해서 넣어주긴 했어요. 단점으로는 children 속성이 강제적으로 포함되지만, 타입 정의가 표준화되는 이점이 있어서 적어줬어요.

필수적으로 필요한 건 아니긴 한데 혹시 별로시면 아래처럼 FC 들어가는 컴포넌트들 모두 수정할까요?

interface FilterDropdownProps {
  options: string[];
  selected: string;
  onChange: (value: string) => void;
}

const FilterDropdown = ({
  options,
  selected,
  onChange,
}: FilterDropdownProps) => {

해당 부분이 별로라기 보다 다현님께서 React.FC를 사용하시는 이유가 제일 궁금했습니다! 예전에 블로그 들에서 React.FC 사용을 지양해야한다라는 의견을 봐서 사용하시는 분 입장에서는 어떤 장점이 있는 지 궁금했습니다!

알아보니 단점으로 꼽아주신 children이 암묵적 타입으로 포함된다는 점도 해당 pr에서 개선된 것으로 보입니다.

정말 코드 포멧에 대한 취향차이로 느껴지는 부분이라 섣불리 어떤 부분이 더 분명하게 낫다라고 말쓰드리긴 어려운 면이 있다고 생각합니다.
저는 개인적으로 다른 코드 포멧에 대한 규칙들이 제 스스로 많이 못 지켜지고 있는게 보이다보니 이번 건에 대해서는 React.FC를 사용하지 않는 쪽으로 통일되는 것이 덜 부담스러울 것 같습니다!

네! React.FC 타입이 사용되는 모든 코드 수정했습니다!좋은 부분 짚어주셔서 넘 감사해요! 🫡✨
변경사항 마지막으로 확인 후, Approve 해주시면 Merge 진행하겠습니다 :)