Nomadcoder React Study 4기 React 졸업작품 회고

노마드코더 리액트 스터디 4기의 "React Master Course" 졸업작품에 대한 느낀점을 적어보려고 한다.

지금 시간이 오전 1시 58분인데, 자고나면 지금 감정이나 생각을 다 까먹을게 분명하기 때문이다ㅋㅋ

리콰이어먼트는 framer motion을 사용해서 애니메이션을 구현하고, movie api를 사용해서 영화 정보를 보여주는 spa를 만들면 되는 아주 간단한 스펙이었다.

어떻게 구현을할까 고민하다가, 작년에 리액트를 처음 배웠을때 만들었던 "쿠팡 플레이"를 다시 한번 만들어 보자라고 생각했다.

리액트를 처음 배웠을때의 결과물과, 지금 내가 만든 결과물을 비교해보면 스스로 성장했는지, 퇴보했는지 또 얼만큼 성장 혹은 퇴보를 했는지 나름 객관적으로 비교할수 있을거라고 기대했기 때문이다.

결과먼저 말하자면, 리액트를 처음 배웠을때 만든 쿠팡플레이보다 만족스럽지 못한 결과물이 나왔다ㅋㅋ

다 갈아엎고 새로 짜볼까도 싶었는데, 도저히 남은기간 하루만에 새로 구현할수 있겠다는 자신이 없었다.
(진짜 GC돌때 내 코드도 통째로 갖고가라고 하고싶다, 쓰레기 코드다 쓰레기🗑️;;)

2023년 8월 1일 JS, React 태어나서 처음배우고 만든것

약 8개월 지난 현시점에서 만든것

(회원가입도 가능하도록 간단한 DB도 만들어서 배포했다)

8개월전 JS, React를 처음 배우고 만든결과물 대비 달라진점들은 아래와 같다.

• 간단하게 회원가입할수 있는 serverless DB 배포 및 연동한점
• 3rd party css library를 사용해 style component 대비 작업속도가 빨라진점
• modal, toast 자잘한 잡기술 추가된점?
• React Suspense 사용해본점
• 좀 더 많은 api를 사용해본점
• (tanstack query, react router dom의 version up에따른 문법변화는 제외)

이 외에는 사실상 8개월전 결과물과 비교했을때 달라진게 없다.

사실 쿠팡플레이를 클론한거니까, 쿠팡플레이가 그만큼 큰 변화가 없었다고 생각하는게 맞을까?

여튼저튼 리액트를 처음배우고 나서 만든거와 달라진점들과, 이번에 어떤의도를 가지고 접근을했고, 그 결과 어떤 봉변을 당하면서 삽질을하고 다시는 이러지 말아야겠다라고 느낀점들을 풀어보려고 한다.

---

8개월전 대비 구현하면서 달라진 점

첫번째, 먼저 간단하게 회원가입수 있는 serverless DB를 배포하고 연동해봤다.

8개월동안 Google Firebase도 몇번 사용해봤고, Django도 배워봤다(이건 진짜 배워만봄).

사실 Serverless인 Firebase가 빠르게 필요한 부분만 구현하고 프로젝트에 접목시킬수 있어서 편하긴하지만, 이번에 진행하는 졸업작품에서는 email / username만 쌍으로 기억하면 되기때문에 굳이 firebase까지 사용해야하나? 라는 의문이 들었다.

그래서 어떻게 하면 좋을까~~~ 하다가 CloudFlare를 이용해서 간단하게 serverless db를 만들었다.

정말 간단하게 GET request로 계정생성 및 유저정보를 갖고오는걸 구현했다.

원래라면 POST requeset로 계정을 생성해야겠지만, 진짜진짜 너무 간단한 DB라고 생각이 들어서 GET reuqest만으로 모두 대체해버렸다.

그리고 배포해서 사용하는데, CORS 에러때문에 월요일부터 시작해서 화요일 8시쯤에 해결했다.

진짜 별것도 아닌 문제였는데 삽질하는 바람에 시간을 많이 빼았겼다.

