리액트,프론트 엔드, Page는 얼마만큼의 props를 가져야하나?, 컴포넌트에 프롭스 넘겨주기[20221207-TIL]

 리액트, 컴포넌트와 프롭스

리액트를 검색해본다면 단연코 가장 빼놓을수 없는 말은 컴포넌트(component)와 프롭스(props, properties)일 것이다. 리액트는 공용컴포넌트를 만들어 비슷한 템플릿을 하나의 컴포넌트로 관리해줄 수 도 있고 단일 페이지에서 코드가 난잡하게 뭉쳐진 것들을 컴포넌트로 분리시켜 관리할 수 있다는 장점이 있다. 하지만 언제 컴포넌트를 분리시켜야하고 언제 컴포넌트에 프롭스를 넘겨주어야할 지

기준이 잘 서지 않아 많이 헷갈렸었는데 오늘은 그것에 관해서 조금 정리해보고자 글을 쓴다.

 

1. 컴포넌트를 나누어야하는 기준

컴포넌트는 사실 코더가 자신의 코드를 기준으로 나누어주어야하는게 아닐까 싶다. 아직 잘 짜인 코드들의 많은 레퍼런스를 보지 못해서

이렇다고 대답은 못하지만 주로 나열을 하거나 객체 하나하나의 디테일을 보여주거나 즉 하나의 큼직한 기능 단위로 나누면 관리가 편하다고 생각했다.

큰 규모의 앱을 만들면 만들수록 이것은 감이 생기는게 아닐까 싶다.

 

2. 언제 프롭스(props)를 넘겨주지?

이것은 간단한 것 같은데 컴포넌트를 나누어야 관리가 편하지만 상위 컴포넌트에서 받아오는 프롭스를 하위 컴포넌트가 사용해야핧 때라고 말할 수 있을 것 같다.

나는 기존에 트레이너 분께서 프롭스를 내려주는 것을 보고 가장 최상단 페이지에서 프롭스를 모두 관리하고 있어야하고 하위 컴포넌트는 이것을 모두 받아오는 형태여야하는구나 라고 생각을 했고

이렇게 진행중 이디가 컴포넌트의 depth가 너무 깊어지고 넘겨주는 프롭스가 10개가 넘어갈때부터 이상한 느낌이 들었다.

그리고 코드를 수정할 때 하나를 추가하기위해선 몇 개의 컴포넌트를 넘나들면서 프롭스를 추가헤야한다는 것을 느끼면서 불편하다고 생각을 했다.

심지어 플럭스 구조를 이용하고 있어서 어떤 컴포넌트에서든 스토어를 통해서 모델의 상태를 업데이트 하고 수정할 수 있는데도 저런 구조를 띄고 있었다.

 

3. 복잡성과 불편함

2번의 실수를 반복하고 어플리케이션의 사이즈가 커지는데 몇 단계나 위에 있는 최상단 컴포넌트에서 업데이트를 해주어도 하위 컴포넌트에서는 그 업데이트를 못받아오는 상황이 발생했다.

해당 업데이트를 받아오려면 그와 관련된 모든 모델들과 함수들을 다시 몇 개나 되는 컴포넌트에 쏴주어야했느데 그럴수록 관리의 포인트도 늘어나고 더이상 내가 관리하는 컴포넌트가

컴포넌트로 만드는 장점을 모두 사라지게 하고 있었다. ( 컴포넌트 안에서 독립적으로 관리 , 다른 컴포넌트와 불필요한 의존성 분리 등) 더욱이 이렇게 불필요한 의존성을 더해주면 테스트

또한 복잡해지는 문제가 있다.

 

오늘은 직접 좋지않은 사례를 의도치않게 코드를 짜며 불편함을 느끼고 다시 flux 구조의 장점을 느낄 수 있어서 좋았다. 역시 똥인이 된장인지는 먹어봐야 안다.

 

대표 경험주의 철학자 프랜시스 베이컨