단편 시리즈처럼 React hooks API 의 사용법에 대해서 기록해볼 예정입니다.

React Hooks 의 자세한 개요는 공식 홈페이지에서 확인할 수 있습니다.

useState

state 를 편하게 관리할 수 있는 가장 기본적인 API 입니다.
아마 useState 는 React hooks API 중에서 가장 많이 사용되는 혹은 가장 많이 사용될 API 가 아닐까 싶네요.

기존엔 state 를 사용하려면 다음과 같이 코드를 작성해야 했습니다.

 

 

클래스 기반의 컴포넌트를 작성하고 그 안에서 state 를 선언하고 관리하는 방식이었습니다.

이러한 방식의 단점은 관리할 state 가 많아지면 코드의 가독성이 떨어지는 문제가 있었습니다.

그리고 redux, mobx 와 같은 스토어 중심의 상태 관리 시스템이 등장하면서 state 를 사용하는 일이 크게 줄어들었습니다.

그래서 React hooks API 가 등장하기 전까지는 state 는 이제 레거시와 같은 느낌의 날 것으로 남아있는 그런 느낌도 들었으니까요.

React hooks 가 등장한 좀 더 구체적이고 명확한 이유는 공식 홈페이지에서 업로드한 영상에서 확인하실 수 있습니다.

어쨌든, useState 를 사용하면 어떤 코드가 되는지부터 살펴보겠습니다.

 

 

보기에는 크게 다를게 없어보이지만 다음과 같은 차이점이 존재합니다.

 

클래스 기반에서 함수형 기반으로

React hooks API 는 클래스형 컴포넌트에서 사용할 수 없습니다.
이런 배경이 되는 이유는 왜 React hooks 가 등장했는지를 알아야하는데요.
공식 홈페이지의 리액트 소개글에는 이런 문구가 있습니다.

 

We’ve found that classes can be a large barrier to learning React.
...
The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers.

저희 개발팀은 클래스가 리액트를 배우는데에 큰 장벽이 될 수 있다는 점을 느꼈습니다.
...
React 에서 함수형과 클래스형 컴포넌트를 두고 언제 어떤걸 사용해야하는지에 대한 의견은 리액트를 오랫동안 사용한 전문가들 사이에서도 의견이 분분합니다.

 

위 글만 보더라도 React 측에서도 함수형 컴포넌트를 그다지 선호하지 않는다는 점을 미뤄 짐작할 수 있습니다.
개인적으로는 자바스크립트에서 초심자에게 가장 이해하기 어려운 난해한 개념들이 바로 프로토타입과 this, 클로져 라고 생각하는데 React 측에서도 이러한 점을 어느정도 수긍하고 있고, 리액트를 사용하는 개발자들이 반드시 자바스크립트에 익숙한 개발자라는 보장이 없다는 점을 전제로 한 패치방향이라고 볼 수 있을 듯 합니다.

state 업데이트 방식

기존의 클래스 컴포넌트 방식에선 state 를 업데이트하기 위해선 setState 메소드를 사용해 state 를 업데이트 할 수 있었습니다.
새롭게 도입된 React hooks 에선 useState 메소드를 사용할 수 있습니다.
사용 규칙은 아주 간단합니다.

 

예를 들어서 state 로 사용하고 싶은 변수명이 count 라면, setState 역할을 할 메소드는 state 변수명 앞에 set 을 붙이고 카멜케이스 기법에 따라 네이밍을 처리하면 됩니다. 즉, setCount 가 되겠죠.
그리고 count, setCount 는 대괄호로 감싸줍니다.
useState 에 전달할 파라미터 값으로는 state 변수를 초기화하고 싶은 값을 넣으면 됩니다.
딱히 초기화하고 싶지 않다면 null 을 넣어주어도 무난합니다.

앞서 설명한 방식을 적용한다면, 이런 식으로 사용할 수 있을 겁니다.
const [count, setCount] = useState(0);
초기화 할 값은 0 으로 지정해주었고, 네이밍은 카멜케이스에 맞게 정해주었습니다.

state 값을 업데이트할 땐 아주 간단합니다.
setCount 메소드를 호출하고 그 안에 값을 넣기만하면 끝입니다.
자동으로 count 가 업데이트가 될 것이고, this 를 사용할 필요도, this bounding 에 대한 고민 또한 전혀 필요 없습니다.
왜냐면 함수형 컴포넌트이기 때문이죠!

 

컴포넌트 지옥 탈출

React 로 개발을 하다보면, 이러한 고민에 종종 빠집니다.
"이 컴포넌트 보기가 좀 싫은데.. 분리시켜야하나?"

