※ 해당 포스트는 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 패턴을 구현하기 위해 제작된 프레임워크가 아닙니다. 그저 확장성과 관리효율성 차원에서 고려되어져 만들어진 우수한 성능의 자바스크립트 라이브러리일 뿐입니다. 기본적인 베이스를 잡고 있는 프레임워크나 라이브러리는 존재하되, 필요한 기능을 더 편리하고 강력하게 구현하는 기능을 제공해주는 것이 있다면, 현재 사용중인 개발언어의 기능과 비교해보고 더 나은 것을 선택하는 것이 바람직하다고 할 수 있습니다.


+ Recent posts