리액트 패턴 - Render Props Pattern

📖들어가며..

오랜만에 다시 리액트 패턴을 알아보려고 한다.

여태 이것저것 하는게 너무 많아버려서..

저번에는 HOC, 고차 컴포넌트에 대해서 알아보았다.

고차컴포넌트에  여러 컴포넌트가 동일한 데이터나 동일한 로직을 포함해야 할 때 컴포넌트의 로직을 재사용할 수 있게 되면 편해질 수 있다는 것을 알았다.

 

컴포넌트를 재사용할 수 있는 다른 방법으로 Render Props Pattern이 있다고 한다.

해당 패턴을 예시를 보면서 사용해보고 경험해보려고 한다.

 

 

👨‍💻 Render Props Pattern

아래 코드를 보자

현재  InputText 컴포넌트에서 text상태를 관리하고 있다.

input이 InputText 컴포넌트에 있기 때문에 보통 코드를 빠르게 작성하려고 한다면 이렇게 작성한다. 

 

하지만 만약 View 컴포넌트에서도 이 text값을 사용하려면 어떻게 해야할까?

위처럼 바꿔보았다.

상태를 부모 컴포넌트로 옮겼다.

위에서 말했던 문제는 해결했지만 규모가 큰 앱에서 컴포넌트가 여러 자식 컴포넌트를 가지고 있는 경우 이 작업을 하기에는 현명하지 못한 방법이다.

 

상태의 변경은 모든 자식 컴포넌트의 리렌더링을 유발할 수 있고 이런 상황이 쌓이면 앱의 전체적인 성능을 떨어트릴 수 있다.

 

👨‍💻Render Props Pattern 활용

이럴 때 Render Props Pattern을 사용할 수 있다.

InputText 컴포넌트가 render props를 받고,여기에 필요한 인수를 넣어서 JSX.Element로 반환했다.

즉 상태를 끌어올려서 사용하고 있다고 보면 된다.

 

이때 Children props를 활용할 수도 있다.

 

👨‍💻children을 이용한 Render Props Pattern

InputText 컴포넌트에 명시적으로 render prop을 넘기는 대신 자식 컴포넌트를 함수로 넘기도록 수정해 보자,

Input컴포넌트는 children을 통해 이 함수에 접근할 수 있다. 

props.render를 쓰는 대신에 props.children함수를 호출하며 인자를 넘기도록 수정했다.

이렇게 하면 render prop의 이름을 어떻게 지을까 고민하지 않고 입력 값을 자유롭게 사용할 수 있게된다.

 

 

이러한 Render Props 패턴의 특징을 정리하면 아래와 같다.

• 컴포넌트간 데이터를 공유하는 것은 고차 컴포넌트(이하 HOC) 패턴과 같습니다.

• 그러나 HOC의 props 구분에 대한 이슈가 해결됩니다.

• 렌더링 컴포넌트와 비즈니스 로직을 분리할 수 있습니다.

• 하지만 대부분의 문제는 Render Props보다 Hooks로 해결할 수 있습니다.

• 특히, Render Props 내에서 생명 주기(Lifecycle) 함수를 사용할 수 없습니다.

📢Hooks

몇몇 상황에 render props 패턴은 hooks로 대체될 수 있다.

이전에도 HOC 컴포넌트는 hooks로 대체할 수 있었다.

 

사실 우리가 지금까지 예제로 쓴 코드는 정말 간단한 코드이기에 

저렇게까지 Render Props 패턴을 고집해서 사용안해도 된다.

그냥 하나의 컴포넌트를 만들고 거기에 몰아주면 된다.(상태가 간단하므로)

 

대표적인 예시로  Apollo Client가 있다.

해당 내용은 여기에 자세하게 나와있다.

 

간단하게 말하자면 해당 패턴은 트리가 깊어지는 문제가 생길 수 있다.

그래서 custom hooks가 나온 이후로는 hooks를 모두 이용하고 있다는 것이다

 

 

👀Render Props의 장단점

Render Props 패턴은 컴포넌트 간 데이터 공유와 재사용성을 높여주는 방법이다.

HOC 패턴과 유사하지만, 몇 가지 장단점이 있다.

 

장점

• 명시적인 Props 전달: Render Props는 부모 컴포넌트에서 명시적으로 props를 전달받기 때문에, props의 출처를 명확히 알 수 있습니다. 이는 HOC 패턴에서 props가 어디서 만들어졌는지 구분하기 어려운 문제를 해결합니다.
• 로직과 렌더링 분리: 상태를 가진 컴포넌트는 Render Props를 통해 상태가 없는 컴포넌트를 렌더링할 수 있어, 비즈니스 로직과 UI 렌더링을 분리할 수 있습니다.

 

단점

• Hooks로 대체 가능: React Hooks가 도입되면서 대부분의 Render Props 패턴은 Hooks로 대체될 수 있습니다. Hooks는 컴포넌트 재사용성과 데이터 공유의 방식을 근본적으로 바꾸어 놓았습니다.
• 생명 주기 함수 사용 불가: Render Props 내에서는 생명 주기 함수를 사용할 수 없어, 받은 데이터를 수정할 필요가 없는 컴포넌트에만 적합합니다.

 

결론적으로, Render Props 패턴은 HOC의 문제를 해결하면서 로직과 UI를 분리할 수 있지만

많은 경우 Hooks로 더 효율적으로 대체할 수 있다.

 

 

📘마무리하며..

Render Props 패턴을 공부하면서 HOC와의 차이에 대해서 알게 되었다.

사실 HOC 패턴이나 Render Props 패턴은 잘 사용하지 않았었다.

모르는 패턴이기도 했지만 공통 로직이 생기면 나는 주로 Custom hooks를 만들어서 해결했었기 때문이다.

 

그저 이러한 패턴이 있구나를 알게 되었고, 잘 사용하지는 않을 것 같다.

개인적으로 Render Props 패턴은 뭔가 직관적이지 못한 것 같았다.

Children을 사용한 부분은 뭔가 괜찮아 보였지만 

굳이 저렇게 나누는 상황이 생길까? 라는 생각이 들었다.

 

내가 상당히 경험 중심적인 생각을 가지고 있어서 그런 것일 수도 있다.

다양한 기능을 개발하면서 해당 패턴을 한 번씩 적용해보면서 직접 느껴봐야 알 것 같았다.