[12월 5주차] 인스타그램 클론 코딩 (feat. 항해99 7주차 클론 코딩주차)

크리스마스 기념으로 젭에서 스케이트장을 만들어서 한번 타봤다!

1주일 늦게 쓰는 12월 5주차 WIL이다ㅎㅎㅎ 변명이지만 12월 4주차부터 5주차까지 정말 눈코뜰새 없이 코딩만 했다. 일주일중 딱 하루 쉬는 일요일은 또 휴식을 취하느라 바빴다. 그래서 1월이 되고 1주일이 더 지나서 쓰는 WIL이다. 항해 7주차에 해당하는 클론 코딩을 진행하였고, 우리조는 인스타그램을 클론 해보기로 하였다. 항상 스마트폰으로 써서 몰랐던 인스타그램의 UI들을 많이 알게 되었다. 특히나 모달창이 매우 많다는 것이다. 모달창이 한두개가 아니라 너무 많아서 portal이 아닌 그냥 컴포넌트로 모달창을 만들다 보니 어려운 점이 많았다. 그치만 또 나름대로 성공적으로 잘 완료하였다. 아래는 우리조의 최종적인 구현을 담은 유튜브 영상이다. 최대한 UI를 똑같이 구현하려고 노력하였다.

 

 

1. 모달창

인스타그램은 모달창이 매우 많다. 어느정도냐면 메인페이지와 마이페이지를 제외하고 거의 다 모달로 작동이 된다. 그런데 모달창은 한번이라도 만들어봤어야 말이다. 지금 생각해보면 portal이라는 것을 꼭 사용했어야했다. 처음에 호기롭게 그냥 컴포넌트로 모달을 만들다 보니, 이게 한 두개 만들 때는 괜찮은데, 개수가 너무 많아지다보니 모달끼리 z-index가 꼬이기도 하고 상세페이지 모달인데 뒤에 나와야할 게시물들이 막 올라오기도 하도 난리도 아니었다. 가장 큰 문제는 페이지 전환이 아닌 모달창이다보니, 상세페이를 눌렀을 때 해당 게시물의 postId가 넘어와야 하는데 모든 게시물의 postId가 넘어왔다는 것이다. 그치만 어찌저찌 작동은 되게 만들어놓았다. 또 다른 문제는 모달창이 많아 모달창 자식 컴포넌트를 타고 타고 들어갈 때가 있는데, 예를 들면 상세페이지에서 점3개 버튼을 눌렀을 때나오는 수정 및 삭제 버튼들이 나오는 모달창이다. 이렇게 모달 위에 또 모달 이렇게 되면, 모달끼리 자식 컴포넌트로 타고 타고 들어가다 보니 각각의 모달창들을  true, false로 끄고 띄우는 컨트롤이 매우 힘들었다. 다시한번 라이브러리의 필요성을 깨달았다.

위와 같이 나름의 로직을 짜보며 게시물 수정 모달창에 대한 로직을 짜보기도 했다. 특히 게시물 수정의 경우 모달창이 3개가 동원되어야하고, 데이터 수정 요청이나 모달창 끄기와 같이 해야 할게 많다 보니 이렇게 정리하고 코딩을 하니 나름대로 잘 되었다. 그리고 모달창의 순서 역시 처음에는 막 뒤죽박죽이어서 꼬이기도 하다보니 위와 같이 정리를 하고 z-index를 수정하여 해결했다.

 

또한 이 과정에서 css관련 지식도 얻게 되었다. 첫째로는 z-index는 엘리먼트의 position 속성이 static이 아닌 경우 효과가 나타나게 된다는 것이다. 실컷 z-index 설정했는데 왜 적용이 안될까 고민하다가 알게 된 것이었다. 그리고 또 한가지는 display가 flex인 경우에는 position 속성이 적용이 안되는 것이다. position이 작동하지 않아 그 이유를 몰랐는데, display를  flex로 해놓아서 그런 거였다.

 

또 디테일 페이지를 모달창으로 대체하니 생긴 문제가 디테일 모달창이 나올 때 이전에 클릭했던 게시물이 아주 잠시 먼저 나올 때가 있었다. 페이지를 열 때마다 같은 state를 사용하는 데, 그걸 모달창을 끌 때 그 데이터를 지우지 않았기 때문에 생긴 문제였다. 이는 cleanup 함수를 통해 해결하려고 시도했는데, 자꾸 타입 에러가 뜨고 시간도 부족해서 결국 해결하지 못했다.

 

 

2. 좋아요 기능

좋아요 기능의 경우 이번 프로젝트에서 가장 완벽하게 구현한 기능이었다. 거의 어디가서 좋아요 잘한다고 해도 될 정도다ㅎㅎㅎ 아래는 매니저님의 도움으로 작성한 대략적인 구조와 흐름 도식이다.

 

이 도식에서 변경된 부분이 많지만 결론은 모달을 누르기 전 main과 디테일 모달창의 경우를 통합하여, 서버로부터 받아온 좋아요 개수와 유저가 좋아요를 눌렀는지 여부를 나타내는 불리언 값을 useState로 저장해두었다가 유저가 좋아요를 눌렀을 때, 이 전에 좋아요를 눌렀는지 여부에 따라 하트의 모양과 좋아요 개수를 useState값을 변경하여 화면에서 하트 모양과 좋아요 개수를 변경되도록 하였다. 동시에 좋아요를 누를 때마다 하트 수정 관련 post요청을 해주었다. 그렇게 되면 서버 데이터는 좋아요를 누를 때마다 바뀔 것이므로 유저가 새로고침을 하거나 디테일 모달창을 눌렀을 때에도 바뀐 상태가 잘 나타나게 되는 것이다. 디테일 모달에서 좋아요를 누른 경우에는 메인으로 이동할 때 메인 게시물 get요청을 다시 함으로써 좋아요 데이터는 가장 최근의 상태를 유지할 수 있다.

 

 

3. 회고

전반적으로 핵심 기능 구현은 성공적이었고, 화면 구성은 최대한 동일하도록 노력하여 뿌듯하지만 한편으로 소셜 로그인과 무한 스크롤 기능을 구현해보지 못한 아쉬움이 남는다. 실전에서는 특히 무한 스크롤 기능을 구현해보고 싶다.