아마 CORS 에러 수정하는거랑, 페페 + 토끼 + 피카츄 + 도라에몽 + 쿠로미 텍스트로 노가다한게 월요일~화요일 8시까지의 시간을 다 잡아먹지 않았을까 싶다.

아! 추가적으로 정말 간단한 DB로 구성했기 때문에 user로부터 입력받은 email이 valid한지 확인하는 로직은 없다.

firebase나 django를 사용했으면 쉽게 구현했을법한데, 일단 없이했다.

두번째, 3rd party css library를 사용해 style component 대비 작업속도가 빨라진점

8개월전 처음으로 리액트로 작업물을 만들때는 styled components를 사용했고, 결과물을 완성시키는데 2주일이 걸렸다. (그때 챌린지 기간이 2주였고, 거의 2주를 꽉채워서야 완성시켰던 기억이다.)

이번에한 작업은 4일 걸렸다. 14일대비 4일이면 3배이상 결과물을 만드는데 빨라졌는데, 영타속도가 올라간걸까?ㅋㅋ

모든 공학은 trade off라고 생각하는데, tailwind 기반의 3rd party css library 덕분에 css작업 속도가 엄청 빨라짐과 동시에 기본적으로 제공하는 컴포넌트들이 많아서 적재적소에 빠르게 사용하기에도 좋다.

display: flex, justify-content 이런것들을 최대한 타이핑을 적게할수 있고, spinner 같은것들도 바로 갖다 사용할 수 있으니 편하긴하다.

다만 재활용성이 조금 떨어진다는 느낌을 받았다.
물론 이것도 해결할수 있기는 하지만, 공수가 더 들어가는데 3rd party library 사용 이점이 희석되는 기분이랄까?

그것보다 더 큰 문제라고 생각되는 부분이 코드의 가독성이 너무너무너무 떨어졌다.

동시에 styled component를 사용할때는 변수의 이름을(Container라던지?) 직관적으로 내가 정해줄수 있어서, return문 내부만봐도 어떤식으로 화면을 그려주겠구나? 라는 roadmap이 머릿속에서 좀 더 빠르고 쉽게 그려졌다.

하지만 3rd party library를 사용할때는 정해진 이름만 사용해야한다는게 단점이었다.

<Box
    key={index + startIndex}
    h="100%"
    borderRadius="5px"
    bgSize="cover"
    bgPosition="top center"
    bgImage={`url(${backdropParser(
             imageDatas[index + startIndex] as any,
               movie.backdrop_path,
               movie.poster_path
	)})`}
    _hover={{
      cursor: "pointer",
      transform: "scale(1.2)",
      zIndex: "99",
      }}
    transition="all 0.2s linear"
    onClick={() =>
      	onMovieClick(
          movie.title,
          index + startIndex
        )
    }
/>

일단 개인적으로는 tailwind보다는 보기에는 더 편하지만, 필요한 prop들을 저렇게 나열하다보면 결국 코드가 엄청 길어지는건 마찬가지였다. (가로로 길어지냐, 세로로 길어지냐의 차이같다랄까??)

동시에 어떤 역할을 하는지 바로 유추하기가 어렵다. (위의 경우는 onClick이 있는것을 보고 "clickable한 image를 갖고있는 무언가" 이겠구나 생각이 가능하다만, onClick도 없다면 2시간 이후에 보면 이게 뭐지...? 하게된다.)

근데 또 3rd party css library를 사용함으로써 기본으로 제공해주는 기능들이 너무 강력하다ㅠ
modal, toast, acodian, spinner 등등등 내가 직접 구현하기에는 시간과 노력이 많이 들어가는것들이 default로 사용가능한건 너무나도 강력한 장점이라고 생각한다.

그래서 일단은 어떤걸 사용해야 편하면서 가독성도 좋을지 고민을 계속 해봐야할것 같은데, 결국 tailwind를 사용하지 않을까 라는 생각이 든다...NextJS...

세번째, React Suspense 사용해본점

사실 이번 졸업과제를 하면서 가장 사용해보고 싶었던 기능이 바로 Suspense였다.

