TIL 221118 컴포넌트를 나누는 기준 + Enable text compression

컴포넌트를 나누는 기준

팀 프로젝트를 진행하면서 여러 번 들었던 생각은 '저 사람은 왜 컴포넌트를 이렇게 나눴을까?'라는 궁금증이었다. 그러면서 내가 컴포넌트를 나누는 기준은 옳은가라고 되돌아보게 되면서 '컴포넌트를 나누는 좋은 기준은 무엇일까'라는 의문이 들었다.

 

리액트 공식 홈페이지를 보면 컴포넌트는 독립적이고 재사용이 가능한 최소 단위인데 컴포넌트를 나누는 기준을 판단하기에는 모호한 표현같다. 그래서 사람마다 컴포넌트를 나누는 기준도 모두 다르고 검색을 했을 때도 다양한 의견들이 나온다. UI를 기준으로, 비슷한 관심사를 기준으로, 데이터를 기준으로, 기능을 기준으로 등등.. 어떤 글에서는 큰 문제가 발생하지 않는다면 굳이 불필요하게 컴포넌트를 나눌 필요 없다고도 말한다. 여러 글들을 읽어보고 내가 생각했을 때 합리적으로 컴포넌트를 나누는 기준을 정해봤다.

 

큰 프로젝트는 아주 작은 단위도 컴포넌트로 쪼갠다고도 하던데 내 경험상 최대한 컴포넌트를 나누지 않는 방향으로 기준을 정했다. 불필요하게 컴포넌트를 나누면 props drilling도 심해지고 그렇게 쪼개진 다른 사람의 코드를 읽으면서 불편했던 경험이 있기 때문이다.

 

• UI 기준으로 불필요하게 나누지 않는다.
• 반복, 재사용이 필요해질 때 나눈다.
• 먼저 컴포넌트를 쪼개두지 않는다. 필요할 때만 나눈다.

의미없이 컴포넌트를 나누지 않으려고 한다. 파일의 개수가 많아져서 들여다봐야하는 파일수가 많아지기 때문이다. 의미없이 컴포넌트를 나누는 사람을 봤는데 같은 컴포넌트 안에 둬도 되는걸 굳이 나눠둬서 파일을 하나 더 눌러보고 props를 한번 더 전달해줘야했다. 미리 예상해서 컴포넌트를 나눠두지 않고 필요해졌을 때 나눠야 불필요하게 나누는 걸 방지할 수 있는 것 같다.

 

• 가독성을 위해서 컴포넌트를 한번 더 나눈다. (예 : CardList 컴포넌트, Card 컴포넌트)
• 한 파일에 코드가 너무 길어졌을 때 나눈다.

List에 해당하는 컴포넌트와 Item에 해당하는 컴포넌트는 한 번 더 나눠도 괜찮은 것 같다. ul 태그와 Item 컴포넌트가 함께 있으면 애매해 보여서 이들을 List 컴포넌트로 한번 더 묶어주는게 가독성에 좋은 것 같다. 코드가 너무 길어져서 읽기가 불편할 때도 컴포넌트를 분리해주면 좋은 것 같다.

---

Enable text compression

라이트하우스(lighthouse)로 성능 측정을 했을 때 개선하면 좋을 점에 첫번째로 Enable text compression이 나왔다. 글자를 줄이라는 말 같은데 내 제품에 있는 글자는 모두 필요한데... 어떻게 줄이라는 거지...? 다른 방법이 있나 싶어서 찾아봤다.

가장 많이 나오는 말은 GZIP이라는 압축형식을 이용해서 텍스트를 압축하는 방법이다. 공식사이트는 뭔가 수상하게 생겨서 CDN으로 GZIP을 이용할 수 있는 사이트를 찾았는데 유료라서 패스하고 더 찾아보는 중인데 어떻게 적용을 하는지 알아내지 못했다...🥲

이 글을 보면 Nginx라는 것도 같이 사용해서 라이트하우스 점수를 높였다는데 어떻게 하라는건지.. 모르겠다...🥲 compress 해준다는 npm 패키지들은 build 할 때 압축해주는 것 같고... 좀 더 찾아봐야될 것 같다....🥲🥲🥲🥲🥲 이것만 해결하면 90점이 될 것 같은데... 승부욕이 불타오른다....🔥 어떻게 하는거야....🥲