예시를 한 번 들어보겠습니다.

 

 

컴포넌트를 뭔가 조금 더 깔끔하게 하고 싶었는데, componentDidMount 등과 같은 생명주기 메소드를 사용해야했기 때문에 클래스형 컴포넌트 사용이 강제될 수 밖에 없었고 결국 컴포넌트를 하나 더 만들어서 함수형 컴포넌트로 작성했습니다.
아마 React 를 사용하시는 대부분의 분들이 이런 비슷한 경험을 했거나 고민을 한 적이 있을거라고 생각합니다.
실제로 운영중인 프로젝트에선 그 깊이가 상당히 깊을 수도 있겠네요.

React hooks API 는 기본적으로 이러한 고민을 없애고자(줄이고자) 함수형 컴포넌트 기반에서 컴파일되도록 설계된 메소드들입니다.
그래서 함수형 컴포넌트 기반으로 깔끔하게 작성할 수 있습니다.

 

예제 코드

예제 코드를 아래에 첨부하겠습니다.

 

두 개의 다른 버전에서 동작하는 모습을 확인해보세요.
이렇게 React hooks 에 추가된 메소드 중 하나인 useState 에 대해서 알아봤습니다.
다음엔 다른 메소드를 기록해볼 예정입니다.

 

참고가 되었으면 좋겠습니다 :D





※ 해당 포스트는 Dave Ceddia 님의 동의 하에 글을 번역한 것임을 알립니다.


※ 자연스러운 글의 흐름을 위해 작성자의 임의로 의역한 부분이 있음을 알립니다.







React 컴포넌트가 제대로 렌더링이 안되고 있습니까?


그 전에 잠깐! React 컴포넌트가 componentWillMount 에서 서버로부터 데이터를 받아오는 작업을 아래와 같이 하고 있다면, 과연 무엇이 렌더링이 될까요?



사진의 출처 - Jay Galvin



만약 '아무것도 일어나지 않는다' 혹은 'a console error'라고 생각하셨다면, 정답입니다.

만약 '데이터를 받아온다'고 생각했다면, 이 포스트를 읽으시는게 좋겠군요.


State는 초기화되어 있지 않다

우선 여기서 짚고 넘어가야할 두 가지 중요한 사실들이 있습니다:

1. 컴포넌트의 상태 값(e.g. this.state) 의 시작 값은 null이다.
2. 비동기적으로 데이터를 처리할 때, 컴포넌트는 적어도 한 번, 데이터가 불러지기 전에 렌더링 된다.

- 데이터가 constructor, componentWillMount , componentDidMount 혹은 그 어디에 있는지와 상관이 없이 말이다.


그렇습니다. constructorcomponentWillMount가 최초의 렌더링 그 이전에 실행이 된다고 할지라도, 비동기 호출은 컴포넌트가 비동기 이전에 렌더링이 되는 것을 막아주지는 못합니다. 그래서 여러분이 여전히 문제를 일으키고 있는 것이고요.


해결방안

사실 해결책은 간단합니다. 가장 쉬운 방법은 constructor 안에서 state를 그럴싸한 값으로 기본 설정해주는 것입니다.


위의 컴포넌트에 대한 예제는 아래와 같이 풀어볼 수 있습니다.


그리고 아래처럼 또한 빈 값을 render 안에서 설정해줄 수도 있습니다.



이 것은 이상적인 방법은 아닙니다. 만약 기본 설정 값(default value)을 부여할 수 있다면, 그렇게 하세요.


낙수효과(Trickle-Down effect)의 실패에 따른 부작용

"비어있는 상태값(state)"이 만약 제대로 설정이 되어 있지 않다면, 결국에 이 문제는 개발자에게 더 큰 후폭풍을 안겨주게 됩니다.

(※ 작성자에 의한 의역임을 알림(or를 오타로 판단해 of로 해석). 원문 : The lack of default or “empty state” data can bite you another way, too)

바로 자식 컴포넌트에게 정의되지 않은(undefined) 상태값이 전달될 때 말이죠.


위의 예제를 조금 더 확장해 봅시다. 가령 Quiz 컴포넌트안에 있는 자식 컴포넌트로 list를 넘겨준다고 한다면,



문제가 보이시나요? Quiz가 처음으로 렌더링이 될 때, this.state.itemsundefined 입니다. 무슨 말인가하면, ItemList 컴포넌트가 items 이라는 데이터를 undefined 상태로 넘겨받게되고, 결국에는 화면에서 Uncaught TypeError: Cannot read property 'map' of undefined 를 보게되는 것이란 말입니다.