tanstack query의 useQuery를 사용하면 isLoading(혹은 버전에 따라서 isFetching)값을 통해서 화면에 표시하는 컨텐츠를 다르게 그려줄수 있다.

return (
  	{query.isLoading ? <h1>Loading</h1> : <h1>Done</h1>}
)

혹은 아래와 같은 방식으로도 표현할수 있을것 같다.

export default function Something() {
  	if(query.isLoading) {
      	return <h1>Loading</h1>
    }
  	return <h1>Done</h1>
}

어떤식으로 표현하던지 내가 마음에 들지 않았던 부분이 바로 컴포넌트 내부에서 useQuery를 통해서 받아온 data의 상태가 undefined일 가능성이 있기때문에 Query의 상태(loading or not)를 확인해서 Loading 중일때는 이거, Loading이 끝나고 data를 받아오면 이거, 이런식으로 state에 따라 각각 다른 화면을 렌더링 해야한다는것 이었다.

그래서 Suspense를 꼭 사용해보고 싶었다.
(평소에는 api를 통해서 데이터를 요청하고 받아올 일이 없었기에 Suspense를 사용해볼일이 없었고, 8개월전에 리액트를 처음 배울때는 Suspense라는게 있는지도 몰랐다.)

그리고 사용했다, 아주 많이, 결과적으로 오남용했다. ㅋㅋㅋ

그래도 새로운걸 사용해볼수 있어서 좋았다.

일단 Suspense와 fallback을 사용하니 query의 state고려할 필요가 없어져서 좋았다,

또 그로인해서 Loading state에 대응할 부분을 data를 표현할 부분에 작성하지 않아도 되어서 코드를 작성이 한결 수월했다.

동시에 fallback에 사용할 컴포넌트를 재활용할수 있어서, api request url이 달라서 rendering되어야 하는 위치는 다르지만, interface의 format은 유사한 컴포넌트에 추가적인 fallback 컴포넌트를 새로 작성해야할 필요가 없어졌다.

여로모로 사용해봐서 좋았다.

아!! 기존에 사용하던 react-query의 버전이 너무 낮아서 suspense를 지원하지 않았다.

그래서 최신버전으로 업데이트했더니 isLoading을 사용하는 부분들이 모두 에러가 발생했다.
(보통 button에다가 user에게 "지금 너의 요청을 처리하고 있어~"라고 알려주고 싶어서 loading중일때 spinner가 돌아가도록 구현한다.)

그래서 왜그러지~ 하고 한 30분을 찾아봤는데, 이름이 isLoading에서 isFetching으로 바뀌었다.
그러면서 tasnstack query doc을 V5를 안보고 V4를 보면서, "왜 에러야 ㅡㅡ" 이러면서 짜증을 냈었는데 추후에는 문서를 찾아볼때도 버전부터 맞는지 체크해봐야겠다.

동시에 아쉬운 부분은 ErrorBoundary를 사용해보지 않은게 후회된다.
써볼까? 라고 생각했지만, api response가 항상 status 200을 반환했었기 때문에 "Requirements에도 없고 귀찮은데 나중에 해보지뭐~" 하고 넘겼다.
근데 이게 나중에 큰 업보로 돌아올줄 몰랐다...ㅋㅋ 후...

네번째, 좀 더 많은 api를 사용해본점

지금 생각해보니 "좀 더 많은 api" 라는 말이 너무 거창해보인다.

8개월전대비 더 사용한 api라고는 movie / tv의 detail image를 받아볼 수 있는 api를 하나 더 사용했다.

위 이미지를보면 알수있지만, 8개월전에 구현한 결과물에서 보여주는 영화들의 사진에는 "타이틀"이 없는 그냥 이미지만 보여주고 있다.

예를들어서 톰크루즈 사진은 있지만, "미션임파서블" 이라는 제목이 포스터에는 없었다.

하지만 이번에 구현할때는 detail images를 받아와서 english title이 포함된 image가 있다면, 해당 이미지를 보여주도록했다.

