Pay it forward

일단 서버에서 불러온 게시물이 무한정 아래쪽으로 쭈~욱 달라붙는 상황. 게시물에 사진도 들어가고 엄청 많아지면...? 이렇게 하면 안 될 것 같다. 그래서 페이징 처리를 어떻게 구현할지 고민을 했다. 우리가 겪었던 상황과 문제는 백엔드를 맡아준 팀원들이 처음에 전체게시물 가져올 때, response로 "한 페이지에 띄울 게시물 수", 그리고 "총 페이지 수"를 알 수 있다는 것. 그리고 우리쪽에서 특정 페이지에 들어갔을 때 그 페이지 넘버를 보내주면 해당 페이지에 해당하는 게시물을 보내주도록 노력해보겠다는 것. 우리 백엔드를 믿으니까 분명히 해결할 것이라고 생각하고 기능을 구현한다 ㅋㅋ 위 두개의 상황을 가지고 우리 프론트엔드에서는 서버에서 받은 "총 페이지 수" 만큼 ui를 띄워서 유저가 언제든 다른 ..

백엔드 작업이 완료되고 mockAPI가 아니라 실제 서버에 axios요청을 하니 새로운 문제가 발견되었다. 위 사진은 addCommentDB 미들웨어의 내부이고 response가 200으로 들어왔을 때, addComment리듀서로 디스패치하는 부분이다. addComment리듀서에서는 기존의 댓글리스트 데이터를 찾아 데이터의 앞쪽에 끼워 넣어 동적으로 보이게 처리를 했다. 결과물을 확인하자. 새로고침 하지 않고 방금 생성한 댓글은 댓글 내용이 불러져서 미리 들어가 있지 않아서 수정란에 빈칸으로 나온다. 당연히 수정도 안된다. 이유를 찾아보니 이 부분에서 mockAPI로 작업을 할 때 댓글을 일단 상단에 띄울 생각으로 commentId를 Date.now()로 아예 큰 수를 만들어 넣었던 것이 문제였다. 새로..

일단 불러오고, 만들고, 지우는 기능까지는 꽤 쉽게 완성. 이제 수정을 하면 되는데 댓글 수정하기가 의외로 어렵다. 일단 ui를 어떤 식으로 해볼지 팀원 분과 상의해봤다. 팀원분이 다른 팀의 지인들과 대화를 해봤는데 해당 페이지에서 ui를 바꾸면서 동적으로 처리하기가 너무 어려워서 다들 모달을 사용했다고 한다. 좋은 방법이지만 지금까지 동적으로 잘 만들어왔는데, 갑자기 댓글 수정에서 모달 기능을 넣으려니 뭔가 개운치가 않은 기분 ㅠㅠ 계획을 이렇게 세웠다. 1. 일단 컴포넌트를 하나 더 만들어서 수정버튼을 누르면 나타나게 하자. 2. 그 안의 input창에는 기존에 작성했던 댓글이 들어있게 하자. 3. input을 바꾸고 수정버튼을 누르면 아래 목록에서 리액트스럽게 동적으로 변경 처리되도록 하자 edit..

협업다운 협업은 이번에 처음인 것 같다. 느낀점과 배운점, 궁금한점을 남긴다. 백엔드 분들과 협업을 하면서 느끼는 점은 진짜 API가 전부 라는것! 한번 API를 결정하고 나면 각자 기능을 완성할때까지 열심히 하면된다. 동시에 api를 바꿔야하는경우, 서로 업무가 늘어날 수 있기 때문에 아주 신중해야 한다는 것! 잘 만들어두면 편하게 할 수 있다. 왼쪽사진은 메인화면에서 받아오는 게시물 데이터이고, 오른쪽은 게시물 상세페이지에서 받아오는 상세게시물 데이터이다. 만약 최상위 컴포넌트 app.js에서 useEffect로 post데이터를 가져올때, post_content까지 받아왔으면 api가 하나 줄지 않았을까? 최상위컴포넌트에서 받은 데이터로 언제든 useSelector 훅을 이용해서 데이터를 가져오면되니..

리덕스에서 불변성을 유지해야 하는 이유가 궁금하여 수많은 블로그를 봤지만 거의 복붙에 불과.. 대체 불변성에 대해 왜 신경을 써야 하는지...? 블로그마다 등장하는 shallow equality는 대체 뭔지.. 한번 정리해보고자 한다. 리덕스에서 불변성을 유지해야 하는 이유는 데이터가 변경 되는 것을 감지하기 위하여 shallow equality 검사를 하기 때문. shallowCompare returns true if the shallow comparison for props or state fails and therefore the component should update. shallowCompare returns false if the shallow comparison for props and s..

앱의 사이즈가 커지고 컴포넌트의 관계가 점점 더 복잡해지면 state와 props로 상태관리를 추적하기가 매우 힘들어질 것 같다. 자식의 자식의 자식컴포넌트에서 데이터가 필요해서 부모의 부모까지 props를 전달해오면서 코딩할 생각을 하니 머리가 아프다. 그래서 리덕스가 필요하다. 리덕스는 스토어라는 곳에서 전역상태관리를 하기 때문이다. 전역상태관리란 그냥 모든state를 최신화해서 한곳에서 관리한다. 이렇게 이해하면 될 것 같다. 참 말이 어렵다. 지금부터 어려운 말은 빼고 흐름을 익힌다음 거기에 이름을 붙여보자. 스토어는 실제로 데이터를 가공하는 일을 하는 함수를 여러개 가지고 있다. 그리고 그 함수는 object형식의 데이터를 받아서 처리한다. 근데 매번 데이터를 보낼때 객체형식을 입력하려면 귀찮고..