왜 ReactHooks일까? 그리고 어떻게 여기까지 왔을까?

* 이 글은 Why React Hooks, and how did we even get here? 번역하였습니다.

Why React Hooks, and how did we even get here?

---

TL;DR:  higher order component(HOO), mixins 과 render props의 trade-off를 배우고 이를 보완하는 Hooks는 flat하게 선언하는 방식으로 구성 가능한 동작을 만드는 새로운 방법을 제공합니다.

---

Hooks는 하나의 해결책이 아닌 자신들만의 방식이 존재합니다. 때때로 우리는 계층을 만들어야 할 때가 있습니다. 그것에 대해 한번 이야기 해보죠. 

 

React Hooks가 나오자마자, 한 순간에 매료되었습니다. 이 토픽에서는 Hooks가 왜 좋은지 이해하도록 지금까지의 React가 가진 문제점을 풀어보는 방식으로 도움을 줄 수 있을 것 같습니다.

 

당신은 Mouse의 위치를 유저에게 보여줘야 한다고 가정을 해봅시다. 아래의 코드를 보시죠. 

⚠️ 이런 가정에서는 새로운 문제가 발생합니다. 

1. 만약에 다른 Component 에서 Mouse를 움직여야 한다면, 같은 코드를 또 다시 작성해야 할 것입니다. 

2. 또 다른 액션들을 Mouse에 적용시켜야 한다면, componentDidMount 와 componentWillUnmount의 새로 적용시켜야 하는 로직을 나눠서 작성해야 하므로, 이해하기 어려워 질 것입니다. 

 

그래서 이런 문제를 해결할 수 있는 방법이 구현되었습니다. 이러한 문제를 해결할 수 있는 방법을 함께 알아봅시다. 

Mixins

Mixins은 엄청난 방법입니다. Mixins은 하나의 effect를 표현하기 위해 라이프 사이클 hooks을 그룹화하는 단계를 설정합니다.

캡슐화하는 일반적인 아이디어는 훌륭하지만 우리는 mixins에서 몇 가지 중요한 교훈을 배울 수 있습니다.

this.state.x가 어디로부터 올 수 있었는지가 확실하지 않고, mixins이 component안에만 property가 있다는 사실에 맹목적으로 의존 할 수도 있습니다. 

 

많은 다수의 사람들이 mixins 패턴을 확장하고, 작성할 때 이는 커다란 문제가 될 수 있습니다. 리팩토링은 쉬어야 합니다. 이러한 패턴은 구성 요소에 속하지 않음을 더 분명하게 보여야하며 component의 내부에 작성을 해서는 더더욱 안됩니다. 

 

Higher Order Components

mixins과 비슷한 효과를 얻을 수 있고, props을 보내주는 container를 만들어 어려움을 덜어 줄 수 있습니다. 상속의 trade-off는 리팩토링을 어렵게 만드는 것입니다. 상황을 한번 만들어보죠 

많은 코드가 필요하지만, 옳바른 방향으로 만들었습니다. mixins의 모든 장점을 가지게 되었습니다. <MouseRender /> 구성요소는 더 이상 다른 요소에만 의존적으로 엮여 있지 않고, 개별적으로 이동할 수 있게 되었습니다. 

 

Render Props & Children as a Function

아래의 패턴은 자주 접하게 되는 패턴입니다. mouse의 이동을 다루는 component가 있고 이는 코드를 통해 rendering 됩니다. 

 

이 미묘한 차이에는 몇 가지 놀라운 이점이 있습니다.

 

1. x, y에게 무엇을 제공하는지 확실하게 알 수 있습니다. 또한 name 충돌을 예방하도록 새롭게 이름을 만들 수도 있습니다. 

2. rendering을 유연하게 제어할 수 있습니다. 새로운 component를 만들 필요도 없을 뿐더러 그냥 복사 붙여넣기하면 됩니다. 

3. 이 모든 것을 component의 rendering 함수에서 직접 볼 수 있습니다. 이는 새로운 개발자들이 합류할 때 쉽게 이해 할 수 있고, 명시적으로 해석을 할 수 있습니다.  

 

이 패턴의 주된 문제는 component가 rendering 중 상당 부분을 중첩해야한다는 것입니다. 중첩되어 있는 component들의 prop들을 rendering 하자마자 무슨일이 일어날지 금방 깨달을 수 있을 것입니다. 

 

또한 잘못된 계층 구조를 만들수도 있습니다. 이는 동작이 다른 동작 아래에 중첩되어 있다고 해서 부모의 동작에 의존한다는 말이 아닙니다. 예시를 보죠. 

만약 이런 callback과도 같은 구조가 생성이 된다면...... 어떤 일이 발생하게 될까요?.... 

 

Hooks

중첩을 제거하고 모든 것을 위로 올릴 수 있다면 어떨까요? rendering 함수의 유일한 JSX는 괜찮은 로직입니다.

이는 제가 원했던 구조입니다. 

 

1. 그작은 패키지의 깔끔한 동작을 만들어 낼 뿐만 아니라, useEffect는 세 가지 다른 수명주기 hook에 분산되지 않도록합니다.

2. component가 데이터를 가져 오는 곳은 명확하며 rendering 내에 깔끔하게 중첩되어 있습니다.

3. 이 중 몇 개를 가져와야하더라도 코드는 중첩되지 않습니다.

 

However, there are some catches

hooks를 사용할 때 몇가지 룰을 명심해야 합니다.

 

1. render 함수의 가장 상위에서 hooks을 불러오세요.

 조건부 hooks이 없다는 것을 의미합니다. React의 룰에서는 매번 같은 순서로 같은 양의 hooks를 불러와야하는 것입니다. 

 

이 룰은 Mixins과 HOC의 동작과 비교 했을 때 더욱 확실해 질 것입니다. 조건적으로 hooks를 사용하지 마시고, 각각의 render에서 재 사용하세요. 

 

만약 조건부 effect를 사용하고 싶으시다면, 다른 component안에서 hooks를 나누거나 다른 패턴을 생각해보세요. 

 

2. React function components와 Custom Hooks에서만 hooks를 사용하세요.

일반 함수에서도 hooks를 불러오지 못하는 기술적인 이유가 있는지는 확실하지 않습니다. 확실한 것은 데이터가 항상 component의 표시된다는 것입니다. 

 

3. hook의 기본 요소에는 componentDidCatch, getSnapshotBeforeUpdate가 없습니다. 

React team은 현재 준비 중이라고 언급하였습니다. 

 

componentDidCatch를 사용하기 위해서 Error Boundary Component를 만드세요.

 

Some Final Note

hooks는 우리가 React를 보는 관점을 바꿀 것이라 믿어의심치 않고 다수의 모범사례들을 만들어 낼 것입니다. 이에 관련된 많은 libraries들이 출시되는 부분은 굉장히 고무적입니다. 

 

하지만 저는 과거에 이러한 디자인 패턴에 대한 좋지 않은 부분을 경험한 적이 있습니다. 결국엔 굉장히 유익한 하나의 툴이 되었지만 모든 것들은 배우는데 애를 먹었습니다. 

 

저는 아직까지도 hooks의 trade-off를 완벽하게 이해하지는 못합니다. 계속해서 hooks의 예제를 살펴보시고, 사용해보는 것을 제안드립니다. 

 

읽어주셔서 감사합니다. 

---

< 참고자료 >

 

[사이트] #medium 

https://www.npmjs.com/package/axiosmedium.com/free-code-camp/why-react-hooks-and-how-did-we-even-get-here-aa5ed5dc96af

Why React Hooks, and how did we even get here?

<React> Why React Hooks, and how did we even get here? end