배포를 위한 PR

[Min9ithub]

🛠️ PR 유형

어떤 변경 사항이 있나요?

• FEAT: 새로운 기능 추가
• FIX: 버그 수정
• DESIGN: CSS 등 사용자 UI 디자인 변경
• REFACTOR: 코드 리팩토링
• COMMENT: 주석 추가 및 수정
• DOCS: 문서 수정
• BUILD: 빌드 부분 혹은 패키지 매니저 수정
• DELETE: 파일 혹은 폴더 삭제
• CHORE: 그 외 자잘한 수정

📝 요약(Summary)

• 변경 사항 및 관련 이슈에 대해 간단하게 작성해주세요. 어떻게 보다 무엇을 왜 수정했는지 설명해주세요.

📸스크린샷 (선택)

💬 공유사항 to 리뷰어

• 리뷰어가 중점적으로 봐줬으면 좋겠는 부분이 있으면 적어주세요.
• 논의해야할 부분이 있다면 적어주세요.
• ex) 메서드 XXX의 이름을 더 잘 짓고 싶은데 혹시 좋은 명칭이 있을까요?

🔗 Reference

• 해당 작업을 수행하며 참고한 Link를 모두 작성

✅ PR Checklist

PR이 다음 요구 사항을 충족하는지 확인하세요.

• 커밋 메시지 컨벤션에 맞게 작성했습니다.
• 변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트).

[github-actions]

🤖 Gemini AI 코드 리뷰

⚡ 렌더링 성능

• watch('description', '')를 사용하여 description 필드의 값을 추적하고 있습니다. description 값이 변경될 때마다 TeamNewPage 컴포넌트 전체가 리렌더링될 가능성이 높습니다. 이전 Controller를 사용했을 때는 render prop 내부만 리렌더링되어 렌더링 범위가 더 제한적이었습니다. FieldMaster 컴포넌트가 memo화 되어있지 않다면, FieldMaster 또한 불필요하게 리렌더링될 수 있습니다.

💡 코드 품질 개선

• 길이 제한 로직 중복 및 복잡성: description 필드의 길이 제한을 위해 maxLength: 200 HTML 속성, register의 onChange 내 setValue 호출, 그리고 validate 함수를 동시에 사용하고 있습니다.
  • maxLength는 브라우저 단에서 입력을 제한하지만, 붙여넣기 시에는 작동하지 않을 수 있습니다.
  • onChange에서 setValue를 호출하여 길이를 강제하는 로직은 react-hook-form의 내부 상태 관리와 충돌하거나 불필요한 리렌더링을 유발할 수 있습니다. 일반적으로 register의 rules만으로 유효성 검사를 처리하고, onChange에서 setValue를 직접 호출하는 것은 특별한 경우가 아니라면 피하는 것이 좋습니다.
  • validate 함수는 maxLength와 onChange 로직이 모두 적용된 후의 최종 값에 대해 검증하므로, onChange에서 이미 200자로 잘랐다면 validate는 불필요할 수 있습니다.
  • 이러한 로직들을 명확히 하고 중복을 제거하여 코드를 간결하게 만들 필요가 있습니다. maxLength와 rules만으로 충분한지, 아니면 붙여넣기 시의 동작을 위해 onChange 로직이 꼭 필요한지 검토해 보세요.
• Controller 재고: 외부 컴포넌트(FieldMaster)에 폼 필드를 연결할 때 Controller는 react-hook-form에서 권장하는 표준적이고 렌더링 최적화에 유리한 방법입니다. 현재 Controller를 제거하고 register와 watch를 조합하여 value를 제어하는 방식은 Controller를 사용하는 것보다 복잡하고 렌더링 성능 측면에서 불리할 수 있습니다. Controller를 다시 사용하여 FieldMaster에 field 객체를 전달하는 것을 고려해 볼 수 있습니다.

---

Gemini 2.5 Flash | Diff 크기: 3417 bytes