그래서 최상단에 위치한 Main Banner의 쿵푸팬더 이미지와(로고와 버튼은 별개로), "곧 찾아올 영화"에 위치한 쿵푸팬더의 이미지가 다른 이유이고, 사진만 보고 어떤 영화인지 알 수 있도록 했다.

---

어떤의도를 가지고 과제를 시작했는지?

시작하기 이전에 대충 막 휘갈기면서 낙서하듯이 필요한거를 몇개 적어봤었다.
글씨를 또박또박 적으면 손도아프고 어차피 나만 볼꺼니까 진짜 휘갈겼더니 엉망인거같다ㅋㅋ
다음엔 좀 또박또박 적어야겠다.

여튼 정리하면 과제를 시작하기 이전 처음에 생각했던 내용들을 추려보면 아래와 같다.

1. Movies / TV Shows / Search / My List / Share버튼 클릭시 URL 클립보드로 복사 기능 구현
2. Email, Name으로 User를 회원가입 및 로그인 기능 구현
3. 재생하기 버튼을 눌렀을때 Youtube Video가 Play되도록 구현
4. User가 로그인한 이후 Page Refresh를 진행해도 Login 상태가 유지되도록 구현
5. Login한 이력이 없는 User가 URL을 직접적으로 조작해서 Movie / TV Show Router로 접속할때 Login Page로 Redirection 구현
6. Movies / TV Show 각각 4개의 카테고리만 존재했는데(now playing, upcomming, top rated, popular 이런식) 그 이상의 컨텐츠를 보여주고 싶었다.
   그니까 Movies / TV Shows 페이지에서 4개의 카테고리가아닌 8개정도의 카테고리를 보여줘서 컨텐츠가 풍부하고 더 많은 카테고리가 있는것처럼 보여주고 싶었다.
7. User가 초기 1회 Login한 이후 어떠한 컨텐츠를 클릭해도 더 이상의 추가 Loading없이 immediately하게 모든 data를 표현하도록 구현 (이땐 이게 독이될지 몰랐지..ㅋㅋ)

그리고 코드를 작성하면서 중간에 detail image의 response를 다시 확인해보고, logo image와 title이 들어간 back image를 갖고와서 사용하도록 추가했었다.

---

삽질, 봉변, 느낌점

위에 작성한 7가지 항목들을 구현하는데 어려움은 없었다.
말 그대로 구현은 어렵지않게 했다. 다만 그 과정에서 테스트를 하지 않았다.

무슨말이냐? 실제로 api를 사용해서 data를 잘받아오는지 초반에 확인하고, 그 이후에는 api를 사용하지 않고 dummy data를 사용해서 필요한 컴포넌트들 구현에 집중했다.

Header, Footer, Skeleton, Main Banner, Slider, Detail Page, Information Summary, etc...

필요한 컴포넌트를 모두 다 만들고나서 Movies / TV Shows에 각각 8개의 카테고리를 보여주도록 페이지를 구성하고 api를 붙혀서 테스트 해봤다.

그리고 오~ 사진 잘 보이네! 애니메이션도 잘 되네~ㅎㅎ 하고 중간에 위치한 영화의 detail 정보가 잘 나오는지 확인하려고 클릭하는 순간 list에서 filter 메소드를 사용하려고 하는데 사용할 수 없다는 에러와 함께 런타임중에 뻗었다 ^^

그래서 아ㅡㅡ 뭐야 무슨소리야 하고 보니까 list로 들어와야할 데이터가 undefined였고, 그제서야 개발자도구를 열어서 콘솔창을 열어봤다.

ㅋㅋㅋㅋ 무슨 제철딸기 만큼이나 시뻘건 콘솔창이 날 반겨주었다.

그리고 저 에러들을 금요일 오후 5시쯤 확인을했었고, 토요일은 코딩을 못하는데... 일요일 하루만에 처음부터 새로 짤 수 있을까? 라는 생각이 들면서 아 이거 어찌하면 좋을까...🤦‍♂️ 하면서 찾아봤다.

