리액트 강좌

6-1.컴포넌트

클래스 컴포넌트

웹 클라이언트 프레임워크의 주된 기능은 실행중에 동적인 페이지를 생성하여 그리는(Render) 것이다. 내부적인 속성과 상태를 적용하여 가상 DOM을 동적으로 생성하고 웹 페이지에 그려야 한다. 이런 동작을 하는 부품을 리액트 컴포넌트라고 한다.

컴포넌트는 독립적인 상태를 유지하고 사용자의 입력을 받아 스스로 동작한다. 이런 목적에 딱 어울리는 문법적 장치가 클래스이다. 클래스는 필드에 정보를 저장하고 메서드로 동작을 처리하며 라이프 사이클에 따른 특정 시점을 잡아낼 수도 있다. 그래서 리액트 초기에는 컴포넌트를 클래스로 구현했다. 성적표 컴포넌트를 클래스로 구현해 보자.

class ScoreClass extends React.Component {

render() {

let score = 123

return (

<div>

<p>점수는 {score}입니다.</p>

</div>

)

}

function App() {

return (

</>

)

}

React.Component로부터 상속받는 클래스를 정의하고 render 메서드에서 JSX 형식으로 가상 DOM을 만들어 리턴한다. 형식만 조금 다를 뿐 앞에서 만들었던 함수 컴포넌트와 별반 다를 것도 없다. render 메서드의 안쪽을 함수로 감싸면 된다.

그러나 여기에 속성이나 상태가 들어가면 복잡해진다. 이번에는 상태값을 가지는 카운트 컴포넌트를 클래스로 만들어 보자. 예전에는 이랬다는 걸 설명하는 중이니 아래 예제의 모든 문법을 굳이 다 이해할 필요는 없고 가벼운 마음으로 구경만 하자.

class CounterClass extends React.Component {

state = {

};

increment = () => {

this.setState((prevState) => ({

}));

};

decrement = () => {

this.setState((prevState) => ({

}));

};

render() {

return (

<h2>{this.state.count}</h2>

</>

)

}

function App() {

return (

</>

)

}

상태를 state 객체 필드에 정의하고 count를 10으로 초기화했다. 증가 함수인 increase는 this.SetState 메서드로 이전 상태값에 1을 더한다. 비동기 처리를 위해 직접 상태값을 증가하지 않고 함수를 전달한다. 감소 함수인 decrease도 비슷하다.

render 함수에서는 this.state.count로 현재 카운트를 출력하고 버튼 두 개를 배치한 후 onClick에 증감 함수를 지정한다. 버튼을 클릭하면 핸들러가 호출되고 setState를 실행할 때마다 랜더링을 다시 하여 증감한 카운트를 다시 그린다. 동작은 당연히 같다.

이 정도면 클래스로도 만들만한 것처럼 보인다. 그러나 위 예제는 ES13에서 추가된 클래스 필드 선언 문법을 사용하고 있어 구형 브라우저나 오래된 Node.js 환경에서는 실행되지 않는다. 그 이전의 환경에서는 클래스 메서드를 선언하고 this 바인딩을 해야 하며 그러기 위해 생성자가 필요하다.

class CounterClass extends React.Component {

constructor(props) {

super(props);

this.state = {

};

this.increment = this.increment.bind(this);

this.decrement = this.decrement.bind(this);

}

increment() {

this.setState((prevState) => ({

}));

};

decrement() {

this.setState((prevState) => ({

}));

};

오픈 소스가 다 그렇지만 조금 조금씩 자잘하게 기능을 늘리다 보니 그에 맞춰 코드를 제대로 짜기 어렵다. 설사 가능하다 하더라도 보다시피 구현하고자 하는 기능보다 형식을 맞추기 위한 군더더기 코드가 더 많다. 그래서 리액트 개발팀은 클래스보다 간편하고 좋은 방법을 찾았다. 그게 바로 훅이다.

훅의 도입

컴포넌트는 상태 관리나 생명 주기 메서드가 필수적이었고 이 정도 기능을 구현하려면 클래스가 필요하다. 그러나 클래스는 덩치가 크고 메서드에 코드가 분산되어 가독성과 유지 보수성이 낮다. 사실 클래스 자체는 훌륭한 문법이며 까일만한 대상이 아니다. 자바스크립트의 클래스 지원이 워낙 열악한데다 버전에 따라 문법이 춤을 춘다는게 더 큰 문제이다.

어쨌거나 초보자에게 클래스는 가히 쉬운 대상이 아니고 숙련자라 해도 비대해지면 관리하기 어렵다. 이런 불편함을 해소하기 위해 리액트 16.8에서 도입한 것이 훅이다. 훅(hook)은 함수에게 클래스 수준의 고급 기능을 부여하여 함수만으로도 많은 것을 할 수 있게 해주는 장치이다. 훅으로 인해 함수가 여러 복잡한 기능을 가질 수 있게 되었다.

▶ 함수 내부에 상태를 저장하고 관리한다.

▶ 생명주기 메서드로 초기화, 종료 처리 등을 처리할 수 있다.

▶ 이벤트를 받아 동작을 처리한다.

▶ 함수 안에 모든 것이 포함되므로 재사용하기 쉽다.

▶ 객체 지향을 잘 몰라도 쉽게 배우고 일관되게 만들 수 있다.

사실 함수는 클래스보다 한참 급이 낮은 개념이며 복잡한 것을 처리하기는 어렵다. 함수 안에 포함된 것은 모두 지역적이고 유지 기간이 짧아 값을 오래 저장할 수 없다. 앞에서 우리가 만들었던 카운트 예제를 다시 보자.

function Counter() {

let count = 10

...

function Counter() {

const [count, setCount] = useState(10);

...

변수든, 상태든 함수 안에 있으니 함수가 끝나면 사라질 운명이다. 그러나 자바스크립트는 클로저라는 기막힌 장치가 있어 이를 잘 활용하면 함수도 정보를 오랫동안 유지할 수 있다. 리액트 개발팀은 이런 문법을 적극 활용하여 함수에게 이전 상태를 기억하는 능력을 부여하였다.

또한 리액트 내부의 상태, 생명 주기 정보를 갈고리처럼 걸어서 액세스하는 것도 가능하다. 그래서 이런 형태의 함수에게 훅(Hook)이라는 멋진 이름을 붙였다. 훅은 정밀한 코드여서 오랜 기간 연구했으며 충분한 테스트를 거쳐 공개하였다.

함수가 어떻게 클래스를 대신할 수 있는지 훅의 원리를 연구해 보기 위해 useState의 동작 방식을 보여주는 간단한 예제를 분석해 보자. 실제 훅은 이보다 정교하고 복잡하지만 개념을 살펴 보기에는 충분하다. 브라우저에서 바로 실행할 수 있도록 HTML안에 자바스크립트 코드를 작성했다.

에제 : hook.html

<!DOCTYPE html>

<html>

<head>

<title>reacthook</title>

</head>

<body>

// 컴포넌트별 상태를 저장하는 배열. 전역이므로 값을 계속 유지한다.

let componentState = [];

// 다음 사용할 배열 위치(=슬롯). 0부터 시작

let currentStateIndex = 0;

function useState(initialState) {

// 상태를 저장할 슬롯 찾음

const slot = currentStateIndex;

// 비어 있으면 초기값을 저장한다.

if (componentState[slot] === undefined) {

componentState[slot] = initialState;

}

// 상태 변경 함수. 슬롯에 새 값을 대입한다.

// slot은 클로저에 의해 값을 유지한다.

const setState = (newState) => {

// 함수를 전달받았으면 함수에게 현재값을 전달하여 처리하고 그 결과를 슬롯에 기록한다.

if (typeof newState === 'function') {

componentState[slot] = newState(componentState[slot]);

// 값을 전달받았으면 슬롯에 값을 바로 기록한다.

} else {

componentState[slot] = newState;

}

// 상태가 바뀌면 다시 랜더링한다.

render();

};

// 다음 상태값을 저장할 슬롯 지정

currentStateIndex++;

// 슬롯에 저장된 값과 변경 함수를 배열로 묶어 리턴한다.

return [componentState[slot], setState];

}

// 두개의 정수, 문자열 상태를 가지는 샘플 컴포넌트

function Compo() {

const [count, setCount] = useState(0);

const [text, setText] = useState('One');

document.writeln('Count : ' + count + ' ,Text : ' + text + '<br />');

// 정수 증가, 문자열 갱신 메서드를 객체로 묶어 리턴한다.

return {

increment: () => setCount(prevCount => prevCount + 1),

updateText: (newText) => setText(newText),

};

}

function render() {

// 랜더링할 때마다 0번 슬롯부터 순회한다.

currentStateIndex = 0;

// 두 개의 메서드를 제공하는 컴포넌트 객체를 생성하여 리턴한다.

return Compo();

}

// 컴포넌트 생성. 이때 두 개의 상태가 초기화된다.

const compo = render();

// 정수 증가. setState에 의해 슬롯의 값이 1증가하고 다시 랜더링한다.

// Compo를 다시 생성. useState는 슬롯의 값 유지.

compo.increment();

// 문자열 변경

compo.updateText('Two');

// 숫자 한번 더 증가

compo.increment();

</script>

</body>

</html>

이 예제를 이해하려면 자바스크립트의 클로저와 화살표 함수 등의 고급 문법을 이해해야 하는데 사실 그렇게 어려운 문법도 아니다. 지금은 자바스크립트 문법을 설명할 단계는 아니므로 자세한 설명은 생략한다. 코드의 주석을 대충 읽어만 봐도 어떤 식으로 동작하는지 감을 잡을 수 있다.

대충 이런 식으로 구현했다는 것을 보여주는 것이므로 사실 굳이 다 이해하지 못해도 상관은 없지만 훅도 문법에 기반할 뿐 마술같은 존재는 아니라는 것만 인식하자. 나보다 똑똑한 사람들이 알아서 잘 만들어 놨겠거니 믿고 사용하면 된다. 실행 결과는 다음과 같다.

Count : 0 ,Text : One

Count : 1 ,Text : One

Count : 1 ,Text : Two

Count : 2 ,Text : Two

숫자를 증가시키는 increment 함수는 값을 전달하는게 아니라 이전 값을 읽어 1증가시키는 함수를 전달한다. 왜 이렇게 되어 있는지는 증가값을 직접 전달해 보면 알 수 있다.

increment: () => setCount(count + 1),

이러면 값이 한번만 증가하여 0이 1이 될 뿐이며 1은 증가시켜도 2가 되지 않는다. 왜냐하면 count는 Compo의 지역 변수이되 increment 함수에 의해 클로저로 갇혀 있어 최초의 값을 가질 뿐 상태 배열의 실시간값을 알지 못한다. 그래서 증가한 값이 아니라 증가시켜 주는 함수를 전달하여 호출 시점의 실제값을 읽어 증가하도록 해야 한다.

훅은 계산이나 동작을 처리하는 일반 함수와는 달리 컴포넌트를 생성한다. 똑같은 함수 모양이라도 클래스에 준하는 기능을 제공하니 확실히 급 차이가 있다. 역할이 다르다보니 일반 함수에 비해 엄격한 규칙이 적용된다.

▶ 훅은 컴포넌트의 최상위 레벨에서만 호출해야 하며 조건문이나 반복문 블록, 지역 함수 안에서 호출해서는 안된다. 다음 코드를 보자. 조건문 안에서 어떤 상태를 만들고 관리하는 것은 딱 봐도 뭔가 어울리지 않는다.

if (조건) {

useState(...)

}

▶ 훅은 리액트 함수 컴포넌트에서만 호출해야 하며 일반 함수에서 호출해서는 안된다. 리액트 내부 구조에 접근하는 동작은 랜더링되는 컴포넌트 내에서만 필요하다.

▶ 리액트는 각 훅 호출을 컬렉션으로 관리하며 순서의 의존하여 상태를 연결한다. 그래서 랜더링할 때마다 항상 같은 순서로 호출한다. 위 코드의 currentStateIndex 변수가 순서를 관리하는 역할을 한다.

훅을 직접 만들어 쓸 수도 있다. 이때는 위의 규칙을 준수해야 하고 훅이라는 것을 명확히 표시하기 위해 이름을 항상 use로 시작할 것을 권장한다. 이 접두를 붙이는 순간 ESLint는 훅의 규칙을 잘 지키는지 알아서 검사해 준다.

함수 컴포넌트

훅을 적극 활용하면 함수만으로도 상태를 유지할 수 있고 생명 주기 메서드도 작성할 수 있다. 이런 능력을 총동원하면 함수로도 컴포넌트를 충분히 만들 수 있고 훨씬 더 편리하다. 요즘은 모든 컴포넌트를 함수형으로 만들 것을 권장하며 클래스 컴포넌트는 웬만하면 쓰지 말라고 권고한다. 그러나 더 복잡한 경우를 위해 클래스 컴포넌트도 계속 지원할 계획이라고 공식적으로 발표하였다.

지금까지 만든 ScoreBoard, Counter, AdBox 컴포넌트는 모두 함수형이다. 클래스형보다 간편해 쓰기도 편하고 컴포넌트로서의 요건은 다 갖추고 있어 기능적으로도 완벽하다. 그러나 함수형이라고 해서 아무렇게나 만들어 되는 것은 아니고 요건은 지켜야 한다. 다음 컴포넌트는 출력되지 않는다.

function scoreBoard(props) {

return (

<p>{props.name}님의 점수는 {props.score}입니다.</p>

</>

)

}

function App() {

return (

</>

);

}

컴포넌트의 이름은 HTML 태그와 구분하기 위해 첫자를 대문자로 쓰도록 강제한다. 별걸 다 간섭한다 싶겠지만 권장 사항이 아니라 강제 사항이다. 소문자로 된 태그는 HTML 태그라고 인식해 랜더링하지 않으며 무시해 버린다.

에러가 나지 않는 이유는 scoreBoard라는 HTML 태그가 장래에 생길 수 있다고 생각하고 DOM 트리에 그대로 써 버리기 때문이다. 브라우저도 이 태그를 인식하지 않으며 조용히 무시한다. 그래서 에러는 아니며 화면에 아무 것도 나타나지 않을 뿐이다. 때로는 명시적인 에러보다 조용한 무시가 더 위험하다.

함수형 컴포넌트는 function 키워드로 만드는데 꼭 그래야 하는 것은 아니다. 함수의 형태이기만 하면 함수 리터럴이나 화살표 함수를 const 변수로 대입받아도 된다. 필요할 때 호출할 수만 있으면 된다. 다음 두 형태 모두 가능하다.

const ScoreBoard = function(props) {

....

const ScoreBoard = (props) => {

....

취향에 따라 선택할 문제이되 나는 명시적인 함수 형태가 가독성에 유리하다고 생각하여 선호하는 편이다. 컴포넌트를 정의할 때는 완전한 함수 형태를 주로 사용한다. 그러나 이름이 없는 익명 함수는 안된다. 익명 함수로 정의하더라도 반드시 이름있는 변수나 상수로 대입받아야 한다. 컴포넌트는 재사용성이 기본인데 이름이 없으면 가상 DOM에 컴포넌트로 포함시킬 방법이 없다.

6-2.useEffect

부효과

리액트는 여러 가지 훅을 제공한다. 훅을 통해 복잡한 처리를 수행할 수 있기 때문에 함수만으로도 컴포넌트를 훌륭하게 만들 수 있다. 리액트가 제공하는 표준 훅부터 하나씩 익혀 보자. 상태를 관리하는 useState와 useReducer는 이미 사용해 봤다.

useEffect는 특정 상태가 바뀔 때의 후속 처리를 수행한다. 한 값이 바뀌면 자연스럽게 같이 바뀌거나 또는 연이어 처리해야 하는 필수 동작이 있다. 예를 들어 쇼핑몰에서 상품을 장바구니에 담으면 장바구니의 상품 개수를 증가시켜야 한다. 이처럼 변화에 의해 자동으로 적용되는 것을 부효과(Side Effect)라고 한다. 부수 효과라고 번역하기도 하는데 여기서는 가급적 짧은 단어를 사용하자. 사용형식은 다음과 같다.

useEffect(부효과콜백, [감시대상])

감시대상을 명시해 두면 이 값이 바뀔 때마다 부효과를 처리하는 콜백을 호출한다. 감시대상은 배열에 여러 개 지정할 수 있다. 이 값 중 하나라도 변할 때마다 처리해야 할 작업이 있으면 콜백 함수에서 처리한다. 카운트가 바뀔 때 로그를 출력해 보자. useState 예제에 다음 코드를 작성한다.

import {useEffect} from 'react';

function Counter() {

const [count, setCount] = useState(10);

function decrease() {

setCount(count - 1)

}

function increase() {

setCount(count + 1)

}

function doEffect() {

console.log('현재 카운트 : ' + count)

}

useEffect(doEffect, [count])

return (

<h2>{count}</h2>

</>

)

}

function App() {

return (

</>

)

}

배포 예제 선두에는 import문이 미리 작성되어 있지만 새로운 훅을 쓸 때마다 import 문은 알아서 추가해야 함을 잊지 말자. useEffec에 의해 count 상태가 바뀌면 doEffect 함수를 호출한다. 증감 버튼을 눌러 보면 콘솔창에 로그가 나타난다. 여기서는 확인을 위해 로그만 찍어 봤는데 카운트 변경 후 해야 할 복잡한 동작을 처리할 수도 있다.

count가 바뀌는 시점에 어떤 일을 하려면 increase, decrease 함수에서 직접 처리할 수도 있다. 다음과 같이 바뀐 시점에 부효과를 처리해도 일단 효과는 같다.

function decrease() {

setCount(count - 1)

console.log('현재 카운트 : ' + count)

}

function increase() {

setCount(count + 1)

console.log('현재 카운트 : ' + count)

}

그러나 이런 식이라면 count를 바꾸는 모든 곳에 이 코드를 작성해야 하니 비효율적이다. 또 상태 갱신은 비동기적이라 증감한 후에 읽어도 count는 이전 값이어서 한박자 느리다는 문제가 있다. 현재 카운트 출력이라는 애초에 목적에 맞지도 않다.

useEffect로 감시 대상을 지정해 두면 바뀌는 시점을 정확히 알 수 있다. 또한 감시 대상을 여러 개 지정하여 하나라도 바뀔 때 한꺼번에 부효과를 처리할 수 있는 이점도 있다. count 뿐만 아니라 delta, score가 바뀔 때도 똑같은 부효과 처리가 필요하다면 [] 괄호안에 감시 대상을 나열한다.

useEffect(doEffect, [count, delta, score])

세 상태중 하나라도 바뀌면 doEffect가 호출된다. 이 함수는 세 상태값을 종합적으로 고려하여 부효과를 처리한다. 만약 각 상태별로 처리할 부효과가 다르다면 각 상태에 대해 useEffect를 따로 지정한다.

useEffect(doCountEffect, [count]);

useEffect(doDeltaEffect, [delta]);

useEffect(doScoreEffect, [score]);

이렇게 되면 각 상태의 변화에 대해 독립적인 처리를 수행할 수 있다. 부효과 지정의 개수 제한은 없다.

초기화, 종료처리

어떤 컴포넌트는 확실한 초기화와 깔끔한 종료 처리가 중요하다. 스스로 자신의 실행 환경을 만들고 다 쓰고난 다음에는 정리하고 나가야 한다. 이런 처리는 보통 생명 주기의 onCreate와 onDestroy 등에서 처리하는데 리액트 컴포넌트에도 비슷한 시점이 있다.

useEffect의 감시대상은 하나일 수도 있고 여러 개일 수도 있다. 감시 대상이 아예 없거나 빈 배열로 지정하면 특수한 효과가 나타난다. 감시대상을 지정하지 않으면 랜더링할 때마다 부효과를 처리한다.

useEffect(콜백) // 랜더링할 때마다 콜백을 호출한다.

useEffect(콜백, []) // 처음 랜더링할 때 딱 한번만 호출한다.

빈 배열을 전달하면 컴포넌트를 최초 로드할 때 초기화를 수행한다. 또 콜백은 리턴값으로 정리 함수를 리턴할 수 있는데 이 함수는 컴포넌트를 종료할 때 호출된다. 이 두 기능을 사용하면 초기화와 종료 처리를 멋지게 수행할 수 있다. 컴포넌트의 생명 주기의 처음과 끝에 다음 두 사건이 발생한다.

▶마운트 : 컴포넌트를 생성하고 웹 페이지의 DOM에 하나의 노드로 자리 잡는다. 이때부터 사용자 눈에 보이며 스스로 동작하기 위한 초기화를 수행한다.

▶언마운트 : 컴포넌트를 숨겨 DOM에서 제거된다. 화면에서 사라지므로 초기화시 할당했던 자원을 반납해야 한다.

useEffect 훅으로 마운트와 언마운트 시점을 잡아 처리해 보자. 이 실습을 하려면 컴포넌트를 숨기고 보이는 처리가 필요해 부모 컴포넌트를 만들고 자식 컴포넌트에서 useEffect를 처리한다. 자원 할당이나 해제 등은 복잡하니 로그를 찍어 제대로 발생하는지만 확인해 보자.

function Child() {

function onMount() {

console.log('안녕하세요.')

return onUnMount;

}

function onUnMount() {

console.log('안녕히 가세요.')

}

useEffect(onMount, [])

return (

</>

)

}

function Parent() {

const [show, setShow] = useState(true)

return (

<button onClick={() => setShow(!show)}>{show ? "숨기기" : "보이기"}</button>

{show && <Child />}

</>

)

}

function App() {

return (

</>

)

}

부모는 자식의 보이기 상태를 관리하며 버튼을 누를 때 자식을 토글한다. 자식은 useEffect 훅의 감시 대상에 빈 괄호를 적어 마운트될 때 onMount를 호출하도록 했다. 처음 등장할 때 인사말을 출력한다. onMount는 종료 처리를 할 함수를 리턴하는데 인사말을 출력하는 onUnMount 함수를 리턴했다. 실행해 보자.

시작하자 마다 로그창에 '안녕하세요.' 인사말이 나타난다. 버튼을 눌러 숨기면 '안녕히 가세요.' 인사말을 출력한다. 다시 보이면 또 인사말이 나타난다. 마운트시 다시 숨겼다 나타나는 것처럼 보이는 이유는 main.tsx에 설정된 엄격 모드( <React.StrictMode>) 때문이다. 이 모드를 없애거나 프로덕션 환경에서는 정상적으로 한번만 출력된다.

마운트/언마운트에 대해 제대로 호출됨을 알 수 있다. 두 시점에 원하는 초기화와 종료 처리를 하면 된다. 코드를 이해하기 쉽도록 onMount, onUnMount 함수를 정의했는데 한번만 쓸 함수이므로 인라인으로 써도 된다.

useEffect(() => {

console.log('안녕하세요.')

return () => console.log('안녕히 가세요.')

}, [])

똑같은 코드이지만 함수의 인수에 함수가 있고 그 함수가 리턴하는 것도 함수라 처음 보면 헷갈린다. 이런 코드를 빠르게 파악할 수 있도록 습관이 들어야 한다.

타이머 구현

useEffect의 초기, 종료 처리 시점을 잘 활용하면 타이머를 돌리며 계속 증가하는 타이머를 쉽게 만들 수 있다.

function Counter() {

const [count, setCount] = useState(10);

useEffect(() => {

const timerId = setInterval(() => setCount(count => count + 1), 1000)

return () => clearInterval(timerId)

}, []);

return (

<h2>{count}</h2>

</>

)

}

function App() {

return (

</>

)

}

마운트될 때 1초 주기의 타이머를 설치하고 타이머 콜백에서 count를 1 증가시킨다. setCount(count + 1)로 하면 카운트가 증가하지 않으므로 함수를 전달해야 한다.

정리 함수는 타이머를 해제한다. 해제를 위해 설치한 타이머의 ID를 timerId에 대입해 두고 해제할 때 전달했다. 지역 변수여서 해제시 값을 잃어 버릴 거 같지만 클로저에 갇혀 있어 값을 계속 유지한다. 굉장히 안정적인 코드이며 권장되는 패턴이다.

이 예제의 경우 페이지를 떠날 때나 브라우저를 닫을 때만 언마운트되므로 화면이 실행중인 동안에는 타이머가 멈추지 않는다.

6-3.useRef

useRef

useRef 훅은 값에 대한 참조를 저장하는 역할을 한다. 단순히 저장만 하기 때문에 값 변화에 대해 랜더링이 발생하지 않는다는 점에서 상태와는 다르다. 이런 특성을 이용하여 DOM 엘리먼트를 제어하거나 값을 읽을 때 참조를 저장한다. 다음 예제는 사용자가 입력한 이름에 대해 인사말을 출력한다.

import {useRef} from 'react';

function Login() {

const nameInput = useRef(null);

return (

<button onClick={()=>{alert('안녕하세요 ' + nameInput.current.value + '님')}}>인사</button>

</>

)

}

function App() {

return (

</>

);

}

입력 컨트롤과 버튼을 배치하고 이름을 입력한 후 인사 버튼을 누르면 사용자의 이름을 읽어 메시지를 출력한다.

이 동작이 가능하려면 사용자가 입력 컨트롤에 적은 이름을 읽어야 하며 이를 위해 입력 컨트롤의 참조가 필요하다. 컨트롤에 대한 참조를 얻기 위해 useRef 훅을 사용한다. useRef의 인수로 초기값을 지정하는데 최초 랜더링할 때는 DOM 요소가 아직 생성되어 있지 않아 가리킬 수 없다. 그래서 초기값을 null로 주어 대상이 없음을 분명히 표시하고 참조할 엘리먼트의 ref 속성에 참조 변수를 대입하는 식으로 초기화한다.

<input ref={nameInput} 지정에 의해 이후부터 nameInput 변수가 이 컨트롤을 가리키며 input 엘리먼트를 참조할 수 있다. 참조할 엘리먼트를 읽을 때는 current 속성을 읽는다. nameInput.current가 입력 컨트롤이고 value 속성을 통해 사용자가 입력해 놓은 내용을 읽을 수 있다.

컨트롤의 값을 읽는 것 외에 focus 메서드로 포커스를 줄 수도 있고 style.visibility 속성에 'hidden'을 대입하여 숨길 수도 있다. 참조만 가지고 있으면 어떤 동작이든 가능하다. useRef 훅을 쓰는 대신 DOM 함수로 직접 엘리먼트를 찾아서 참조하는 것도 가능하다. 참조할 컨트롤에 id 속성을 지정하고 getElementById 함수로 찾으면 된다.

function Login() {

return (

<button onClick={()=>{alert('안녕하세요 ' + document.getElementById("who").value + '님')}}>

인사</button>

</>

)

}

이렇게 쓰면 버튼을 누를 때마다 매번 새로 찾으니 속도가 느리다. useRef는 최초 딱 한번만 찾아 놓고 랜더링을 다시 해도 그 참조를 유지하므로 더 빠르다. 버튼 클릭시의 반응 속도차 정도는 큰 의미 없지만 루프내에서 자주 참조한다면 심각한 차이가 발생한다.

리액트에서 자바스크립트를 쓸 수 있으므로 DOM을 직접 조작하는 것이 가능하지만 권장하지 않는다. 리액트는 가상 DOM에 기반하여 동작하는데 외부에서 임의로 DOM을 변경해 버리면 리액트가 이 사실을 알 수 없기 때문이다. 두 방법으로 DOM을 조작하면 성능 최적화도 할 수 없으며 복잡해지고 예측도 어려워 골치아픈 버그의 원인이 된다.

포커스 관리, 멀티미디어 재생, 외부 라이브러리와의 연동 등 리액트로 처리하기 어려운 경우에 한해서만 조심스럽게 사용해야 하며 리액트 내부의 상태와 동기화하도록 항상 신경써야 한다.

타이머 ID 저장

useRef는 컴포넌트내의 영구 데이터를 저장하는 용도로도 사용한다. 함수 내부의 지역 변수는 영구적으로 값을 저장하지 못하지만 useRef로 저장하면 값을 유지할 수 있다. 함수 컴포넌트가 클래스 수준의 인스턴스 변수를 가질 수 있도록 해 준다.

앞에서 useEffect 훅으로 구현한 타이머는 시작 직후부터 끝날 때까지 가동하므로 훅 내부의 지역 변수에 타이머 ID를 저장해도 문제가 없었다. 이번에는 실행중에 버튼으로 시작, 중지를 명령할 수 있는 타이머를 만들어 보자. 타이머를 설치, 해제해야 하므로 타이머 ID를 저장해야 하며 이때 useRef 훅을 사용한다.

function Counter() {

const [count, setCount] = useState(10);

const timerRef = useRef(null);

function handleStart() {

if (timerRef.current === null) {

timerRef.current = setInterval(() =>

setCount(count => count + 1), 100)

}

function handleStop() {

if (timerRef.current !== null) {

clearInterval(timerRef.current)

timerRef.current = null

}

return (

<h2>{count}</h2>

</>

)

}

function App() {

return (

</>

)

}

마운트 직후에 타이머는 정지 상태이며 그래서 useRef훅에서 timerRef는 null로 초기화한다. 시작 버튼을 누르면 0.1초 단위의 타이머를 생성하고 timerRef.current에 ID를 저장해 둔다. useRef는 참조만 저장할 뿐이며 내부의 실제값은 current 속성을 읽어야 한다. 타이머에서 카운트를 계속 증가한다.

정지 버튼을 누르면 저장해둔 ID를 사용하여 타이머를 해제하며 null로 무효화한다. 시작, 정지시 if문으로 타이머의 유효성을 점검하여 이미 설치한 상태에서 재설치하지 않도록 했다. 해제시에도 원칙에 따라 조건을 점검하고는 있지만 clearInterval이 무효한 ID는 무시하므로 실제로는 생략해도 무방하다. 최초 시작 후 정지 상태이며 시작 버튼을 누르면 타이머가 돌고 중지 버튼을 누르면 카운트를 멈춘다.

이 예제에서 timerRef는 함수 내부에 있지만 useRef 훅에 의해 마치 멤버 변수처럼 값을 계속 유지한다. ID는 단순한 값이니 지역 변수로 저장해도 될 거 같지만 절대 안된다. 왜 그런지 예제를 만들어 보자.

function Counter() {

const [count, setCount] = useState(10);

let timerId = null;

function handleStart() {

if (timerId === null) {

timerId = setInterval(() =>

setCount(count => count + 1), 100)

}

function handleStop() {

if (timerId !== null) {

clearInterval(timerId)

timerId = null

}

....

timerId가 지역 변수이면 함수가 실행중인 동안만 값을 유지하며 다음 랜더링시에는 초기값인 null로 돌아가 버린다. ID를 잃어 버리면 해제할 수 없으므로 중지 버튼을 눌러도 타이머가 멈추지 않는다. 뿐만 아니라 시작 버튼을 또 누르면 이전 타이머와는 다른 새로운 타이머를 하나 더 설치하여 카운트가 매 주기마다 2번 증가한다.

또한 컴포넌트를 언마운트하거나 페이지를 벗어나도 타이머를 해제할 수 없으므로 리소스가 누출되는 심각한 문제가 발생한다. 이 모든 문제의 원인은 함수 컴포넌트의 지역 변수가 값을 영구적으로 저장할 능력이 없기 때문이다. 이 능력을 부여하는 장치가 바로 useRef훅이다.

의존 배열

문제를 해결하는 방법은 항상 여러 가지가 있다. 각 방법마다 장단점이 있고 잘못된 방법을 선택하면 함정에 빠질 위험도 있다. 타이머를 설치/해제하지 말고 useEffect에서 계속 설치해 두되 isRunning 상태값 하나로 카운트 증가 여부를 통제하는 방법도 가능하다.

어떤 동작을 할 것인지 말 것인지는 둘 중 하나를 선택하는 문제이므로 상태로 저장하고 통제할 수 있다. 과연 가능한지 예제를 만들어 보자.

function Counter() {

const [count, setCount] = useState(10);

const [isRunning, setIsRunning] = useState(false);

useEffect(() => {

const timerId = setInterval(() => {

if (isRunning) {

setCount(count => count + 1)

}

}, 100)

return () => {

clearInterval(timerId)

}

}, [isRunning]);

return (

<h2>{count}</h2>

<button onClick={() => setIsRunning(true)}>시작</button>

<button onClick={() => setIsRunning(false)}>중지</button>

</>

)

}

function App() {

return (

</>

)

}

isRunning 상태는 카운트 증가 여부를 결정하는 허가 변수이며 초기값은 false이다. 두 버튼을 클릭하면 isRunning의 상태값을 변경하고 상태가 바뀔 때 타이머의 동작이 바뀌어야 하므로 useEffect 훅의 감시 대상에 [isRunning]을 반드시 적어야 한다.

isRunning의 상태가 바뀌면 useEffect는 정리 함수를 호출하여 타이머를 해제하고 바뀐 상태에 따라 타이머를 재가동한다. isRunning이 false이면 타이머를 가동하더라도 카운트를 증가시키는 동작은 하지 않는다. 즉, 타이머는 항상 설치해 놓되 isRunning에 따라 카운트 증가 여부가 달라진다.

이 예제의 동작 방식은 어렵지 않게 이해할 수 있고 코드가 바뀐 부분도 많지 않다. 그런데 useEffect의 감시 대상에 왜 [isRunning]이 지정되어 있을까? 이 지정 없이 [] 빈 괄호만 적어 놔도 타이머는 설치되고 isRunning 상태값은 잘 바뀔 것처럼 보인다. 과연 그런지 테스트해 보자.

useEffect(() => {

....

}, []);

이러면 ESLint가 먼저 이상을 감지하고 위험하다는 경고를 보낸다. 감시 대상을 빼면 안된다는 충고이다.

비록 경고는 발생하지만 빈 괄호는 마운트시에 한번만 실행하라는 뜻으로 이 자체가 문법 에러는 아니어서 실행은 가능하다. 과연 제대로 되는지 실행해 보면 브라우저에 화면은 제대로 나타난다. 그러나 원하는대로 동작하지 않는다.

useEffect는 마운트될 때 딱 한번만 실행되고 이때 클로저에 캡처되는 isRunning의 초기값은 false이다. 이후 시작 버튼을 눌러 isRunning을 true로 바꾸어도 이미 설치한 타이머는 이 변화를 알 수 없는 상태이다. 낡은 클로저(Stale Closure)가 상태 변화에 반응하지 않으니 결국 카운트는 증가하지 않는다.

그래서 useEffect의 의존 배열에 isRunning을 적어 이 상태가 바뀌면 변경된 상태값을 참조하여 타이머를 새로 설치하도록 해야 한다. useEffect의 부효과 처리 코드에 isRunning을 참조하는 문장이 있으니 이 상태가 바뀌면 부효과를 다시 처리해야 논리적인 이상이 없다. ESLint는 이를 정확히 간파한 것이다.

타이머를 항상 설치하지 않고 isRunning이 true일 때만 설치하는 방법도 가능하다. 타이머에서 할 일이 카운트 증가밖에 없다면 빈 타이머를 설치하는 것보다는 아예 타이머를 설치하지 않는 방법이 더 간단하다.

function Counter() {

const [count, setCount] = useState(10);

const [isRunning, setIsRunning] = useState(false);

useEffect(() => {

let timerId = null;

if (isRunning) {

timerId = setInterval(() => {

setCount(count => count + 1)

}, 1000)

}

return () => {

clearInterval(timerId)

}

}, [isRunning]);

return (

<h2>{count}</h2>

<button onClick={() => setIsRunning(true)}>시작</button>

<button onClick={() => setIsRunning(false)}>중지</button>

</>

)

}

function App() {

return (

</>

)

}

이 경우 타이머 ID는 조건에 따라 설치 여부가 달라지므로 상수일 수 없으며 변수여야 한다. 허가 상태가 바뀔 때마다 타이머를 재설치하기 위해 useEffect의 의존 배열에는 isRunning을 지정해야 한다.

아무 것도 하지 않는 빈 타이머를 돌리는 것보다는 이 방법이 리소스 절약에 유리하다. 만약 타이머에서 해야 할 다른 일도 있다면 이때는 앞 예제처럼 타이머는 계속 돌리고 상태 변수는 카운트 증가 여부만 제어하는 방식이 적합하다.

상태 무한루프

랜더링을 할 때마다 처리할 부효과가 있다고 하자. 시간이 얼마나 걸렸는지 측정하거나 자원 사용량을 알아낼 수도 있는데 여기서는 로그만 출력해 보자. 랜더링할 때마다 실행할 코드라면 useEffect훅의 의존 배열을 아예 생략해 버리면 된다.

function Fruit() {

const [fruit, setFruit] = useState("Choice")

function onRender() {

console.log('랜더링')

}

useEffect(onRender)

return (

<h2>{fruit}</h2>

<button onClick={() => setFruit("Apple")}>Apple</button> 

<button onClick={() => setFruit("Orange")}>Orange</button>

</>

)

}

function App() {

return (

</>

)

}

useEffect 훅에서 부효과 함수로 onRender를 지정하고 의존 배열은 적지 않았다. 버튼을 누를 때마다 랜더링을 다시 한다는 로그가 출력된다.

잘 동작하지만 뭔가 심심하고 같은 로그만 찍히니 재미도 없다. 단순히 랜더링을 한다는 사실만 찍을게 아니라 몇 번째 그리는 것인지 카운트를 출력해 보자. 상태 변수를 하나 더 만들고 그릴 때마다 1씩 증가시키고 그 값을 찍으면 될 거 같다.

function Fruit() {

const [fruit, setFruit] = useState("Choice")

const [rendCount, setRendCount] = useState(0);

function onRender() {

setRendCount(rendCount + 1)

console.log('랜더링 회수 : ' + rendCount)

}

useEffect(onRender)

return (

<h2>{fruit}</h2>

<button onClick={() => setFruit("Apple")}>Apple</button> 

<button onClick={() => setFruit("Orange")}>Orange</button>

<h2>저는 랜더링 회수를 카운트합니다.</h2>

</>

)

}

function App() {

return (

</>

)

}

rendCount 상태를 정의하고 onRender에서 1 증가시킨 후 그 값을 로그로 출력했다. Apple, Orange 버튼을 누를 때마다 랜더링 회수가 증가할 거 같지만 실행해 보면 그야 말로 난리가 난다.

CPU는 미쳐 날뛰며 컴퓨터 팬이 우렁차게 돌기 시작한다. 이대로 계속 방치하면 방이 따뜻해지는 난방 효과가 나타난다. 랜더링 회수는 빠른 속도로 증가하며 중간 중간에 '이거 너무 하잖아'라는 투덜거림이 보인다.

이렇게 되는 이유는 onRender 함수가 과일을 바꿀 때만 호출되는 것이 아니라 상태중 하나라도 바뀔 때마다 호출되기 때문이다. onRender 안에서 rendCount 상태를 바꾸고 있으니 결국 자신이 자신을 다시 호출하는 무한 루프에 빠진다.

문제의 핵심은 rendCount가 랜더링을 유발하는 상태값이라는 것이다. 화면에 출력하지 않고 로그로만 출력할 단순 변수임에도 상태로 정의한 것이 패착의 원인이다. 그렇다면 상태가 아닌 단순 변수로 정의하면 어떻게 될까?

function Fruit() {

const [fruit, setFruit] = useState("Choice")

let rendCount = 0;

function onRender() {

rendCount++

console.log('랜더링 회수 : ' + rendCount)

}

이 코드는 말썽은 없지만 랜더링 회수가 항상 1이다. 왜냐하면 지역 변수는 함수가 호출될때마다 초기화되고 카운트값을 유지할 능력이 없기 때문이다. 위 두 예제의 문제점을 정리해 보면 다음과 같다.

▶rendCount 상태 : 값은 기억하지만 변경에 의해 랜더링이 발생한다.

▶rendCount 변수 : 값을 바꿔도 랜더링은 발생하지 않지만 값을 기억하지 못한다.

문제를 알았으니 해결책을 찾아야 한다. 값을 기억하면서도 랜더링을 발생시키지 않는 장치가 필요하가. 그게 바로 useRef이다.

function Fruit() {

const [fruit, setFruit] = useState("Choice")

const rendCount = useRef(0);

function onRender() {

rendCount.current++

console.log('랜더링 회수 : ' + rendCount.current)

}

useEffect(onRender)

return (

<h2>{fruit}</h2>

<button onClick={() => setFruit("Apple")}>Apple</button> 

<button onClick={() => setFruit("Orange")}>Orange</button>

<h2>저는 랜더링 회수를 카운트합니다.</h2>

</>

)

}

function App() {

return (

</>

)

}

rendCount를 useRef로 선언하고 초기값을 0으로 지정했다. 읽거나 변경할 때는 current 속성을 참조하면 된다. 값을 잘 기억하면서도 무한 루프는 발생하지 않는다.

useState와 뭐가 다른지 명확히 알 수 있는 예제이다. 화면에 보일 필요 없고 내부적인 값을 저장할 때는 상태가 아닌 참조를 사용한다.

6-4.useContext

컨텍스트

컴포넌트가 다른 컴포넌트를 포함하는 경우는 흔하며 컴포넌트끼리 계층을 이루어 더 복잡한 부품을 만든다. 이때 부모는 자신에게 속한 자식의 속성을 받아 대신 전달해 줘야 한다. 다음 예제는 App-Parent-Child 세 개의 계층으로 된 컴포넌트를 만든다.

function Parent(props) {

return (

<p>I am a Parent</p>

</>

)

}

function Child(props) {

return (

<p>It is Child</p>

<h2>{props.version === 'basic' ? '무료버전':'유료버전'}</h2>

</>

)

}

function App() {

return (

</>

);

}

웹앱도 과금 여부에 따라 기능에 차이를 두어 유료 버전을 만들 수 있다. 이를 구분하려면 일반용 무료 버전(basic)인지 돈받고 파는 유료 버전(Pro)인지 구분하고 코드의 모든 부분에서 참조해야 한다.

App에서 Parent에게 제품 버전을 version 속성으로 알려 주지만 Parent는 껍데기일 뿐이라 이 정보를 직접 사용하지는 않는다. 실제 기능을 구현하는 제일 아래쪽의 Child만 이 속성을 사용한다. App에서 Child를 직접 생성하지 않으니 Child에게 version을 바로 전달할 방법은 없고 Parent를 경유해 Child에게까지 가도록 해야 한다.

이 예제에서는 3단계이지만 경우에 따라서는 6단계, 7단계를 내려갈 수도 있다. 계층을 따라 아래쪽으로 쭉 파고 든다고 해서 속성 드릴링(Prop drilling)이라고 하며 사용하지 않는 인수를 오로지 아래로 전달하기 위해 받아야 하므로 통과 인수라고도 한다.

여기 저기서 사용할 전역적인 값을 속성을 통해 일일이 전달하는 것은 비효율적이다. 중간 단계에서는 직접 쓰지 않지만 전달을 위해 어쩔 수 없이 받아야 하니 구조상으로 바람직하지 않고 속성이 늘어나거나 줄어들 때 관리하기도 어렵다.

색상이나 크기, 테마처럼 앱 전체가 영향을 받는 값은 전역으로 정의하고 모든 컴포넌트가 자유롭게 참조하는 것이 편리하다. 전역 저장소를 컨텍스트라고 하며 여기에 값을 넣어 두면 어디서나 참조할 수 있다. 컨텍스트를 사용하여 통과 인수를 제거해 보자.

import { createContext, useContext } from "react";

const VersionContext = createContext();

function Parent() {

return (

<p>I am a Parent</p>

</>

)

}

function Child() {

const version = useContext(VersionContext);

return (

<p>It is Child</p>

<h2>{version === 'basic' ? '무료버전':'유료버전'}</h2>

</>

)

}

function App() {

return (

<VersionContext.Provider value='basic'>

</VersionContext.Provider>

</>

);

}

컨텍스트는 createContext 함수로 생성한다. 전역적인 저장소이므로 이 선언문은 당연히 최상위 레벨의 전역 범위에 있어야 한다. 이 함수는 훅이 아니라 그냥 자바스크립트 함수일 뿐이어서 함수 안에서도 호출할 수는 있지만 공유를 위해 생성하는 객체가 함수 안에 있다는 것 자체가 말이 안되고 실제로도 동작하지 않는다.

컨텍스트의 Provider 컴포넌트로 값을 지정하는데 이때 공유할 속성의 이름은 value로 약속되어 있다. Provider 컴포넌트로 둘러싸인 영역에서는 컨텍스트의 정보를 언제든지 꺼내 사용할 수 있다. 예제에서는 value에 'basic'값을 지정하고 <Parent/ > 컴포넌트를 감쌌으므로 Parent는 물론이고 Parent에 속한 모든 컴포넌트가 VersionContext의 정보를 사용할 수 있다.

컨텍스트의 값을 꺼낼 때는 useContext훅을 사용한다. Child는 VersionContext에 저장된 값을 꺼내 version으로 대입받아 코드에서 사용한다. Provider에서 값을 전달할 때는 항상 value이지만 꺼내 쓸 때는 원하는 이름으로 대입받을 수 있다. Parent가 통과 인수를 전달하지 않아도 하위 컴포넌트가 필요할 때 값을 꺼내 쓸 수 있는 이점이 있다. Provider 의 value 속성을 변경하면 Child가 즉시 알아챈다.

여기서는 단일 문자열 하나만 저장했는데 컨텍스트에 객체를 저장하면 여러 정보를 넣어둘 수 있다. 전역적인 값을 편리하게 저장할 수 있는 이점이 있지만 자식 컴포넌트와 부모 컴포넌트가 컨텍스트로 묶여 있는 상태라 단체로 같이 움직여야 하는 것은 단점이다. 독립성은 떨어지며 재활용하기는 어렵다.

기본값 지정

createContext 함수는 보통 인수없이 호출하지만 전역 속성의 디폴트값을 인수로 지정할 수 있다. 이 값은 Provider로 감싸지 않은 상태에서 useContext 훅으로 컨텍스트를 읽을 때 적용된다. 기본값을 basic으로 지정하고 명시적으로 지정할 때만 pro로 적용해 보자.

const VersionContext = createContext('basic');

function Parent() {

return (

<p>I am a Parent</p>

</>

)

}

function Child() {

const version = useContext(VersionContext);

return (

<p>It is Child</p>

<h2>{version === 'basic' ? '무료버전':(version === 'pro' ? '유료버전':'미정')}</h2>

</>

)

}

function App() {

return (

<VersionContext.Provider value='pro'>

</VersionContext.Provider>

</>

);

}

Provider에서 value를 명확히 pro로 지정했으면 Child가 읽는 값은 pro이다. 반면 Provider를 생략하거나 Provider 외부에 있는 컴포넌트는 기본값인 basic을 읽는다.

function App() {

return (

</>

);

}

여기까지는 상식적이지만 다음 결과는 좀 의외일 수도 있다. Provider는 있지만 value를 생략하면 이때는 기본값이 아닌 undefined가 적용된다.

function App() {

return (

<VersionContext.Provider>

</VersionContext.Provider>

</>

);

}

즉, createContext로 지정하는 디폴트값은 Provider를 생략했을 때 적용되는 값이지 value를 생략할 때 적용되는 값이 아니다. 속성을 항상 명시적으로 전달한다면 디폴트값은 굳이 지정하지 않아도 상관 없다.

컨텍스트의 전역값 변경

컨텍스트에 저장해 둔 전역값은 필요에 따라 바꿀 수도 있다. 예를 들어 무료 버전으로 시작했다가 사용자가 제품을 등록하면 그때부터는 유료 버전이 된다. 변경하지 않을 값이라면 그냥 상수를 쓰면 될 뿐 굳이 컨텍스트에 저장할 필요도 없다. 버튼 두 개를 배치하고 전역 변수를 바꿔 보자.

const VersionContext = createContext();

function Parent() {

return (

<p>I am a Parent</p>

</>

)

}

function Child() {

let version = useContext(VersionContext);

return (

<p>It is Child</p>

<h2>{version === 'basic' ? '무료버전':'유료버전'}</h2>

<button onClick={() => version = 'pro'}>제품 등록</button>  

<button onClick={() => version = 'basic'}>등록 취소</button>

</>

)

}

function App() {

return (

<VersionContext.Provider value='basic'>

</VersionContext.Provider>

</>

);

}

version은 상수가 아닌 변수이므로 const가 아닌 let으로 선언한다. 두 버튼을 클릭하면 version을 pro와 basic으로 토글한다. 그러나 이 예제는 여러 가지 이유로 원하는대로 동작하지 않는다.

▶ version은 컨텍스트에서 읽은 사본이며 Child의 지역 변수에 불과하다. 이 값을 바꾼다고 해서 컨텍스트에 저장된 값이 바뀌는 것은 아니다.

▶ 설사 값이 바뀌었다고 하더라도 변수에 값을 대입하는 것만으로 랜더링이 발생하지는 않는다. 화면에는 아무 변화가 없다.

변경 가능하고 랜더링까지 하려면 결국 상태여야 한다. 또한 이 상태가 전역적이려면 컨텍스트 안에 넣어야 한다.

const VersionContext = createContext();

function Parent() {

return (

<p>I am a Parent</p>

</>

)

}

function Child() {

const {version, setVersion} = useContext(VersionContext);

return (

<p>It is Child</p>

<h2>{version === 'basic' ? '무료버전':'유료버전'}</h2>

<button onClick={() => setVersion('pro')}>제품 등록</button>  

<button onClick={() => setVersion('basic')}>등록 취소</button>

</>

)

}

function App() {

const [version, setVersion] = useState('basic');

return (

<VersionContext.Provider value = {{version, setVersion}}>

</VersionContext.Provider>

</>

);

}

컨텍스트를 제공하는 App 또는 별도의 전역 컴포넌트에 version 상태를 정의한다. 그리고 상태값 version과 상태를 변경하는 함수 setVersion을 객체로 묶어 컨텍스트에 저장한다. value = {{version, setVersion}} 대입문에서 안쪽 괄호는 객체이고 바깥쪽 괄호는 JSX의 값 표현식이다.

Child에서 useContext로 객체를 꺼내면 이 안에 version 상태와 이 상태를 변경하는 setVersion이 들어 있다. 현재 버전은 <h2>에 출력하고 버튼의 클릭 이벤트에서 setVersion을 호출하여 상태를 변경한다. 상태가 바뀌면 즉시 랜더링이 발생하고 화면이 갱신된다.

useState와 useContext를 같이 쓰니 어려워 보이지만 그리 복잡한 예제는 아니다. 컨텍스트는 전역 변수를 저장할 뿐 전역 상태를 저장하는 것은 아니므로 useState로 상태를 정의하고 이 상태를 컨텍스트에 넣는다. 이때 컨텍스트에 값뿐만 아니라 변경 함수까지 같이 넣어 둔다는게 핵심이다.

전역 변수와의 차이점

값을 영구적으로 저장할 목적이라면 전역 변수라는 것도 있다. 최상위 레벨에 변수를 선언해 두고 값을 참조하거나 변경하면 될 거 같다. 예상 가능하듯 전역 변수로는 값을 저장할 수 없다.

let version = 'basic';

function Parent() {

return (

<p>I am a Parent</p>

</>

)

}

function Child() {

return (

<p>It is Child</p>

<h2>{version === 'basic' ? '무료버전':'유료버전'}</h2>

<button onClick={() => version = 'pro'}>제품등록</button>  

<button onClick={() => version = 'basic'}>등록 취소</button>

</>

)

}

function App() {

return (

</>

);

}

최상위 레벨에 선언한 전역 변수이므로 랜더링이 발생해도 값을 유지한다. 또 필요할 때 전역 변수의 값을 마음대로 변경할 수도 있다. 그러나 리액트는 변수가 변경된 것을 전혀 알지 못하며 따라서 값을 바꿔도 랜더링이 발생하지 않는다. 이런 간단한 방법이 가능하다면 상태니 컨텍스트니 하는 복잡한 것을 만들 필요가 없을 것이다.

설사 이런 문제가 아니더라도 전역 변수는 일반적으로 기피 대상이다. 어디서 누가 값을 바꿀지 알 수 없으니 골치 아픈 버그의 원인이 되고 누구에게나 공개되어 있으니 보안상의 문제도 있다. 컴포넌트가 특정 전역 변수에 의존하면 독립성도 떨어지고 재활용하기도 어렵다.

6-5.메모

useMemo

useMemo는 함수의 실행 결과를 미리 계산하여 캐시에 저장해 둠으로써 중복 실행을 방지하고 실행 속도를 개선하는 기법이다. 사용 형식은 다음과 같다.

결과값 = useMemo(콜백, [의존배열])

의존 배열내의 값 중 하나라도 변경이 있으면 콜백을 재실행하여 결과값을 다시 계산해 놓는다. 값이 바뀌지 않으면 다시 실행할 필요없이 미리 계산해 놓은 결과값을 계속 사용한다. 의존배열이 없거나 비어 있으면 최초 랜더링시 딱 한번만 계산한다. 실행중에 변하지 않는 거대한 상수값을 사용할 때는 의존 배열을 비워 두기도 한다.

일상 생활에서 중요한 걸 메모해 두듯 어딘가에 적어 놓는다고 해서 메모화(Memoization)라고 한다. 다음은 메모화의 필요성과 동작을 보여주는 간단한 예이다.

import { useMemo } from 'react';

function SumArray() {

const nums = [1,2,3,4];

const sum = useMemo(() => {

let total = 0;

for (let i = 0;i < nums.length;i++) total += nums[i];

return total;

}, [nums]);

return (

</>

)

}

function App() {

return (

</>

);

}

이 예제는 1 ~ 4까지의 정수 배열 nums의 합계를 미리 계산하여 sum 변수에 대입해 둔다. 최초 랜더링시 또는 nums 배열이 바뀔 때마다 콜백을 다시 호출하여 재계산하되 이 예제에서는 외부에서 nums를 변경하는 부분이 없어 딱 한번만 계산하는 셈이다. 합계를 구하는 콜백의 동작은 지극히 상식적인 코드이되 더 간단하게 줄일 수도 있다.

const sum = useMemo(() => { return nums.reduce((a,c) => a+c, 0)}, [nums]);

이 코드가 더 간단하지만 화살표 함수가 중복되면 가독성이 떨어져 쉽게 풀어썼다. 이렇게 계산한 결과를 <h3> 엘리먼트에 담아 출력했다.

어차피 계산해야할 값이라면 컴포넌트 시작 직후에 계산해도 똑같은 결과를 얻을 수 있다. 다음 예제도 실행 결과는 같다.

function SumArray() {

const nums = [1,2,3,4];

let sum = 0;

for (let i = 0;i < nums.length;i++) {

sum += nums[i];

}

return (

</>

)

}

이렇게 되면 랜더링을 할 때마다 계산 루프를 매번 다시 실행하기 때문에 불필요한 연산을 하는 셈이다. useMemo는 딱 한번만 계산하고 의존 배열이 바뀌지 않으면 저장해 놓은 값을 사용하므로 성능 향상 효과가 뚜렸하다. 또 useMemo는 한번 계산한 값을 재사용하겠다는 의사를 명확히 하고 어떤 값이 바뀔 때 재계산하는지를 분명히 표시하여 개발자간의 의사 소통이 쉽다.

예제를 확장하여 합계를 계산해둘 범위를 상태로 지정하고 실행중에 범위를 조정하는 기능을 넣어 보자. 범위가 바뀌면 합계도 재계산해야 하며 로그를 출력하여 재계산함을 표시했다. 합계를 보여줄 캡션을 변경하는 기능도 넣었다.

function SumArray() {

const [from, setFrom] = useState(5);

const [to, setTo] = useState(10);

const [cap, setCap] = useState('합계');

const sum = useMemo(() => {

let total = 0;

console.log('합계 재계산');

for (let i = from;i <= to;i++) total += i;

return total;

}, [from, to]);

return (

<button onClick={() => setFrom(from - 1)}>from 감소</button> 

<button onClick={() => setTo(to + 1)}>to 증가</button> 

<button onClick={() => setCap(cap === '합계' ? "Total":"합계")}>cap 변경</button>

</>

)

}

function App() {

return (

</>

);

}

useMemo의 의존 배열에 from과 to를 지정했다. from 감소, to 증가 버튼을 누르면 의존 배열이 바뀌므로 useMemo가 재계산을 수행한다.

그러나 캡션은 출력 형태를 지정할 뿐 계산 결과에는 영향을 미치지 않아 재계산할 필요가 없다. useMemo는 의존 배열 내의 변수가 바뀔 때만 재계산하는데 cap은 의존 배열에 없으니 불필요한 재계산을 하지 않는다.

메모화를 어느 수준까지 할 것인가는 예상 시간을 보고 잘 결정해야 한다. useMemo 자체도 의존값을 일일이 비교하느라 시간을 소모하기 때문에 항상 이득이라고 볼 수 없다. 사실 정수합을 구하는 간단한 연산은 굳이 메모화까지 할 필요는 없다. 그러나 배열이 거대하고 연산도 복잡하다면 메모화로 인한 성능 향상 효과가 있다.

특히 외부 네트워크 입출력을 할 때는 지구 반대편에 있을지도 모르는 서버와 통신해야 하므로 꼭 필요치 않은 연산은 최소화해야 한다. 예를 들어 기상 서버에 접속해서 현재 온도를 조사한다면 최소한 분단위는 바뀌었을 때 재조사하는 것이 합리적이다. 온도가 초단위로 바뀔리는 없고 섭씨/화씨 표시 형식을 변경할 때는 아예 접속할 필요가 없다.

memo

컴포넌트는 단독으로도 사용하지만 다른 컴포넌트의 부품으로 사용하여 계층을 이루기도 한다. 이 상태에서 부모가 바뀌어 다시 그려야 한다면 자식도 다시 랜더링하는게 자연스럽다. 과연 그런지 다음 예제로 확인해 보자.

function Child(props) {

console.log('render');

return (

<div>{props.value}</div>

)

}

function Counter() {

const [count, setCount] = useState(0);

const [lang, setLang] = useState('han');

return (

<h2> Count = {count} </h2>

<button onClick={()=>setCount(count+1)}>증가</button> 

<button onClick={()=>setLang(lang ==='han' ? 'eng':'han')}>언어 변경</button>

</>

)

}

function App() {

return (

</>

);

}

카운트 아래에 문자열을 출력하는 Child를 배치했다. Child는 부모로부터 속성을 전달받아 화면에 출력하며 랜더링이 발생하는지 확인하기 위래 콘솔에 로그도 출력한다. 부모는 카운트를 증가시키는 버튼과 언어를 변경하는 버튼이 있다. 실행 후 두 버튼을 눌러 보자.

언어를 변경하면 Child도 출력할 메시지를 바꿔야 하니 당연히 다시 그려야 한다. 그러나 카운트를 증가하는 것은 Child에 아무런 영향을 미치지 않지만 부모가 바뀌어 매번 다시 랜더링하는 불합리함이 있다.

memo 함수는 컴포넌트를 저장하여 불필요한 랜더링을 방지한다. 랜더링할 때 props를 비교해 보고 바뀌었을 때만 랜더링하고 그렇지 않으면 기억해 둔 차일드를 리턴하여 성능을 향상시킨다. 항상 속성을 비교하도록 되어 있어 별도의 의존 변수는 지정하지 않는다. 사용 방법은 간단하다. 자식 컴포넌트를 memo 함수로 감싸 새로운 컴포넌트를 정의한다.

function Child(props) {

console.log('render');

return (

<div>{props.value}</div>

)

}

const MemoizedChild = memo(Child);

function Counter() {

const [count, setCount] = useState(0);

const [lang, setLang] = useState('han');

return (

<h2> Count = {count} </h2>

<button onClick={()=>setCount(count+1)}>증가</button> 

<button onClick={()=>setLang(lang ==='han' ? 'eng':'han')}>언어 변경</button>

</>

)

}

function App() {

return (

</>

);

}

memo(Child)를 대입받는 MemoizedChild는 저장해 놓은 컴포넌트이며 부모는 Child 대신 MemoizedChild를 배치한다. 메모화된 컴포넌트는 이전 속성과 비교하여 다시 그릴 것인지 아닌지 결정하고 불필요한 랜더링을 방지한다.

이러면 언어를 변경할 때 Child로 전달할 속성이 바뀌므로 다시 랜더링하지만 카운트를 증가할 때는 그럴 필요없다. 부모의 카운트가 증가한 것과 Child의 출력 모습은 아무런 관련이 없기 때문이다. memo로 Child를 감싸 별도의 변수로 대입받는 것이 번거롭다면 컴포넌트를 화살표 함수로 정의하여 감싸면 된다.

const Child = memo((props) => {

console.log('render');

return (

<div>{props.value}</div>

)

});

형식이 복잡해서 가독성은 떨어지지만 같은 코드이다. 화살표 함수 대신 함수 리터럴 형식의 memo(function(props) {... } 을 인수로 넘겨도 된다. 부모는 접두없이 <Child>라는 평이한 이름으로 자식 컴포넌트를 배치할 수 있어 사용면에서는 더 간편하다.

memo는 함수이지만 인수로 컴포넌트를 받아 더 향상된 기능의 컴포넌트를 리턴한다. 이처럼 실행중에 컴포넌트를 만들어 내는 기법을 고차 컴포넌트(Higher-Order Component, HOC)라고 부른다. 함수로 컴포넌트를 만들면 공통 코드를 재사용하여 비슷한 컴포넌트를 효율적으로 찍어낼 수 있지만 이름 충돌이나 래핑에 의한 복잡성이 증가하는 단점이 있어 꼭 필요할 때만 주의깊게 사용해야 한다.

useCallback

useMemo는 값을 메모화하고 memo 함수는 컴포넌트를 메모화한다. 이에 비해 useCallback은 함수를 메모화하여 매번 재생성하는 것을 방지한다. 이 훅은 적용되는 상황이 제한적이어서 직관적으로 이해하기 난해하다. 먼저 카운트 예제를 통해 개념적인 사용예를 보자.

import { useCallback } from 'react';

function Counter() {

const [count, setCount] = useState(10);

const dec = () => {

console.log('dec');

setCount((c) => c - 1);

}

const inc = useCallback(() => {

console.log('inc');

setCount((c) => c + 1);

}, []);

return (

<h3> Count = {count} </h3>

</>

)

}

function App() {

return (

</>

);

}

카운트 증감을 dec, inc 함수로 작성했는데 지역 함수도 컴포넌트의 일부이므로 랜더링할 때마다 새로 생성된다. 함수가 거대하고 내용이 바뀌지 않는다면 굳이 매번 재생성할 필요 없다. dec는 일반 함수로 작성하여 매번 생성하도록 내버려 두었지만 inc는 useCallback 훅으로 감싸 매번 생성하지 않도록 했다.

함수의 본체를 저장해 두고 랜더링할 때마다 계속 사용하므로 그만큼 성능 향상의 효과는 있다. 그러나 이 예제가 랜더링할 때마다 inc를 재생성하는지 아니면 메모화된 함수를 계속 사용하는지 확인할 방법은 없다. 로그는 함수 호출에 대해 찍는 것이지 함수 생성시에 찍는게 아니기 때문이다. 또 이 정도 길이의 짧은 함수를 저장해 봐야 실질적인 이득도 경미하다. 아니, 오히려 저장하고 꺼내느라 더 손해볼 확률이 높다.

즉, 이 예제는 어디까지나 개념을 보여줄 뿐 실용적인 기법이 아니고 useCallback 훅의 효과를 실감하기 어렵다. 함수를 메모화해야 하는 기법은 memo 함수로 컴포넌트를 메모화하고 그 컴포넌트의 콜백으로 함수를 전달할 때에 진가를 발휘한다. 콜백 함수에 주로 적용한다고 해서 훅의 이름이 useCallback이다.

이 훅의 동작 예를 보기 위해 앞 항의 예제를 변형하여 Child에게도 스스로 언어를 변경할 수 있는 기능을 추가해 보자. 부모가 이미 언어를 변경하는 기능을 가지고 있으므로 이 함수를 Child의 속성으로 전달하고 Child는 버튼 클릭시 콜백으로 전달받은 함수를 호출하면 된다.

const Child = memo((props) => {

console.log('render');

return (

<div>

<h3>{props.value}</h3>

</div>

)

});

function Counter() {

const [count, setCount] = useState(0);

const [lang, setLang] = useState('han');

function toggleLang() {

setLang(lang === 'han' ? 'eng' : 'han');

}

return (

<h2> Count = {count} </h2>

<button onClick={()=>setCount(count+1)}>증가</button> 

</>

)

}

function App() {

return (

</>

);

}

언어를 변경하는 기능을 toggleLang 함수로 작성하고 Child에게 onLang 속성으로 전달했다. 부모나 자식이나 필요할 때 이 함수를 호출하면 양쪽에서 언어를 변경할 수 있다.

실행해 보면 잘 동작한다. 그러나 로그를 잘 관찰해 보면 또 다른 문제가 있다. Child를 메모화해 놓았으므로 카운트 증감에는 랜더링할 필요없지만 증가 버튼을 누르면 Child도 항상 랜더링된다. 그 이유는 부모를 랜더링할 때 toggleLang 함수가 재생성되기 때문이다. 이 함수를 속성으로 전달받는 Child는 메모화되어 있더라도 속성이 바뀌었으므로 다시 랜더링해야 한다고 판단한다.

그러나 부모가 카운트를 증가시킨다고 해서 toggleLang 함수가 영향을 받는 부분은 없다. 언어가 바뀔 때는 toggleLang도 재생성해야 하지만 카운트 변경에 대해서는 그럴 필요가 없다. 이런 이유로 toggleLang을 메모화해야 하며 이럴 때 사용하는 것이 useCallback 훅이다.

const toggleLang = useCallback(function () {

setLang(lang === 'han' ? 'eng' : 'han');

}, [lang]);

toggleLang을 useCallback으로 감싸되 의존 변수는 lang으로 지정하여 외부에서 이 변수를 변경할 때만 재생성한다. 현재 코드에는 lang 상태를 변경하는 코드가 자기 자신밖에 없다. 함수가 lang을 토글하면 useCallback은 변경된 lang에 대해 toggleLang 함수를 재생성하여 재귀적인 것처럼 보이지만 그렇지는 않다.

함수가 lang을 바꾼 후 다시 재생성되지만 상태를 바꾸는 것은 아니므로 딱 한번만 재생성될 뿐이다. 오히려 의존 변수에 lang을 적지 않으면 함수가 처음 초기화된 상태 그대로 유지되어 버린다. 언어가 초기값인 han인 상태로 함수의 동작이 고정되므로 한번만 eng로 바뀌며 다시 한글로 바꿀 수 없다.

toggleLang을 메모화한 후 실행해 보면 언어 변경에 대해서는 Child를 랜더링하지만 카운트 증가에 대해서는 랜더링이 발생하지 않는다. 카운트가 아무리 바뀌어도 toggleLang 함수가 바뀌지 않으며 Child가 받는 인수도 변화가 없으므로 다시 랜더링할 필요가 없다.

함수 재생성을 최소화하는 만큼 성능은 향상되지만 향상의 정도는 극히 미미하다. 웬만큼 큰 함수라도 본체를 만드는 동작이 엄청난 시간을 소모하는 것은 아니다. useCallback을 사용하는 진짜 의미는 함수를 메모화하는 것이 아니라 이 함수를 콜백으로 받는 컴포넌트 전체의 랜더링을 최소화하는 것이다.