[최권진] Sprint5 #122
[최권진] Sprint5 #122
Conversation
dongqui
left a comment
dongqui
left a comment
There was a problem hiding this comment.
권진님..! 그동안 많은 성취가 있으셨군요!? 👍 👍
기본적인 리액트는 익숙하신 것 같습니다.
이제는 재사용 가능한 공통 컴포넌트를 만들어보는 연습을 해보시면 좋을 거 같아요 :)
조금 더 깊이 있게 도전하고 싶으시다면, Select 같은 컴포넌트에 Compound Pattern을 적용해 보시는 것도 좋습니다~!
컴포넌트 분리 관련
Items 페이지의 컴포넌트가 너무 많이 쪼개진 것 같다는 생각이 듭니다. 구현하면서도 헷갈릴 때가 많았어요..
→ 가독성, 예측 가능성, 응집도/결합도 관점에서 적절하게 쪼갠 건지 피드백 부탁드립니다.
→ 굳이 분리하지 않아도 되는 컴포넌트가 있다면 지적해주시면 감사하겠습니다!
-> 저는 컴포넌트는 적절하게 잘 쪼개셨다고 생각합니다. :)
JSX도 깔끔하고, 기능에 맞게 유의미하게 나뉜 것 같아요. 다만 헷갈리다고 느끼셨다면, 상태 문제일 것 같습니다.
useAllProductsController의 경우 너무 과하게 추상화됐다고 생각합니다. 어떤 값들인지, 어떤 값들이 어떻게 쓰이는지 모두 가려져 있고, 코드를 파악하기 위해 한 뎁스 더 들어가야 합니다.
추상화에 정답이 있는 것은 아닙니다. 상황에 맞게, 혹은 팀 문화나 개인의 취향에 따라 많이 달라지긴 합니다.
다만 모든 것을 일단 치워버리는 것은 커스텀 훅의 대표적인 안티 패턴 중 하나입니다. 🤣 (의견 정도로 받아주세요! 틀렸다는 게 아니라, 주의할 점입니다~!)
네이밍 관련
일부 컴포넌트나 함수 네이밍이 애매하다고 느껴집니다.
→ 헷갈릴 수 있는 네이밍, 더 명확하게 개선할 수 있는 네이밍이 있다면 지적해주시면 감사하겠습니다.
-> 어떤 부분이 애매하셨나요? 🤣 저는 전반적으로 편안하게 봤습니다!
ErrorBoundary 사용
ErrorBoundary를 적용해보긴 했는데, 제가 적용한 방식이 맞는지 확신이 없습니다.
→ 실무에서 흔히 사용하는 구조인지, 보완할 점이 있는지도 궁금합니다.
→ ErrorBoundary가 만능이 아니라는 이야기도 블로그에서 봤던 것 같아서, 적용 위치나 방식에 문제가 있을지도 고민이 됩니다.
->
기본적으로는 잘 활용하셨습니다. :)
적용 범위나 방식은 서비스에서 추구하는 UI나 정책 등에 따라 달라질 수 있습니다.
<ErrorBoundary>
<BestProducts />
<AllProducts />
</ErrorBoundary>지금은 페이지 메인 부분 대부분을 감싸고 있는데, 이럴 경우 BestProducts에서만 에러가 발생해도 AllProducts에도 영향을 주게 되죠.
또한 페이지 이동을 시키기 때문에, 사용자 입장에서는 에러를 핸들링하기 불편할 수 있습니다. :)
에러 바운더리의 범위를 좁히거나, 페이지 이동이 아닌 다른 방법으로 핸들링하는 방식으로 대응할 수 있겠죠!
(이건 기술적이라기보다는 서비스 정책에 따라 달라질 수 있어요.)
또 추가적으로 해보시면 좋은 건, BestProducts에 이미 에러 관련 로직과 UI가 포함되어 있는 것으로 보입니다.
이미 ErrorMessage 컴포넌트를 만들어 두셨는데, 해당 컴포넌트를 fallback으로 활용하실 수 있어요.
<ErrorBoundary fallback={<ErrorMessage />}>
<BestProducts />
</ErrorBoundary>이렇게 하면 BestProducts 컴포넌트는 에러와 관련된 로직을 신경 쓰지 않아도 되겠죠!
(이렇게 하려면 지금처럼 try-catch로 에러를 잡는 대신, 에러를 ErrorBoundary로 보내야 합니다.)
react-error-boundary를 활용하면 좀 더 쉽게 구현 가능합니다!
상태관리 관련
현재는 Context API나 상태관리 라이브러리를 사용하지 않았습니다.
→ 제 코드에서 Context API를 사용했으면 더 좋았을 부분이 있었을까요?
→ 상태관리 라이브러리를 적용했어야 했던 부분이 있다면 알려주시면 감사하겠습니다.
->아직은 프로젝트가 복잡하지 않아서 굳이 안 써도 될 것 같습니다. :)
Tailwind CSS 관련
처음 Tailwind를 적용해봤는데 아직 tailwind.config.js 활용이 어렵습니다.
→ 효율적으로 사용하는 팁이나, 실무에서 많이 쓰는 설정 방식이 있다면 알려주세요!
→ 더 잘 사용하는 방법이 있다면 공유 부탁드립니다.
특별한 방법이 따로 있지는 않습니다. (혹시 찾으면 공유드릴게요. 🤣)
지금은 아직 디자인 토큰이 많지 않아서 tailwind.config.js를 적극적으로 확장할 필요는 커 보이지 않아요.
굳이 추가한다면 colors 정도 확장하거나, Arbitrary values 사용을 줄이는 방향 정도가 있을 것 같습니다.
다만 지금 설정이 복잡하게 느껴지셨다면, 그 이유는 오히려 컴포넌트 단위의 스타일 관리 때문일 수도 있어요.
이럴 땐 먼저 UI를 React 컴포넌트 단위로 먼저 구현해 보시고, 꼭 재사용 해야하는 스타일만 css단에서 만드시면 좋을 거 같습니다! 또, config에 모든 스타일을 넣기보다는, @apply와 함께 적절히 역할을 나누는 게 유지보수에 더 좋습니다. :)
4 participants
요구사항
체크리스트 기본
중고마켓
반응형
체크리스트 [심화]
주요 변경사항
멘토에게
컴포넌트 분리 관련
Items 페이지의 컴포넌트가 너무 많이 쪼개진 것 같다는 생각이 듭니다. 구현하면서도 헷갈릴 때가 많았어요..
→ 가독성, 예측 가능성, 응집도/결합도 관점에서 적절하게 쪼갠 건지 피드백 부탁드립니다.
→ 굳이 분리하지 않아도 되는 컴포넌트가 있다면 지적해주시면 감사하겠습니다!
네이밍 관련
일부 컴포넌트나 함수 네이밍이 애매하다고 느껴집니다.
→ 헷갈릴 수 있는 네이밍, 더 명확하게 개선할 수 있는 네이밍이 있다면 지적해주시면 감사하겠습니다.
ErrorBoundary 사용
ErrorBoundary를 적용해보긴 했는데, 제가 적용한 방식이 맞는지 확신이 없습니다.
→ 실무에서 흔히 사용하는 구조인지, 보완할 점이 있는지도 궁금합니다.
→ ErrorBoundary가 만능이 아니라는 이야기도 블로그에서 봤던 것 같아서, 적용 위치나 방식에 문제가 있을지도 고민이 됩니다.
상태관리 관련
현재는 Context API나 상태관리 라이브러리를 사용하지 않았습니다.
→ 제 코드에서 Context API를 사용했으면 더 좋았을 부분이 있었을까요?
→ 상태관리 라이브러리를 적용했어야 했던 부분이 있다면 알려주시면 감사하겠습니다.
Tailwind CSS 관련
처음 Tailwind를 적용해봤는데 아직 tailwind.config.js 활용이 어렵습니다.
→ 효율적으로 사용하는 팁이나, 실무에서 많이 쓰는 설정 방식이 있다면 알려주세요!
→ 더 잘 사용하는 방법이 있다면 공유 부탁드립니다.
기초 프로젝트가 끝나고 나태해졌다가 시간에 쫒겨서 급하게 진행하다보니 아쉬운 부분이 많습니다.
→ 앞으로 계속 리팩토링 하면서 개선할 예정인데, 우선 지금 구조나 흐름에서 가장 아쉬운 부분이나 우선적으로 고치면 좋을 점이 있다면 알려주세요!