Replies: 3 comments
-
sprint-19-part3-7team/Taskify-Frontend#38 (comment) 그리고 리뷰 남겨주신 내용 중에 |
Beta Was this translation helpful? Give feedback.
0 replies
-
요런 느낌 으로 하시면 쓰는사람이 편하지 않을까 했습니다 ㅎ |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
타입정의는 구현한 Avatar 컴포넌트를 봐야 감이 올것같네용 좀있다 같이 보시죠 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment

Uh oh!
There was an error while loading. Please reload this page.
-
오늘 팀 미팅에서 타입 정의 방식에 대해 팀원들과 논의해보았는데
아직 어떤 방식이 효율적인 것인지 결론이 나지 않아 질문드립니다!
서버에서 전달받는 데이터를 보여주는 컴포넌트를 만들고 있습니다 (
Avatar 컴포넌트)Avatar 컴포넌트는
user/meapi에서 전달 받는 데이터 중 일부만 사용하고 있습니다!이 상황에서 타입을 어떻게 정의하면 좋을지 방식을 두 가지로 고민하고 있습니다.
1. 서버 DTO 전체 타입을 먼저 정의해두고, 컴포넌트에서는 Pick으로 필요한 타입만 가져오기
1번 방식은 서버와 타입 구조가 동일하고, 만약 api가 변경되면 타입 에러로 바로 파악할 수 있어서 장점이 있다고 생각했습니다!
타입 일관성도 높다고 생각했구요!
1번 방식에 고민되는 점은 저렇게 Pick으로 정의하게 되면 DTO 전체를 알아야 하고
괜히 더 복잡해지는건 아닌가 하는 고민이 되었던 것 같습니다!
2. 컴포넌트에서 사용하는 타입만 별도로 인터페이스로 정의하기
2번 방식은 타입이 중복되긴 하지만 바로 직관적으로 이해하기에는 좋은 것 같다고 생각했습니다!
1번 방식, 2번 방식 중 어떤 방식으로 타입을 정의하는게 좋을지 궁금합니다!
Beta Was this translation helpful? Give feedback.
All reactions