간략한 목차
1. 훅을 통해 상태 관련 로직의 독립적인 테스트와 재사용이 가능합니다.
2. 훅은 이해하기 쉽습니다.
3. 훅은 Class 없이 리액트를 사용가능하게 만듭니다.
- 훅은 컴포넌트로부터 상태 관련 로직을 추상화하여 독립적인 테스트와 재사용이 가능하게 만듭니다.
= 훅을 통해 상태 관련 로직의 독립적인 테스트와 재사용이 가능합니다.
React는 컴포넌트간에 재사용 가능한 로직을 붙이는 방법을 제공하지 않습니다. (예를 들어, 스토어에 연결하는 것) 이전부터 React를 사용해왔다면, render props이나 고차 컴포넌트와 같은 패턴을 통해 이러한 문제를 해결하는 방법에 익숙할 것입니다.
그러나 이런 패턴의 사용은 컴포넌트의 재구성을 강요하며, 코드의 추적을 어렵게 만듭니다. React 개발자 도구에서 React 애플리케이션을 본다면, providers, consumers, 고차 컴포넌트, render props 그리고 다른 추상화에 대한 레이어로 둘러싸인 “래퍼 지옥(wrapper hell)“을 볼 가능성이 높습니다. 개발자 도구에서 걸러낼 수 있지만, 이 문제의 요점은 심층적이었습니다. React는 상태 관련 로직을 공유하기 위해 좀 더 좋은 기초 요소가 필요했습니다.
Hook을 사용하면 컴포넌트로부터 상태 관련 로직을 추상화할 수 있습니다. 이를 이용해 독립적인 테스트와 재사용이 가능합니다. Hook은 계층의 변화 없이 상태 관련 로직을 재사용할 수 있도록 도와줍니다. 이것은 많은 컴포넌트 혹은 커뮤니티 사이에서 Hook을 공유하기 쉽게 만들어줍니다.
우리는 자신만의 Hook을 구축하는 법에 대해 좀 더 알아볼 것입니다.
자신만의 Hook을 만들면 컴포넌트 로직을 함수로 뽑아내어 재사용할 수 있습니다.
- 훅은 이해하기 쉽습니다.
우리는 때론 간단하게 시작했지만 관리하기가 힘들어지는 상태 관련 로직들과 사이드 이펙트가 있는 컴포넌트들을 유지보수해야 합니다. 각 생명주기 메서드에는 자주 관련 없는 로직이 섞여들어가고는 합니다. 예시로
componentDidMount 와 componentDidUpdate는 컴포넌트안에서 데이터를 가져오는 작업을 수행할 때 사용 되어야 하지만, 같은 componentDidMount에서 이벤트 리스너를 설정하는 것과 같은 관계없는 로직이 포함되기도 하며, componentWillUnmount에서 cleanup 로직을 수행하기도 합니다. 함께 변경되는 상호 관련 코드는 분리되지만 이와 연관 없는 코드들은 단일 메서드로 결합합니다. 이로 인해 버그가 쉽게 발생하고 무결성을 너무나 쉽게 해칩니다.위와 같은 예시에서, 상태 관련 로직은 한 공간안에 묶여 있기 때문에 이런 컴포넌트들을 작게 분리하는 것은 불가능하며 테스트하기도 어렵습니다. 이 때문에 많은 사용자들은 React를 별도의 상태 관리 라이브러리와 함께 결합해서 사용해왔습니다. 그러나, 이런 상태 관리 라이브러리는 종종 너무 많은 추상화를 하고, 서로 다른 파일들 사이에서 건너뛰기를 요구하며 컴포넌트 재사용을 더욱더 어렵게 만들었습니다.
이같은 문제를 해결하기위해, 생명주기 메서드를 기반으로 쪼개는 것 보다는, Hook을 통해 서로 비슷한 것을 하는 작은 함수의 묶음으로 컴포넌트를 나누는 방법을 사용할 수 있습니다. (구독 설정 및 데이터를 불러오는 것과 같은 로직) 또한 이러한 로직의 추적을 쉽게 할 수 있도록 리듀서를 활용해 컴포넌트의 지역 상태 값을 관리하도록 할 수 있습니다.
이에 대해 Effect Hook에서 더 알아볼 것입니다.
- 훅은 Class 없이 리액트를 사용가능하게 만듭니다.
React 에서의 Class 사용을 위해서는 JavaScript의
this 키워드가 어떻게 작동하는지 알아야만 합니다. JavaScript의 this키워드는 대부분의 다른 언어에서와는 다르게 작동함으로 사용자에게 큰 혼란을 주었으며, 코드의 재사용성과 구성을 매우 어렵게 만들고는 했습니다. 또한 class의 사용을 위해 이벤트 핸들러가 등록되는 방법을 정확히 파악해야 했으며, 이는 ES2022 public class fields가 없을 때 코드를 매우 장황하게 만들었습니다. 사용자들은 props, state, 그리고 top-down 데이터 흐름을 완벽하게 하고도, Class의 이해에는 어려움을 겪고는 했습니다. React 내의 함수와 Class 컴포넌트의 구별, 각 요소의 사용 타이밍 등은 숙련된 React 개발자 사이에서도 의견이 일치하지 않습니다.React는 지난 5년 동안 널리 사용되어 왔으며, React의 개발진은 5년 뒤에도 React가 지금과 같이 널리 이용되길 원합니다. Svelte, Angular, Glimmer 등에서 보여주듯이, 컴포넌트를 미리 컴파일해놓는 방식에는 높은 잠재력이 있습니다. 템플릿에 한정하지 않는다면 더 그렇고요. 개발진은 최근 Prepack을 사용한 컴포넌트 folding에 대해서 실험해왔고 긍정적인 결과를 보았습니만, Class 컴포넌트가 이러한 최적화를 더 느린 경로로 되돌리는 의도하지 않은 패턴을 장려할 수 있다는 것을 발견했습니다. Class는 최근 사용되는 도구에서도 많은 문제를 일으킵니다. 예를 들어 Class는 코드의 최소화를 힘들게 만들고, 핫 리로딩을 깨지기 쉽고 신뢰할 수 없게 만듭니다. 우리는 코드가 최적화 가능한 경로에서 유지될 가능성이 더 높은 API를 제공하길 원하였습니다.
이러한 문제를 해결하기 위해, Hook은 Class없이 React 기능들을 사용하는 방법을 제시합니다. 개념적으로 React 컴포넌트는 항상 함수에 더 가깝습니다. Hook은 React의 정신을 희생하지 않고 함수의 사용을 권장합니다. Hook은 명령형 코드로 해결책을 찾을 수 있게 해주며 복잡한 함수형 또는 반응형 프로그래밍 기술을 배우도록 요구하지 않습니다.
# 훅는 클래스 컴포넌트의 문제점을 개선하고 함수형 컴포넌트를 사용하기 위해 등장
- 함수형 컴포넌트에서는 사용하지 못했던 것들
- state
- 생명주기
- 이것들을 사용하지 못했기 때문에 함수형 컴포넌트의 이점에도 (속도와 코드의 간결함) 클래스형 컴포넌트를 사용합
- 훅이 등장한 이후로 함수형 컴포넌트에서도 생명주기를 사용할 수 있어
- 데이터를 가져오고 / 컴포넌트가 시작되자마자 API를 호출하는 것 등이 가능해짐
- 결과적으로 함수형 컴포넌트 더 간결한 코드, 빠른 속도의 이점을 취할 수 있게 됨 →(3번과 연결)
- (정리) 클래스형 컴포넌트보다 함수형 컴포넌트가 간결한 이유
- 클래스형 컴포넌트는 생명주기를 이용할 때, componentDidMount 와 componentDidUpdate, componentWillUnmount 이렇게 다 다르게 처리해주지만
- 함수형 컴포넌트에서 훅을 사용하면 useEffect 안에서 한 번에 처리 가능하기 때문
# HOC 컴포넌트를 Custom React Hooks로 대체해서 많은 Wrapper 컴포넌트를 줄이게 됨 → (1번과 연결)
- HOC란?
- 화면에서 재사용 가능한 로직만을 분리해서 component로 만들고 재사용 불가능한 UI와 같은 다른 부분들은 파라미터로 받아서 처리하는 방법
- 유저리스트를 가져오는 공통적인 부분은 HOC 컴포넌트에 넣어주고 그 HOC 컴포넌트로 각각의 컴포넌트를 감싸주면 모든 컴포넌트에 따로 인증을 위한 부분은 넣어주지 않아도 됩니다. 훅이 나오기 전에는 이 방법이 추천되었습니다. 하지만 여기에도 문제가 있습니다. 바로 너무 많은 Wrapper 컴포넌트가 생길 수 있다는 것 입니다. 아래 그림처럼 Wrapper 가 너무 많아지면 데이터의 흐름을 파악하기 어렵습니다.
- 이 문제는 Custom React Hooks를 이용해서 해결할 수 있습니다
리액트 훅을 도입하게 된 목적은 여러가지가 있다. 먼저 컴포넌트에서 상태관련 로직을 사용할 때 레이어 변화 없이 재사용할 수 있게하기 위함이 첫번째 목적이다. 기존에는 여러가지 레이어로 둘러 쌓여있어서 구조가 복잡했기 때문이다. 두 번째 목적은 기존의 라이프사이클 메서드 기반이 아닌 로직 기반으로 나눌 수 있어서 컴포넌트를 함수 단위로 잘게 쪼갤 수 있다는 이점 때문이다. 그 외에도 클래스 기반 컴포넌트를 지양하고자 하는 목적 등도 있다.
메모
- 분량 : 1장~1장 반 (타입스크립트 교재)
- 타입 스크립트 교재 보니까 소스코드도 몇 개 집어넣던데 소스코드도 넣으면 좋을 듯
하지만 클래스 컴포넌트는 컴포넌트 간 상태 로직의 재사용 및 구조 파악이 어렵고 코드가 길고 복잡하다는 단점이 있습니다.