먼저 status code 429를 돌려줬는데, 해당 코드가 뭘 의미하는지 먼저 찾아봤다.

출처: MDN

너무 많은 request를 보내서 그렇다는걸 알았다.

그리고 그제서야 아!!!!? 하면서 생각났다.

무료로 사용하는데 얼마나 많은 request를 보낼수 있는지 확인하지 않고 그저 요청하는대로 알아서 잘 주겠지~~ 하고 있었다. 🤨
진짜 지금 생각해도 멍청한거같다, 그리고 ErrorBoundary를 사용안한거도 후회됐다.

여튼 그래서 바로 TMDB의 문서를 뒤적뒤적 거려봤는데 아래와 같이 적혀있었다.

Rate Limiting

While our legacy rate limits have been disabled for some time, we do still have some upper limits to help mitigate needlessly high bulk scraping. They sit somewhere in the 50 requests per second range. This limit could change at any time so be respectful of the service we have built and respect the 429 if you receive one.

User가 초기 1회 Login한 이후 어떠한 컨텐츠를 클릭해도 더 이상의 추가 Loading없이 immediately하게 모든 data를 표현하도록 구현

여기에만 매몰된채 무지하게 그냥 필요한 requests를 모두 날렸다.

그리고 그제서야 내가 얼마나 많은 requests를 보내는지 확인해봤다.

• Movies / TV Shows에는 각각 8개의 Rows가 있다. (8개의 Categories)
• 그리고 각각의 Row에는 20개의 contents가 들어있다. (TV or Movie)
• 그리고 각각의 content는 detail, video, image, credit 정보들이 필요해서 총 4개의 요청을 보낸다.
  Detail => Runtime정보 및 Genres 정보
  Video => Official Youtube Video Key 정보
  Image => Logo Image 및 English Title이 포함된 Backdrop Image
  Credit => 출연한 배우들 및 Genres 정보

따라서 8개의 Rows X 20개의 contents X 4개의 extra information X 2개의 page = 1,280이라는 결론이 나온다.

즉 Movies or TV Shows page로 이동하면 640번 requests를 보낸다. ㅋㅋㅋ

또 Movies and TV Shows page한테 context로 넘겨줄 8개의 Rows에 보여질 정보가 필요하기때문에,
맨처음에 16개의 requests도 보낸다.

여튼 무자비하게 무지하게 requests를 보내고있다는걸 알았다.

8개월전에 만들때는 detail page로 이동하면, 그때 id를 기준으로 필요한 정보들만 다시 받아오기 때문에 user가 loading되는 과정을 기다려야 하지만 429에러를 볼 일이 없었다.

그래서 이번에는 user가 초기 1회 이후에는 loading을 기다리는 일이 없게 만들어야지! 라고 했던거였다.

그리고 다 지우고 새로짤 시간도 자신도 없었기에 어떻게하면 이 에러를 피해갈수 있을까 고민하기 시작했고,
결과적으로 무식하게 delay를 모든 api request에 추가했다....🤯

그 결과 아래와같은 무시무시한 side effects가 날 반겨주었다 ㅋㅋ🤪

• login 이후 movies page로 redirect된다. 따라서 16 + 640 = 656번의 requests를 보낸다.
  그래서 login 이후에 user가 Moives page를 제대로 보려면 약 40초가량 로딩시간이 필요해진다.
• 그 이후에 TV Shows page로 넘어가면 위의 로딩시간이 또 추가로 필요해진다.
• 내가 찜한 목록으로 이동하면, 내가 찜한 id를 기반으로 또 추가적인 정보를 요청하기에, 대략 N * 5초의 로딩시간이 또 추가로 필요해진다.
• delay를 줘도 여전히 에러가 간헐적으로 나와서 Movies / TV Shows의 카테고리를 8개에서 7개로 줄였다.
• search page로 이동하면, Movies, TV Shows, 찜한 리스트 이 3개 페이지의 쿼리를 사용하는 컴포넌트들이 언마운트가 되면서 캐시된 쿼리가 날라간다.
  그래서 search page를 다녀오면 위의 로딩과정을 모두 다시 거쳐야한다.
