이번 주는 클론 코딩을 진행하는 주차였는데 우리 조는 유튜브를 주제로 했다.
지난주와 마찬가지로 프론트가 2명인 조로 배정이 되어 역할분담을 나눌 때
다른 프론트 팀원분이 post CRUD를 맡아보고 싶다 하여서 그 외의 기능은 내가 맡게 되었다.
조금 힘들었지만 저번주보다 꽤 많은 기능을 만져볼 수 있었다.
유튜브 클론코딩 맡은 기능들
✅ 로그인 회원가입
✅ 코멘트 기능 CRUD
✅ 검색 기능
✅ 좋아요, 싫어요, 구독
✅ 전체 뷰 CSS 작업 반응형으로 만들기
나를 힘들게 한 좋아요 기능...
첫날 다른 프론트분과 와이어 프레임을 짜는 동안 백엔드분들이 API를 전부 설계해 주셨는데 한번 훑어보고 궁금한 거 몇 개 물어보고 바로 작업에 들어갔다. 하지만 아뿔싸.. 요게 나중에 조금 문제였다.
좋아요, 싫어요, 구독이 전부 같은 로직이었는데
백에서 좋아요에 대한 상태를 true와 false로 체크를 하고 프론트에서 똑같이 그 값을 보내주기만 하면 되었길래 간단하겠지? 하고 안일하게 생각한 게 오산이었다...
likeCheck: false + false => likeCheck: true, likeCount +1
likeCheck: true + true => likeCheck: false, likeCount -1
백에서 설계해 주신 좋아요 로직은 대강 이렇고
나는 저 likeCheck api를 상위 컴포넌트에서 props로 받아서 useState를 이용해 버튼을 토글 할 때마다 그대로 서버로 보내고 난 뒤 반대 값으로 전환해 주었다.
또 좋아요 카운트 api는 게시물 조회 api에서 끌어다 쓰고있었기 때문에 새로고침을 하지 않으면 반영이 되지 않아 좋아요 리듀서에서 true일때 숫자 count + 1, false일때 count -1을 해주었다.
//likeIcon.js
const likeCheck = props.likeCheck
const [like, setLike] = useState(likeCheck)
const toggleLike = () => {
dispatch(postActions isLikeDB(like)
setLike(!like)
}하지만 여기서 문제점 1
나는 likeIcon을 따로 컴포넌트로 빼서 관리를 했기 때문에 likeCheck api는 props로 받아와서 관리했다. 하지만 useState로 관리하는 순간 값이 렌더링 되기 전에 불러와져서 undefind가 된 상태로 서버에 보내지고 있었던 것이다. 그래서 useState 값을 지우고 useEffect를 이용해 렌더를 시켜 보내봤지만 어째서인지 값이 계속 true로만 보내졌다...
결국 리듀서에서 likeCheck 값을 반대로 변환시키고 카운트를 시키는 방향으로 수정하였다.
//post.js
[IS_LIKE]: (state, action) =>
produce(state, (draft) => {
const { likeCheck } = action.payload
{
likeCheck
? (draft.detail = {
...draft.detail,
likeCheck: !likeCheck,
postLikeNum: draft.detail.postLikeNum - 1,
})
: (draft.detail = {
...draft.detail,
likeCheck: !likeCheck,
postLikeNum: draft.detail.postLikeNum + 1,
})
}그랬더니 잘 작동하는 좋아요...
나머지 싫어요 버튼과 구독 버튼도 똑같은 로직이었기 때문에 코드를 똑같이 수정하였는데 엥?? 이건 또 작동이 잘 안되는... 문제가 발생
이걸 계속 잡고 있기엔 벌써 배포 날이어서 일단 묻어두고 나중에 기술 매니저님에게 여쭤보기로 했다.
기술 매니저님은 이럴 경우 백에서 response로 countNum 정보도 같이 보내줘야 한다 했고 프론트가 이 데이터를 가공하지 않게끔 해야 한다고 하셨다. 지금 방식은 프론트가 리덕스 내에서 저 값을 가공하게 되면서 뭔가 계속 꼬이게 된 점이 문제점인 것 같다고 하셨다.
다른 기술 매니저님께도 슬랙으로 여쭤보았는데 이런 경우에는 좋아요와 좋아요 취소를 따로 api를 만드는 것이 restful한 방식이라 하셨다.
이래서 API설계가 중요하구나...
사실 백에서 보내주는 데이터 로직도 제대로 이해가 가지 않아 다른 프론트 크루원분들께 많이 여쭈어보고 도움을 받았다. true와 false 값으로만 좋아요를 관리하는 것은 프론트입장에서 조금 관리하기 까다롭다고 다들 말씀하셨고 이런 지점에서 설계할 때 프론트와 백 간에 많은 대화가 주고받아졌어야 하는 지점인데 그게 제대로 이뤄지지 않은 상태에서 작업이 진행되어 많은 시간을 할애해버린 것 같아 아쉽다.
배포 후 문제점
-
로그인을 하지 않은 상태에선 게시물 조회 부분 화면 정보가 불러와지지 않았다. 뭐가 문제지...? 싶었는데 게시물 조회 데이터는 헤더에 토큰을 담아 서버에 보냈기 때문에 토큰이 없는 상태에선 데이터를 받을 수 없었던 것이다...
바로 백분들에게 상황을 공유하고 토큰 없이도 조회가 가능하도록 변경하였다. -
포스트 수정이 제대로 되지 않음
폼데이터로 묶어서 보냈기 때문에 항목을 전부 수정해야 변경이 가능하다고 했다. 급하게 수정하기 버튼 옆에 데이터를 전부 수정해 달라는 안내 문구를 적어 넣었다. -
수정 삭제 버튼이 바로 뜨지 않음
로그인 후 메인 페이지로 이동할 때 새로고침을 강제적으로 해줘야 버튼이 보였다.
🧘♀️... ☕️
사실은 조금 힘들었던 한 주였다.
실력이 부족한데 많은 기능을 맡았던 점도 있었고, 전체적인 css까지 전부 도맡아서 진행했기 때문에 매일 꼴딱 밤을 샜다. 소셜로그인이나 모달창, 소켓같은 다른 추가기능도 시도해 보고 싶었는데 목표로 한 기능도 벅차 시도해보지 못해 아쉬웠다. 하지만 이번 경험을 통해 프론트를 주도해봤다는 경험과 백분들과의 조금 더 수월하게 소통하는 능력치가 조금 up 된 것 같아.. 많은 것을 배워간 한 주였던 것 같다.
