언젠가는 펼쳐 볼 아카이브

... 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를 타고 접근하는게 좀 더 좋아보입니다. 그리고 자원의 경로..

React 테스팅 코드 테스트가 필요한 경우 코드 작성 후, 원하는 대로 동작하는지 알려고 할 때 코드에 버그가 있으면 어떤 상황에서 버그가 발생하는지 확인할 때 코드를 리팩토링 한 후에, 원래대로 동작하는지 테스트할 때 리액트 앱의 컴포넌트가 늘어날 수록 컴포넌트끼리 서로 영향을 미치는 경우가 많아짐 특정 코드가 수정되면, 어떤 컴포넌트에서 에러가 발생할 수 있음 테스팅 코드 작성의 이점 언급한 상황들에 대한 테스팅 코드를 작성하여, 미연의 에러를 방지 TDD(Test Driven Development) 등의 방법론을 적용하여 생산성을 향상함 테스트가 늘어나면서 테스트 코드가 구현 코드에 대한 문서화가 됨 테스트가 용이하게 코드를 작성하여, 코드 품질과 신뢰성을 높임 mocking : 특정 동작을 흉내..