[React] hooks 만든 동기, 사용하는 이유 요약

728x90
반응형

이 글은 React 공식 홈페이지 

ko.reactjs.org/docs/hooks-intro.html#ts-hard-to-reuse-stateful-logic-between-components

 

Hook의 개요 – React

A JavaScript library for building user interfaces

ko.reactjs.org

을 읽고 요약하며 생각한 사담을 넣은 글입니다. 

 

동기

기존 리액트는  컴포넌트 사이에서 상태와 관련된 로직을 재사용하기 어렵다

 

React는 컴포넌트 재사용 가능한 행동을 붙이는 별다른 방법을 제공하지 않는다.

따라서 render Props나 고차 컴포넌트 같은 패턴이 재사용성을 위해서 사용되어 왔다.

하지만 이런 패턴은 컴포넌트를 재구성해야하고 (render props의 경우 매번 함수가 생성되는 것을 막기위해 내부 함수를 다시 만들어준다) 코드를 추적하기가 어렵다.

 

 

React 개발자 도구에서 전형적인 React application을 볼 때

(*작성자 사담: 아마 전형적인 이란 말은 hooks 이전의 React로 개발된 것을 말하는 것 같다)

 

providers, comsumers, 고차 컴포넌트, render props 등 다른 레이어로 둘러싸인 래퍼 지옥을 볼 가능 성이 높다.

 

Hooks은 컴포넌트로 부터 상태 관련 로직을 추상화할 수 있다. 한 컴포넌트에 의존하는 것이 아니기 때문에 독립적인 테스트와 재사용이 가능하다.hook은 계층 변화없이 상태 관련 로직을 재사용할 수 있게 도와준다

(*작성자 사담: 전역 상태 라이브러리를 사용하는 이유와 같은 거 같네요)

 

이는 많은 컴포넌트 사이에서 (혹은 커뮤니티)에서 hook을 공유하기 쉬워진다

생명주기

생명주기 메서드는 자주 관련없는 로직이 섞여 있다. 이렇게 상태 관련 로직이 모든 공간에 있기 때문에 컴포넌트를 작게 쪼개기 불가능하고 테스트하기 어렵다.

이 때문에 사람들이 React를 별도의 상태 관리 라이브러리와 결합해서 사용하는데 너무 많은 추상화하고 다른 파일들 사이에서 건너뛰며 재사용하기 더 어려워지기도 한다.

이를 해결하기 위해 생명 주기 메서드 기반으로 쪼개기 보다는 hook을 통해 로직에 기반을 둔 함수로 컴포넌트를 나눌 수 있다.

 

(* 사담: 예를 들면 componentDidMount에서 여러 로직을 같이 사용하지 않고 useEffect를 로직 종류별로 분리해서 작성하는 것이 해당 되겠네요)

class

class 기반에서는 this가 javascript에서 어떻게 작동해야 되는지 알아야했고 class를 사용하는 다른 언어와 다르게 작동하기도 한다.

class는 잘 축소되지 않고 핫 리로딩을 깨지게도 하면서 최근 사용되는 도구에도 문제를 일으키기도 한다. facebook은 코드가 최적화에서 더 오래 유지될 가능성이 높은 API를 제공하고 싶다.

hook은 class 없이 react 기능을 사용하는 방법을 알려준다. hook은 명령형 코드로 해결책을 찾을 수 있게 도와주며 복잡한 함수형, 반응형 프로그래밍 기술을 배우도록 하지 않는다.

 

728x90
반응형
TAGS.

Comments