만약 ItemList안에 propTypes에 대한 정의가 컴포넌트에 새겨져 있었다면 디버깅하기는 더 수월했겠군요.



이렇게 정의가 되어 있었다면 콘솔에 나오는 메시지는 다음과 같습니다.

"Warning: Failed prop type: Required prop items was not specified in ItemList."

(경고: prop type 오류: 필수요건인 itemsItemList에 정의되어 있지 않음.)


그러나 여전히 Uncaught TypeError: Cannot read property 'map' of undefined 의 에러는 남아있습니다. propType의 유효성을 검사하는 것은 컴포넌트의 렌더링에 관한 문제를 해결해주지는 않습니다. 다만 알려주기만 할 뿐이죠.


그러나 최소한 이러한 방법은 디버그를 조금 더 수월하게는 해줍니다.


기본 Props 설정(Default Props)

한 가지 더 쉬운 방법이 있습니다. props의 default값을 설정해주면 됩니다.


Default props는  항상 최선책은 아닙니다. 이 방법을 사용하기전에 더 나은 해결책이 없는지, 이 방법이 그저 임기응변(band-aid solution)에 지나지 않는지 항상 확인하세요.


Default 값들을 설정하는 것이 그저 값들이 정의되지도 않아서 발생하는 수 많은 에러들을 모두 예방해줄 수 있을 것이라 생각하시나요? 그 전에 값(data)들을 제대로 정의하는 것을 먼저 고려하십시오.


아니면 prop이 단순한 선택적인 것에 불과하다고 말할 수 있습니까? prop이 전달되지 않은 상태에서 컴포넌트가 렌더링이 되는 경우에 대해서는 문제가 없다고 생각하십니까? 그렇다면 기본 값 설정에 대한 문제 해결을 받아들일 준비가 되었습니다.


이 문제는 몇 가지 방법으로 해결할 수 있습니다.


defaultProps 이용하기

이 메소드는 여러분의 컴포넌트가 상태(state)를 갖고 있지 않은 함수인지, React.Component를 상속받는 클래스인지에 얽매이지 않습니다.



이 메소드는 컴포넌트가 클래시 형식일 때, 여러분의 컴파일러가 ES7의 static initializer 문법을 지원할때만 동작합니다. 



render 조작

이 방법은 아래에 있는 render 안에서, ES6의 destructuring syntax에 의해 다음과 같이 표현됩니다.



이 라인은 다음과 같은 의미입니다.

"items 키를 this.props에서 가져오고, 만약 undefined상태라면 빈 배열로 초기화한다"



인자 값(arguments) 조작

만약 컴포넌트가 함수형이라면, 아래와 같이 초기화를 해줄 수 있습니다.



요약

  • 컴포넌트 라이프 사이클이 실행되는 동안에 이루어지는 비동기 호출은 컴포넌트가 데이터가 로드되기 전에 렌더링이 된다는 것을 의미합니다. 그래서..

  • constructor 안에서 state를 초기화하거나 빈 값을 적절히 처리해야 합니다.

  • 디버깅을 더 수월히 하기 위해 ProTypes를 사용하십시오.

  • defaulProps를 적절히 활용하세요.

  • 구조 변경(※ 의역, 원문: Destructuring syntax: 구문 파괴)은 깔끔하면서 쉽게 기본 값들을 설정할 수 있습니다.




React.js를 사용해 개발을 하다보면 사실상 눈에 띌 정도로 '좋다'고 느끼는 것은 그다지 많지 않습니다. React에익숙하지 않은 개발자라면 이러한 현상이 더욱 드러날 것이겠지요. 그런데도 우리가 React를 사용하는 이유는 바로 이런것이 아닐까 싶네요.


React의 공식 홈페이지의 내용을 조금만 인용해 등장배경부터 알아 보자면 다음과 같습니다.

  • By unifying your markup with its corresponding view logic, React can actually make views easier to extend and maintain.
  • 여러분이 만들어놓은 마크업(markup)과 그에 상응하는 뷰 로직을 하나로 만들 때, React는 실제로 뷰를 더욱 확장성 있고 관리하기 쉽도록 만들어줍니다.

출처 - https://facebook.github.io/react/blog/2013/06/05/why-react.html


