개발을 하면서 저를 가장 괴롭혔던 로직은 컴포넌트 분리였습니다. 이 로직이 괴로웠던 이유는 굳이 하위 컴포넌트로 만들어 데이터를 prop로 전달해야 할까하는 마음이 있었기 때문입니다. 하위 컴포넌트가 많아지고 계층이 깊어질수록 프로젝트를 이해하는 것이 더 어렵다고 느꼈습니다. 오히려 한 컴포넌트에서 발생하는 모든 이벤트를 다루는 것이 직관적이지 않을까 해서 컴포넌트 분리에 대해 자세히 알아보지도 않았던 것 같습니다.
그렇게 이악물고 모른 척 해왔는데, 취업을 준비하면서 채용 자격요건이나 사전 질문에 컴포넌트 분리에 대한 본인의 기준이 있는지에 대한 질문을 하는 것으로 보아 컴포넌트 분리는 이미 프론트엔드 개발자의 기본 소양임을 느낄 수 있었습니다. 그래서 왜 컴포넌트를 분리해주어야 하는지, 또 많은 개발자들은 어떻게 컴포넌트를 분리하는지 간단하게 알아보았습니다.
컴포넌트를 적절하게 분리하지 않으면 하나의 동작에 분리하지 않은 코드 모두 리렌더링되거나, Side-Effect가 발생할 수 있습니다. 이는 웹 성능을 나쁘게 만드는 원인이 되기도 하며, 나쁜 사용자의 경험의 원인이 되기도 합니다. 또, 다른 개발자가 보았을 때 한 컴포넌트 안에 원래는 컴포넌트로 나뉘어야 할 코드를 모두 붙여쓰게 된다면 이해하기 어려운 코드가 되기도 합니다.
많은 개발자들이 컴포넌트를 분리하는 기준으로,
**1. 재사용성
를 선택합니다.
먼저 재사용성을 위해 컴포넌트를 분리하는 기준은 저 역시 잘 이해하고 있고, 이미 당연하게 분리해주는 기준이기도 합니다. 같은 코드를 여러 번 작성할 필요가 없기 때문에, 반복되는 코드가 있다면 한 곳에서 작성한 뒤 해당 코드를 컴포넌트로서 불러오는 것이 매우 합리적인 선택이라고 생각합니다.
하지만 저에겐 복잡도를 낮추기 위한 컴포넌트 분리 기준은 매우 모호했습니다. 복잡도라는 의미 자체를 잘 이해하지 못하고 있고, 이에 따라 복잡도를 낮출 수 있도록 컴포넌트를 분리하는 방법을 모르고 있기 때문입니다.
복잡도를 낮춘다는 의미를 이해하기 위해 여러 글을 참고해보았지만, 가장 와닿았던 부분은 **"하나의 역할만 하도록 분리하기 (=원하는 방식대로 동작하기에 있어 각 이벤트들이 적절하게 독립적으로 분리되었는가?)"**입니다. 하지만 이 내용이 모든 경우의 복잡도를 낮추는 행위를 의미하는 것 같지 않아 설명이 부족한 것 같습니다.
이번 원티드 프리온보딩 FE 챌린지를 통해 컴포넌트를 분리할 때 복잡도라는 개념이 감각의 영역인지 명확하게 구분할 수 있는 영역인지를 명확하게 이해하고, 실제로 낮추는 방법에 대해 학습하고자 합니다. 그리고 전역 상태관리 툴인 Redux를 이번 챌린지에서 배울 수 있다는 소식이 매우 기대됩니다.