• search 결과를 보여줄수는 있지만, 해당 결과물의 detail한 정보는 볼 수 없다.
  결과적으로 detail한 정보는 초기에 loading된 contents들만 볼 수 있다.
  왜냐면 필요한 정보들을 slider를 그릴때 fetch하는데, search된 결과물은 그렇게할수 없기에 그냥 결과만 뿌려줬다. (예전처럼 id를 확인해서 필요한거를 요청하는 구조라면 상관없지만, 이미 초기에 모든 정보를 다 fetch하고, 그걸 그냥 뿌려주도록 해둬서 새로운 contencts들은 그렇게 할 수 없었다)

한마디로 최악이다.

그래도 이번에 삽질하면서 내가 얼마나 무능한지, 내가 얼마나 부족한지, 프로젝트 기획의 중요성, 테스트는 가능하면 많이 등등을 다시 느꼈다. (테스트를 계속하면서 콘솔을 모니터링했더라면, 조기에 구조를 바꿀수 있었을텐데... 라는 생각?)

그리고 가장 크게 새롭게 느낀점은 디자인 패턴의 필요성이었다.

사실 여태까지 했던 코드챌린지 과제들은 규모도작았고, 다뤄야하는 데이터의 양도 적었다.
그래서 UI를 렌더링하는 컴포넌트에서 data를 fetch하고 조작해도 코드의 양이 작았다.

여튼 이번에 작성한 코드들도 기존과 마찬가지로 UI를 Rendering하는 컴포넌트에서 data fetch와 data 가공 그리고 data redering까지 이루어졌고

그 결과

• 코드가 더러워졌다. 진짜로
• 내가 내 코드를 보는데 멀미가 났다.
• 코드가 불필요하게 길어졌다.
• data를 직접 fetch하고 가공하다보니 컴포넌트 재사용이 불가능해졌다.
• 재사용이 불가능하니, 비슷한 기능을하는 컴포넌트들이 우후죽순으로 생겨났다.
  (사실 movie와 tv를 각각 따로 만들 필요가 없지 않은가? 하지만 난 따로 만들어야했다...)
• 우후죽순으로 생겨나니 프로젝트 관리와 유지보수 및 수정에 들어가는 비용이 늘어났다.
  (뭐하나 작은거 수정 / 추가해도 여기저기 전부다 건들여야했고, 실수로 하나만 빼먹어도 동작이 어긋났다)

위와같은 불편함들을 정말 정말 많이 느꼈다.

실제 폴더 구조

