함수 컴포넌트 등장과 한계
(1) 클래스 컴포넌트의 한계
React의 초기 버전에서는 클래스(class)로 컴포넌트를 작성해 상태 관리와 생명주기를 다뤘습니다. 다음은 클래스 컴포넌트 예시예요.
복잡해 보이지요? 함수 컴포넌트를 작성해볼게요.
깔끔하죠? 게다가 코드 흐름이 더 직관적입니다.
(2) 함수 컴포넌트의 한계
하지만, 은총알은 없습니다. 위와 같은 예시는 간단하기 때문에 문제를 깔끔하게 해결해주지만, 조금만 컴포넌트 관계가 복잡해져도 금방 한계에 부딪힙니다. 컴포넌트 관계가 복잡해지다보면 상태 로직을 재사용하게 되는데, 이 과정에서 HOC(Higher Order Components) 문제나 래퍼 지옥(wrapper hell) 문제가 자주 발생하죠.
과장한 게 아니예요. 마치 콜백 지옥처럼(callback hell) 컴포넌트가 깊게 중첩되는 건 흔히 발생합니다. 게다가 함수 컴포넌트는 JavaScript 측면에선 함수잖아요. 함수 안에서 변수에 접근하는 스코프(scope)가 각 중첩 단계마다 생성되므로 코드 가독성이 좋지 않지요. 또 컴포넌트가 강하게 결합되어 분리하기 어렵고, 코드 수정을 어렵게 합니다.
이러한 문제를 Hooks가 해결해줍니다.
리액트 Hooks
리액트 Hooks는 함수 컴포넌트에서 상태(state) 관리와 생명주기(lifecycle) 기능을 사용할 수 있게 해주는 기능입니다. 훅(갈고리)이라는 이름의 유래는 공식적인 설명은 없는 것 같은데, 컴포넌트 생명주기에 어떤 동작을 건다는 설명이 가장 지지 받지요.
(1) 컴포넌트 생애주기(lifecycle)
리액트 컴포넌트의 생애주기는 크게 3단계로 구분합니다.
1) 컴포넌트 마운트 될 때
컴포넌트가 리액트 돔(Dom)에 렌더링 되는 시점입니다.
2) 상태가 변경될 때
컴포넌트가 받는 Props가 변경되거나 컴포넌트의 상태(State)가 변경되는 시점입니다.
다이시 카토는 리액트 훅이 등장하면서 상태를 생성하는 새로운 방법이 생겼다고 하면서, 폼, 서버 캐쉬, 내비게이션 상태와 같은 상황에서 발생하는 상태 관리 문제를 해결하는 것이 리액트 훅의 목표 중 하나라고 하기도 했습니다. (책, 리액트 훅을 활용한 마이크로 상태 관리 (위키북스))
3) 마운트 된 컴포넌트가 마운트 해제 될 때
리액트 돔에 마운트 된 컴포넌트가 마운트 해제되어 DOM에서 제거되는 시점입니다.
(2) Hooks 사용 방법
리액트 훅은 JavaScript 측면에서 단순 함수입니다. `use`라는 접두사를 붙인 이름을 사용하지요.
리액트 훅은 함수 컴포넌트 안이나 사용자 제작 훅(Custom Hook) 안에서만 사용할 수 있습니다. 훅을 호출(call, invoke)하는 건 최상위 스코프 단계에서만 호출할 수 있어요. 가령, 조건문 안에서는 사용하지 못해요. 가장 중요한 이유는 훅의 순서를 보장하지 못하기 때문이에요. 조건에 따라 호출되는 훅이 달라지거든요.
반복문에서 사용하지 못합니다. 반복문을 사용하기에 따라서는 순서가 보장되지만, 예측 가능성이 떨어지고 최적화하기 어렵습니다. 이와 관련해서는 조건부 렌더링에서 Transpiling과 Compiling을 설명하며 다뤘습니다. 그리고, 또 다른 이유는 리액트가 규약보다는 설정(Convention over Configuration) 철학을 따르는 점이 아닐까 생각합니다. 유연성을 조금 포기하는 대신 안전하고 유지보수하기 좋은 코드를 유도하는 거죠.
푸딩캠프 이야기
토이스토리 2기 모집을 잠시 기다려주세요
혹시 토이스토리 2기에 참가하러 방문하신 분이라면 신청하는 영역이 없어서 당황하셨을 거예요. 내부 사정으로 잠시 2기 모집을 멈추고 정비하고 있거든요. 그대로 모집을 유지해도 되지만, 초반에 참가하신 분은 결제 후 하염없이 기다리실 것 같아 고민 끝에 모집을 잠시 멈췄습니다.
곧 재개할 예정이며, 12월 초에서 중순에 2기 시작을 하도록 일정을 계획하고 있습니다. 조금만 기다려주세요!
댓글
의견을 남겨주세요