실제로 JavaScript나 jQuery만을 이용해 어플리케이션을 개발했을 때를 생각을 해보자면, 하나의 HTML파일에 여러가지 모듈화된 js파일들을 불러왔었을 겁니다. 어플리케이션의 크기가 증가하면서 코드의 양도 자연스레 비례적으로 증가하였고 단편적으로 HTML의 양이 대폭적으로 늘어났다고 가정을 해보면, 우선 분리되어있지 않은 코드들이 가독성을 제일 먼저 떨어트릴 것입니다. 그리고 이러한 DOM들을 제어 · 관리하는데에 사용하는 jQuery의 양도 매우 많아지겠죠. 즉, 한마디로 말해 '관리의 효율' 문제라는 겁니다. 아무리 버그가 없고 이상이 없는 사이트인데 오늘만 산다는 마음가짐으로 코드 관리를 매우 비효율적으로 해놓는다면, 추후의 관리의 차원에서 너무 힘들어지겠죠. 나 혼자만 개발하는 것이 아니라 협업의 관계에 속해있다면 관리는 반드시 고려해야할 숙제 중 하나입니다.

다행스럽게도, React는 이러한 관리문제를 컴포넌트의 모듈화로 제법 해결해놓았습니다.  아래의 코드는 아주 간단한 jQuery 예제로 jQuery가 어떻게 DOM에게 간섭하는지를 보여줍니다. jQuery의 시작은 항상 $으로 시작하죠, 이 기호를 이용해 모든 DOM에 접근할 수 있습니다. (솔직히 제 개인적으로도 jQuery만큼 DOM관리하는데에 편한것도 없는 것 같습니다.)

See the Pen PmBLLZ by Munkyu Yang (@moonformeli) on CodePen.


아래에는 같은 내용의 코드를 React.js를 통해서 구현해본 것입니다.

See the Pen WjKmqj by Munkyu Yang (@moonformeli) on CodePen.

언뜻 보면 React.js의 코드가 더 길고 복잡해 보입니다. HTML 코드는 jQuery의 코드를 기준으로 8줄이네요. 그리고 React는 코드를 컴포넌트라는 하나의 클래스를 만들어 모듈화를 통해 관리합니다. 즉, '뚜렷한 의미를 가지는 클래스들의 모듈화' 를 이용하는 것이죠. 이는 상당히 중요한 개념입니다. 제 개인적으로는 React가 jQuery보다 앞서있다고 생각되는 점 중에 하나입니다.


만약에, 어플리케이션이 방대해져서 HTML만 1,000줄이 필요하다고 가정을 해보면, 무수히 많은 클래스들과 아이디가 부여가 될 것이고 그에 따른 CSS제어, 액션제어들이 필요하겠죠. 이 모든 것들을 $.ready()에서 처리한다고 생각해본다면 얼마나 읽기가 힘들지는 눈에 선하죠? jQuery에서도 js파일을 나눠서 관리할 수 있습니다만.. 특정한 의미가 없이 그저 코드의 양을 줄이고자 나누는 작업은 오히려 가독성을 낮출 수 있습니다. 하나의 파일에서 시간을 조금만 들여서 보면 될 것을 파일의 분기때문에 이 파일 저 파일 번갈아가면서 봐야할 수도 있는거죠.


React는 1,000줄의 HTML에서 이런식으로 흐름을 분기합니다. 


이런식의 의미있는 컴포넌트만 불러와 하나의 HTML을 만드는 것은 상당히 편리하고 강력합니다. 또 <로그인 />에서는 로그인에 필요한 액션 제어, <회원가입/> 에서는 그에 맞는 액션제어(Form 전송 등)를 알맞게 할 수 있고, 나중을 위한 유지보수의 첫 단추도 잘 넣게 되는 것이죠.



그러나, 한 가지 염두해두고 있어야 할 점은, React가 낫다, jQuery가 낫다 아니면 혹은 다른 프레임워크들이 낫다고 생각해 한 가지만을 고집하는 것은 어리석은 생각입니다. 공식 홈페이지에서도 나와있듯이, React는 MVC 패턴을 구현하기 위해 제작된 프레임워크가 아닙니다. 그저 확장성과 관리효율성 차원에서 고려되어져 만들어진 우수한 성능의 자바스크립트 라이브러리일 뿐입니다. 기본적인 베이스를 잡고 있는 프레임워크나 라이브러리는 존재하되, 필요한 기능을 더 편리하고 강력하게 구현하는 기능을 제공해주는 것이 있다면, 현재 사용중인 개발언어의 기능과 비교해보고 더 나은 것을 선택하는 것이 바람직하다고 할 수 있습니다.



저의 블로그는 React.js에 대한 기초를 강의하지는 않습니다. 다만 개인적으로 React.js를 다루면서 느꼈던 부분들에
대해 어떻게 풀어나가는지를 적어보려고 합니다.

+ Recent posts