📦src
┣ 📂components
┃ ┣ 📂banner
┃ ┃ ┣ 📜MovieBanner.tsx
┃ ┃ ┣ 📜Summary.tsx
┃ ┃ ┣ 📜TVBanner.tsx
┃ ┃ ┗ 📜style.ts
┃ ┣ 📂detail
┃ ┃ ┣ 📜LikeButton.tsx
┃ ┃ ┗ 📜ShareButton.tsx
┃ ┣ 📂footer
┃ ┃ ┣ 📜Information.tsx
┃ ┃ ┣ 📜LinkButton.tsx
┃ ┃ ┣ 📜Policy.tsx
┃ ┃ ┗ 📜SNS.tsx
┃ ┣ 📂genre
┃ ┃ ┣ 📜GenreCategories.tsx
┃ ┃ ┗ 📜category.ts
┃ ┣ 📂home
┃ ┃ ┣ 📂skeleton
┃ ┃ ┃ ┣ 📜CategorySkeleton.tsx
┃ ┃ ┃ ┣ 📜MainSkeleton.tsx
┃ ┃ ┃ ┣ 📜OneLineSkeleton.tsx
┃ ┃ ┃ ┗ 📜VideoSkeleton.tsx
┃ ┃ ┣ 📜CategoryButton.tsx
┃ ┃ ┣ 📜Header.tsx
┃ ┃ ┗ 📜HomeSkeleton.tsx
┃ ┣ 📂login
┃ ┃ ┣ 📂Account
┃ ┃ ┃ ┣ 📜LoginModal.tsx
┃ ┃ ┃ ┣ 📜ModalButton.tsx
┃ ┃ ┃ ┣ 📜RegisterModal.tsx
┃ ┃ ┃ ┗ 📜UserInput.tsx
┃ ┃ ┣ 📜AdBanner1.tsx
┃ ┃ ┣ 📜AdBanner2.tsx
┃ ┃ ┣ 📜IconAndTitle.tsx
┃ ┃ ┣ 📜LoginBanner.tsx
┃ ┃ ┣ 📜LoginButton.tsx
┃ ┃ ┣ 📜QnA.tsx
┃ ┃ ┗ 📜TopShadow.tsx
┃ ┣ 📂mylist
┃ ┃ ┗ 📜MyListSkeleton.tsx
┃ ┣ 📂search
┃ ┃ ┣ 📜Content.tsx
┃ ┃ ┣ 📜ContentGrid.tsx
┃ ┃ ┣ 📜GenreGrid.tsx
┃ ┃ ┣ 📜SearchInput.tsx
┃ ┃ ┗ 📜SearchSkeleton.tsx
┃ ┣ 📂slider
┃ ┃ ┣ 📜MovieSlider.tsx
┃ ┃ ┣ 📜TVSlider.tsx
┃ ┃ ┗ 📜style.ts
┃ ┗ 📂top20
┃ ┃ ┣ 📜MonoplyBadge.tsx
┃ ┃ ┣ 📜MovieTop20.tsx
┃ ┃ ┣ 📜NewestBadge.tsx
┃ ┃ ┣ 📜RankPoster.tsx
┃ ┃ ┣ 📜TVTop20.tsx
┃ ┃ ┗ 📜style.ts
┣ 📂global
┃ ┣ 📜api.ts
┃ ┣ 📜apiResponse.ts
┃ ┣ 📜genres.ts
┃ ┗ 📜projectCommon.ts
┣ 📂pages
┃ ┣ 📂common
┃ ┃ ┣ 📜Footer.tsx
┃ ┃ ┣ 📜Layout.tsx
┃ ┃ ┗ 📜NotFound.tsx
┃ ┣ 📜Detail.tsx
┃ ┣ 📜HomeLayout.tsx
┃ ┣ 📜Login.tsx
┃ ┣ 📜Movies.tsx
┃ ┣ 📜MyList.tsx
┃ ┣ 📜MyListLayout.tsx
┃ ┣ 📜NotSuppot.tsx
┃ ┣ 📜Search.tsx
┃ ┣ 📜SearchLayout.tsx
┃ ┣ 📜SearchResult.tsx
┃ ┗ 📜Tvs.tsx
┣ 📜App.tsx
┣ 📜index.tsx
┗ 📜utils.ts

현업에서 일을할때는 당연하게 고려하고 설계했던 부분들이, 새로운 언어, 라이브러리, 프레임워크를 배우면서 시간에 쫒기는 작업을 하다보니 "파충류의 뇌 🦎🧠"가 되면서 무지성으로 작성한거같다.

• 데이터의 구조를 잡아주는 부분과
• 실제로 데이터를 가공? 핸들링? 하는 부분과
• 가공된 데이터를 받아서 화면에 뿌려주는 부분

모두 쪼개놔야 코드의 양도 줄고, 전체적으로 코드 유지보수에 들어가는 비용이 줄어들수 있겠다라고 확신이 들었다.

그리고 CSS관련해서 제니쓰님께서도 리뷰해주셨는데, 이 부분역시 많이 부족하다는걸 다시 느꼈다.

추후에는 첨언해주셨던 반응형과, 사소한 디테일들을 고려해서 더욱 user friendly하도록 만들어봐야겠다.

그리고 마지막으로 아래는 2023년 8월 처음으로 JS와 React를 배우고 만들었던 결과물과, 이번에 만들어본 결과물들 링크이다.

2023.08 - https://reactjs-coupangplay.pages.dev/
2024.03 - https://nomadcoder-react-study-4th-react-final-challenge.pages.dev/