언젠가는 펼쳐 볼 아카이브

... const CommentItem: React.FC = ({ item, onDelete }) => { const handleDelete = () => { onDelete(item._id); }; ... 함수 컴포넌트를 React.FC 로 타이핑한게 눈에 들어옵니다. 이전에는, 암묵적인 children 및 숫자나 문자를 반환하면 에러가 발생하였는데 이제는 괜찮아 졌습니다. 그런데, 여전히 제네릭이라던가 defaultProps 는 개선이 안된 것 같습니다 . 그리고 오히려 저 코드가 더 읽기 어렵게 만들수도 있기에, 우리에게 친숙한 props 에만 타입을 명시해주는 형태로 작성하셔도 됩니다. :) 참고링크 : )https://www.totaltypescript.com/you-can-stop-hating..

현재 프로젝트에서 동일하게 코드 컨벤션을 맞추기 위해 eslint와 prettier를 적용했습니다. 다수의 인원과 함께 프로젝트 작업을 하신다면, 코드 퀄리티를 위해 eslint 와 prettier 를 적용하는게 좋습니다. 컴포넌트 작성할때 함수 표현식으로 사용하기로 했는데, 선언식과 차이가 있을까요? 어떤 것이든 사용해도 상관은 없습니다. 다만 hoisting 이슈만 유의해서 사용해주시면 됩니다. 타입스크립트를 사용할때 유의점이 있을까요? 타입스크립트를 사용할 때, "모든 타입을 적어줄거야!" 보다는 타입 추론이 되는 것들은 작성하지 않아도 됩니다. 그래야 생산성도 올라가고, 흔히 말해 가독성도 좋아지거든요. 필요한 것에만 타입 선언을 하시면 됩니다. React Query 버전 관련 React Quer..

북마크 추가/삭제 API를 /users/:id/bookmarks로 잡았는데, 수정이 필요할까요? 데이터 스키마에서 User가 본인이 북마크한 리스트를 가지고 있으려고 bookmark라는 key를 넣어주고 API path를 이렇게 짰습니다. 좀 더 RESTful 한 방식을 고려한다면, 리소스 주체를 feed로 잡는 게 좋을 것 같습니다. 서버에서 api 경로를 나눌 수 있겠죠? feed, user 등등 이렇게 나뉠텐데.. 그렇다면 bookmark를 추가한다고 했을 때, feed 쪽으로 들어가는게 좀더 유용하지 않을까 싶습니다. bookmark를 추가했을 때 모든 정보를 저장하지 않고 feedId만 DB에 저장할것 같은데, 그럴거면 feed쪽 api를 타고 접근하는게 좀 더 좋아보입니다. 그리고 자원의 경로..

commit 등 관리할 때, 백엔드/프론트 엔드 별로 나눠서 레포를 관리하면 너무 번거로워져서 한 레포로 작업하려고 합니다. husky로 보려고 해도 애매한데요. 이렇게 적용하는게 맞을까요? 아니면 더 좋은 방법이 있을까요? 현재 구성한 구조는 client/ server에서 동일한 패키지를 사용한다고 했을 때, 각 폴더마다 중복되는 패키지가 설치가 될 겁니다. 저장소를 하나로 두고 구성한다는 것은 mono repo로 구성한다는 것이겠죠? mono repo를 구성한다는 것은 한 repogitory 안에서 client/server 를 구성하는 것이 아닙니다. yarn 또는 npm workspace 를 써서 구성하는 기술이 있습니다. 어떤 workspace를 쓰던 상관은 없지만 "왜 사용했는가"가 매우 중요합..