컴포넌트가 함수로 작성되어 있을 지라도, 리액트를 사용하면 개발자가 직접 그 컴포넌트를 호출하지 않는다. 모든 컴포넌트는 render 되어야 할 것들의 description을 리턴하고 그 description은 <LikeButton>과 같은 user-written 컴포넌트와 div와 같은 platform-specific 컴포넌트 모두를 포함한다. <LikeButton>를 미래의 어느 시점에 unroll하는것 또는 재귀적으로 컴포넌트들의 render 결과에 따라 UI 트리에 변화를 실제 적용하는 것은 리액트의 책임(up to React)이다.

이는 미묘한 차이이지만 굉장히 강력하다. 개발자가 컴포넌트 함수를 호출하지 않고 리액트에 위임 (let React call it)하는 것은 리액트가, 필요하다면, 호출을 지연시키는 권한을 (has the power) 가지고 있다는 뜻이다. 현재의 리액트 (v.16 이전) tree를 재귀적으로 순회(walk)하고 single tick안에 모든 업데이트된 트리의 render 함수를 호출한다. 하지만 미래에는 리액트가 프레임 드랍을 방지하기 위해 몇몇 업데이트를 지연시키기 시작할 것이다.

이는 리액트 디자인 철학 중 하나의 보편적 주제다. 몇 유명한 라이브러리들은 새로운 데이터가 available 할 때 computation이 실행되는 방식의 'push' implementation으로 접근한다. 하지만 리액트는 연산을 정말 필요할 때 까지 지연시킬 수 있는 "pull" 방식을 고집하고자 한다.

리액트는 generic 데이터 processing 라이브러리가 아니라 유저 인터페이스를 빌딩하기 위한 라이브러리다. 우리는 (리액트팀은) 리액트가 어플리케이션에서 어떤 연산이 비교적 급한지 아닌지 알 수 있기에 유니크한 위치에 있다고 생각한다.

만약 어떤게 offscreen일때, 우리는 연관된 모든 로직을 지연시킬 수 있다. 만약 데이터가 frame rate보다 더 빨리 응답으로 도착한다면, 업데이트를 하나로 합치고 일괄처리 할 수 있다. 또한 프레임 드랍을 방지하기 위해 유저 인터렉션으로 부터 오는 work들의 우선순위를 정할 수 있다: high priority(버튼 클릭으로 인한 애니메이션) to low priority(네트워크로 부터 막 loaded된 컨텐츠를 그리는 일)

정확하게는 현재 이 장점을 살리고 있지 않다. 하지만 이러한 일들을 할 수 있는 자유 떄문에 리액트 팀은 스케쥴링 컨트롤 할 수 있는것을 선호하며, setState()가 비동기로 처리되는 이유이다. 개념적으로 우리는 이것들이 "업데이트를 스케쥴링"하는 것으로 생각한다.

사용자가 직접 Functional Reactive Programming의 일부 변형에서 흔히 볼 수 있는 "push" 기반 페러다임으로 직접 뷰를 구성(compose)하도록 둔다면 스케쥴링을 컨트롤 하는 것은 리액트팀에게 더 힘들것이다. 리액튼 팀은 "glue" 코드를 갖길 원한다.

React로 돌아가기 전에 실행되는 사용자 코드의 양이 최소가 되는 것이 React의 핵심 목표이다. (아마 리액트가 직접 관여하는 부분이, 개발자의 코드로서보다, 많은 것을 ideal 하다고 생각한다는 뜻인듯?) 이렇게 하면 React가 UI에 대해 알고 있는 내용에 따라 작업을 예약하고 청크로 분할할 수 있는 기능을 유지할 수 있게된다.

There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”.

Real DOM

DOM, Document Object Model,은 어플리케이션의 UI를 나타내는 간단한 단어다. 어플리케이션 UI 상태의 변화가 있을 때 마다 DOM은 업데이트되고 변화를 적용하여 나타낸다. 하지만 DOM의 잦은 조작은 어플리케이션 퍼포먼스에 영향을 주어 속도 저하를 야기한다.

무엇 때문에 DOM 조작은 속도 저하를 야기하는가

DOM은 트리 자료 구조로 나타나있다. 그렇기 때문에, DOM의 changes와 updates는 빠르다. 하지만 변화 후, update된 element와 그의 자식들은 어플리케이션 UI를 업데이트하기 위해 re-render되어야한다. UI의 re-rendering 혹은 re-painting이 바로 속도 저하를 야기한다. 따라서, UI 컴포넌트가 많은수록 모든 DOM 업데이트를 위해 모두 re-render되어야 할 수 있어 DOM 업데이트에 들어가는 비용이 비싸진다 (소요될 작업량이 많아진다로 이해하면 될듯).

Virtual DOM

위의 이슈로 인해 Virtual DOM의 컨셉이 나왔고 실제 DOM보다 월등히 뛰어난 성능을 자랑한다. Virtual DOM은 그저 단지 DOM의 가상 representation일 뿐이다. 어플리케이션의 상태가 변화할 때 마다, Virtual DOM이 real DOM 대신 업데이트 된다.

간혹 Virtual DOM과 real DOM이 하는 일이 동일해보이기 때문에 double work 하는 것이 아닌지 의문을 갖고 real DOM을 업데이트 하는 것 보다 Virtual DOM이 더 빠른지에 대해 의문을 갖을 수 있다.

왜 Virtual DOM이 실제 DOM보다 빠른지에 대해 알아보자

왜 Virtual DOM이 더 빠른가

UI에 새로운 element가 추가가 되면, tree로 구성된 virtual DOM이 생성된다. 각각 element는 이 트리에서 node이다. 만약 이 elements 중 어느 하나의 element의 상태가 변화하면, 새로운 Virtual DOM 트리가 생성된다. 이 새로운 트리는 이전 Virtual DOM 트리와 diff, 즉 비교가 된다.

비교가 끝난 후, Virtual DOM은 real DOM에 적용할 가장 가능성 높은 (혹은 효율적인) 방법을 계산한다. 이 과정은 실제 DOM 상의 최소한의 작동을 보장한다. 실제 DOM을 업데이트 하는것에 대한 퍼포먼스 비용을 줄이는 것이다.

다음 이미지는 virtual DOM tree와 비교 과정을 보여준다.

빨간색 원은 변화된 노드들을 나타낸다. 이러한 노드들은 그들의 state가 변화된 UI element를 나타낸다. 이전 버전의 Virtual DOM tree와 새로운 버전의 Virtual DOM tree 사이의 차이가 계산된다. 부모의 하위 subtree들은 업데이트된 UI를 표현하기 위해 모두 re-render된다. 그러면 이 업데이트된 트리가 실제 DOM으로 일괄 업데이트 된다.

리액트는 Virtual DOM을 어떻게 사용하는가

리액트에서 모든 UI 조각들은 컴포넌트이며 각 컴포넌트는 상태(state)를 갖는다. 리액트는 observerable pattern을 따르고 모든 상태 변화를 listen한다. 컴포넌트의 상태가 변화하면, 리액트는 Virtual DOM tree를 업데이트 한다. Virtual DOM의 업데이트가 끝나면, 리액트는 현재 버전의 Virtual DOM과 이전 버전의 Virtual DOM을 비교한다. 이 과정을 diffing이라고 부른다.

리액트가 어떤 Virtual DOM object가 변화했는지 알게되면, 리액트는 그 변화된 objects만 실제 DOM에 업데이트한다. 이는 실제 DOM을 직접 조정(manipulating) 하는 것과 비교하여 훨신 나은 퍼포먼스를 만들어 낸다. 이 것이 리액트를 high perfomance javascript library로 돋보이게 하는 것이다.

다시 말해, 개발자는 단지 UI가 어떤 상태로 변화되길 리액트에 말하면, 리액트는 그 상태와 DOM이 일치하도록 보장한다. 이 때문에 개발자들은 리액트 내부에서 속성 변화, 이벤트 핸들링 또는 수동 DOM 업데이트가 어떻게 작동되는지 알 필요없게 된다.

이 모든 세부 정보들은 리액트 개발자로 부터 추상화된다. 개발자가 해야할 일은 필요할 때에 맞게 컴포넌트의 상태를 변화시켜주면 나머지는 리액트가 알아서 처리해준다. 이는 리액트를 사용함에 있어 뛰어난 dx (developer experience)를 경험하게 해준다.

render() 함수

render() 함수는 UI가 업데이트되고 렌더되는 곳이다. render() 함수는 리액트에서 필수적인 lifecycle method다.

render() 함수는 리액트 elements의 트리가 생성되는 엔트리 포인트다. 컴포넌트의 state나 props가 업데이트되면 render() 함수는 리액트 element의 다른 tree를 반환한다. 컴포넌트 내부에서 setState()가 사용되면, 리액트는 상태 변화를 즉시 감지하고 컴포넌트를 re-render한다.

그 후 리액트는 변화가 적용된 가장 최신의 트리에 해당하는 UI로 가장 효율적으로 업데이트하는 방법을 계산한다.

이 떄가 리액트가 먼저 virtual DOM을 업데이트 하고 실제 DOM에서 변화된 objects만 업데이트 하는 떄이다.

Batch Update

리액트는 실제 DOM을 업데이트 하기 위해 batch update mechanism을 따른다. 각 상태 업데이트에 대한 operation을 보내는 대신 실제 DOM에 대한 업데이트를 일괄적으로 보낸다.

UI 리페인팅이 가장 비싼 부분이고 리액트는 UI 리페인트 하기 위해 오직 batched 업데이트들만 실제 DOM이 받을 수 있도록 효율적으로 확신한다.

참고: https://velopert.com/3236

DOM Node와 Element의 차이

Document Object Model, DOM, 은 HTML 혹은 XML 문서를 각 노드가 문서의 객체인 트리 구조로서 처리하기 위한 interface이다. DOM은 tree를 query (불러오기), 구조와 스타일을 변경하기 위한 여러 메소드들을 제공하기도 한다.

DOM은 또한 element라는 단어를 사용한다: node와 상당히 비슷하다. 그럼 두개는 무엇이 다른지 알아보자

1. DOM Node

node와 element의 차이를 알아보기 위해서 node가 무엇인지 알아보는게 중요하다.

더 큰 관점에서 보면 DOM document는 노드 계층으로 구성된다. 각 노드는 부모와 자식 혹은 각각 가질 수 있다. 다음 HTML 문서를 살펴보자

<!DOCTYPE html>
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <!-- Page Body -->
    <h2>My Page</h2>
    <p id="content">Thank you for visiting my web page!</p>
  </body>
</html>

위 html은 다음과 같은 계층으로 표현이 가능하다.

ㄴ DOCTYPE: html
ㄴ HTML
    ㄴHEAD
        ㄴTITLE
            ㄴ#text: My Page
    ㄴBODY
        ㄴ#comment: Page Body
        ㄴH2
            ㄴtext: My Page
        ㄴP id="content"
            ㄴ#text: Thank you for visiting my web page!

<html> 은 <head> and <body> node들을 자식으로 가지고 있는 document tree의 node이다.

<body> 또한 세개의 자식을 갖는 노드다. <!-- Page Body -->, heading <h2>, 그리고 paragraph <p>. <body> node의 부모는 <html> node다.

HTML document의 tag들은 노드를 대표한다. 더 흥미로운건 text 또한 노드이다. paragraph node <p> 는 text node "Thank you for visiting my web page!"를 자식으로 갖는다.

1.1 Node Types

DOM Node 인터페이스를 살펴보면 Node.nodeType 속성으로 노드의 타입을 구분할 수 있다.

Node.nodeType는 노드의 타입을 나타내는 다음의 값들이 있다.

• Node.ELEMENT_NODE
• Node.ATTRIBUTE_NODE
• Node.TEXT_NODE
• Node.CDATA_SECTION_NODE
• Node.PROCESSING_INSTRUCTION_NODE
• Node.COMMENT_NODE
• Node.DOCUMENT_NODE
• Node.DOCUMENT_TYPE_NODE
• Node.DOCUMENT_FRAGMENT_NODE
• Node.NOTATION_NODE

위 상수들은 노드 유형을 의미 있게 나타낸다: 예를 들면, Node.ELEMENT_NODE은 element node를 나타낸다.

예를 들어, paragraph node를 선택하고 선택된 노드의 타입을 살펴보자

const paragraph = document.querySelector('p');
paragraph.nodeType === Node.ELEMENT_NODE; // => true

예상대로 paragraph.nodeType은 paragraph가 element인 것을 알 수 있듯, Node.ELEMENT_NODE값을 가지고 있다.

paragraph는 또한 text node를 가지고 있다.

const paragraph = document.querySelector('p');
const firstChild = paragraph.childNodes[0];
firstChild.nodeType === Node.TEXT_NODE; // => true

또한 노드 타입에는 노드의 전체 document tree를 나타내는 Node.DOCUMENT_NODE 타입이 있다.

document.nodeType === Node.DOCUMENT_NODE; // => true

2. DOM Element

DOM Node가 무엇인지 잘 파악했으니 element와 구분점을 알아보자.

node에 대해 이해가 높다면 답은 명확하다: element은 Node.ELEMENT_NODE 라는 특정 타입의 노드이다.

간단하게 element는 HTML의 tag를 사용해 작성된 node라고 볼 수 있다. <html>, <head>, <title>, <body>, <h2> 등 모두 tag로 대변될 수 있기 때문에 element이다.

하지만 document type, comment, text 노드는 모두 tag로 작성되지 않았기 때문에 element가 아니다.

Node는 node의 constructor이고 HTMLElement는 Javascript DOM에서 element의 constructor이다. paragraph은 node이면서 element이기에 Node와 HTMLElement의 instance다.

const paragraph = document.querySelector('p');
paragraph instanceof Node;        // => true
paragraph instanceof HTMLElement; // => true

element는 node의 subtype으로도 볼 수 있다: 고양이(element)와 동물(node)의 관계

3. DOM 속성: nodes and elements

node와 element의 구분을 차치하고, 오직 node 혹은 오직 element를 위한 DOM 속성들을 구분해볼 필요가 있다.

다음 Node 타입의 속성은 Node 혹은 NodeList로 평가된다.

node.parentNode; // Node or null
node.firstChild; // Node or null
node.lastChild;  // Node or null
node.childNodes; // NodeList

하지만 다음 속성들은 element 혹은 element collection(HTMLCollection)이다.

node.parentElement; // HTMLElement or null
node.children;      // HTMLCollection

node.childNodes와 node.children 모두 children list를 반환하는데 왜 구분이 되어 있을까? 다음 예제 코드로 살펴보자

<p>
  <b>Thank you</b> for visiting my web page!
</p>

그 후 paragraph의 childNodes와 children을 살펴보면,

const paragraph = document.querySelector('p');
paragraph.childNodes; // NodeList:       [HTMLElement, Text]
paragraph.children;   // HTMLCollection: [HTMLElement]

paragraph.childNodes collection은 2개의 노드를 갖는다: bold element인 <b>Thank you</b>와 text node인 for visiting my web page!

하지만 paragraph.children collection은 bold element인 <b>Thank you</b>만 가지고있다. paragraph.children은 오직 element만 가지고 있을 수 있기 때문에 타입이 element(Node.ELEMENT_NODE)가 아닌 text 타입(Node.TEXT_NODE)를 갖는 text node는 포함되지 않는다.

4. 정리

DOM document는 노드 의 계층적 collection이다. 각 node는 부모, 자식 혹은 둘다 가질 수 있다. 즉 HTML의 계층을 표현할 수 있는 모든것은 다 Node다.

element은 Node.ELEMENT_NODE 라는 특정 타입의 노드로 HTML 문서의 tag를 사용해 작성된 node다. Node는 element를 포함한다: 동물(Node)과 고양이(element)의 관계. 또한 Node이면서 element인 경우도 있다: paragraph.

다만, Document node (Node.DOCUMENT_NODE)은 절대 부모를 가질 수 없다.

React Components, Elements, and Instances

컴포넌트와, 그의 instance 그리고 element간의 구분은 헷갈리는 개념이다. 왜 그들은 모두 스크린에 그려진 어떤 것을 지칭하면서 다른 단어들로 사용되는가?

Managing the Instances

만약 React에 새로운 사람이라면, class형 컴포넌트와 instance를 접한적이 있을 것이다. 예를 들면, Button 컴포넌트를 만들기 위해 class를 만들었을 것이다. 어플리케이션이 작동할 때, 화면에는 해당 컴포넌트의 여러 instance들이 나타날 것이고, 각각의 instance들은 고유한 상태와 속성들을 가지고 있다. 이것이 전통적인 객체지향 UI 프로그래밍 (object-oriented UI programming)이다.

이 전통적인 UI 모델에서 child component instance를 만들고 지우는 것은 개발자의 책임 (몫)이다. 만약 Form 컴포넌트가 Button 컴포넌트를 render 하길 원한다면, Form 컴포넌트는 Button 컴포넌트 instance를 만들고 새로운 정보 (new props, state)에 대응하여 수동적으로 최신 상태를 유지해줘야 한다.

class Form extends TraditionalObjectOrientedView {
  render() {
    // Read some data passed to the view
    const { isSubmitted, buttonText } = this.attrs;

    if (!isSubmitted && !this.button) {
      // Form is not yet submitted. Create the button!
      this.button = new Button({
        children: buttonText,
        color: 'blue'
      });
      this.el.appendChild(this.button.el);
    }

    if (this.button) {
      // The button is visible. Update its text!
      this.button.attrs.children = buttonText;
      this.button.render();
    }

    if (isSubmitted && this.button) {
      // Form was submitted. Destroy the button!
      this.el.removeChild(this.button.el);
      this.button.destroy();
    }

    if (isSubmitted && !this.message) {
      // Form was submitted. Show the success message!
      this.message = new Message({ text: 'Success!' });
      this.el.appendChild(this.message.el);
    }
  }
}

위 코드는 프로그램 설계 언어 (pseudocode) 이지만 Backbone과 같이 object-oriented 방식으로 지속, 동일하게 동작하는 라이브러리로 composite (합성) UI를 작성할 때 대체로 작성되는 코드이다.

각 컴포넌트 instance는 그들의 DOM node와 children 컴포넌트들의 instance를 지속적으로 참조해야 하고 ( keep references to ) 알맞은 시기 (time)에 만들고, 업데이트하고 그리고 삭제해야한다. 컴포넌트의 상태(state)의 발생 가능성의 제곱만큼 코드 라인의 수는 늘어나고 부모가 그들의 children component instance에 직접적으로 접근이 가능해야하는 점은 미래에 이들을 분리 (decouple) 하기 어렵게 만든다.

즉, Button의 속성에 따라 (의존하여) 버튼이 스크린에 나타나고 없어지고 혹은 변화하는 등의 관리가 필요한데 해당 컴포넌트가 많으면 많아질수록 instance가 늘어나는 것 뿐만 아니라 instances를 조작하는 코드들도 늘어난다. 이말인즉슥, 관리할 코드가 늘어나고 비대해진 컴포넌트가 만들어져간다. 그렇기에 분리가 어려워진다.

그렇다면 리액트는 어떻게 다른가?

Elements describe the TREE

이 문제에 대해 리액트에서는 elements가 해결사로 등장한다. elements는 컴포넌트 instance 혹은 DOM node와 그들의 속성들에 대한 정보를 가지고있는 (describing) plain object다. 이 plain object는 컴포넌트 타입 (예를 들면 a Button or Form), 해당 컴포넌트 인스턴스나 DOM node의 속성 (예: color 등)과 해당 컴포넌트 인스턴스나 DOM node의 자식 elements에 대한 정보만 가지고 있다.

element는 실제 인스턴스는 아니다. 대신, element는 개발자가 화면에 표현하고 싶은 것을 React에 전달하는 방식이다. 우리는 element에 그 어떤 method를 실행할 수 없다. element는 그냥 (just) type: (string | ReactClass) and props: Object라는 두개의 fields를 가진 불변성의 설명을 담고있는 객체일 뿐이다.

DOM Elements

element의 type이 string 이라면 DOM node에서 해당 tag 이름으로 대변되고 element의 props는 해당 속성dp 해당한다. 아래 예제 코드는 React가 render할 것에 대한 예제 코드이다.

{
  type: 'button',
  props: {
    className: 'button button-blue',
    children: {
      type: 'b',
      props: {
        children: 'OK!'
      }
    }
  }
}

위 예제 코드는 element를 나타내는 코드로서 다음 예제의 html을 plain object로서 나타낸 방법일 뿐이다.

<button class='button button-blue'>
  <b>
    OK!
  </b>
</button>

위 두 예제에서 볼 수 있듯이 element는 nested 될 수 있다. 컨벤션에 따르면 element tree를 생성할때, 자식 element들은 그들을 가지고 있는 element의 children props으로 명시해줘야 한다.

여기서 중요한 것은 child와 parent elements들은 모두 단지 설명 (description)일뿐 실제 instance는 아니다 라는 점이다. 우리가 child와 parent elements들을 만들 때 화면에 나타나는 것들과는 무관하다. 우리는 자유롭게 그들을 만들고 치워버릴수 있고 이는 큰 영향이 없다. (실제 화면 적용에 중요한 역할을 하는 것은 instance라는 뜻으로 이해)

parsed 될 필요가 없는 React element는 횡단하기에 쉽고 (쉽게 순회가 가능하다? 쉽게 순회하며 조작이 쉽다? 파싱 과정이 없기에) 단지 그저 객체이기에 실제 DOM element보다 훨씬 가볍다.

Component Elements

하지만, elements의 type은 React 컴포넌트에 상승하여 함수 혹은 클래스가 될 수 있다.

{
  type: Button,
  props: {
    color: 'blue',
    children: 'OK!'
  }
}

이것은 리액트의 핵심 아이디어다.

컴포넌트를 묘사하는 element 또한 DOM node를 묘사하는 element와 같이 element다. 그들은 서로 nested될 수도 mixed 될 수 있다.

이 기능 (feature)은 개발자로 하여금 DangerButton컴포넌트를 Button 컴포넌트가 DOM에 <button>, <div>를 렌더링할지 혹은 완전히 다른것을 렌더링 할지에 대한 걱정없이 특정 color 속성 값을 갖는 Button 컴포넌트로서 정의가 가능케 해준다.

const DangerButton = ({ children }) => ({
  type: Button,
  props: {
    color: 'red',
    children: children
  }
});

또한 DOM elements와 component elements를 하나의 single element tree안에 mix하고 match 시킬 수 있다.

const DeleteAccount = () => ({
  type: 'div',
  props: {
    children: [{
      type: 'p',
      props: {
        children: 'Are you sure?'
      }
    }, {
      type: DangerButton,
      props: {
        children: 'Yep'
      }
    }, {
      type: Button,
      props: {
        color: 'blue',
        children: 'Cancel'
      }
   }]
});

jsx로 변환하면 다음과 같다.

const DeleteAccount = () => (
  <div>
    <p>Are you sure?</p>
    <DangerButton>Yep</DangerButton>
    <Button color='blue'>Cancel</Button>
  </div>
);

위처럼 mix and matching은 오로지 합성을 통해서만 상속과 합성 관계를 모두 표현할 수 있기에 컴포넌트들을 서로를 분리 (decouple) 되는것에 도움을 준다.

• Button은 구체적인 속성을 갖는 DOM <button>이다.
• DangerButton은 구체적인 속성을 갖는 Button이다.
• DeleteAccount은 <div>안에 Button과 DangerButton을 포함한다.

Components Encapsulate Element Trees

리액트가 함수 혹은 클래스 type의 element를 마주치면, 해당 component에 주어진 해당 props에 맞게 어떤 element가 렌더링 되는지 묻는다. (When React sees an element with a function or class type, it knows to ask that component what element it renders to, given the corresponding props.)

다음과 같은 element를 리액트가 마주하면

{
  type: Button,
  props: {
    color: 'blue',
    children: 'OK!'
  }
}

리액트는 Button (as Component element)에게 무엇을 렌더링하는지 묻는다. Button은 다음 element를 반환한다.

{
  type: 'button',
  props: {
    className: 'button button-blue',
    children: {
      type: 'b',
      props: {
        children: 'OK!'
      }
    }
  }
}

리액트는 페이지의 모든 컴포넌트와 일치하는 DOM tag elements를 알아낼때까지 위의 일련의 과정을 계속 반복한다.

리액트는 마치 "X는 Y이다."에 대해 온 세계의 모든 것을 다 알 때까지 계속 "Y는 어떤 것"인지 물어보는 어린 아이와 같다.

class Form extends TraditionalObjectOrientedView {
  render() {
    // Read some data passed to the view
    const { isSubmitted, buttonText } = this.attrs;

    if (!isSubmitted && !this.button) {
      // Form is not yet submitted. Create the button!
      this.button = new Button({
        children: buttonText,
        color: 'blue'
      });
      this.el.appendChild(this.button.el);
    }

    if (this.button) {
      // The button is visible. Update its text!
      this.button.attrs.children = buttonText;
      this.button.render();
    }

    if (isSubmitted && this.button) {
      // Form was submitted. Destroy the button!
      this.el.removeChild(this.button.el);
      this.button.destroy();
    }

    if (isSubmitted && !this.message) {
      // Form was submitted. Show the success message!
      this.message = new Message({ text: 'Success!' });
      this.el.appendChild(this.message.el);
    }
  }
}

위 class는 리액트에서는 다음과 같이 작성될 수 있다.

const Form = ({ isSubmitted, buttonText }) => {
  if (isSubmitted) {
    // Form submitted! Return a message element.
    return {
      type: Message,
      props: {
        text: 'Success!'
      }
    };
  }

  // Form is still visible! Return a button element.
  return {
    type: Button,
    props: {
      children: buttonText,
      color: 'blue'
    }
  };
};

모든 elements 가 가진 DOM elements 를 알게 되기 떄문에 React는 해당 DOM elements 들을 적절한 때에 create, update, destroy한다. 따라서 Form UI modeling을 위와 같이 간단하게 구현할 수 있게 되는 것이다.

위 예제 코드처럼 props는 그저 컴포넌트의 input이고 컴포넌트는 element tree를 리턴한다.

리턴된 element tree는 DOM nodes의 정보를 갖는 (describing DOM nodes) elements와 다른 컴포넌트의 정보를 갖는 (describing other components.) element를 모두 포함한다. 이는 개발자 (혹은 리액트 사용자)로 하여금 그들의 내부 DOM 구조에 의존하지 않는 독립적인 부분의 UI를 조합(compose)하게 해준다.

우리는 (리액트 사용자는) 리액트가 instance들을 만들고, 업데이트하고 삭제하도록 위임 (let) 한다. 우리는 (리액트 사용자) 그것을 (instance) 컴포넌트로부터 반환된 element로써 설명(describe)한다. (아마 개발자는 instance에서 관심이 분리되고 그저 어떤 UI를 그릴지, 그것도 독립적으로, 리액트에 알려주기만 하면 되는데 그 방법은 컴포넌트 작성이고 리액트는 그 컴포넌트에서 리턴된 element로서 소통한다는 뜻인듯) 그 후 리액트는 instance들을 managing 하는 것을 담당한다.

Components Can Be Classes or Functions

위에서 살펴본 Form, Message 그리고 Button 코드들은 모두 리액트 컴포넌트들이다. 그들은 위 예제처럼 함수로 또는 React.Component의 상속자로서 class로 작성될 수 있다. 리액트 컴포넌트가 선언 (작성) 될 수 있는 방법은 다음 세 방법과 같다.

// 1) props의 함수로서
const Button = ({ children, color }) => ({
  type: 'button',
  props: {
    className: 'button button-' + color,
    children: {
      type: 'b',
      props: {
        children: children
      }
    }
  }
});

// 2) React.createClass() factory를 사용해서
const Button = React.createClass({
  render() {
    const { children, color } = this.props;
    return {
      type: 'button',
      props: {
        className: 'button button-' + color,
        children: {
          type: 'b',
          props: {
            children: children
          }
        }
      }
    };
  }
});

// 3) descending React.Component를 상속받은 ES6 class로서
class Button extends React.Component {
  render() {
    const { children, color } = this.props;
    return {
      type: 'button',
      props: {
        className: 'button button-' + color,
        children: {
          type: 'b',
          props: {
            children: children
          }
        }
      }
    };
  }
}

클래스형 컴포넌트는 함수형 컴포넌트보다 조금 더 powerful하다. 클래스형 컴포넌트는 해당 DOM node가 만들어지거나 지워질 때 일부 로컬 상태 (state)를 저장하고 custom 로직을 수행할 수 있다.

함수형 컴포넌트는 클래스형 컴포넌트 덜 powerful하나 더 simple하고 하나의 render() method를 가지고 있는 클래스형 컴포넌트와 동일하게 작동한다. 리액트 팀은 class에서만 사용가능한 기능이 필요하지 않는한 함수형 컴포넌트 사용을 권장한다.

Top-Down Reconciliation

ReactDOM.render({
  type: Form,
  props: {
    isSubmitted: false,
    buttonText: 'OK!'
  }
}, document.getElementById('root'));

만약 위 코드를 실행하면 어떤 일이 일어날까?

리액트는 Form 컴포넌트에 주어진 props에 대해 어떤 element tree를 반환할지 물어볼 것이다. (React will ask the Form component what element tree it returns, given those props.) 리액트는 작성된 컴포넌트들을 이해하는 과정을 더 간단한 원어들로(primitive as original language 서서히 개선, 개량(refine)할 것이다.

// 개발자가 React에 주어진 props와 함께 Form 컴포넌트를 그려달라고 함
{
  type: Form,
  props: {
    isSubmitted: false,
    buttonText: 'OK!'
  }
}

// Form 컴포넌트가 리액트에 return한 값
{
  type: Button,
  props: {
    children: 'OK!',
    color: 'blue'
  }
}

// Button 컴포넌트가 return한 값. 하위에 더 이상의 children이 없는것으로 사료되어 React는 더 물어볼 것이 없음
{
  type: 'button',
  props: {
    className: 'button button-blue',
    children: {
      type: 'b',
      props: {
        children: 'OK!'
      }
    }
  }
}

위의 일련의 과정을 리액트에서는 reconciliation 이라고 불리는데 이 과정은 우리가 ReactDOM.render() 혹은 setState()을 호출할 때 시작된다. reconciliation이 끝나면 리액트는 최종 DOM tree가 어떻게 구성되어있는지 알게 되고 react-dom 혹은 react-native 같은 renderer가 DOM nodes를 업데이트하기 위해 필요한 최소한의 변화들을 적용한다.

이런 점진적 (gradual) 정제과정은 React 어플리케이션이 최적화하기 쉬운 이유중 하나이다. 만약 컴포넌트 트리가 리액트가 능률적으로 방문 (visit. 아마 위 과정을 모두 훑어보는 것을 의미하는듯)하기에 너무 커진다면, props의 변화가 없다면 이 정제과정 (refining process)과 tree의 특정 부분을 비교 (diffing)하는 것을 건너뛰라고 말할 수 있기 때문이다. 만약 props들이 immutable, 불변하다면 props의 변화유무에 대해 계산하는 것은 굉장히 빠를 것이고 그렇기에 리액트와 불변성은 함께 시너지를 발휘하고 최소한의 노력(effort)으로 큰 최적화(optimization)를 제공할 수 있다.

이 글을 지금까지 보면서 알 수 있듯이, 컴포넌트와 element에 대해서는 많은 설명이 있지만 instance는 그렇지 않다. 그 이유는 다른 대부분의 object-oriented UI 프레임워크에 비해 리액트에서 instance는 그 중요도가 크지 않다.

클래스형 컴포넌트만 instance를 가지고 있고 우리는 절대 직접적으로 instance를 생성하지 않는다: 대신 리액트가 생성하는 일을 해준다. (maybe not only create, but update and destroy). 비록 부모 컴포넌트 instance가 자식 컴포넌트 instance에 접근할 수 있는 mechanism(ref를 말하는듯)이 존재하지만, 그 mechanism은 오직 꼭 필요한 행위(action)를 위해서만 사용되어야하고 일반적으로는 사용을 피해야한다. (ex: fields에 focus on을 하는 등)

리액트는 모든 클래스 컴포넌트에 대한 인스턴스를 만드는 것을 대신 해주기에 우리는 컴포넌트들 methods와 로컬 state와 함께 object-oriented 방식으로 작성할수 있지만 그것 외에도 instance는 리액트 프로그래밍 모델에서 그렇게 중요하지 않고 React에 의해 알아서 manage 된다.

정리

element는 우리가 화면에 나타내고 싶은 것을 DOM nodes나 다른 컴포넌트로서 설명을 하는 plain object이다. element는 다른 element를 자신들의 props로 가지고 있을 수 있다. React element를 생성하는 것은 저렴하다. 한번 element가 만들어지면 절대 불변이다 (never mutated).

컴포넌트는 여러 다른 방법으로 선언이 가능하다. 컴포넌트는 render() 메소드를 내포하는 클래스일 수 있다. 대안으로 더 간단한 방법은 함수로 정의되는 것이다. 두 경우 모두 props를 input으로 받고 element tree를 output으로서 반환한다.

만약 컴포넌트가 props들을 input으로 받는다면 (receives), 이는 특정 부모 컴포넌트가 해당 타입과 props와 함께 element를 리턴했기 때문이다. 그렇기에 React에서 props는 부모에서 자식으로 한방향으로 flow한다는 이유이다.

instance는 우리가 작성하는 컴포넌트 class안의 this로 대변되는 것이다. instance는 로컬 state를 보관하고 라이프사이클 이벤트들에 반응하기에 유용하다.

함수형 컴포넌트는 instances가 아예 없다. 클래스형 컴포넌트는 instances를 갖지만 리액트가 알아서 해주기에 우리는 직접 컴포넌트 instance를 만들 필요가 없다.

최종적으로 elements를 만들기 위해서는 React.createElement(), JSX 혹은 element factory helper를 사용한다. 실제 코딩에 element를 plain objects로 작성하는 것을 권장하지 안흔ㄴ다. 그저 내부적으로 elements는 plain objects라는 것만 알아두자.

정리 in my words

결국 React element는 기존 OOP UI model의 문제점을 개선하기 위함이라고 볼 수 있을 것 같다. 컴포넌트가 많아질수록 instance도 많아지고 이는 각 instance에 대한 로직 (instance 조작)이 많아진다는 결론을 유추 가능하다. 이렇게 되면 하나의 컴포넌트가 수행해야할 일들이 많아질 수 있다는 뜻인데 결론적으로 부모와 자식의 분리가 어렵다는 뜻으로 볼 수 있다. 더 나아가 왜 hooks와 함수형 컴포넌트를 리액트 팀에서 권장하는지에 대한 힌트로도 볼 수 있다. 결국 부모와 자식의 분리뿐 아니라 로직과 ui의 분리도 어렵다고 볼 수 있지 않을까?

따라서 리액트에서는 element라는 개념을 활용했다. element는 그저 화면에 그려질 것들을 props와 type으로서 DOM node를 설명하는 것이다. 즉 다시말해 element는 그저 DOM node의 정보 객체라고 볼 수 있다. 또한 element는 다른 elements를 props로 가지고 있을 수 있는데 그렇기 떄문에 tree 구조가 될 수 있다. 이는 바꿔말해 우리가 컴포넌트를 작성하면 React가 실제 DOM tree와 같은 위계질서를 갖는 구조로 파악할 수 있다는 뜻이다. 또한 element의 타입은 element이거나 컴포넌트 일 수 있는데 이는 기존의 DOM node와 React component를 mix하고 nest하는 구조로 만들 수 있다는 것이다.

또한 reconciliation을 통해 react는 모든 dom tree를 완벽하게 알게되고, 리액트는 렌더링과 제거되는 부분을 적절하게 알고 따로 진행한다. 그리고 우리 작성한 elements에는 DOM tree에 전달할 정보만 담고 있으면 된다. 실제 Dom의 구조를 활용하는게 아니라 elements를 활용해서 나머지 로직들은 다른곳에서 제어하고, 필요한 정보만 독립적으로 UI로 관리 할 수 있도록 하여 기존의 UI모델링을 분리해서 간단하게 구현 할 수있게 된다.

결론의 결론은 element는 DOM tree에게 전달할 정보를 가지고 있는 순수 객체라고 보면 된다.

1. element는 화면에 나타낼 DOM tree에 대한 정보를 가지고 있는 순수 객체
2. component는 props를 input으로 받아 DOM Node를 출력하는, 리액트로 만들어진 앱을 이루는 최소한의 단위
3. instance 클래스로 선언된 Component에서만 갖는 것.

DOM Node와 element 더 알아보기

render()함수는 브라우저에서 UI를 render 하려할 때 마다 불리우는 함수이다. 최상위 render 함수는 React element들의 트리를 재귀적으로 리턴하는 함수라고 볼 수 있다. 그 후 다음 렌더 cycle에서 해당 컴포넌트의 트리는 다시 생성된다(regenerated). 리액트는 위 두개의 트리를 diff (변경점을 찾는것)해야 하고 실제 브라우저 DOM에 해당 diff를 적용해야한다. 리액트가 어느 부분의 UI가 변경되어야 하는지 결정하기 위해 하나의 트리와 다른 트리의diff에 사용하는 알고리즘을 reconciliation이라고 한다. 📎React Internals (Part 1) - The Basic Concepts and the Prerequisites

1. Reconciliation

리액트는 매 업데이트마다 개발자가 정확히 무엇이 변경되는지 걱정할 필요없게 선언적 API를 제공한다. 이로 인해 어플리케이션 개발 (writing applications)은 엄청 쉬워졌지만 이것이 어떻게 React에 적용되었는지 (implemented, 주입되었는지) 명확하지 않다. 이 후의 글들은 high-performance app에서도 충분히 빠를 수 있게 컴포넌트 업데이트가 예측가능할 수 있도록 React의 diffing 알고리즘에 어떠한 결정을 내렸는지 설명할 것이다.

2. Motivation of reconciliation

우리가 React를 사용할 때, render() 함수는 React 요소의 트리를 생성하는 것으로 생각이 드는 순간이 있을 것이다. state나 props가 갱신되면 render() 함수는 새로운 React 엘리먼트 트리를 return 한다. 그 후 React는 가장 최신의 트리 (the most recent tree)와 일치하는 UI로 업데이트 하기 위해 효과적으로 (efficiently) 할 수 있는 방법을 찾아내야한다.

하나의 트리를 다른 트리로 변환하기 위해 최소한의 연산을 하는 알고리즘 문제를 풀기 위해 일반적인 해결책들이 있다. 그러나 이러한 최첨단의 알고리즘도 n개의 엘리먼트가 있는 트리에 대해 O(n3)의 복잡도를 가진다.

React에 이 알고리즘을 적용한다면, 1000개의 엘리먼트를 그리기 위해 10억 번의 비교 연산을 수행해야 한다. 너무나도 비싼 연산이기에 React는 대신, 두 가지 가정을 기반하여 O(n) 복잡도의 휴리스틱 알고리즘을 구현했습니다.

첫번째로, 서로 다른 타입의 두 엘리먼트는 서로 다른 트리를 만들어낸다. 두번째로, 개발자가 key prop을 통해, 여러 렌더링 사이에서 어떤 자식 엘리먼트가 변경되지 않아야 할지 표시해 줄 수 있다.

실제로 거의 모든 사용 사례에서 이 가정들은 들어맞았다.

3. The Diffing Algorithm: 비교 알고리즘

두 개의 트리를 비교(diffing) 할 때, React는 먼저 두 엘리먼트의 루트(root) 엘리먼트부터 비교한다. 이후의 동작은 루트 엘리먼트의 타입에 따라 달라진다.

3.1. DOM 엘리먼트의 타입이 다른 경우

두 루트 엘리먼트의 타입이 다른 모든 경우에는, React는 이전 트리를 버리고 처음부터 완전히 새로운 트리를 만든다. <a>에서 <img>로, <Article>에서 <Comment>로, 혹은 <Button>에서 <div>로 바뀌는 것 모두 트리 전체를 재구축하는 경우다.

트리를 버릴 때 이전 DOM 노드들은 모두 파괴되고 컴포넌트 인스턴스는 componentWillUnmount()가 실행된다. 새로운 트리가 만들어질 때, 새로운 DOM 노드들이 DOM에 삽입된다. 그에 따라 컴포넌트 인스턴스는 UNSAFE_componentWillMount()가 실행되고 componentDidMount()가 이어서 실행된다. 이전 트리와 연관된 모든 state는 사라진다.

루트 엘리먼트 아래의 모든 컴포넌트도 당연 모두 언마운트되고 그 state도 사라집니다. 예를 들어, 아래와 같은 비교가 일어나면,

<div>
  <Counter />
</div>

// when obove updated into below

<span>
  <Counter />
</span>

// then the explanation above the code block will be executed or getting into process

이전 Counter는 사라지고, 새로 다시 마운트가 된다.

3.2. DOM 엘리먼트의 타입이 같은 경우

같은 타입의 두 React DOM 엘리먼트를 비교할 때, React는 두 엘리먼트의 속성을 확인하여, 동일한 내역은 유지하고 변경된 속성들만 갱신한다. 예를 들어,

<div className="before" title="stuff" />

<div className="after" title="stuff" />

위 두 엘리먼트를 비교할 때, React는 현재 DOM 노드 상에 className만 수정한다. style이 갱신될 때, React는 또한 변경된 속성만을 갱신한다. 예를 들면,

<div style={{color: 'red', fontWeight: 'bold'}} />

<div style={{color: 'green', fontWeight: 'bold'}} />

위 두 엘리먼트 사이에서 변경될 때, React는 fontWeight는 수정하지 않고 color 속성 만을 수정한다. DOM 노드의 처리가 끝나면, React는 이어서 해당 노드의 children을 재귀적으로 처리한다.

3.3. 컴포넌트 엘리먼트의 타입이 같은 경우

컴포넌트가 업데이트될 때, 인스턴스는 동일하게 유지되어 렌더링 간 state가 유지된다. React는 새로운 엘리먼트의 내용을 반영하기 위해 현재 컴포넌트 인스턴스의 props를 업데이트 하고 이때 해당 인스턴스의 UNSAFE_componentWillReceiveProps(), UNSAFE_componentWillUpdate(), componentDidUpdate를 호출합니다. 그 후, render() 메서드가 호출되고 비교 알고리즘이 이전 결과와 새로운 결과를 재귀적으로 처리합니다.

3.4. children에 대한 재귀적 처리

DOM 노드의 children에 대해 재귀적 처리를 할 때, 기본적으로 React는 list of children을 동시에 순회하고 차이점이 있으면 변경을 생성할 것이다. 예를 들어, children의 끝에 엘리먼트를 추가하면, 두 트리 사이의 변경은 잘 작동할 것이다.

<ul>
  <li>first</li>
  <li>second</li>
</ul>

<ul>
  <li>first</li>
  <li>second</li>
  <li>third</li>
</ul>

React는 두 트리에서 <li>first</li>가 일치하는 것을 확인하고, <li>second</li>가 일치하는 것을 확인합니다. 그리고 마지막으로 <li>third</li>를 트리에 추가한다.

하지만 위와 같이 단순하게 구현하면, 리스트의 맨 앞에 엘리먼트를 추가하는 경우 성능이 좋지 않을 것이다. 예를 들어, 아래의 두 트리 변환 예제는 형편없이 (poorly) 작동한다.

<ul>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

<ul>
  <li>Connecticut</li>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

React는 <li>Duke</li>와 <li>Villanova</li> 종속 트리를 그대로 유지하는 대신 모든 자식을 변경할 것이다. 이러한 비효율은 문제가 될 수 있다.

3.5. key

이러한 위의 문제를 해결하기 위해, React는 key 속성을 지원한다. 자식들이 key를 가지고 있다면, React는 key를 통해 기존 트리와 이후 트리의 자식들이 일치하는지 확인할 것이다. 예를 들어, 위 비효율적인 예시에 key를 추가하여 트리의 변환 작업이 효율적으로 수행되도록 수정할 수 있다.

<ul>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

<ul>
  <li key="2014">Connecticut</li>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

이제 React는 '2014' key를 가진 엘리먼트가 새로 추가되었고, '2015'와 '2016' key를 가진 엘리먼트는 그저 이동만 하면 되는 것을 알게 된다. 실제로, key로 사용할 값을 정하는 것은 어렵지 않다. 그리려고 하는 엘리먼트는 일반적으로 식별자를 가지고 있을 것이고, 그대로 해당 데이터를 key로 사용하면 된다.

이러한 상황에 해당하지 않는다면, 여러분의 데이터 구조에 ID라는 속성을 추가해주거나 데이터 일부에 해시를 적용해서 key를 생성할 수 있다. 해당 key는 오로지 형제 사이에서만 유일하면 되고, 전역에서 유일할 필요는 없다.

최후의 수단으로 배열의 인덱스를 key로 사용할 수 있다. 항목들이 재배열되지 않는다면 이 방법도 잘 동작할 것이지만, 재배열되는 경우 비효율적으로 동작할 것이다.

인덱스를 key로 사용 중 배열이 재배열되면 컴포넌트의 state와 관련된 문제가 발생할 수 있는데, 컴포넌트 인스턴스는 key를 기반으로 갱신되고 재사용된다. 인덱스를 key로 사용하면, 항목의 순서가 바뀌었을 때 key 또한 바뀌게 되고 그 결과, 컴포넌트의 state가 엉망이 되거나 의도하지 않은 방식으로 바뀔 수도 있다.

4. 고려 사항

reconciliation 알고리즘은 구현상의 세부사항일뿐이다. React는 항상 전체 앱을 재렌더링할 수도 있지만, 최종적으로 출력되는 결과는 항상 같을 것이다. 좀 더 정확히 말하자면, 여기서 말하는 재렌더링은 모든 컴포넌트의 render를 호출하는 것이지 React가 언마운트시키고 다시 마운트하는 것은 아니다. 즉, 앞서 설명했던 규칙에 따라 렌더링 전후에 변경된 부분만을 적용한다.

우리는 일반적인 사용 사례에서 더 빠르게 작동할 수 있도록 계속 휴리스틱 알고리즘을 개선하고 있다. 현재 적용된 방법은 한 종속 트리가 그 형제 사이에서 이동했다는 사실을 표현할 수는 있지만, 아예 다른 곳으로 이동했다는 사실은 표현할 수 없다. 알고리즘은 전체 종속 트리를 재렌더링할 것입니다.

React는 휴리스틱에 의존하고 있기 때문에, 휴리스틱이 기반하고 있는 가정에 부합하지 않는 경우 성능이 나빠질 수 있다.

알고리즘은 다른 컴포넌트 타입을 갖는 종속 트리들의 일치 여부를 확인하지 않는다. 매우 비슷한 결과물을 출력하는 두 컴포넌트를 교체하고 있다면, 그 둘을 같은 타입으로 만드는 것이 더 나을 수도 있다. React team은 실제 사용 사례에서 이 가정이 문제가 되는 경우를 발견하지 못했다. key는 반드시 변하지 않고, 예상 가능하며, 유일해야 한다. 변하는 key(Math.random()으로 생성된 값 등)를 사용하면 많은 컴포넌트 인스턴스와 DOM 노드를 불필요하게 재생성하여 성능이 나빠지거나 자식 컴포넌트의 state가 유실될 수 있다.

타입변환은 코더의 의도에 따라 가시적으로 의도가 보이는 명시적 타입변환과 엔진에 의해 자동으로 변환되는 암묵적 타입변환이 있다. 단축평가는 값을 평가하여 코드 흐름을 제어할 떄 좀 더 간결하게 사용할 수 있는 연산문으로 대표되며 단축평가에서 예측가능한 코드를 위해 타입 변환이 어떻게 동작하는지 이해해보자.

9.1 타입변환이란?

자바스크립의 모든 값은 타입이 있고 이 타입은 개발자의 의도에 따라 다른 타입으로 변환할 수 있다. 이를 명시적 타입 변환 / explicit coercion, 또는 타입 캐스팅 type casting이라고 한다.

var x = 10;

//명시적 타입 변환
var str = x.toString(x);
console.log(typeof str, str); // 'string', '10'

console.log(x); // 10
// 그렇다고 기존 원시값과 타입이 변하지는 않는다.

반대로 자바스크립트가 표현식을 평가하는 도중에 엔진에 의해 개발자의 의도와 상관없이 암묵적으로 타입이 자동 변환되기도 하는데 이를 암묵적 타입 변환 / implicit coercion 또는 타입 강제 전환 / type coercion 이라고 한다.

var x = 10;

var str = x + '';

console.log(typeof str, str); // 'string', '10'

console.log(x); // 10
// 그렇다고 기존 원시값과 타입이 변하지는 않는다.

위 두 예제에서 봤듯이 명시적 타입 변환이든 암묵적 타입 변환이 일어나든 기존 원시 값을 직접 변경하는 것은 아니며 이미 정리했든 원시 값은 변경 불가능한 값, immutable value이다. 즉 기존 워시 값을 사용해 다른 타입의 새로운 원시 값을 사용하여 (생성하여) 평가에만 사용할 뿐 기존 변수에 재할당되지 않는다. 단지 엔진이 표현식을 에러 없이 평가하기 위해 타입 변환을 통해 새로운 값을 만들어 단 한 번 사용한 후 버린다.

명시적 타입 변환은 개발자의 의지와 의도가 코드에 명백히 드러나는 반면 암묵적 타입 강제 변환은 암묵적으로 자동 변환되기 떄문에 코드 흐름에 따라 그 의도와 의미 (값의 타입) 예측과 추적이 예측하기 힘들어질 수 있다. 이는 곧 오류 발생 확률을 높히기도 한다.

9.2. 암묵적 타입 변환

자바스크립트 엔진은 표현식을 평가할 때 코더의 의도와 상관없이 코드의 문맥을 고려해 암묵적으로 타입을 강제 변환할 때가 있다.

// 피연산자가 모두 문자열 타입이어야 하는 문맥
'10' + 2 // '102'

// 피연산자가 모두 숫자타입이어야 하는 문맥
5 * '10' // 50

// 피연산자 또는 표현식이 불리언 타입이어야 하는 문맥

!0 // true

if (1) {
// if문의 코드 블럭이 실행된다.
}

위 예제처럼 표현식을 평가할 때 문맥에 부합하지 않는 상황이 발생하면 자바스크립트는 가급적 에러를 발생시키지 않도록 암묵적 타입 변환을 통해 표현식을 평가한다. 암묵적 타입 변환이 발생하면 원시 타입 중 하나로 타입을 자동 변환한다.

9.2.1. 문자열 타입으로 변환

1 + '2' //  '12'

전에 정리했듯이 피연산자중 하나 이상이 문자열이면 +연산자는 문자열 연결 연산자로 동작한다. 문자열 연결 연산자의 역할은 문자열 값을 만드는 것이므로 모든 피연산자는 코드의 문맥에서 모두 문자열 타입이어야 한다. 따라서 자바스크립트 엔진은 문자열 연결 연산자 표현식을 평가하기 위해 피연산자 중에서 문자열 타입이 아닌 피연산자를 문자열 타입으로 강제 변환한다.

이뿐만 아니라 템플릿 리터럴은 표현식의 평가 결과를 문자열 타입으로 암묵적으로 변환하는데 이처럼 피연산자 뿐만 아니라 표현식 또한 코드 문맥에 부합이 필요하다면 자바스크립트 엔진은 암묵적 타입 변환을 실행한다.

`1 + 1 = ${1 + 1}` // "1 + 1 = 2"

문자열 타입이 아닌 값을 문자열 타입으로 강제 변환되는 예는 다음과 같다.

// 숫자타입
0 + '' // "0"
-0 + '' // "0"
1 + '' // "1"
-1 + '' // "-1"
NaN + '' // "NaN"
Infinity + '' // "Infinity"
-Infinity + '' // "-Infinity"


//boolean type
true + '' //  'true'
false + '' //  'false'

// null type
null + '' // 'null'

// undefined type
undefined + '' // 'undefined'

// Symbol type
(Symbol()) + '' // TypeError: Cannot convert a Symbol value to a string

// Object type
({}) + '' // '[object Object]'
Math + '' // '[object Math]'
[] + '' // ''
[10, 20] + '' // "10,20"
(function(){}) + '' //  "function(){}"
Array + '' // "function Array() { [native code] }"

9.2.2. 숫자 타입으로 변환

연산식에서 문자열 연결 연산자을 제외한 모든 연산자는 산술 연산자이며 그 역할은 숫자 값을 만드는 것이다. 즉, 모든 피연산자는 코드 문맥상 모두 숫자 타입이어야 한다. 따라서 산술 연산자 표현식을 평가하기 위해 산술 연산자의 피연산자 중에서 숫자 타입이 아닌 경우 숫자 타입으로 암묵적 타입 변환한다. 이때 숫자 타입으로 변환되지 않는 값은 NaN이 된다.

또한 숫자 타입 변환이 일어나는 문맥은 산술 연산자뿐만 아니라 비교 연산자에서도 일어난다. 비교 연산자에서도 숫자 타입으로 암묵적 타입 변환이 일어나는 이유는 크기를 비교해야하기 떄문이다.

앞서 연산자 부분에서 + 단항 연산자는 피연산자가 숫자 타입의 값이 아닐 경우 숫자 타입으로 강제 변환한다고 했다. + 단항 연산자를 통해 다른 타입들이 숫자타입으로 어떻게 변환되는지 알아보자.

+'' //  0
+'0' // 0
+'1' // 1
+'string' // NaN

+true // 1 
+false // 0

+null // 0

+undefined // NaN

+Symbol() // TypeError: cannot convert a Symbol value to a number

+{} // NaN
+[] // 0
+[10,20] // NaN
+(function(){}) // NaN

runjs로 이것저것 하다가 재밌는것을 발견했다. object 타입 피연산자에 숫자 피연산자를 + 연산자로 연산하는 표현식을 실행해보면 신기한 결과가 나온다. object 타입의 문자열로의 타입 강제전환 후 string + number인 경우처럼 + 연산자가 문자열 연결 연산자로 작동한 결과처럼 보였다. 뇌피셜이긴 하지만 객체타입과 숫자타입의 피연산자를 + 연산자로 연산할 경우 객체타입은 문자열로 강제타입 변환 후 연산이 되는 것 같다.

// 분명 문자열 연결 연산자가 아닐것 이라고 생각했는데 
// 마치 "" + 1 처럼 작용됐다. 
[]+1 // "1"

// 분명 문자열 연결 연산자가 아닐것 이라고 생각했는데 
// 마치 ({} + '') + 1 처럼 작용됐다. 
{} + 1 // '[object Object]1'

반대로 - 연산자의 경우 숫자타입 변환 예제처럼 작동한다.

console.log([] - 1) // -1
console.log({} - 1) // NaN

9.2.3. 불리언 타입으로 변환

불리언 타입으로 변환은 if 문이나 for문과 같은 제어문 또는 삼항 조건 연산자의 조선식을 활용할 때 사용된다.

if (true) console.log('1')
if ('') console.log('2')
if (0) console.log('3')
if ('str') console.log('4')
if (null) console.log('5')

// 1, 4

이때 자바스크립트 엔진은 불리언 타입이 아닌 값을 Truthy 값 또는 Falsy 값으로 구분한다. 즉 불리언 값으로 평가되어야 할 문맥 (ex: 제어문의 조건식)에서 Truthy 값은 true로 Falsy 값은 false로 불리언 타입으로 암묵적 타입 변환한다.

• Falsy값들: false, undefined, null, 0, -0, NaN, ""

Falsy 값들을 제외한 모든 값은 모두 true로 평가되는 Truthy 값이다.

//Truthy 값들
function isFalsy(value) {
  return !value
}

function isTruthy(value) {
  return !!value
}

isFalsy(false);
isFalsy(undefined);
isFalsy(null);
isFalsy(0);
isFalsy(-0);
isFalsy(NaN);
isFalsy('');
// all return false

isTruthy(true);
isTruthy('0');
isTruthy({});
isTruthy([]);
isTruthy(Infinity);
// all return true

연산자는 하나 이상의 표현식을 대상으로 산술, 할당, 비교, 논리, 타입, 지수 연산 등을 수행하여 하나의 값을 만든다. 이때 연산의 대상은 피연산자이다. 피연산자는 당연히 값으로 평가될 수 있는 표현식이어야하고 연산자 표현식도 값으로 평가될 수 있는 표현식이다. 즉, 연산자는 값으로 평가된 피연산자 또는 값으로 평가된 표현식을 연산해 새로운 값 또는 표현식을 만든다.

7.1. 산술 연산자

Algebra or Arithmetic operator 피연산자를 대상으로 수학적 계산을 통해 새로운 숫자 값을 만든다. 피연산자간 산술 연산이 불가능한 경우 NaN을 반환한다.

7.1.1. 이항 산술 연산자 / Binary

2개의 피연산자를 산술 연산하여 숫자 값을 만드는 연산자로서 사용된 피연산자의 값을 변경하는 side effect가 없는 것이 특징이다. 즉 언제나 새로운 값을 만들어낸다.

+ 
//덧셈
- 
// 뺄셈
*
// 곱셀
/ 
//나눗셈
% 
// 나머지
5%2 = 1
// 5를 2로 나눈후 (정수만) 남은 값

7.1.2. 단항 산술 연산자 / Unary

1개의 피연산자만을 대상으로 산술 연산하여 숫자 값을 만든다.

증가, 감소 연산자는 피연산자의 값을 변경하는 부수 효과가 있다. 다음 예제로 살펴보자.

var x = 1;

x++;

console.log(x)
// 2

x--;
console.log(x)
// 1

또한 증가, 감소 연산자는 연산자의 위치에 따라 값이 달라질 수 있다.

var x= 5, result;

//선할당 후증가 (postfix increment operator)
result = x++;

console.log( x, result )
// 6, 5

//선증가 후할당 (prefix increment operator)
result = ++x;

console.log( x, result)
// 7, 7

//선할당 후감소 (postfix increment operator)
result = x--;

console.log( x, result )
// 6, 7

//선감소 후할당 (prefix increment operator)
result = --x;

console.log( x, result)
// 5, 5

+, - 단항 연산자는 그 어떠한 피연산자에 주는 부수효과가 없다. 다음예제를 통해 정리해보자.

+10
// 10
+(-10)
// 10
-(-10)
// 10

-'10' // -10. 문자열은 연사자의 피연사자일 때 숫자로 치환되는데 

-'x' // NaN. 숫자로 치환할 수 없는 문자열일 경우 NaN

숫자 타입이 아닌 피연산자에 + 단항 연산자를 사용하면 피연산자를 숫자 타입으로 변환하여 반환한다. 다만 피연산자를 변경하는 것이 아니라 단지 연산에 사용될 피연사자의 값을 숫자 타입으로 변환하여 연산에 사용한다.

var x = '1';

console.log(+x); //1 as number

//부수효과 없음
console.log(x); // "1" as string

x = true;

console.log( +x ); // 1 as number

console.log(+x+1); // 2 as number. true는 숫자와 연산시 숫자 1로 치환된다.

//부수효과 없음
console.log(x); // true

x = false;

console.log( +x ); // 0 as number

console.log(+x+1); // 1 as number. false는 숫자와 연산시 숫자 0으로 치환된다.

//부수효과 없음
console.log(x); // false

x = 'x';

console.log(+x); // NaN

//부수효과 없음
console.log(x); //'x'

7.1.3. 문자열 연결 연산자

• 연산자는 피연산자 중 하나 이상이 문자열인 경우 문자열 연결 연산자로 동작한다. 그 외의 경우는 산술 연산자로 동작.

//피연산자 중 하나 이상이 문자열인 경우
"1"+2; // '12' as string

1 + '2'; // 12 as string

// 피연산자 중 하나 이상이 문자열인 경우 외의 경우

1 + 2; // 3

1 + true; // 2

1+ false; // 1

1 + null; // 1. null 또한 산술 연산자로 작동한 연산식에서는 0으로 치환된다. 

1 + undefined; // NaN

+undefined; // NaN

불리언 타입, null 타입이 산술 연산자로 동작한 연산식에 있을 경우 자바스크립트 엔진은 타입과 값을 변경한다. 또한 string 타입이 피연산자 중 하나로서 연산자가 문자열 연결 연산자로 동작할 경우 string은 number 타입과 값으로 변경된다. 다만 string값이 number의 값으로서 치환될 수 없을 경우 NaN으로 치환된다.

위의 일련의 변경 과정을 암묵적 타입 변환 (implicit coercion) 또는 타입 강제 변환 (type coercion) 이라고 한다. to be continue in CH.9 타입 변환과 단축 평가

7.2. 할당 연산자 / Assignment operator

변수에 값을 할당하는 여러 연산자

var x;

x= 10;
// 10

x +=5 // x = x+5
// 15

var str = "My name is";

str += "Lee"; // str = str + "Lee"
// My Name is Lee

앞서 표현식은 값으로 평가될 수 있는 문으로 문에는 표현식인 문과 아닌 문이 있다고 정리했다.

그렇다면 할당문은 표현식인 문일까?

할당문은 변수에 값을 할당하는 부수 효과만 일을 뿐 값으로 평가되지 않을 것 처럼 보인다. 하지만 ** 값으로 평가되는 표현식인 문으로서 할당된 값으로 평가 ** 된다.

var x;

console.log(x=10);
// 10

따라서 다음과 같은 동일한 값을 연쇄 할당도 할 수 있는 것이다.

var a, b, c;

a = b = c = 10;

console.log(a, b, c)
// 10, 10, 10

7.3. 비교 연산자 / Comparison operator

좌항과 우항의 피연산자를 비교 후 결과를 불리언 값으로 반환하는 연산자.

7.3.1. 동등/일치 비교 연산자

동등 비교 (loose equality) 연산자와 일치 비교 (strict equality) 연산자는 좌항과 우항의 피연산자가 같은 값으로 평가되는지 비교해 불리언 값을 반환한다. 다만 그 엄격성의 정도가 다르다. shallow vs deep

동등 비교 연산자는 좌항과 우항의 피연산자를 비교할 때 먼저 암묵적 타입 변환을 통해 타입을 일치시킨 후 같은 값인지 비교한다. 즉, 좌항과 우항의 피연산자가 같은 타입이 아니더라도 암묵적 타입 변환 후 같은 값이라면 true일 수 있다.

5 ==5; // true

5 == '5'; // true

이처럼 암묵적 타입 변환이 이뤄지기 때문에 결과를 예측하기 어렵고 의도치않은 결과가 나올 수 있다. 다음과 같다.

'0' == ''; // false
0 == ''; // true
0 == '0'; // true

false == 'false'; // false
false == '0'; // true
false == 0; // true
false == null; // false
null == 0; // false*
false == undefined; //false

이처럼 동등 비교 연산자는 예측하기 어려운 결과를 만들어낸다. 대신 일치 비교 연산자, deep comparison / deep equality를 사용하는 것이 좋다.

** 추가적으로 같이 보면 좋을것들** truthy and falsey 문자열 '0'은 문자열 연결 연산자로 작동하는 연산문에서 숫자 0 으로 타입 변경이 된다. false는 0으로 true는 1로 타입 변경 및 값이 변경된다. null은 0으로 타입과 값이 변경된다. 하지만 비교 연산자에서 동등 비교 연산시 null은 null로서 남아있는다.

0 == null; // false

일치비교 연산자는 좌항과 우항의 피연산자의 타입과 값이 모두 같은 경우에만 true를 반환한다. 즉, 암묵적 타입 변환이 이뤄나지 않아 결과 예측이 쉽다.

5 ===5; // true
5 ==='5'; // false

하나 짚고 넘어가야할 부분은 NaN이다.

NaN === NaN; // false

'1' == NaN; // false

NaN은 자신과 일치하지 않은 유일한 값이다. 따라서 비교 연산자에서 값이 NaN인지 조사하려면 함수 Number.isNaN을 사용하여야 한다.

Number.isNaN(NaN); // true
Number.isNaN(10); // false
Number.isNaN(1 + undefined); // true

숫자 0 또한 양의 0과 음의 0이 모두 존재하는데 이 둘을 비교하면 true가 반환된다.

0 === -0; // true
0 == -0; // true

// Object.is 함수를 이용하면 좀 더 예측 가능한 정확한 비교가 가능하다.

0 === -0; // true
Object.is(-0, +0); // false

NaN === NaN; // false
Object.is(NaN, NaN); // true

7.3.2. 대소 관계 비교 연산자

대소 관계 비교 연산자 비교표

7.4. 삼항 조건 연산자 / ternary operator

삼항 조건 연산자는 조건식의 평가 결과에 따라 변환할 값을 결정한다. 부수 효과는 없고 다음과 같이 사용한다.

var result = score >=60 ? 'pass' : 'fail'

score의 값이 60과 같거나 큰지에 대한 연산이 먼저 실행된다. ?를 기준으로 좌항의 값이 참이면 :뒤의 값을 리턴하고 참이 아니면 fail을 리턴한다. 삼항 연산자는 조건문의 줄임으로 사용될 수 있다.

var x = 2, result;
if (x%2) result = '홀수';
else result = '짝수';

var result = x % 2 ?'홀수' : '짝수';

다만 차이점은 삼항 조건 연산자 표현식은 값처럼 사용할 수 있다. 즉 값으로 평가할 수 있는 표현식인 문이다.

7.5. 논리 연산자 / logical operator

우항과 좌항의 피연산자 (부정 논리 연산자의 경우 우항의 피연산자)를 논리 연산한다.

// 논리합 연산자
// || 기준 좌항의 값이 true일 경우 좌항을 return, false일 경우 우항을 return
true || true; // true
true || false; // true
false || true; // true
false || false; // true

// 논리곱 연산자
// && 기준 좌항의 값이 true일 경우 우항을 return, false일 경우 좌항을 return
true && true; // true
true && false; // false
false && true; // false
false && false; // false

// 논리 부정 연산자
!false; // true
!true; // false

논리 부정 연산자는 언제나 불리언 값을 반환한다. 만약 피연산자가 불리언 값이 아니면 불리언 타입으로 암묵적 타입 변환된다. 자세한건 CH.9 단축평가에서....

7.6. 쉼표 연산자.

왼쪽 피연산자부터 차례대로 피연산자를 평가하고 마지막 피연산자의 평가가 끝나면 마지막 피연산자의 평가 결과를 반환

var x, y, z;
x = 1, y=2, z=3; // 3

7.7. 그룹 연산자.

소괄호로 피연산자를 감싸 연산식에서 평가 순서를 컨트롤할 수 있다.

10 *2 +3; // 23

10 * (2 +3); // 50

7.8. typeof 연산자

피연산자의 데이터 타입을 문자열로 반환. 반환되는 문자열은 다음 7가지와 같다.

1. stirng
2. number
3. boolean
4. undefined
5. symbol
6. object
7. function

null을 반환하는 경우는 없으며 예제는 다음과 같다.

typeof ''; // "string"
typeof 1; // "number"
typeof NaN; // "number"
typeof true; // "boolean"
typeof undefined; // "undefined"
typeof Symbol(); // "symbol"
typeof null; // "object"
typeof []; // "object"
typeof {}; // "object"
typeof new Date(); // "object"
typeof /test/gi; // "object"
typeof function() {}; // "function"

typeof null의 경우 object를 반환하는데 이는 자바스크립트의 첫 번째 버전의 버그다. 따라서 값이 null 타입인지 확인할 떄는 일치 연산자(===)를 사용하는 것이 정확하다.

var foo = null;

typeof foo === null; // false
foo === null; // true

7.9. 지수 연산자

ES7에서 도입된 지수 연산자는 좌항의 피연산자를 밑으로, 우항의 피연산자를 지수로 거듭 제곱한다.

2 ** 2; // 4
2 ** 0; // 0

//지수연산자 도입전
Math.pow(2, 2); // 4
Math.pow(2, 0); // 0

//음수를 거듭제곱 시 괄호로 묵어야 한다.
-5 ** 2 // SyntaxError: ...

(-5) ** 2 // 25

// 할당 연산자와 함께 사용 가능
var num = 5;
num **= 2; // 25

7.10. 그 외의 연산자

7.12. 연산자 우선순위

6. 데이터 타입

7개의 데이터 타입은 원시타입과 객체타입으로 구분할 수 있다.

숫자타입의 1과 문자열 타입의 '1'은 생김새는 비슷할지언정 전혀 다른 값이다. 우선 생성한 목적과 용도가 다르고 두개의 다른 데이터 타입은 서로 확보해야 할 메모리 공간의 크기도 다르며 메모리에 저장되는 2진수도 다르다. 당연히 2진수도 읽어 들여 해석하는 방식도 다르고 값도 다르다.

6.1. 숫자 타입

자바스크립트에게 숫자는 그냥 숫자다. 그게 정수던 실수던

ECMAScript 스팩에 따르면 숫자 타입의 값은 배정밀도 64비트 부동소수점 형식을 따른다는데 간단히 말해 모든 숫자를 실수로 처리한다는 뜻이다. 즉 자바스크립트에게 숫자타입은 실수뿐이다.

var binary = 0b01000001; //2진수
var octal = 0o101; // 8진수
var hex = 0x41; // 16진수

위 예제에서 각 변수에 할당된 평가된 값들은 모두 메모리에 배정밀도 64비트 부동소수점 형식의 2진수로 저장된다고 한다. 즉 각 진수에 따른 별도의 데이터 타입이 제공되지 않기 떄문에 위 평가된 값들은 모두 같다.

var binary = 0b01000001; //2진수
//65
var octal = 0o101; // 8진수
//65
var hex = 0x41; // 16진수
//65

console.log(binary === octal) 
// true
console.log(octal === hex)
// true

심지어 정수와 실수 또한 아래와 같이 평가된다.

console.log(1 === 1.0)
// true

하지만 또 아래와 같은 현상도 존재한다.

const a = 0.1
const b = 0.2

console.log(a+b === 0.3);
//false
console.log(0.30000000000000004 === a + b);
//true 


console.log(a === 0.10)
//true
console.log(a === 0.1000000000000001)
//false
console.log(a === 0.10000000000000001)
//true

console.log(0.300000000000000004 === a + b);
//false 
console.log(0.30000000000000004 === a + b);
//true 

이는 배정밀도 64비트 부동소수점 형식떄문이라는데 자세한 내용은 아래 링크에 또한 추후에 정리할 예정이다. (아마 책 뒤에 내용이 나오지않을까 싶은데) 간단하게만 정리하자면 컴퓨터는 비트에 담긴 0과1을 사용해서 이진법으로 숫자를 표현하기 때문에 표현할 수 있는 숫자의 개수는 비트 수에 정비례한다. “유한개”인 표현방법으로 “무한개” 인 모든 수(실수)를 표현할 수 없기 때문에, 정확도를 낮추는 대신 표현할 수 있는 범위를 넓히는 방향을 택할 수 있다. *즉 자바스크립트는 정확도를 낮추는 대신 표현할 수 있는 범위를 넓히는 방향을 택한것이다. * 자바스크립트 64비트 부동 소숫점 자바스크립트 소수점 계산 오류

6.2. 문자열 타입

텍스트

문자열 타입은 0개 이상의 16비트 유니코드 문자 (UTF-16)의 집합으로 작은따옴표, 큰따옴표 또는 백틱으로 감싸주면 문자열로 평가된다. 문자열은 원시 타입으로 변경 불가능한 값 (immutable value)이다. 문자열이 생성되면 그 문자열을 변경할 수 없는 이는 추후에 더 자세한 내용이 나온다.

6.3. 템플릿 리터럴

백틱

백틱을 따옴표 대신 사용하여 감싸진 문자열이다. 일반 문자열에서 허용됮 않는 개행이 허용되고 표현식또한 삽입할 수 있다.

/*
`나는
아직
배고프다
`
*/
`나는
아직
배고프다
`

const lastName = "Lee"
const firstName = "Jouz"
const greeting = `제 이름은 ${firstName} ${lastName} 입니다.`
console.log(greeting)
// 제 이름은 Jouz Lee 입니다. 

6.4. 불리언 타입

논리적으로 참 거짓을 나타내는 true와 false 뿐이다. 빈 문자열과 숫자 0은 falsey 하다. 자바스크립트한테 ''와 0은 논리적으로 거짓이라고 해석해도 될까?

6.5. undefined 타입

undefined는 개발자가 의도적으로 할당하기 위한 값이 아니라 자바스크립트 엔진이 변수를 초기화 할 떄 사용하는 값이다. 자바슼므립트 엔진이 변수를 초기화하는 데 사용하는 undefined를 개발자가 의도적으로 변수에 할당한다면 본래 취지와 어긋날뿐더러 혼란을 줄 수 있으므로 권장하지 않는다고 한다.

6.6. null 타입

위 undefined처럼 변수에 값이 없다는 것을 명시하고 싶을 때 사용할 수 있는 타입으로 null 값이 유일하다. null은 변수에 값이 없다는 것을 의도적으로 명시할 수 있고 변수에 null을 할당한다는 것은 이전 참조값을 더 이상 참조하지 않겠다는 의미다. 즉 이전 할당 값에 대한 참조를 명시적으로 제거하는 것 또한 의미할 수 있다.

하지만 typeof를 통해 null의 타입을 확인해보면 아래와 같다.

console.log(typeof null)

// object

이에 대한 논리적인 이유는 없고 because the spec says so

6.7. 심볼 타입

ES6에서 추가된 다른값과 중복되지 않는 유일무이한 값

주로 이름이 충돌할 위험이 없는 객체의 유일한 프로퍼티 키를 만들기 위해 사용된다. 심벌 이외의 원시 값은 리터럴을 통해 생성하지만 심벌은 Symbol함수를 호출해 생성한다. 이렇게 생성된 심볼값은 외부에 노출되지 않으며, 다른 값과 절대 중복되지 않는 유일무이한 값이다.

6.9. 데이터 타입의 필요성

데이터 타입에 따라 저장할 메모리 공간을 경제적으로 확보하고, 저장된 메모리의 범위를 미리 알 수 있게 되며, 해석에도 사용된다.

자바스크립트 엔진은 값을 메모리에 저장하기에 앞서 저장할 공간을 미리 확보한다. 즉 데이터 타입에 따라 먼저 확보해야할 메모리 공간의 크기가 결정된다. 이는 값을 저장할 때 낭비와 손실을 없애기 위함이다.

또한 앞서 메모리에 값이 저장될 때 2진수의 값으로 저장된다 정리하였고 메모리 셀 하나의 크기는 1바이트라고 정리하였다. 그렇다면 만약 8비트 크기의 숫자 값을 메모리에 저장한다고 가정한다면 8개의 셀이 필요하고 바꿔말하면 8개의 메모리 주소가 변수에 할당된다는 뜻이다.

이때 8비트 크기의 값을 참조한다고 가정해보면 데이터 타입의 필요성을 더 정리해볼 수 있다. 우선 참조 시 변수명 혹은 식별자를 통해 숫자 타입의 값 100이 저장되어 있는 메모리 공간의 선두 메모리 셀의 주소를 찾아갈 수 있다 그 후 데이터 타입을 통해 한번에 읽어 들여야 할 메모리 공간의 크기 또는 셀의 개수를 알 수 있게된다. 더 나아가 특정 메모리 공간에 저장된 2진수 값을 해석할 때 데이터 타입은 필수적이다. 같은 2진수 값이여도 데이터 타입에 따라 해석한 값이 달라지기 때문이다.

정리하자면

• 값을 저장할 떄 확보해야 하는 메모리 공간의 크기를 결정하기 위해
• 값을 참조할 때 한 번에 읽어 들여야 할 메모리 공간의 크기 (범주)를 결정하기 위해
• 읽어 들인 2진수 값을 어떻게 해석할지 결정하기 위해

데이터 타입이 필요하다.

6.10. 동적 타이핑

동적 타입 언어와 정적 타입 언어중 자바스크립트는 동적 타입 언어이다. 자바스크립트는 변수의 선언과 할당 단계가 나누어져있는데 선언이 아닌 할당에 의해 타입이 결정된다. 타입 결정은 타입 추론으로도 볼 수 있고 재할당에 의해 변수의 값이 변하듯 타입 또한 변할 수 있다. 동적 타입 언어는 유연성은 높지만 신뢰성은 떨어진다. 잘못된 타입 추론과 예측으로 복자성이 증가되고 처리 흐름을 추적하기 어렵기 때문이다. 우리가 변수명에 신경써야 하는 이유이기도 하다.

자바스크립트는 변수를 선얼할 때 타입을 선언하지 않는다. 다만 키워드를 사용해 변수를 선언하는데 미리 선언한 데이터 타입의 값만 할당 할 수 있는 것이 아닌 어떠한 데이터 타입의 값도 자유롭게 할당할 수 있다. 또한 변수는 데이터 타입을 갖지 않는다고 볼 수 있고 변수에 할당되어 있는 값에 의해 변수의 타입이 동적으로 결정된다고 표현하는게 더 정확하다.

정적 타입 언어는 변수 선언 시점에 미리 변수의 타입을 선언하여 결정되고 변수의 타입을 변경할 수 없지만 자바스크립트는 값을 할당하는 시점에 변수의 타입이 동적으로 결정되고 변수의 타입을 언제든지 자유롭게 변경할 수 있다. 정리하자면 *자바스크립트의 변수는 선언이 아닌 할당에 의해 타입이 결정 (타입 추론) 된다. 그리고 재할당에 의해 변수의 타입은 언제든지 동적으로 변한다. * 이러한 특징을 동적 타이핑이라고 하며 자바스크립트를 정적 타입 언어와 구별하기 위해 동적 타입언어라 한다.

변수 값이 언제든지 변경될 수 있는 자바스크립트이기에 복잡한 프로그램에서는 변화하는 변수 값을 추적하기 어려울 수 있을뿐더러 해당 변수의 타입도 언제든지 변경될 수 있기에 값을 확인하기 전에는 타입을 확신하기 어렵다. 또한 개발자의 의도와 상관없이 자바스크립트 엔진에 의해 암묵적으로 타입이 자동으로 변환되기도 한다. 따라서 자바스크립트와 같은 모든 동적 타입 언어는 유연성은 높지만 신뢰성이 떨어질 수 밖에 없고 다음처럼 변수를 사용할 떄 주의해야한다.

1. 필요한 경우에 한해 제한적으로 사용한다. 변수 값은 재할당에 의해 언제든지 변경될 수 있음으로 잘못된 타입 예측에 의한 오류 발생 가능성이 크고 이는 변수가 많이 사용될 수록 오류가 발생할 확률도 높아진다는 뜻이다. 따라서 변수의 무분별한 남블을 삼가하고 필요한 만큼 최소한으로 유지 하도록 주의해야 한다.

2. 변수의 유효범위, 즉 스코프를 최대한 좁게 만들어 부작용을 억제해아한다. to be continue CH.13 스코프

3. 어디서든 참조/변경 가능한 전역변수 사용을 최소화한다. 전역 변수는 모든곳에서 참조, 변경이 가능하기에 의도치 않게 값이 변경될 가능성이 더 높고 이는 다른 사용처에서의 오류를 발생시키는 등 코드에 영향을 준다. 이는 곧 처리 흐름을 추적하기 어렵게 만들고 오류의 원일을 특정하기 어렵게 만든다. to be continue CH.14 전역 변수의 문제점

4. 변수보다는 상수를 사용해 값의 변경을 언제한다. to be continue CH.15 const 키워드

5. 변수 이름은 변수의 목적이나 의미를 파악할 수 있도록 네이밍한다. 개발자의 의도를 나타내는 명확한 네이밍은 코드를 이해하기 쉽게 만들고 이는 협업과 생산성 향상에 도움을 준다.

정리하며

자바스크립트의 데이터 타입은 크게 원시타입과 객체 타입으로 나누어 볼 수 있고 또한 원시타입은 7가지로 나누어볼 수 있다. 데이터 타입은 간단하지만 중요하게 짚고 넘어가볼 필요가 있다. 그 이유는 기본적으로 데이터 타입에 의해 메모리 공간을 미리 확보하고 정확한 위치로 참조할 수 있기 때문이다. 또한 가장 중요하게 데이터 타입에 의해 값의 해석이 달라지기 때문이다. 또한 자바스크립트는 동적 타입 언어로서 7가지의 원시타입간뿐 아니라 모든 데이터 타입간 재할당에 의해 변수의 타입은 동적으로 변할 수 있다. 이처럼 자바스크립트는 유연하지만 신뢰성이 떨어진다. 그렇기 때문에 타입스크립트를 써야한다. ㅎㅎ

5. 표현식과 문

표현식은 그 자체로 표현식이면서 문이 될 수 있다. 하지만 모든 표현식이 문이 될 순 없다.

5.1. 값

값은 표현식이 평가되어 생성된 결과

식을 해석하여 값을 생성하거나 참조한다면 그것을 평가라 할 수 있고 그 값은 모두 데이터 타입을 가진다. 이 들은 메모리에 2진수,즉 비트의 나열로 저장되는데 데이터 타입에 따라 같은 값일지라도 그 해석이 달라진다. 12진수 0100 0001는 숫자타입으로는 65이지만 문자타입으로는 'A'다.

앞서 변수는 값을 저장하기 위해 확보한 메모리상의 공간 자체로서 그 공간을 인간친화적으로 식별하기위해 붙이는 이름이라고 정리했다. 따라서 변수에 할당되는 것은 값이다.

var sum = 10 + 20;

위의 예제에서 변수 sum은 10 +20이 할당될 것 같다. 하지만 10+20은 표현식으로서 평가되어야 하고 그 평가의 결과인 30이 변수 sum에 할당된다. 즉 메모리에는 숫자 30이 저장된다.

5.2. 리터럴

리터럴은 사람이 이해할 수 있는 문자 또는 약속된 기호를 사용해 값을 생성하는 표기법이다.

숫자 3은 숫자 리터럴이다. 인간에겐 아라비아 숫자가 더 이해가 빠를 것이다. 정리하면 인간이 이해하는 3 이라는 아라비아 숫자를 사용해 컴퓨터에게 전달하면 컴퓨터에게, 정확히는 자바스크립트 엔진에게는 숫자 리터럴 3이고 이를 평가하여 숫자 값 3을 생성한다.

이처럼 리터럴은 사람이 이해할 수 있는 문자 (아라비아 숫자, 알파벳, 한글 등) 또는 미리 약속된 기호 ('', "", ., [], {}, // 등)로 표기한 코드다. 자바스크립트 엔진은 런타임 시점에 리터럴을 평가해 값을 생성하는데 따라서 리터럴은 값을 생성하기 위한 약속된 표기법이라고 할 수 있다.

리터럴 종류

• 정수 리터럴 (100)
• 부동소수점 리터럴 (10.5)
• 2진수 리터럴 (0b01000001) // 0b로 시작
• 8진수 리터럴 0o101 // ES6에서 도입됐으며 0o으로 시작
• 16진수 리터럴 0x41 // ES6에서 도입됐으며 0x으로 시작
• 문자열 리터럴 ('Hello', "World")
• 불리언 리터럴 (true, false)
• null 리터럴 (null)
• undefined 리터럴 (undefined)
• 객체 리터럴 ({ name: 'Lee", address: 'Seoul'})
• 배열 리터럴 ( [1,2,3])
• 함수 리터럴 ( function() {})
• 정규 표현식 리터럴 (/[A-Z]+/g) 등이 있다.

5.3. 표현식

표현식은 값으로 평가될 수 있는 문이다. 표현식이 평가되면 새로운 값을 생성하거나 기존 값을 참조한다. 리터럴도 표현식이다.

var scre = 100;

100은 정수 리터럴로서 자바스크립트 엔진에 의해 평가되어 값을 생성하므로 리터럴은 그 자체로 표현식이다.

var score = 50 + 50;

50 + 50 은 숫자 리터럴 50과 연산자 +로 이뤄져있다. 50+50도 평가되어 숫자 값 100을 생성하므로 표현식이다. 위 코드의 변수 score를 참조하면 변수 값으로 평가된다. 비록 새로운 값을 생성하지는 않지만 값으로 평가되므로 표현식이라 할 수 있다. 따라서 값으로 평가될 수 있는 문은 모두 표현식이고 표현식은 값처럼 사용할 수 있다. 이는 값이 위치할 수 있는 자리에는 표현식도 위치할 수 있다고 문법적으로 이해해볼 수 있다.

var x = 1;
var y= 1;

var z = x+ 1;
//or
var z = 1+ y;
// or
var z = x+ y;

5.4. 문

문을 작성하여 순서에 맞게 나열하는 것이 프로그래밍이다. 즉 문은 프로그램을 구성하는 최소 단위라고 볼 수 있다.

문은 여러 토큰으로 구성되는데 토큰이란 문법적인 의미를 가지며, 문법적으로 더 이상 나눌 수 없는 코드의 기본 요소를 의미한다. 토큰의 예로는 키워드, 식별자, 연산자, 리터럴, 세미콜론 혹은 마침표 등이 있다.

또한 문을 명령문이라고도 부르는데 다르게 해석하면 ** 문은 컴퓨터에 내리는 명령** 이다. 예로는 선언문, 할당문, 조건문, 반복문 등이 있다.

문과 표현식을 구별하고 해석할 수 있으면 자바스크립트 엔진의 입장에서 코드를 해석해볼 수 있고 실행 결과를 예측하기는데 도움이 될 것이다. 이는 버그를 줄이고 코드의 품질을 높여줄 것이다.

5.6.6 표현식인 문과 표현식이 아닌 문

표현식은 문의 일부일 수도 있고, 그 자체로 문이 될 수 있다.

var x;
// 변수 선언문은 값으로 평가될 수 없으므로 표현식이 아니다. 

// 선언문은 초기화 단계에서 undefined가 할당되어 값으로 평가되지 않을까 생각할 수 있지만
// 이해한 바로는 초기화 단계에서의 undefined의 할당은 목적이 있는 값의 할당이 아니라
// 자바스크립트가 인터프리터언어로서 갖는 코드 실행 방법으로 인해 쓰레기 값을 참조하게 되면
// 의도치 않은 값이 참조되는 것을 방지하기 위해 할당되는 것이기에 
// 선언문 자체가 undefined로 평가된 값을 할당되는 것으로 보이지만 
// 사실은 값으로 평가될 수 없는 과정이기에 표현식이 아니라고 하는것이 아닐까?

x = 1 + 2;
// 1, 2, 1 + 2, x = 1+ 2 모두 표현식
// x= 1 + 2는 표현식이면서 완전한 문이다. 

이처럼 표현식인 문과 표현식이 아닌 문이 있다. 바꿔말해 표현식은 문이지만 표현식이 아니라해서 문이 아닌것 또한 아니다. 이처럼 표현식과 문은 비슷하여 구분하기 힘들다.

하지만 변수에 할당을 해보면 표현식인문과 표현식이 아닌 문을 간단하고 명료하게 구별할 수 있다. 앞서 변수에는 값으로 평가되어지면 할당할 수 있다고 정리했다. 만약 문이 값으로 평가되면 변수에 할당 할 수 있는 것이고 값으로 문을 평가할 수 없다면 변수에 할당 할 수 없기에 에러가 발생한다.

var foo = var x // SyntaxError: Unexpected token var
/*
위의 코드는 예상치못한 토큰인 var가 있다는 문법오류를 내밷는다. 
토큰에 대해서는 아마 실행 컨텍스트 부분에서 자세히 다룰 것 같지만 
위에 정리한 토큰에 대한 간단한 정리를 대입해서 생각해보면 
값을 평가하는 부분에서 예약어에 해당하는 토큰이 존재한다면 문법적으로 맞지 않는다는 것이다. 
이렇게도 표현식인문과 표현식이 아닌 문을 구분해볼 수 있을까?
*/
var foo = x = 1+2;
/*
위 코드는 아무 에러 없이 실행이 된다.
따라서 x= 1+2는 값으로 사용될 수 있는 표현식인 문이다. 
*/
// [1]
var foo = 10;
if (true) {};
/*
두개의 문 모두 값으로 평가될 수 없다. 
1. 선언문
2. 조건문
*/

// [2]
var num = 10; 
//이라는 코드가 이미 존재했을 때

100 + num;

num = 200
/*
두개의 문 모두 값으로 평가될 수 있으며 100+ num은 표현식 문이고 num=100은 할당문 (재할당)이다. 
*/

정리하며

문을 작성하여 순서에 맞게 나열하는 것이 프로그래밍이다.

또한 문을 명령문이라고도 부르는데 다르게 해석하면 ** 문은 컴퓨터에 내리는 명령** 이다. 예로는 선언문, 할당문, 조건문, 반복문 등이 있다.

문과 표현식을 구별하고 해석할 수 있으면 자바스크립트 엔진의 입장에서 코드를 해석해볼 수 있고 실행 결과를 예측하기는데 도움이 될 것이다. 이는 버그를 줄이고 코드의 품질을 높여줄 것이다.

4. 변수

사람은 계산과 기억을 모두 두뇌에서 한다. 반면 컴퓨터는 CPU를 통해 연산하고, 메모리를 통해 데이터를 기억한다.

4.1. 변수란 무엇인가? 왜 필요한가?

메모리는 데이터를 저장할 수 있는 메모리 셀의 집합체다. 메모리 셀 하나의 크기는 1바이트 (8비트)이며, 컴퓨터는 메모리 셀의 크기, 즉 1바이트 단위로 데이터를 저장하고 읽어들인다.

또한 각 셀은 고유의 메모리 주소를 갖는데 이는 메모리 공간의 위치이다. 0부터 메모리의 크기만큼 정수로 표현되는데 예를들어 4GB 메모리는 0부터 4,294,967,296 (0x00000000 ~ 0xFFFFFFFF)까지의 주소를 갖고 데이터 종류와 상관없이 모든 데이터는 2진수로 저장된다.

//예제
10 + 20

위와 같은 연산이 실행되면 10과 20은 메모리 상의 임의의 위치에 저장되고 CPU는 이 값을 읽어 연산을 한다. 연산의 결과로 생성된 숫자 값 30 또한 메모리 상의 임의의 위치에 저장된다. 하지만 문제는 여기서 시작한다. 연산 결과 값 30이 저장된 메모리 공간에 직접 접근하지 않는다면 이 값 30은 재사용할 수 없다는 문제가 있고 메모리 주소를 통해 값에 직접 접근하는 것 또한 치명적 오류를 발생시킬 가능성이 높은 매우 위험한 일이다. 이 때문에 자바스크립트에서는 직접적인 메모리 제어를 허용하지 않는 매니지드 언어이다.

자바스크립트가 직접적인 메모리 제어를 허용하지 않는 이유는 값이 저장될 메모리 주소가 매번 임의로 결정되기 때문이다. 코드가 실행될 때 메모리의 상황에 따라 메모리 주소가 임의로 결정되는 메커니즘으로 인해 동일한 컴퓨터에서 동일한 코드를 살행해도 메모리 주소는 변경된다. 즉 코드가 실행되기 이전에는 값이 저장된 메모리 주소를 알 방법이 없기 때문에 직접 접근하는 방법은 올바르지 못하다.

따라서 값을 저장하고 읽어 들여 재사용하기 위해 변수라는 메커니즘을 제공하는데 변수는 하나의 값을 저장하기 위해 확보한 메모리 공간 자체 또는 그 메모리 공간을 식별하기 위해 붙힌 이름을 말한다. 즉 변수는 값을 저장하고 참조하는 메커니즘으로, 값의 위치를 가리키는 상징적인 이름이다. 이 상징적인 이름은 컴파일러 또는 인터프리터에 의해 값이 저장된 메모리 공간의 주소로 치환되어 실행된다. 따라서 자바스크립트는 개발자가 직접 메모리 주소를 통해 값을 저장하고 참조할 필요없이 변수를 통해 안전하게 값에 접근할 수 있게 한다.

메모리 공간에 저장된 값을 식별할 수 있는 고유한 이름을 변수명이라하고 그 변수에 저장된 값을 변수 값이라고 한다. 또한 변수에 값을 저장하는 것을 할당이라 하고, 저장된 값을 읽어 들이는 것을 참조라 한다. 즉 변수명은 사람을 위해 사람이 이해하기 쉬운 언어로 주소값에 별칭(상징적인 이름)을 지어주는 것이다. 변수명을 사용해 참조를 요청하면 자바스크립트 엔진은 변수 이름과 매핑된 메모리 주소를 통해 메모리에 접근하여 저장된 값을 반환한다.

코드는 컴퓨터에게 내리는 명령이지만 개발자를 위한 문서이기도 하다. 따라서 개발자의 의도를 나타내는 명확한 네이밍은 코드를 이해하기 쉽게 만들기 때문에 첫아이 이름을 짓듯이 심사숙고해서 지어야 한다.

4.2. 식별자

변수뿐만 아니라 모든 식별자를 사용하기 위해선 선언이 필요하다.

식별자는 어떤 값을 구별해서 식별할 수 있는 고유한 이름으로 사람을 이름으로 구별해서 식별하듯 값도 식별자로 구별하여 식별할 수 있다. 또한 식별자라는 용어는 변시 이름에만 사용되지 않고 함수, 클래스 등의 이름 모두 식별자로서 선언에 의해 자바스크립트 엔진에 식별자의 존재를 알린다.

4.3. 변수 선언

값을 할당하기 위한 준비

변수 선언을 통해 메모리 공간상 저장될 값의 공간을 확보하고 공간의 주소와 변수명을 연결하여 값을 저장 (할당) 할 수 있게 준비하는 것이다. 이렇게 확보된 메모리 공간은 해제되기 전까지는 누구도 확보된 메모리 공간을 사용할 수 없도록 보호된다.

변수를 사용하려면 반드시 var, let, const 키워드를 사용한 선언이 필요하다.

키워드는 자바스크립트 코드를 해석하고 실행하는 자바스크립트 엔진이 수행할 동작을 규정한 일종의 명령어다. 자바스크립트 엔진은 키워드를 만나면 자신이 수행해야 할 약속된 동작을 수행한다. 예를 들어, var 키워드를 만나면 자바스크립트 엔진은 뒤에 오는 변수 이름으로 새로운 변수를 선언한다.

//예제
var score;

위 변수 선언문은 변수 이름을 등록하고 저장할 메모리 공간을 확보한다. 값이 할당되어 있지 않다고 하더라도 선언으로 인해 확보된 메모리 공간은 비어있지 않고 자바스크립트 엔진에 의해 undefined라는 값이 암묵적으로 할당되어 초기화된다. 이는 자바스크립트의 독특한 특징으로 다음과 같은 2단계에 거쳐 변수 선언을 수행한다.

• 선언 단계: 변수 이름을 등록해서 자바스크립트 엔진에 변수의 존재를 알린다. (변수를 실행 컨텍스트의 변수 객체에 등록하는 단계)
• 초기화 단계: 값을 저장하기 위한 메모리 공간을 확보하고 암묵적으로 undefined를 할당해 초기화한다.

초기화란 변수가 언언된 이후 최초로 값을 할당하는 것으로 var 키워드로 선언한 변수는 undefined로 암묵적으로 최기화가 자동 수행된다. 따라서 키워드로 선언했지만 할당되지 않은 변수는 undefined라는 값을 갖는다. 이 초기화 단계를 거치는 이유는 확보된 메모리 공간에는 이전에 다른 어플리케이션이 사용했던 값이 남아 있는 수 있기 때문이다. 이러한 값을 쓰레기 값이라고 하는데 메모리 공간 확보 후 초기화 단계를 통해 쓰레기 값이 참조되는 것을 예방할 수 있다.

4.4. 변수 선언의 실행 시점과 변수 호이스팅

자바스크립트 코드는 인터프리터에 의해 한 줄씩 순차적으로 실행된다. 호이스팅된 변수 선언은 빼고

//예제
console.log(score)
var score

위 예제에서 console.log(score)가 실행되면 참조 에러가 발생할 것 같지만 실은 undefined가 출력된다. 그 이유는 변수 선언이 런타임이 아니라 그 이전단계에서 먼저 실행되기 때문이다. 자바스크립트 엔진은 소스코드를 실행하기에 앞서 평과 과정을 거치며 소스코드 실행을 위한 준비를 하는데 이때 엔진은 변수 선언을 포함한 모든 선언문을 소스코드에서 찾아내 먼저 실행한다. 이러한 과정이 포함된 평과 과정이 끝나면 모든 선언문을 제외한 소스코드를 한 줄씩 순차적으로 실행한다. 이렇게 변수 선언문이 마치 코드의 선두로 끌어 올려진 것처럼 동작하는 자바스크립트의 고유의 특징을 변수 호이스팅이라고 한다. 추가로 var, let, const, function, function*, class 키워드를 사용해서 선언하는 모든 식별자는 호이스팅된다.

+TDZ 리서치 후 추가 필요(var, let, const 선언의 라이프 사이클)

let, const선언 변수는 호이스팅되지 않는 것이 아니다. 스코프에 진입할 때 변수가 만들어지고 TDZ(Temporal Dead Zone)가 생성되지만, 코드 실행이 변수가 실제 있는 위치에 도달할 때까지 액세스할 수 없는 것이다. let/const변수가 선언된 시점에서 제어흐름은 TDZ를 떠난 상태가 되며, 변수를 사용할 수 있게 된다.

4.5. 값의 할당

값의 할당은 런타임에 실행된다.

할당 연산자 =를 사용하여 변수에 값을 할당한다.

//변수 선언과 값의 할당이 나누어져서 이뤄지는 케이스
var score;
score=80;

// 변수 선언과 갑의 할당이 하나의 문으로 실행
var score = 80;

위 예제의 2개의 코드 라인은 정확히 동일하게 동작한다. 하나의 문으로 단축 표현해도 선언과 할당을 2개의 문으로 나누어 각각 실행한다. 따라서 변수 선언과 값의 할당의 실행 시점이 다르다. 변수선언은 소스코드가 순차적으로 실행되는 시점인 런타임 이전에 먼저 실행되고 값의 할당은 소스코드가 순차적으로 실행되는 시점인 런타임에 실행된다.

재미있는 부분은 초기화 단계에서 변수 (메모리 공간)에 undefined가 할당된 후 변수에 값을 할당할 때는 이전 값이 저장되어 있던 메모리 공간을 지우고 그 공간에 값을 새롭게 저장하는 것이 아닌 새로운 공간을 확보하고 그곳에 값을 할당한다.

4.6. 값의 재할당

이미 값이 할당된 변수에 새로운 값을 또다시 할당해보자. 단, const는 빼고

var score = 80;
score = 90;

var 키워드로 선언한 변수는 값을 재할당할 수 있다. 엄밀히 따지고보면 var키워드로 선언한 변수는 선언과 동시에 undefined로 초기화 되기 때문에 변수에 처음 값을 할당하는 것도 사실은 재할당이다. 어찌되었든 변수에 값을 재할당을 하게되면 이전 값이 저장되어 있던 메모리 공간을 지우고 재할당값을 새롭게 저장하는 것이 아니라 새로운 메모리 공간을 확보하고 그 메모리 공간에 재할당 값을 저장한다. 그 결과로 변수의 이전값들은 어떤 변수도 값으로 갖고 있지 않는다. 즉 어떤 식별자와도 연결되어 있지 않다. 이러한 불필요한 값들은 가비지 콜렉터에 의해 메모리에서 자동 해제된다. 단 언제인지는 예측 불가이다.

4.7. 마무리

어플리케이션의 근본은 데이터를 다루는 소프트웨어다. 아무리 복잡한 기능의 어플리케이션이라도 핵심은 데이터를 입력받아 처리하고 그 결과를 출력하는 것이다. 이런 어플리케이션은 프로그래밍 언어로 만들어지고 그 언어에서 변수는 데이터를 관리하기 위한 핵심 개념이다.

이 중요한 변수는 식별자로도 불리며 값을 지닌 듯 보이지만 사실 메모리 주소를 기억(참조)하고 있는, 인간이 프로그래밍을 함에 있어서 도움을 주기위한 메모리 주소값에 대한 인간 언어로 된 별명 정도이다. 따라서 프로그래밍적뿐만 아니라 현실 혹은 실전에서도 변수는 중요하다. 프로그래밍은 절대 혼자서 행해지지 않고 같이 협업을 통해 이뤄지기 때문이다. 즉 네이밍 규칙을 잘 협의하고 준수해야한다. 이는 함께 프로그래밍을 하는 사람들간 서로의 커뮤니케이션을 원할하게 도와준다. 명확한 커뮤니케이션은 변수의 존재 목적을 쉽게 이해할 수 있도록 의미를 명확하게 표현하고 일관성을 지킴으로 인해 높아진 가독성이 큰 도움이 되기 때문이다.

1.1. 프로그래밍이란?

프로그래밍이란 0과 1밖에 알지 못하는 기계가 실행할 수 있을 정도로 정확하고 상세하게 요구사항을 설명하는 작업을 코드로 명령을 전달하는 것이다.

1.2. 프로그래밍 언어

이때 명령을 수행할 주체인 컴퓨터가 이해할 수 있는 언어, 즉 기계어로 명령을 전달해야하는데 이는 인간이 사용하는 언어와는 너무나도 체계가 다르기 때문에 매우 어려운 일이다. 따라서 가장 좋은 방법은 사람이 이해할 수 있는 약속된 구문 (문법:syntax)으로 구성된 프로그래밍 언어를 사용해 프로그램을 작성한 후 그 언어를 기계어로 변환하는 컴파일러 또는 인터프리터 (번역기)를 이용하는 것이다.

다시말해 프로그래밍 언어란 사람과 컴퓨터 (컴파일러 또는 인터프리터) 모두가 이해할 수 있는 약속된 형태의 인공어이며 컴퓨터와 인간간 소통 (컴퓨터로의 명령)에 사용되는 일종의 표현수단이다. 즉 프로그래밍은 프로그래밍 언어를 사용해 컴퓨터에게 실행을 요구하는 일종의 커뮤니케이션이며 구문(syntax) 과 의미(semantic) 의 조합으로 표현될 수 있다.

1.3. 구문과 의미

결국 프로그래밍은 요구사항의 집합을 분석해서 적절한 자료구조와 함수의 집합으로 변환한 후 (구문), 그 흐름을 제어(의미)를 통해 컴퓨터에게 실행을 요구하는 커뮤니케이션이다.

2. 자바스크립트란?

2.5. 자바스크립트의 특징

웹 브라우저에서 동작하는 유일한 프로그래밍 언어로 개발자가 별도의 컴파일 작업을 수행하지 않는 인터프리터 언어다. 인터프리터는 소스코드를 즉시 실행하고 컴파일러는 빠르게 동작하는 머신 코드를 생성하고 최적화하는 방법으로 대부분의 모던 자바스크립트 엔진 (크롬 V8)은 두 언어의 특징을 결합해 비교적 처리 속도가 느린 인터프리터의 단점을 해결했다.

[컴파일러 언어와 인터프리터 언어의 비교]

대부분의 모던 브라우저에서 사용되는 인터프리터는 복장한 과정을 거치며 일부 소스코드를 컴파일한다.

또한 자바스크립트는 명령형, 함수형, 프로토타입 기반 객체지향 프로그래밍을 지원하는 멀티 패터다임 프로그래밍 언어로 클래스 기반 객체지향 언어보다 효율적이면서 강력한 프로토타입 기반의 객체지향 언어이다.

다시 말하지만 graphQL은 graphQL 서버와 통신하기 위한 쿼리 언어일뿐 서버 통신 방법이 아닐뿐더러 graphQL 역시 비동기로 처리가 된다. 지난번 블로깅을 통해 graphQL 서버에 QUERY라는 요청하는 방법, 더 자세히는 문법에 대해 알아보았다. 여러가지 문법을 통해 원하는대로 요청을 보내고 원하는대로 응답을 받고 또한 여러 상황에 대해서 서버와 통신하는 graphQL만의 문법을 알아보았다. 그렇다면 실제로 서버와의 통신과정과 통신을 통한 응답을 우리가 만드는 어플리케이션에 가져올 수 있을까?

1.0. Apollo Client

Apollo Client is a fully-featured caching GraphQL client with integrations for React, Angular, and more. It allows you to easily build UI components that fetch data via GraphQL. 출처:npmjs-apollo-client

npmjs.com에 나온 Apollo Client에 대한 설명이다. graphQL API를 어플리케이션 내에서 사용할 때 유용한 package들이 여러개 있는데 (예를 들면 페이스북의 relay) Apollo Client가 최고이며 가장 많이 사용된다고 하는데 이유들은 다음과 같다.

1. Apollo Client는 개발자로 하여금 graphQL을 통한 local과 remote 데이터 관리가 가능하게 해주는 종합적인 자바스크립트 상태관리 라이브러리 이고 (apollo의 cache 기능과 관련이 있다. 나중에 깊게 정리할 예정)
2. 경제적이고, 예측 가능하고 선언적인 방법인 모던한 개발 방식과 일관되도록 코드를 작성하도록 도와주고
3. 그 어떤 프레임워크던지 관계없이 자바스크립트 프론트엔드로 하여금 graphQL 서버로 부터 데이터 통신이 가능하고

등등의 이유가 있다. 하지만 개인적으로 Apollo Client가 graphQL과 찰떡궁합인 이유는 (비록 relay를 사용해보지 못하였지만) graphQL API의 작동원리에 있다고 생각한다.

1.1. graphQL API와 REST API

graphQL API의 작동방법을 간단하게 살펴보면 결국은 fetch이다. 이 말이 무슨 뜻이냐 하면 graphQL API는 결국은 REST API와 다를바 없다는 뜻이다. REST API는 url로 접근하여 원하는 method를 코드로 작성하여서 서버와 통신을 한다. graphQL은 이와는 조금 다르게 단 하나의 endpoint인 url에 접근하여 원하는 방식과 데이터 필드를 query와 mutation을 통해서 통신한다. 하지만 조금만 더 깊게 살펴보면 graphQL API는 기본적으로 우리가 원하는 정보를 query나 mutation으로 작성하여 Axios의 fetch와 함께 POST request를 서버로 보낸다. graphQL API는 모두 단 하나의 endpoint를 가진다는 차이점을 제외하면 결국 통신은 fetch,POST 등으로 이뤄진다는 점에서 큰 차이점은 없다.

위 이미지의 빨간색 박스 두개를 보듯이 실제 graphQL 통신은 fetch타입에 POST method임을 알 수 있다. 즉 apollo-client와 같은 패키지 없이 graphQL 서버와 통신하기 위해서는 우리가 원하는 정보와 함께 작성한 query를 Axios의 fetch와 함께 POST request로 보내야한다. 그 방법이 존재하는지 어떻게 하는지 알지도 못하지만 매우 복잡해 보이고 번거로워보인다. 그래서 apollo-client를 이용하면 apollo가 직접 이런 방식으로 알아서 서버와 통신을 가능케 해주고 모든 설정을 다 자동으로 해주는 package를 제공해준다.

2.0. REACT에 Apollo-client 더하기

위의 이유들 중 가장 손꼽히는 apollo의 장점은 cache기능으로서 불필요한 서버 통신을 최대한으로 줄여준다. 더 나아가 리액트 개발자로서 apollo-client가 제공해주는 여러 hook들은 나로 하여금 apollo를 사용하지 않을 이유가 전혀 없다고 본다. 물론 react말고도 다른 javascript 프론트엔드 프레임워크에서도 사용이 가능하지만 이상하리만큼 REACT에 대한 기능 제공이 많다. 그럼 너무 감사하니 한번 기본 세팅을 적용해보자. Apollo-client에서 사용하는 여러 페키지가 있었지만 지금은 core-package하나면 충분히 사용이 가능하게 update되었다

npm install @apollo/client graphql 요 2개의 패키지만으로도 충분히 사용 가능하다.

@apollo/client: 이 싱글 페키지는 Apollo Client를 세팅하기 위해 필요한 사실상 거의 모든것이 들어있다. [in-memory cache, local state management, error handling, and a React-based view layer] 등등 graphQL서버와 통신을 위해 사용하는 Apollo Client 세팅을 할 수 있게 해준다. graphql: 이 패키지는 GraphQL 쿼리들을 파싱하는 로직들을 제공해준다.

또한 apoll-client자체가 커뮤니티 오픈 소스 기반으로 개발된 라이브러리라 customized되고 공식 문서에서 인증해주는 패키지들도 존재한다.

2.1. Client 설정하기

역시나 공식문서에 잘 설명이 되어있다. 특히 react관련은 더더욱 다양하고 자세한 설명이 존재한다. 공식문서에 따라 천천히 설정해보자.

import { ApolloClient, InMemoryCache } from '@apollo/client';
import { gql } from '@apollo/client';


const client = new ApolloClient({
  uri: 'endpoint of your graphQL server',
  cache: new InMemoryCache()
});

client
// client에 접근하여
  .query({
  // query요청임을 명시해주고
    query: gql`
      query GetRates {
        rates{
          currency
        }
      }
    `
  // query에서 우리가 원하는 내용을 명시해준다.
  // 이렇게 직접 명시도 가능하지만 지난번 블로그에서 정리했듯이 query내용을 직접 다른 파일에 정의해놓고 import해서 사용도 가능하다. 
  })
  .then(result => console.log(result));
// fetch타입의 post method임으로 Promise패턴으로 접근이 가능하다. 

이게 기본적인 client 설정과 그 설정에 접근하여 실제로 Apollo-client 도움으로 graphQL 서버와 통신하는 방법이다. 하지만 우리는 개발자이기에 매번 요청마다 client를 설정하여 서버와 통신하는 방법보다 조금 더 개발자스러운 방법으로 해보자.

2.2. Provider

Provider 패턴을 통해 매번 client를 정의할 필요없이 props로 받아서 사용해보자.

import React from 'react';
import { render } from 'react-dom';

import { ApolloProvider } from '@apollo/client';
import { ApolloClient, InMemoryCache } from '@apollo/client';

function App() {
  const client = new ApolloClient({
  uri: 'https://48p1r2roz4.sse.codesandbox.io',
  cache: new InMemoryCache()
  });
  return (
    <ApolloProvider client={client}>
      <div>
        <h2>My first Apollo app 🚀</h2>
      </div>
    </ApolloProvider>
  );
}

render(<App />, document.getElementById('root'));

이런식으로 Provider 패턴을 통해 Provider에 의해 감싸진 컴포넌트들은 어느 곳에서든 client를 props로 받아서 서버와 통신이 가능해진다.

// getExchangeRatesQuery.js
import { gql } from '@apollo/client';
export const EXCHANGE_RATES = gql`
  query GetExchangeRates {
    rates {
      currency
      rate
    }
  }
`;

// ExchangeRates.js
import { useQuery} from '@apollo/client';
import {EXCHANGE_RATES} from 'getExchangeRatesQuery.js'

function ExchangeRates() {
  const { loading, error, data } = useQuery(EXCHANGE_RATES);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error :(</p>;

  return data.rates.map(({ currency, rate }) => (
    <div key={currency}>
      <p>
        {currency}: {rate}
      </p>
    </div>
  ));
}

이렇게 hook사용이 가능한 함수형 컴포넌트에서는 apollo-client가 제공해주는 hook으로 사용이 가능하며 class형 컴포넌트에서는 props.client로 접근하여 사용이 가능해진다.

3.0. 마무리

이번 블로그에서 client 설정 즉, apollo-client를 설정하는 다양한 방법에 (Link, onError 등등) 대해서 함께 정리하려했다. 하지만 정말 이번주도 바쁘고 다음주도 바쁠예정이라 오늘은 블로깅이 부끄럽게 느껴질만큼 간단하지만 여기서 마무리 하려 한다. 다음 블로깅에서는 다양한 client 설정 방법과 옵션설정들에 대해서 알아보고 추가로 실제로 accessToken과 refreshToken을 이용한 인증 인가 부분을 개발하며 했었던 삽질과 해결 방법을 통해 Apollo-client의 error handling에 대해서 정리할 계획인다. 개발하며 정리하고 넘어가고 싶은 부분이 정말 많은데 매번 일정에 쫒겨 정리를 못하는 모습에 반성만 하고 있는 내모습에 다시한번 반성하며 이번 블로깅은 여기서 끝.

0. Why?

회사에서 graphQL을 사용함에 따라 간간히 공식문서와 니콜라스의 영상을 보며 개발을 하고있던 중 동료 개발자들과의 수다에서 이런 의문이 나왔다. "우리가 과연 graphQL을 사용한다고 말할 수 있을까요?" 우리는 모두 아니라고 대답했고 제대로 사용하고 있는 것 같지도 않다고 대답했다. 그냥 요청을 보내면 응답을 보내주는 수준이라고 말해 개발팀 모두가 빵터진적도 있었다. 적어도 일주일에 블로그 하나씩 작성하자는 다짐은 밀리고 밀리는 task들에 밀려 지켜지지 못했고 graphQL을 정리해보자라는 생각을 가진지 한달이 지나서야 겨우 글을 끄적이게 되었다. 사실 지금도 일정에 맞춰 개발하기 위해 개발을 해야하지만 그간 graphQL과 Apollo를 겉핧기식으로 알고 사용하면서 한 이슈에 대해서 3시간 혹은 반나절의 시간을 낭비(?)하는 일들도 있었으니 나중을 위한 투자가 되지 않을까 라는 변명으로 잠시 개발을 쉬고 정리를 해보려한다.

GraphQL을 사용해보니 정말 좋은점은, 프론트엔드로서, 너무 편하다. 스키마에 정의된 타입들을 잘 정리해서 정의해주고 원할 떄 쿼리와 뮤테이션을 사용하여 서버와 통신을 하면 끝이다. (반대로 백엔드에서 정말 과하다 싶을정도로 모든 로직 등등을 다 처리해준다.) 또한 cache 기능, 사용자가 우리 서비스를 사용하는 과정에 있어서 받아와서 사용하는 데이터들 중 그 특정 과정 떄문에 발생하는 데이터의 null 값, 빈값 혹은 undefined 등등의 데이터 값을 처리하는 과정에 있어서 너무나도 편리하게 처리가 가능했다. REST와 비교하면 정말 편리하다. (페이스북 팀이 Native Mobile App에 사용하기 위해 사용했다는 이유가 너무나도 납득이 된다.) 또한 같이 사용하는 Apollo 라는 상태관리 라이브러리와도 궁합이 너무 좋은데 Apollo client에서 제공해주는 client/cache를 이용하면 사실상 global statemanagement도 가능하다. 거기에 React를 사용하는 개발자로서 hook이 제공된다는 점이 너무나도 좋다.(매일매일 apollo를 향해 절하고 싶은 마음이 들정도로)

이렇게 사용하기 편한만큼 GraphQl 공식문서만 봐도 너무나도 쉽게 사용이 가능하다. 먼저 GraphQL에 대해서 알아보자.

1. GraphQL

GraphQL 은 API를 위한 쿼리 언어이며 타입 시스템을 사용하여 쿼리를 실행하는 서버사이드 런타임입니다. 출처: https://graphql-kr.github.io/learn/

이렇게 공식문서에서 설명해주고 있다. 쉽게 말하자면 언어이자 문법이라고 생각하면 된다. REST와 가장 큰 차이점은 GraphQL은 단 하나의 endpoint만 가지고 있다는 것이다. 말로 하니 어렵다. 코드로 살펴보자

{
  "user" : {
    "name" : "Lee",
    "age" : 30,
    "phoneType": "IPhone"
  }
}

위와 같은 데이터를 서버로부터 받는다고 가정해보자.

REST API는 아래와 같이 요청할 것이다.

// REST API
fetch('http://example.com/user.json')
  .then(response => response.json())
  .then(data => console.log(data));

GrapQL은 아래와 같이 요청하면 된다.

query {
  user {
    name
    age
    phoneType
  }
}

여기서 큰 차이점이 하나 더 존재한다. 만약 해당 API를 통해서 우리가 필요한 데이터가 name뿐이라고 치자. 그럼 우리는 쓸데없는 age와 phoneType의 데이터도 받아와야한다. 하지만 GraphQL은 name만 뽑아서 받아올 수 있다. 아래처럼

query {
  user {
    name
  }
}

Facebook이 gql을 사용하게 된 이유도

1. 커져만 가는 어플리케이션
2. 증가하는 서버로부터 받아오는 데이터의 양
3. 모바일로 서비스를 접속하고 이용하는 사용자가 증가

한다는 점에서 데이터 통신을 가볍게(?)하기 위해서라는 것이 이해가 가는 부분이다.

이렇게 gql 언어를 사용하면 REST와 동일하게 서버로부터 요청을 통해 응답으로 데이터를 받을 수 있다. 그럼 이 언어의 형태와 구성 그리고 문법에 대해서 알아보자.

2. Query & Mutation.

Query와 Mutation은 GraphQL 쿼리 언어로 실행할 수 있는 작업 유형들이다. 이들 외에도 Subscription이라는 작업 유형이 존재한다.

Subscription은 웹소켓을 통한 실시간 양방향 통신을 구현할 때 사용되는데 이는 나중에 웹소켓을 정리하며 같이 정리하도록 하고 Query와 Mutation은 기본 REST API에서 CRUD인 POST, GET, DELETE 등등을 담당한다고 보면된다. 그림에 나와있는 것처럼 Query는 GET, Mutation은 POST, PUT, DELETE 등의 행위를 하는 작업 유형이다. 이들은 Schema와 Docs에 명시된, 일종의 API 명세에 입각하여 작성하면 된다. 실제 Query와 Mutation의 실행에는 상태관리를 도와주는 Apollo Client 라이브러리를 주로 사용하는데 이에 대한 설명과 방법은 다음 블로그에서 하고 이번 블로그에서는 작성법에 초점을 맞춰서 정리해보자. 또한 Query와 Mutation 작업 유형의 실행을 "서버에 쿼리를 날린다" 혹은 "서버에 쿼리를 한다" 라고 통칭으로 사용한다. 따라서 이에 입각하여 쿼리하는 방법에 대해서 알아보자. 그리고 그 전에 Schema와 Docs에 대해서 간단하게 정리를 먼저 해보자.

3. Schema & Docs

Schema와 Docs는 API에 대한 명세라고 봐도 무방하다. 쿼리 요청을 작성함에 있어 형태와 필요 요소가 정리된 문서 라고 생각하면 쉽다. 그래도 말로만하니 뭔지 모르겠다. 예제를 살펴보자.

위와 같이 Docs에는 우리가 요청할 수 있는 Fields들의 목록이 나와있다. 그리고 Schema에는 Fields들의 목록과 함께 밑에 Type들이 명세되어 있는데 타입은 Fields들의 return의 형태,요소이자 모습이고 Fields는 우리가 받고자 하는 value의 key값들이라고 생각하면 쉽다.

4. Fields & Types

그래도 말로하니 어렵다. 위에 사용한 예제를 다시 가져와보자.

query {
  user {
    name
    age
    phoneType
  }
}

위와 같이 서버에 쿼리를 하면 다음과 같은 응답이 올 것이다.

{
  "user" : {
    "name" : "Lee",
    "age" : 30,
    "phoneType": "IPhone"
  }
}

위의 예제에서 Fields는 user, name, age 그리고 phoneType이다. 그리고 응답으로 온 Lee, 30, IPhone 그리고 그들을 포함하는 하나의 객체가 Types이다. 이래도 어렵다. 실제 docs와 schema를 살펴보자.

위의 사진에서 첫번째 칼럼에는 총 3개의 Fields가 존재한다. 이들 중 서버에 collections에 해당하는 데이터를 받아오자고 가정해보자. 앞으로 우리가 작성할 요청은 우리가 특정한 fields로 구성된 하나의 객체를 서버로 요청하여 받아오는 것이다. 그렇게 되면

1. collections는 해당 요청의 Field가 되고 이 field는 Collection이라는 GraphQL 객체타입들로 구성된 배열을 리턴한다.
2. 두번째 칼럼에는 Collection 객체타입에 대해 나와있다. 즉 이 객체타입은 필드가 있는 타입으로 스키마는 대부분 객체타입이다.
3. id, title 그리고 items는 Collection 타입의 필드들로서 GraphQL 쿼리의 Collection 타입 어디서든 사용이 가능한 필드다.
4. id와 title 필드가 리턴하는 ID와 String 타입은 Scalar타입으로서 구체적인 데이터로 해석되는 쿼리의 끝이라고 보면 된다. 즉 Collection 타입이 collections필드의 하위 필드로서 존재하는것과 다르게 Scalar타입은 하위 필드가 존재하지 않는 데이터의 값 그 자체인 끝자락이라고 보면 된다. Scalar로서 존재할 수 있는 타입은 공식문서 스키마-스칼라타입에 잘 설명되어 있다.
5. 반면 items필드는 Item 객체의 배열을 나타내고 있다. 즉 하위 필드를 작성해주어야 한다는 뜻이다.
6. 세번째 칼럼을 보면 하위 필드로서 작성가능한 필드들이 명세되어있다. 여기서 데이터 타입뒤의 느낌표는 꼭 작성을 해줘야 하는 필드들이라고 보면 되고 느낌표가 없으면 필요에 의해서만 작성해주면 된다.

역시 말로하니 뭔말인지 모르겠다. 직접 코드를 처보자.

query {
  id
  title
  items {
    id
    name
    price
    imageUrl
  }
}

위와 같이 Docs를 보며 작성하면 된다. 다시 말하지만 서버에 쿼리를 하는 것은 우리가 원하는 데이터들을 하나의 큰 객체안에 Fields로서 작성하여 요청하는 것이다. 위에 대한 응답은 아래와 같을 것이다.

{
  "data": {
    "collections": [
      {
        "id": "cjwuuj5bz000i0719rrtw5gqk",
        "title": "Hats",
        "items": [
          {
            "id": "cjwuuj5ip000j0719taw0mjdz",
            "name": "Brown Brim",
            "price": 25,
            "imageUrl": "https://i.ibb.co/ZYW3VTp/brown-brim.png"
          },
          {
            "id": "cjwuuj5j4000l0719l3ialwkj",
            "name": "Blue Beanie",
            "price": 18,
            "imageUrl": "https://i.ibb.co/ypkgK0X/blue-beanie.png"
          },
          {
            "id": "cjwuuj5je000n0719ch6nbhik",
            "name": "Brown Cowboy",
            "price": 35,
            "imageUrl": "https://i.ibb.co/QdJwgmp/brown-cowboy.png"
          },
          {
            "id": "cjwuuj5jh000p0719rtjatb2f",
            "name": "Grey Brim",
            "price": 25,
            "imageUrl": "https://i.ibb.co/RjBLWxB/grey-brim.png"
          },
          ...
        ]
      }
    ]
  }
}

이게 기본적인 Query와 Mutation이다. Query와 Mutation은 단지 실행하는 작업 유형이 다를뿐 문법이나 형태는 둘이 동일하다.

그렇다면 어느 정도 감이 잡혔으면 문뜩 의문이 생길 것이다. 만약 특정 id에 해당하는 데이터만 받아오고 싶으면 어떻게할 수 있을까?

5. Arguments

이는 우리가 함수에 인자를 넣어서 해당 인자에 대한 연산의 값이 return되듯이 똑같이 Query와 Mutation에도 적용된다. 위에 쿼리로 받아온 collection 객체의 배열중 첫번째 객체의 정보만 받아오고 싶으면 어떻게 해야할까? 이때 인자를 사용하면 된다.

XX 물론 인자를 사용하는 부분은 apollo client를 사용해서 cache 데이터를 client 부분으로 사용이 가능하지만 이는 나중의 이야기이고 순수하게 사용하려면 백엔드에서 서버가 해당 인자를 인식하여 연산이 되도록 개발이 되어있어야한다. 해당 예제는 인자를 사용하는 로직이 개발이 되었다는 가정하에 정리하는 것XX

위와 같이 id를 받아 해당 id를 갖는 Collection타입의 필드들만 return 하는 API가 개발되어있다. 우리가 할 일은 저 docs를 보고 단순히 작성해주면 된다. 원하는 id값을 인자로 넣어주고 그 id에 해당하는 데이터 객체중 필요한 field를 작성해주면 된다.

query {
  collection (id:"cjwuuprqs00240719lb9kvlqe") {
    id
    title
    items {
      id
      name
      price
      imageUrl
    }
  }
}

그러면 아래와 같은 응답이 올것이다. 만약 items 필드가 필요없다면 아래와 같이 요청하면 된다.

query {
  collection (id:"cjwuuprqs00240719lb9kvlqe") {
    id
    title
  }
}

그러면 아래와 같이 응답이 올 것이다. 이처럼 인자를 이용해서 해당 id에 match되는 field 값들을 가져왔다. 또한 인자와는 관련없이 내가 필요한 filed만 작성하여 쿼리하는 것은 모든 쿼리에 해당한다.

이제 슬슬 감이 잡히는 것 같다. 그럼 만약 위의 예제에서 더 나아가 2개의 id값에 해당하는 field만 가져오려면 어떻게 해야할까 궁금증이 생긴다.

6. Aliases

일명 별칭으로 각 결과 객체 필드가 동일한 타입을 리턴할 때 구분을 지을 수 있게 도와준다. 만약 위의 예제에서 cjwuuprqs00240719lb9kvlqe와 cjwuuj5bz000i0719rrtw5gqk 두개의 아이디에 대한 데이터를 받아오려면 어떻게해야할까?

query {
  collection (id:"cjwuuprqs00240719lb9kvlqe") {
    id
    title
  }
  collection (id:"cjwuuj5bz000i0719rrtw5gqk") {
    id
    title
  }
}

이렇게 쿼리를 하면 된다고 생각할 수 있지만 이렇게 하면 "Fields \"collection\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional." 이렇게 다른 aliases 즉 별칭을 사용하라는 에러 메시지가 나온다. 그럼 원하는대로 별칭을 사용해보자.

query {
  firstUser: collection (id:"cjwuuprqs00240719lb9kvlqe") {
    id
    title
  }
  secondUser: collection (id:"cjwuuj5bz000i0719rrtw5gqk") {
    id
    title
  }
}

과연 요청에 대한 응답은 데이터일것인가 아니면 에러 메시지일것인가

짜잔! 두개의 별칭으로 나뉘어져 값이 들어왔고 추후에도 우리는 각각의 별칭으로 response에 접근/할당 하여 사용할 수 있게 된다. 근데 찐 개발자는 반복되는 코드를 싫어해야한다고 들었다. 찐개발자 흉내를 내보려보니 id와 title 두개의 fields를 반복적으로 작성하는게 귀찮다. 방법이 없을까?

7. Fragment

반복적으로 사용되는 value 등을 변수에 담아 혹은 더 나아가 변수에 담아 여러곳에서 사용하듯이 쿼리에서도 사용해보자! 기본적인 Fragment의 형태는

fragment <FragmentName> on <Type Name> {
  <fieldName>
  <fieldName>
}

이와 같다. 그럼 적용해보자!

query {
  firstUser: collection (id:"cjwuuprqs00240719lb9kvlqe") {
    ...collectionFields
  }
  secondUser: collection (id:"cjwuuj5bz000i0719rrtw5gqk") {
    ...collectionFields
  }
}
fragment collectionFields on Collection {
  id
  title
}

응답은... 짜잔! 약간 개발자 스러운 코드가 되었다. 사실 좀 더 자세하게 사용하려면 자세한 예제가 필요하다. 지금은 기본적인 형태만 알아보고 apollo-client를 정리할 때 실제 적용한 코드를 예제 삼아 정리하도록 하자.

8. 마무리

GraphQL 언어의 기초적인 문법들에 대해서 정리해보았다. 사실상 gql로 개발을 하다보니 위 문법들을 이것저것 짬뽕하여 사용하게 되는 수준까지 왔다. 하지만 인터넷에는 정말 자료가 너무 부족하다 ㅠㅠ 꼭 내가 궁금한 부분은 질문이 하다도없어서 3시간 6시간 반나절을 보내기도 한다. (다들 어떻게 그렇게 잘 개발하시는지 너무 부럽고 대단하다!) 이번 블로그에 정리된 기본 문법만 공부하고 실제로 바로 gql을 사용하여 개발을 시작했는데 역시는 역시나 적용하는 부분은 졸큼 달랐다. 그 부분을 다음 블로그에서 정리해보자 한다. apollo-client 세팅과 적용 그리고 실제로 gql과 apollo를 활용한 서버와의 통신 적용 이 두 주제를 블로깅 할건데 어떤것을 먼저해야할지 아직은 모르겠다. 후자를 먼저하자니 apollo-client 세팅과 설정은 필수적이고 그렇다고 바로 apollo 정리를 하자니 아직 모르는것도 많고 gql을 보다가 너무 뜬금없어질 수 있기 때문이다. 아무튼 다음에 알아볼 apollo는 정말 React와 찰떡궁합 (일부러 react를 메인 타겟으로 하고 만들어졌기 때문이지만)이고 이 또한 자료가 부족하여 광광 울고 머리 쥐어뜯으면서 개발했지만 진짜 apollo없으면 gql 어떻게 적용했을까 싶을정도로 짱짱맨이다. 아무튼 그렇다 gql짱 apollo짱!

1. EC2란?

아마존 aws에서는 다양한 서비스를 제공해주는데 너무 많기도 하고 이해하기도 어려웠다. 그래서 그냥 간단하게 설명하자면 예전에는 각 회사마다 서버실을 따로 두고 서버관리자가 그것을 관리하며 확장하거나 유지 또는 보수를 하였다. 이 서버실에 필요한 컴퓨터, 서버, 각종 하드웨어 및 서비스들을 아마존에서 가상 머신을 통해 제공해주고 우리는 그것을 원격으로 제어한다고 생각하고 넘어가기로 했다. 말 그대로 아마존의 서버실을 우리 전용으로 계약하여 빌리는 것이다.

2. EC2 인스턴스 생성

여담으로 코딩과 프로그래밍을 배우며 느낀것이지만 영어라 더더욱 그렇겠지만 참 용어들이 어렵고 와닿지 않는다. 인스턴스라.... 한번 살짝 만들어보니 그냥 서버용 컴퓨터를 한대 맞추는 것이였다. 다만 나에게 배송오지 않고 아마존에서 보유(?)하며 우리는 그냥 돈만 내고 모니터링하며 제어하는 것이다.

2.1. AWS - EC2

아마존 AWS로 가서 콘솔에 로그인을 하면 다음과 같은 창이 뜰 것이다. 그럼 클릭이라고 나와있는 EC2를 클릭하면 아래와 같은 화면이 나올 것이다. 뭐라뭐라 참 많은 내용이 나와있다. 하지만 걱정하지말자 우리는 몰라도 된다.(아직은 아마도) 그럼 클릭이라고 나와있는 인스턴스 시작을 눌러보자.

2.2. AMI 선택하기

우리가 아마존한테 받을 가상 컴퓨터의 운영체제를 선택하는 것이다. 연습용이기에 무료로 사용 가능한 것을 선택할 것인데 프리티어 사용 가능이라고 적혀있는 운영체제는 무료로 사용이 가능하다. 그리고 이 운영체제에 대해서 무슨 기준으로 선택해야 하는지 리서치를 했지만 결국 연습용이기에 아무 의미가 없었고 나중에 접속할 때 방법이 조금 달라진다고 하니 그점만 유의해서 원하는 것을 고르면 된다. 나는 처음 EC2에 대해서 배울때 선택했던 Ubuntu Server 16.04 LTS (HVM)... 을 선택할 것이다. 아래와 같이.

2.3. 인스턴스 유형 선택하기

아쉽(?)게도 무료로 사용하려면 하나의 선택지 밖에 없다. 인스턴스 유형이란 결국 우리가 아마존에서 맞추는 가상 컴퓨터의 사양을 세팅하는 것이다. 각각 유형 마다 사용 사례들이 있는데 추후 정말 서비스를 위해서 설정한다면 잘 읽어보고 맞는 인스턴스 유형을 선택하면 될 것 같다! 사진과 같이 선택하고 오른쪽 밑에 다음: 인스턴스 세부 정보 구성을 클릭하자

2.4. 인스턴스 세부 정보 구성

이 부분에 사실 많은 시간을 투자해서 알아보았다. 특히 서브넷과 퍼블릿 ip 자동 할당에 대해서 알아보았는데 현재 역량으로 완벽히 이해하기란 쉽지 않았다. 결국 무엇을 위해서 설정해야하는지 대충 알았지만 한 블로그에서 들어준 예가 사내용 인프라 서버였고 처음 EC2를 배울 때 내용으로 설정하였다. 기본적인 기본세팅은 위의 사진과 같고 실제로 많은 예제 블로그에서는 이 과정을 그냥 default값으로 설정하기도 한다. 하지만 내가 wecode에서 들은 세션에서는 다음과 같이 세팅을 권장하였고 정확한 이유는 기억이 나지 않지만 추후 알아내서 정리할 것이다. 적용한 설정은 서브넷 옵션들 중 2a로 끝나는 것을 클릭하고 퍼블릭 ip 자동 할당을 활성화로 바꿔주었다

2.5. 스토리지추가 & 태그 추가

스토리지 추가는 별로 건들것이 없는 설정임으로 그냥 넘어가고 태그 추가는 그냥 이 EC2에 대한 간단한 메모라고 생각하면 된다. 자유롭게 남겨주자. key를 Name으로 설정하고 값은 자유롭게 정해주자.

2.6. 보안 그룹 구성

보안과 관련된 설정을 하는 것인데 이 인스턴스에 접근하는, 권한과 관련된 설정을 하는 파트다. 네트워크를 통해서 누가 이 인스턴스에 접근할 수 있게 할 것인가, 어떤 방식의 접근만 허용하는지 설정하는 것이다.

먼저 나는 어느 ip든 무관하고 http와 ssh에 무관하게 접속이 가능한 웹 서비스를 배포하고 싶다. 그래서 아래와 같이 설정하였다. 그 후 다음 단계를 진행하면 여태까지 설정한 인스턴스 정보가 나올 것이고 시작하기를 누르면 키 설정이 나올 것이다.

3. 키 페어 설정

아마 시작하기를 누르면 다음 사진과 같이 키 페어를 설정하는 창이 나올 것이다. 이는 쉽게 말하면 인스턴스의 비밀번호와도 같은 것이다. 좀 전에 설정한 보안 그룹 구성은 접속에 관한 이야기라면 이 키 페어는 인스턴스를 조작하고 제어하는 권한을 이 키로 설정하는 것이다. 다음과 같이 설정해보자. 키 페어 이름은 원하는 아무 이름이나 작성하고 키 페어 다운로드를 클릭하여 다운받자 그 후 인스턴스 시작을 누르면 끝!

다음편에 리액트 프로젝트 EC2로 띄워보기를 해보겠습니다!

As the Flux pattern which became the most famous and commonly used pattern in React after it had been brought out by Facebook Development team, some other patterns such as Provider pattern, Observer pattern and etc, had been introduced as state management libraries and APIs earns its fame by developers such as Redux, Context Api, Mobx and etc but all the patterns shares the same common principle: divide the components as smallest as possible, keep the unidirectional data flow, focus on single source of truth and keep it simple.

Even though it is really taugh to look deep under the hood how each libraries works as Provider or Observer pattern, understanding basic flows or how it works is comes to important for developers to make better decision on optimizing application, in my opinion; it makes developers perfectly know when to use optimizing tools or skills such as React.memo or useCallback in application since it is the way of understanding how the flow of the state management libraries or APIs is looks like under the hood.

__Therefore for this blog, let me take a brief explanation of patterns and compare those with pros and cons. __

About desingn pattern with React

1. Observer Pattern: redux

1.1. about Observer Pattern

• depends on single source of truth. : Observer Pattern is useful when connecting and synchronizing various objects or components depending on one state.

• Observer which itself attached to the Subject and keep listen to it until the state has been changed.

  1.2. pros

  • low dependencies among components which mean all components should not always be on the same tree level in order to be synchronized with state or data. unidirectional data flow: makes us easy to track down the flow of data.

    1.3. cons

  • memory leak: to avoid un-used observer, it is required to detach the components which will not be used with Subject.

2. Provdier Pattern: famously known for context api data flow

2.1. about Observer Pattern

• highly useful for React Context which makes components to have global state.
• this is highly useful for updating the child components by the changes on the object from parents components which are highly reusable throughout the numerous componets.
• the most primitive point of Provider Pattern is that it makes us to avoid "Prop Drilling".

  2.2. How it works simply:

• Provider will set up some values into the Context Object at the highest tree level of Components.
• Consumer which also called as Child Component will get a data directly from the context than receives it props from Parent Component.

  2.3. Pros:

  • get free from "Props Drilling": lower the dependency between parents and child components unidirectional data flow: one single source of truth == flux pattern

    2.4. Cons:

  • invisibility among the connections between Context and Consumer: hard to identify which component is parent and where data is coming from.
  • have componets to use global values: general cohesiveness will be higher (dont get it perfectly but according to the Official Doc from React says that less Context used is preferred)

3. basic and core concepts to follow regradless of the pattern type

3.1. divide the components as smallest as possible

3.2. keep the unidirectional data flow

3.3. focus on single source of truth

3.4. keep it simple

4. dive into context pattern / provider pattern in React in shallow depth:

Using React Context Api in elegent way

: composing the React Context Provider and useContex Hook in order to make easier and more confortable with re-using them.

Context is useful when sharing data throughout the project or app without passing data as props regardless of the depth among components: it is more likely using data as global variables or it available us to pass down the value or data to component tree without using props or regradless how depth they apart.

Issues

Context in React is used to share data which is located in global space in a component tree such as an authenticated user or preferred theme without passing that data as props.

And it is also possible to have multiple providers in one application But it would not be recommended to have that pattern since the purpose of using context api is sharing data without using props in multiple components regardless of how much they apart to each others .

However All the consumers that are descendants of Provider will re-render whenever the value prop changes which means all the components who are placed as children of Provder Components, will be re-rendered as value props changes. i.g) <MyContext.Provider value={someValue}>

This problem or issue can be handled by using pure component or React.memo, in my opinion. PureComponent and React.memo can't prevent other consumer components to be unintentionally re-render

Conclusion

To overcome this, using useCallback to that value that commonly shared throughout the application. Use React.memo to the value for the provider value and Use useCallback to the value that makes unintentional re-rendering.

It might be recommended to use context api for such thing as user authentication, for example, which is necessarily to be accessible throughout entire application as an aspect of Service that application provides.

몇일 전 개발을 하다가 JSON파일의 number타입의 id의 값을 컴포넌트의 id값으로 할당하고 다시 JSON파일 속 id와 비교를 할 때 엄청난 애를 먹은적이있다. filter를 이용해서 걸러내려는 함수를 작성했는데 콘솔에 같은 값이 찍히는대도 불구하고 filter함수가 걸러내질 못했다. 콘솔을 좀 더 잘 확인했다면 따옴표를 잘 보고 타입이 달랐다는 것을 알 수 있었겠지만 그거 하나 못봐서 3시간을 고생했다. (좀 더 꼼꼼히 확인하자) 너무나도 당연한 것이지만 HTML의 속성으로 부여된 id의 값은 string이라는 것을 간과해버렸다. (할당한 id가 숫자 타입이라 당연 숫자로 인식되는줄 ㅠ) 위 3시간의 삽질 아닌 삽질은 무한의 스트레스를 주었고 동시에 자괴감과 자존감을 바닥으로 짖눌러 버렸다. 하지만 다음 날 긍정적인(이라고 쓰고 생각없는 이라고 말하는) 마인드로 덕분에 다시한번 자바스크립트 데이터 타입을 공부해봐야 겠다는 생각이 들어 다행이라고 결론짓고 이 참에 한번 간략하게 정리해보려한다.

1. 변수 선언과 할당

변수를 선언하고 값을 할당할 때 어떤일이 일어나고 후에 변수 값을 참조할 때 어떤 식으로 이루워지는지 간략하게 알아보기.

프로그래밍은 변수를 통해 값을 저장하고 참조한다고 한다. 그래서 그 변수는 값의 위치를 나타내는 인간의 언어라고 한다. 변수를 할당했는데 값의 위치를 나타낸다니 정말 웃기는 짬뽕이다. 그 말인 즉슨 할당이라는 코드가 작성되면 컴퓨터는 어느 저장소 한곳에 그 값을 저장하는데 변수가 그 값을 가지고 있는 것이 아니라 메모리상에 값이 저장된 저장소의 위치를 가지고 또는 가르키고 있는 것이다. (여태까지 가지고 있는줄) let bar = 1이라고 선언 할당을 하면 bar의 값은 1 이지만 사실상 딥하게 bar를 파보면 컴퓨터의 언어로 본인이 저장한 저장소의 1이 어디에 저장되어있는지 위치를 알려주는 것이다.

더 나아가 메모리에 값을 저장하려면 먼저 메모리 공간을 확보하는데 이는 데이터 타입에 따라 다르다고 한다. 구글에 관련한 것들을 검색해보면 컴퓨터 공학적인 이야기가 엄청 나오는데 다 각설하고 자바스크립트에 관해서만 알아보자.

1.1. 자바스크립트의 데이터 할당

자바스크립트는 동적인 언어이다. 그래서 타입들 또한 동적인데 이 말인 즉슨 다른 언어들은 (사용안해봐서 잘 모르지만 this is what google says) 선언과 함께 데이터 타입을 알려준다고 한다고 알고있다. 하지만 자바스크립트는 그런것이 없다. 그냥 내가 string이든 number든 할당하고 싶은 것들을 선언과 함께 할당해주면 알아서 잘 인식해준다. 자바스크립트는 변수의 타입지정이 따로 없이 값을 할당하는 과정에서 자동으로 알아서 변수의 타입을 결정한다. 그래서 자유롭게 재 할당이 가능한 것이다. (그래서 Typescript가 대세로 떠오르고 있는것인가?)

어쨋든 자바스크립트는 선언과 할당 과정에서 별도의 타입 지정이 없이 타입 추론을 통해 알아서 결정해준다. 그렇기 때문에 자바스크립트 데이터 타입에 대해서 깊에 공부를 해보려 생각하지 않았나보다 (변명)

2. 자바스크립트의 데이터 타입

그럼 알아서 일어나는 자바스크립트의 데이터 타입 할당(?)을 조금 더 발전시켜서 공부해보자. 어떤 데이터 타입이 존재하고 할당될 때 변수는 그것들을 어떻게 사용하는 것인지. 크게 원시타입(primitive data type)과 객체(object/reference type)으로 나뉜다.

2.1. 원시 타입 (primitive data type)

원시 타입이란 변경 불가능한 값이며 값에 의해 전달된다. 여기서 변경 불가능한 값이란 뜻은 immutable의 해석으로써 컴퓨터가 한번 데이터를 저장소에 저장하면 나중에 변수에 다른 원시타입의 값이 할당 되었을 때 저장된 위치의 값을 바꾸는 것이 아니라 저장소의 새로운 위치에 값을 저장하고 그 주소를 변수가 갖는다는 뜻이다. 간단한 예를 보면

//foo라는 변수에 숫자 1 할당.
let foo = 1

//...

//foo라는 변수에 숫자 20 재할당 
foo = 20

이런식으로 foo에 1을 할당하고 나중에 20을 다시 할당한다고 가정해보자. 처음 코드를 읽어들일때 1은 메모리에 할당된다. 그리고 그 메모리의 위치를, 예를 들어, 100이라고 가정하자. 그 후에 foo를 사용하게 되면 컴퓨터는 메모리의 100 이라는 위치에서 그 값을 가져와서 사용하는 것이다. 만약 나중에 foo에 20을 재 할당하면 어떻게 될까? 컴퓨터는 메모리에서 100이라는 위치를 찾아가서 1을 20으로 바꾸는 것이 아니라 메모리의 새로운 위치에 20을 저장하고 변수 foo에 그 위치값을, 예를 들어, 200 이라면 200을 저장한다. 이것이 불변성 immutable이다. (리액트에서 state관리할 때 정말 중요한 개념 + 배열과 객체인 데이터 가공시에도 매우 중요 ) 원시 타입 데이터들은 할당된 값, 즉 원시 값을 직접 변형할 수 없고 대신 교체가 가능한 것이다.

반대로 뒤에서 살펴볼 mutable은 직접 변형이 가능하다. 물론 교체도 가능하지만 이로 인해 원본이 훼손되는 (의도치 않게) 경우가 발생한다. 특히 리액트에서는 state의 데이터를 mutate 하는 경우 리랜더링이 일어나지 않는 일도 발생한다. 그렇기 때문에 setState를 이용해야하며 직접적으로 state의값을 건들여서는 안된다. 자세한건 나중에 mutation rhk non-mutation을 정리하며 알아볼 것인데 어쨋든 배열과 객체도 똑같이 key의 value에 대해서 모두 메모리의 위치값을 가지고 있기 때문에 shallow copy를 하여 값을 변경하거나 변형시키면 원본도 훼손된다. 여튼 좀 많이 조심해야한다. 내장 함수들 중에서도 배열과 객체를 mutate과 non-mutate하는 함수로 분류된다. (암튼 나중에 더 deep 하게 정리)

여튼 이런 원시 타입들은 boolean null undefined number string symbol (ES6에서 추가) 이 있다.

2.1.1. number & string

데이터 타입에 대해서는 이름만 봐도 알 수 있으니 깊게 정리하지 않고 특징 몇개만 짚어서 같이 정리해보자.

기본적으로 자바스트립트는 이진수로 숫자를 저장한다고 한다. 정수만을 위한 타입이 없고 실수라는데 아마 10 이라는 숫자도 10.000000 이런식으로 인식한다는 뜻인것 같다. 그럼 소수점 몇까지 똑같은지 실험을 해봐야겠다.

console.log(10 === 10.000000000000001)
// false
console.log(10 === 10.0000000000000001)
// true

소수점 15번째 자리까지만 인식가능하다. 그럼 다음 경우는 어떨지 생각해보자.

console.log(0.3 === 0.1+0.2)
// true? false?

답은 false 이다. 인터넷에 찾아보니 0.2의 2진수 표현이 정확하지 않다던데 이부분은 수학적으로 공부가 더 필요하다. 아무튼 소수점을 비교할때는, 그리고 사용할 때는 조심하고 좀 더 알아보면서 사용해야한다.

그리고 string은 문자열이다. 즉 따옴표안에 적힌애들은 모두 문자열인데 특이한 것이 문자열과 숫자의 연산에서 웃긴 결과가 나온다.

console.log("1"+1) 
//11
console.log("1"-1) 
//0
console.log(1+"1") 
//11
console.log(1-"1")
//0
console.log(-1+"1") 
  //-11
console.log(-1-"1") 
  //-2
console.log(-"1"+"1") 
  //-11
console.log(-"1"-"1") 
  //-2
console.log(-"1"+1) 
//0
console.log(-"1"-1)
  //-2
console.log(+"1"+1) 
//2
console.log(+"1"+1) 
//2

자바스크립트는 숫자로 이루어진 string을 연산하려 할때 기본적으로 숫자로 치환해서 연산한다고 한다. 하지만 +를 만나는 경우 문자열 합성 기능이 있어서 문자열로 합성을 먼저 고려한다고 한다.

2.1.2. boolean

true와 false를 나타내는 값이다.

값이 할당되면 true가 되고 할당이 안되어 있으면 false이다. 또한 그냥 하나의 변수에 true/false를 할당도 가능하다. "", undefined, null, 0은 false이다. 즉 0,"", undefined, null이 할당된 값은 boolean check에서 false이다.

2.2. 원시 타입 (primitive data type)

원시타입을 제외한 나머지 값들인데 배열, 함수, 정규표현식 그리고 객체 타입인데 통괄적으로 객체타입으로 생각하면 된다.

간단하다. 이 다음에는 var let const와 호이스팅에 대해서 알아보고 그 다음에 더 ellaborate해서 스포크, 렉시컬, 클로저 그리고 실행문맥을 묶어서 알아보자

callbacks

• be more precisely, it is about callback hell: callback in callback in callback in callback function and so on like the exaple below.

const firstCall = () => {
  return fetch('someUrl',(response)=> {
    let firstRes = response.json()
    let secondRes = firstRes.id
    return fetch(`otherUrl/${secondRes}`, (response)=> {
      let thirdRes = response.userName
      return fetch(`someOtherUrl/${thirdRes}`), (response => {
        let fourthRes = response.phoneNumber
        return fetch(`getUserbill/${fourthRes}`, (response)=> {
          let fifthRes = response.billAmount
          return fifthRes
        })
      })
    })
    })
}
firstCall()

Using callbacks is really bad pattern with coding since it makes hard to not only track down the execution-flow, even for the developer who actually wrote it but also debug.

Promise

As using Promise, it is really easy to track the code flow down, thankfully, but still the style with the Promise pattern doesn't looks like a synchronous flow a bit and throws some complexity compare to javascript functions we wrote. It is because of all the callback functions returned by the Promise in order to keep chaining responses and handling asynchronous execution.

async-await

And now this is the newsest asynchronous solution or pattern brought by ES8, async - await. This new pattern will have developers to write code about asynchronous execution in a style how synchronous execution fucntion written in.

• the declaration of async defines an asynchronous function which returns an AsyncFunction object, which is the instance of the Async Function constructor, allows to use more efficiently and enables asynchronous, promise-based behavior

• when an async function is called, it returns Promise with either resolved status when a function returns a value, or rejected status when a function throws an exception or some value

• another keyword await, provided by async, will pause the execution of the function declared with async

• when Promise has been passed into, the execution resumed and returns the resolved value

Example Code below

// standard promise pattern
let getData =() => {
  return fetch('someUrl')
  .then(response => console.log(response))
  .catch(error => console.log(error.message))
}

//async-await pattern
let getData = async() => {
  let responseFromServer = ""
  try {
    responseFromServer = await fetch('someUrl')
    console.log(responseFromServer)
  }
  catch(error) {
    responseFromServer = error
    console.log(responseFromServer.message)
  }
}

Look how the code style in async-await is pretty much looks like the pattern of function executed syncrhonously, and the readability has been improved.

little deep dive from the shallow of async-await (just a bit)

• async function can have zero or as many await expression as needed

• await expression will pause or suspend the execution through out the entire async function, yielding control of execution and subsequently resuming progress only when an awaited promise-based operation is either fulfilled or rejected.

• as Promise is always be returned value by async function, a resolved value of the Promise will be considered as a returned by the expression with await

• aysnc/await pattern, which is just a good-looking syntax of handling asynchronous execution, behaves similar to combination of generators and promises

• as Async Function always returns a promise, a returned value without wrapped by promise will be wrapped by promise implicitly

• easier to understand that the body of Async Function is divided by await expression; if there is none, it means there is no division

• the very Top-level-code, up to and including the first await expression, runs synchronously; if there is none of await expression meaning that the function will execute in synchronously

• if there is any await expression written, the execution of Async Function will be ended up asynchronously

• the execution of Async Function will be suspended or losing control when the execution meets the first await expression configured with the pending Promise status

• later when first await returns either resolve or rejected Promise, Async Function will re-gain the control over the execution until the progress meets the next await expression

1. 자바스크립트와 엔진의 특성

자바스크립트의 특성과 자바스크립트로 작성된 코드의 실행을 담당하는 엔진의 특성에 대해 알아보자.

1.1. 자바스크립트의 특성

javascript는 웹을 구성하는 3대장 중 하나다. HTML 그리고 CSS와 함께 웹 페이지를 구성하는데 사용된다. HTML이 웹페이지의 UI 구성을 만드는데 사용되고 CSS가 스타일링을 입힌 다면, 그 둘을 유저와의 상호작용을 구현하는데 javascript를 사용한다. 초보자들이 배우기 쉽고 매우 자유로운 언어라고 한다. 자유롭다는 말은 문법이 간단하고 멀티-패러다임 언어로 명령형, 함수형, 객체지향형 언어등 다양하게 활용이 가능해서 그런것 같다. 또한 객체 기반의 언어지만 하지만 상속과 클래스라는 개념은 없다. (이 부분은 추가 리서치 필요)

1.2. 크롬 V8엔진

자바스크립트는 실행되는 환경에 따라 사용되는 엔진이 상이하기도 하다. 일반적으로 chrome에 내장된 chrome V8 엔진이 대표적이다. V8엔진에 의해 실행되는 javascript는 compile(번역)과 interpreter(통역) 두개의 일련의 과정을 거쳐야한다. 여담으로 V8엔진에는 원래 interpreter가 없었지만 2017년 5.9버전이 나오면서 추가 되었다.

어쨋든 compile도 하고 interpret도 거쳐야 하는 자바스크립트는 컴파일언어라고 하기도, 인터프리터 언어라고 하기도 애매하다.

아무튼 compile과 interpreter 두 개의 과정을 거치는 것이 특징인 자바스크립트는 이 과정들을 머신코드로 해석되고 통역되어 브라우저에서 인식할 수 있게 된다. 또 다른 특징은 JIT(just-in-time)이라고 불리는 방식으로 위의 과정을 거치는데 말 그대로 브라우저가(대표적인 javascript가 실행되는 환경) javascript를 읽어 들이는 순간부터 compiler과 interpreter가 실행된다는 것이다.

그래도 가장 대표적인 특징은 V8엔진은 자바스크립트 코드를 단일 스레드, call stack에서 동기적으로 실행 한다. 이는 아마 V8엔진이 JIT 방식으로 compile과 interprete를 거쳐 머신 코드로 변환시키기 때문에 안정화 때문이지 않을까 하는 추측을 해본다.

2. 자바스크립트 엔진의 실행 방식

자바스크립트 엔진, 대표적으로 V8은 자바스크립트 코드를 동기적으로 실행 한다고 했다. 그럼 동기적으로 실행한다는 것이 무슨 뜻일까? 엔진 내부를 살짝 들여다보면서 살펴보자.

2.1. 동기적인 실행 방식

동기적으로 어떤 작업들을 한다는 말은 작업들을 한 작업 한 작업씩 처리한다는 뜻이다. 조금 더 자세히 살펴보자. V8엔진은 싱글 스레드인 하나의 call stack을 가지고 있다. 작업을 처리하는 공간인 call stack은 하나 밖에 없기 때문에 실행이 필요한 javascript 코드들은 이 하나의 call stack에 차곡 차곡 쌓인다. 만약 5개의 코드가 실행이 필요해 call stack에 차곡 차곡 쌓였다. (실행 순서는 나중에 조금 더 자세히 살펴볼 것이다. 지금은 단지 동기적 처리 방식에 대해서만 설명) 이 5개의 작업들을 동기적으로 처리하면 다음과 같은 순서로 진행될 것이다.

1) 첫 번째 순서의 코드가 실행이 된다. 2) 이 때 다음 순서인 두 번째 순서의 코드는 실행이 되지 않는다. 그 대신 첫 번째 순서의 코드의 실행이 완료될 때 까지 대기하게 된다. 3) 일정 시간이 흐른 후 첫 번째 순서의 코드 실행이 완료되었다. 이제 두 번째 순서의 코드 실행이 시작된다. 4) 똑같이 세 번째 순서의 코드는 실행이 되지 않고 자신 앞 순서의 코드 실행이 완료 될 때까지 대기한다. 5) 쭉 반복

이렇게 작동하는 것이 동기적인 작동 방식인데 실행의 요청에 의해 작업이 시작되고 응답이 오면 작업을 완료하고 종료시킨다. 그 후 다음 작업에 대해 실행을 시작한다. 자바스크립트 엔진의 call stack은 이 방식으로 javascript 코드를 실행한다. 하지만 그 순서가 조금은 특이한데 바로 first-in, last-out, 즉 선입후출 방식으로 진행된다.

말로 먼저 설명하자면 함수 호출의 코드를 엔진이 읽어 들이면 call stack에 쌓는다. 근데 방금 호출된 함수 안에는 또 다른 함수의 호출이 있다. 그럼 안에서 호출된 함수에 대응하여 그 함수의 실행을 call stack에 쌓는데 이때는 처음 쌓인 call stack 위에 쌓인다. 안에서 호출된 함수 내부에는 또 다른 함수 호출이 없다. 그래서 엔진은 call stack에 쌓인 함수들을 실행하려 하는데 이 때 늦게 들어온 순서대로 코드실행을 진행한다.

2.2. 예제

말로하니 역시나 어렵다. 다음 예제로 살펴보자.

const funcOne =() => {
  2️⃣console.log("No.1")
  3️⃣funcTwo()
}
const funcTwo =() => {
  4️⃣console.log("No.2")
  5️⃣funcThree()
}
const funcThree =()=> {
  6️⃣console.log("No.3")
}
1️⃣funcOne()

// 결과값
'No.1'
'No.2'
'No.3'

위 코드는 중첩된 함수에 대한 예제이다. 실제로 호출이 되면 call stack에 쌓이는 모습을 살펴보자.

위의 움짤처럼 쌓이고 위의 쌓인 순서대로 실행되고 실행이 완료되면 사라진다. 함수가 호출되어 call stack에 쌓이면 내부 코드를 순서대로 call stack에 쌓는걸 볼 수 있다. 그 후 함수 내부에 다른 함수의 호출이 존재하면 그 함수를 call stack에 쌓는데 그 함수가 실행이 완료되어 call stack에서 사라지기전에 외부함수의 실행도 완료되지 않는점을 명심하자.

3. 비동기 함수와 자바스크립트 엔진

javascrit 엔진 V8이 자바스크립트 코드를 실행하는 과정을 보면 정말 똑똑하다. (실제로 공식 문서를 보면 매번 업데이트에 성능 향상과 최적화에 엄청 공을 들인다.) 성능적으로도 똑똑하지만 (컴퓨터도, 인터넷도 성능이 뛰어난 요즘시대이기에 처음 자바스크립트를 실행시켰을 때 나는 동기적으로 한번에 실행된다고 느꼈다. 하지만 정말 미묘하게 아~주 미묘하게 순서대로 실행되는 것이였다.) 브라우저애서 실행 된다는 점에서 JIT방식으로 실행을 하기 때문에 코드을 읽어 들어와 연산하여 인식하는 과정은 조금 불안정할 수 도 있다. 그렇기 때문에 동기적인 방식으로 실행하는 것 같다는 느낌이 든다. 순차대로 적은 코드들에 대해 순서를 보장해 주는 것이다. 그래서 자바스크립트 엔진을 어느 정도 (아주 조금이지만) 파해쳐보니 조금 더 효율적이고 나은 코드 작성을 준수해야 되겠다는 생각이 크게 든다. (hoisting, execution context, lexical closure 등과 함께 날잡고 정리해야겠다.)

하지만 자바스크립트 엔진이 아무리 최적화하여 똑똑하게 실행을 처리한다고 한들 순서가 보장되지 못하는 경우가 발생하기도 한다. 바로 비동기 함수다. 간단하게 비동기 함수는 자바스크립트의 원칙, 실행 순서를 보장 받는다,를 깨고 비동기로 처리된다. 즉 순서를 보장받지 못하고 뒤로 밀리게 된다. 그럼 비동기 함수는 무엇이며 자바스크립트 엔진은 왜 이런식으로 처리하는 것일까?

3.1. 비동기 함수

대표적인 비동기 함수는 DOM 이벤트 API요청 setTimeout같은 내장 함수들이 있다. setTimeout으로 대표되는 DOM API, fetch 등으로 대표되는 XMLHttpRequest 등의 AJAX 등이 바로 비동기로 처리되는 대표적인 함수들이다. 그런데 이들의 위치가 조금 생소하다. 이 형태를 javascript runtime의 모습으로 살펴보자.

3.2. Javascript Runtime

자바스크립트 엔진에는 memory heap이라는 공간도 존재한다. 설명상으로는 변수와 객체에 대한 모든 메모리 할당이 이루어 지는 곳이라고 하는데 조금 더 리서치가 필요한 부분이다. 하지만 이번 자바스크립트의 코드 실행 방식에는 큰 영향을 주는 것 같지 않다. (그래서 넘어가겠다는 소리)

어찌돼었던 이런 자바스크립트의 실행환경을 보면 엔진 밖에 Web API들이 모여있는 곳이 있다. 자바스크립트 엔진이 제공하는 것이 아닌 브라우저에서 제공해주는 것이다. 다시 말해 이들은 다른 누군가에 의해 정의되고 브라우저에 내장된 내장함수라고 생각해도 무관한데 이들은 비동기 함수이고 브라우저에 위치하고 있다.

다른말로는 자바스크립트 엔진이 콜스텍에 쌓고 실행을 처리하는 함수는 우리가 자바스크립트라는 언어로 작성한 커스텀 함수다.

3.3. 자바스크립트 엔진의 코드 처리 방식

자바스크립트 엔진은 자바스크립트로 작성된 코드들의 실행을 담당한다. 물론 실행을 하기 위해 머신코드로 변환하는 작업을 거치긴 하지만 지금은 논외로 해보자.

3.3.1. 일반적인 코드 처리

자바스크립트로 작성된 코드는 순차적으로 call stack에 쌓이게 된다. call stack에 쌓이는 순간은 바로 코드가 해당 코드를 실행시키도록 작성되어있을 때 이다. 즉 자바스크립트 엔진은 call stack에 코드를 실행하라고 요청을 보내고 그 요청이 call stack에 쌓이는 것이다. 그러면 call stack에서는 해당 코드에 대한 작업을 하고 완료되면 응답을 보내 call stack에서 빼버린다. 명심해야 할 것은 코드 작업의 실행과정은 요청과 응답 이라는 것이다. 하나의 코드 실행은 요청에 의해 작업이 시작되고 완료되어 응답이 오면 비로소 완료되어 사라지는 것이다.

3.3.2. 비동기 함수 처리

만약 우리가 Web API 작업을 포함하는 함수를 자바스크립트로 작성하고 실행시킨다고 가정해보면 call stack에 쌓고 실행 요청을 보낸다. 함수 내부를 살펴보니 Web API를 실행해야하는데 자바스크립트 엔진내에 존재하는 함수가 아니다. 그러면 자바스크립트는 이 실행을 본인 내부에서 하지 않고 Web API가 있는곳에 그에 관련한 요청을 보낸다. 요청에 대한 응답으로 필요한 다른 응답에 대해 다른곳에 요청을 보내는 것이다. 그 요청을 비동기 함수의 callback함수와 같이 보낸다. 브라우저는 요청에 대한 응답으로 callback함수를 보내오는데 그 응답을 call stack에서 처리한다. 그러면 예제의 실행은 완료되는데 자바스크립트는 비동기 함수를 조금 특이하게 처리한다.

앞서 call stack에 요청된 Web API의 실행은 call stack에서 하지 않고 Web API에 위임한다고 했다. 이때 call stack에서는 해당 요청을 사라진다. 즉 해당 요청에 대한 응답을 본인이 처리하지 않기에 브라우저에 요청을 보내고 해당 작업에 대한 모든 정보를, 즉 callback을 call stack에서는 Web API쪽으로 함께 보내버리는 것이다.(위임) 그렇기 때문에 같이 보내진 콜백 함수는 순서를 보장 받기도 전에 다른 곳에 위임이 되어버린다.

하지만 브라우저는 Web API 실행 요청에 대한 응답으로 callback 함수를 보내고 그 함수를 다시 call stack에서 처리한다고 하지 않았는가? 브라우저의 응답으로 온 callback 함수를 실행하라고 call stack에 요청하고 쌓는다. 이때는 제대로 실행 순서를 보장받는다.

쉽게 말해 어린아이가 귤을 먹고 싶은데 (call stack에 요청) 껍질을 본인이 깔 수 없어 엄마한테 껍질을 까달라고 요청하고 (Web API 요청 with callback) 그 요청의 응답으로 알맹이가 돌아오고 (콜백) 그 알맹이를 먹을 수 있게 (call stack에서 실행) 되는 것이다.

그렇기 때문에 call stack은 본인이 수행할 수 있는 요청이 아니기에 브라우저에 껍대기를 까달라고 요청과 함께 비동기 함수안에 정의된 callback 함수도 함께 보낸다. (API 함수에 대한 실행요청으로 실행하려 했지만 실행을 하지도 않고 다른곳으로 위임한다. 그리고 내부에 정의된 콜백함수는 순서를 배정받기도 전에 같이 보내지는 것이다.) 그 후 브라우저에서 껍대기를 까고 알맹이를 돌려주면 (callback 함수) 다시 call stack에서 실행을 요청하고 연산 후 응답으로 보내주면 실행을 완료하고 call stack에서 사라진다.

3.3.3. callback queue와 event loop

하지만 그 callback 함수가 call stack으로 들어가기전에 규칙이 있다. Web API가 요청으로 응답을 보내주기까지 call stack은 기다리지 않고 다른 일을 순차적으로 동기적으로 처리한다. 아직 100개의 일이 call stack에서 처리되어야 한다고 가정해보자. callback함수는 그 중간에 끼어들어 순서를 바꿔버릴까? 그렇게 되면 코드 실행은 엉창진창이 되버릴 것이다. 그래서 대신 callback queue라는 곳에서 기다린다. 일종의 유명한 식당에서 줄을 서며 기다리는 것이다. 이 callback queue에서 기다리가닥 들어온 순서대로 call stack으로 옮겨지는데 event loop라는 친구가 항상 call stack과 callback queue를 지켜보고 있다가 call stack이 비워지게 되면 callback queue에서 대기중인 함수 실행을 call stack을 보내 callback 함수를 실행하게 된다. 결국 call stack과 callback queue는 동기적으로 작동하는데 비동기 함수는 그 순서가 밀리는 것이다.

말로하니 역시 어렵다. 예제 코드를 작성하고 어떤 이동이 일어나는지 살펴보자.

let someVal = 1
let API_EXAMPLE = ()=> {
setTimeout(function() {
 someVal + 10
},3000)
return someVal
}

let someFinalVal = API_EXAMPLE() + 100
console.log(someFinalVal)

콘솔창에 어떤 결과값이 찍힐까? 111? 아니면 101? 진행과정을 보고 한번 살펴보자.

setTimeout이라는 Web API는 비동기 방식으로 처리되었기 때문에 someVal1에 10을 더하지 못한채 API_EXAMPLE함수 실행은 완료되었다. 그래서 결국 콘솔에 찍힐 someFinalVal의 값은 1+100인 101이 되는 것이다.

이렇게 자바스크립트 엔진은 비동기 함수를 실행시킬 때 그 안에 작성된 콜백 함수를 Web API를 처리하는 곳으로 보내고 비동기 함수가 실행되는 동안 call stack에 보장된 순서대로 다음 함수들을 처리한다. 그 사이 비동기 함수가 연산을 마치면 같이 보내진 콜백 함수를 callback queue로 보내고 event loop가 지켜보고 있다가 call stack이 비워지면 콜백 함수를 call stack에 다시 밀어넣고 보장된 순서대로 실행 시키는 것이 바로 자바스크립트가 비동기 함수를 처리하는 방법이다.

비동기 함수가 어떻게 처리되는지 알아봤는데 왜 자바스크립트 엔진은 헷갈리게 브라우저 내장 함수들을 이렇게 처리하는지 이유에 대해서 알아보자.

3.4. 비동기 처리 방식의 이유

이유는 간단하게 blocking script를 방지하기 위해서다. 위의 예제에서 setTimeout라는 Web API를 사용했는데 이 함수는 지정된 시간이 지난 후 실행 되는 대표적인 비동기 함수다. 예제에 이 함수를 사용한 이유는 fetch나 axios 등으로 대표되는 서버와의 통신으로 데이터를 받아오는데 사용되는 Web API를 구현하기 위해서다. 만약 통신으로 데이터를 받아오는데 위 예제처럼 3초가 아니라 10분이 걸린다고 가정해보자. 그리고 이런 함수를 비동기가 아닌 동기로 처리한다고 가정해보자.

그러면 10분동안 아무것도 화면에 나오지 않을 것이다. 만약 통신으로 뉴스의 사진을 받아온다고 가정한다면 통신 다음에 실행되어야 할 코드들이 실행을 계속 기다리게 된다. 이것이 바로 blocking script다. 자바스크립트는 동기로 코드를 실행시키는데 한 코드에 소요 되는 시간이 너무 길기 때문에 그 코드 이후에 실행으로 순서를 부여받은 코드들은 10분을 더 기다려야 실행이 된다.

하지만 만약 비동기로 처리한다면 어떨까? 화면에는 사진만 나오지 않고 글은 보일 것이다. 그리고 유저는 10분뒤 사진을 받아볼 수 있을 것이다.

AJAX 요청이, 대표적으로, 비동기로 처리되는 이유는 웹 페이지에 필요한 리소스들을 대부분 서버로부터 전송받아 viw에 보여주기 때문이다. 그런데 이런 리소스들 때문에 스크립트가 막힌다면 페이지 자체를 보여줄 수 없기 때문이다.

4. 이슈: 결론은 Promise다.

이로 인해 발생하는 이슈는 무엇일까? 바로 위 예제와 같다. 만약 서버와의 통신으로 데이터를 받아와서 그 값을 재연산해서 최종값으로 사용하려 한다면 위의 예제처럼 "+10"이라는 재연산을 하지 못한채 값을 사용하게 된다. 그러면 어떻게 해야할까? 바로 Promise를 사용하는 것이다. Promise는 비동기 함수를 동기적으로 처리할 수 있게 해주는 아주 대단한 친구다. Promise에 대한 정리는 다음에 하도록 하겠다.

5. 추가: Job Queue

인터넷에서 재밌는 글을 읽었는데 바로 Job Queue에 관한 것이다. 먼저 다시 비동기 함수 작동방식을 살펴보면, 비동기 함수는 본인의 함수를 실행하고 콜백으로 넘겨진 콜백함수를 callback queue로 보낸다. 그리고 event loop가 call stack을 지켜보고 있다가 다 비워지면 callback queue에서 first-in, first-out 방식으로 call stack에 밀어 넣는다. 즉 다른 일반 함수의 실행이 모두 끝나야 비동기 함수가 실행 순서를 배부받고 보장받는 것인데 비동기 함수는 call stack 맨 끝부분에 추가된다고 봐도 무방하다. 그런데 이 job queue라는 재밌는 녀석은 비동기 함수한테 조금 더 빠른 순서를 제공한다. 물론 조건이 필요한데 그 조건은 비동기 함수가 실행되는 현재 함수가 끝나기전에 비동기 함수의 실행이 완료되면 현재 함수의 실행이 완료된 후 바로 실행되는 순서를 제공받는다. 다시 말해 다른 일반 함수들의 실행이 끝나 call stack이 비워지기 전에 순서를 제공받는 것이다.

결국 자바스크립트와 리액트를 가지고 무엇을 만드는 것이 아닌 무엇을 하는건지에 대한 명확한 대답을 모르니 계속 빙글빙글 도는 느낌이였다. 단지 프론트엔드 개발자가 되기 위해서, 웹 어플리케이션을 구현하기 위해서라는 모호한 목적만 가지고 있었다. 그래서 그동안 자바스크립트의 개념을 파고 파도 결론은 왜 이런 개념이 있는건데? 라는 자문으로 귀결되었다.

프론트엔드 개발자로서 서비스를 높은 퀄리티로 구현하느 것도 중요하지만 결국 내 코드가, 지금 내가 하는 개발이 궁극적으로 어떤 일련의 과정을 거쳐 구현이 되는지 아는 것도 중요하다는 생각이 들었다. 그래서 자바스크립트의 언어적 특성과 엔진이 코드를 해석하고 번역하는 과정 (간단하게만) 그리고 그 특징과 과정으로 인해 마주치는 대표적인 이슈들에 대해서 정리해보면서 결론적으로 자바스크립트 코드로 무엇을 하는지에 대한 결론을 내보자.

1. 자바스크립트가 뭔데?

간단하게 자바스크립트는 웹 브라우저 위에서 동작하는 언어다. 즉 웹 브라우저에서 HTML, CSS를 동적으로 제어하기 위해 만들어진 언어다. 그럼 동적으로 제어한다는건 무엇을 말하는 것일까?

2000년대 초반 웹사이트와 현재 웹사이트를 비교해보자. 요즘은 뱅킹 사이트에 로그인하면 자동 로그아웃까지 남은 시간을 보여준다. 또한 회원가입시 일정 조건에 맞지 않으면, 예를 들어, "비밀번호는 8글자 이상 입니다." 등의 경고를 띄워주며 동적으로 보여주면서 상호작용한다. 과거의 웹사이트는 어떠한가? 이런 경고창이나 알림창이 전혀 없었다. 즉 상호작용이 없다고 생각해도 무방하다.

2. 자바스크립트는 왜 쓰는데?

이런식으로 웹사이트에 생명을 불어넣어주는 상호작용을 자바스크립트라는 언어로 하는 것이다. HTML과 CSS로 웹 사이트의 구조를 잡는다면 자바스크립트는 그 구조로 정적인 상호작용을 만들어 내는 것이다. 기억해야 할것은 바로 HTML을 변화시키거나 반응하게 하는것이라고 생각하면 된다. 그 이유는 자바스크립트의 코드가 정적인 html을 반응하게 하거나 새롭게 추가 시켜주기까지 할 수 있기 때문이다.

이렇게 웹 페이지가 발전해 나가면서, 즉 자바스크립트로 웹 페이지를 동적으로 만드는일이 가능해지면서, 하나의 이슈가 생겼다. (아마도?) 그건 바로 코드의 가독성이 떨어지는 것인데 html코드와 자바스크립트 코드가 각각 다른 파일에 위치하면서 UI에 집중하기 힘든 구조이기 때문이다. (별도의 자바스크립트 파일을 만들어서 html <script>라는 태그의 src로 넣어줘야 한다.) html 태그를 직접적으로 호출 또는 조작해야하고 html에 변경이 생기면 html 전체를 다시 읽어들여야 하기 때문에 어플리케이션의 무게는 무거워지고 작동의 흐름이 복잡해질 수 밖에 없다는 이슈가 생겨났다. 그 때 혜성같이 (아마도) 나온 라이브러리가 바로 리액트다.

3. 리액트가 뭔데?

리액트는 자바스크립트 라이브러리로서 다양한 편의성을 제공한다. 이 글에서는 가볍게만 알아보는 것이기 때문에 간단하게만 정리해보겠다. 먼저 JSX문법을 통해 UI에 더 집중할 수 있는 구조로 프로그래밍이 가능해졌다. 예전에 UI와 동적움직임에 관한 파일과 코드가 분리되어 있었다면 리액트에서는 JSX문법으로 인해 한 파일에서 한 UI에 대해 모두 작성할 수 있게 됐다. html 태그에 접근하는 방법이 매우 쉬워졌다. 가상의 카피본을 사용하여 변경점이 생긴 부분을 (자바스크립트로 동적인 상호작용을 구현이 시작되거나 완료된 부분) 알아채서 실제의 변경된 부분만 고쳐준다. 이 말은 즉슨, 바닐라 자바스크립트로 html 태그에 직접 접근하여 조작할 때는 html 태그 전체가 영향을 받았지만 리액트는 변경된 부분만 콕 찝어서 접근하여 조작한다.

정리해보자면 자바스크립트는 정적인 웹 페이지를 동적으로 만들 수 있는 기능을 제공하여 많이 쓰이게 되었다. 이 뿐만 아니라 홈페이지에 들어가는 각종 리소스들을 (사진, 글 또는 각종 데이터들) 웹 어플리케이션에 보관할 필요 없이 서버와의 통신으로 받아올 수 있게 되어 성능면에서도 개선이 되었다.

4. 리액트는 왜 쓰는건데?

이런 자바스크립트의 등장으로 웹페이지들은 동적으로 변했지만 가독성과 UI에 집중할 수 없는 어플리케이션 구조 때문에 리액트라는 라이브러리가 각광받게 되었는데 리액트에서 사용할 수 있는 JSX 문법으로 인해 html 파일이 아니더라도 html 코드를 작성하여 같은 위치에서 자바스크립트 코드를 입힐 수 있게 되었다. 또한 예전에는 직접 html 파일의 element에 접근하여 자바스크립트 코드를 입혀야 했지만 리액트의 등장으로, UI의 세분화 즉 html element를 세분화하여 사용할 수 있게 되어 UI에 더 집중할 수 있는 환경이 만들어 진 것이다. 그리고 리액트가 제공하는 htmle 엘리먼트에 대한 가상본으로 인해 실제 변경된 부분에만 접근하게 되어 어플리케이션의 성능에 최적화를 이룰 수 있게 된 것이다.

그렇다면 결국 리액트는 자바스크립트와 html을 더 편리하게 사용할 수 있게 만들어준 라이브러리다. 그럼 리액트를 사용하여 자바스크립트로 html에 무엇을 하는 것일까? 결국은 html element에 접근하여 무언가를 하는 것이다. 이것이 자바스크립트의 사용 목적이다. 그리고 그것이 바로 DOM에 접근하여 동적으로 변경시켜 주는 것이고 그것을 리액트가 편리하게 구현할 수 있게 해준다.

5. DOM이 뭔데?

DOM은 Document Object Model의 줄임말으로서, 문서 객체 모델로 불리며 HTML 문서에 접근하기 위한 일종의 인터페이스, 즉 접점이다. 문서 내의 모든 요소를 정의하고, 정의된 각각의 요소에 접근하는 방법을 제공 한다.

쉽게말해, DOM의 모습은 트리 형태로서 자바스크립트로 하여금

1) 새로운 HTML 요소나 속성을 추가 2) 존재하는 HTML 요소나 속성을 제거 3) HTML 문서의 모든 HTML 요소를 변경 4) HTML 문서의 모든 HTML 속성을 변경할 5) 문서의 모든 CSS 스타일을 변경 6) HTML 문서에 새로운 HTML 이벤트를 추가 7) HTML 문서의 모든 HTML 이벤트에 반응 할 수 있게 해줘 웹 페이지를 동적으로 만드는데 알아야할 중요한 개념이다. 위 일련의 행위를 하는 것을 DOM에 접근한다 라고 흔히들 말한다.

리액트 같은 라이브러리나 비슷한 기능을 제공하는 프레임워크들 (Vue / Angular)이 나오기 전에 DOM에 접근을 하려면 DOM API들인 method와 property들을 자바스크립트로 사용해서 접근해서 1~7번의 행위를 해야했는데 html 파일과 자바스크립트 파일이 분리되어 있었기 때문이다.

하지만 리액트의 등장으로 컴포넌트 (view에서 최소한의 UI 단위로 나눠진 블록) 단위로 html과 자바스크립트를 작성할 수 있게 되어 별로의 다른 파일이 존재할 필요가 없어진 것이다. 또한 JSX문법은 자바스크립트와 html을 함께 사용할 수 있게 해주어 DOM에 접근하기 위해 method와 property로 접근할 필요없이 직접 코딩을 하면 된다. 마지막으로 리액트가 제공하는 가상본, 즉 가상 DOM은 실제 DOM에 접근하기 전에 바뀐 부분만 체크하여 그 부분의 실제 DOM 요소에 접근하여 조작하게 해주어 성능면에서도 장점을 보인다.

정리하자면 DOM은 책 한권을 한장 한장 분리 시켜서 같은 대단원별로, 그 안에서 소단원 별로 so on.. 트리 구조로 바닥에 펼쳐놓는 것이다. JSX문법 이전에는 그 한장 한장을 실제로 찾아서 (tree 구조 이기에 root, 최상단부터 찾아 들어가게 된다) 수정사항을 수정해야 했다면 리액트는 그 한장 한장을 각 파일로 컴퓨터에 저장할 수 있게 해줘 작성과 수정에 편리함을 준 것이다.

7. 프론트엔드 개발자의 본질은 뭔데?

그럼 처음 질문으로 돌아와 자바스크립트로 무엇을 하는가에 대해 잘 생각해보면, 더 나아가 프론트엔드 개발자가 하는 일을 생각해보면 DOM을 조작하는 일이다. DOM을 조작하는 일은 정적인 html코드에 각종 action을 추가시키고, 반응시키고, 수정시키고 더 나아가 그들의 styling도 변경하고 삭제하고 추가하는 것이다. 그러나 바닐라 자바스크립트로는 이슈가 발생하기에 조금 더 편리하게 개발하고 유지 보수하기 위해 리액트같은 라이브러리를 사용하는 것이다. 그럼 결국 DOM을 조작하는 일은 html을 가지고 이리 저리 노는 것(은 아니지만)이라고 볼 수 있겠다. (물론 단편적인 프론트엔드가 무엇을 하는가에 대한 대답이다. 코드 성능, 어플리케이션 최적화 등 신경써야할 부분은 무수히 많다.) 궁극적으로 UI를 html로 구성을 하고 interactiv하게 유저와 상호작용을 할 수 있는 interface를 코드로서 프로그래밍 하는 것이 프론트엔드가 해야 할 일이다. 그 안에는, 앞서 말한바와 같이, 무수히 많은 고려사항이 존재한다. 데이터를 효율적으로 받아오고, 어플리케이션 내부에서 상태를 효율적으로 관리해야하고 에러와 버그와 끝없는 싸움 등등 너무 많다.

또한 SinglePageApplication 이라는 리액트의 특성도 고려해봐야 한다. 모든 페이지의 script를 DOM으로 나타내는 것이 아닌 현재 필요한 view UI에 관한 스크립트만 존재한다. 한장에 페이지를 그렸다가 지웠다가 하는 것이라고 생각하면 된다. 그럼 결국 SPA도 최적화와 관련된 있지 않을까? 그럼 결국 자바스크립트도 how가 아닌 what 목적에 조금 더 초점을 맞춰야 되겠다는 생각이 든다.

근본적으로 위의 행동들은 자바스크립트로 프로그래밍 하게 된다. 그렇기 떄문에 자바스크립트의 궁극적인 목표와 목적에 대해 명확히 알고 있으면 위의 여러 고려사항들로 인해 공부해야할 자바스크립트 중급 이상의 개념들에 대해 조금 더 이해도가 높아지지 않을까 하는 개인적인 희망사항으로 정리 해 보았다. 그리고 how에서 what으로 생각의 중점을 조금씩 옮겨봐야 겠다는 생각이 들기도 한다.

다음글에서는 위에서 말한 일련의 행위들로 생겨나는 issue들을 자바스크립트의 실행 방식과 함께 정리해볼 예정이다.

아래 글에서 자바스크립트 코드가 어떻게 실행되는지 아주 살짝 맛만봤다. 그 맛을 보니 비동기함수를 처리하는 맛도 봤는데 그 때 발생한 이슈에 대처해서 사용할 Promise에 대해 알아보자. https://velog.io/@_jouz_ryul/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EC%99%80-%EC%97%94%EC%A7%84-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%8B%A4%ED%96%89-%EB%B0%A9%EC%8B%9D

개발을 하다보면 API request를 통한 서버와의 교신으로 데이터를 받아와서 사용하는 경우가 많다. 처음에는 이 API request나 Web API를 사용하여 데이터를 받아 사용해야 되는 경우 많은 에러와 어려움을 마주쳤는데 이 모든게 자바스크립트가 비동기 함수를 조금 특이하게 처리하기 때문이다.

이에 대한 해답은 Promise 패턴을 사용하는 것인데 Promise는 하나의 약속과도 같은 개념이다. 그럼 그 약속은 무엇이며 ECMA Scirpt 6 스펙에 정식 포함되기까지 했는지 알아보자.

1. 비동기 함수 처리로 인한 이슈.

자바스크립트는 기본적으로 동기적으로 코드가 실행된다. 하지만 비동기 함수에 대해서는 비동기적으로 처리하는 조금 특이한 점해서 이슈가 발생한다. 대표적인 비동기 함수인 fetch함수로 실제로 통신을 하는 코드를 예제 삼아 알아보자.

1.1. 비동기 함수 이슈.

먼저 어떤 이슈가 발생하는지 알아보자.

let example = 1

let fakeFetch =() => {
  setTimeout( ()=> {
    return example =5
  },3000)
}
fakeFetch()
console.log(example)
// expect example value : 5
// actual example value: 1

우선 fakeFetch함수라는 서버와의 통신을 하는데 3초가 걸린다는 가정으로 만든 가짜 fetch함수, 즉 비동기 함수다. 이 비동기 함수로 서버와의 통신으로 5 라는 값을 가져와 example변수에 다시 할당하는 코드를 작성했다. 그리고 함수를 실행하고 example값이 어떻게 바뀌는지 보자. 여전히 1 이다. 그 이유는 알다시피 비동기 함수의 실행 순서가 제일 뒤로 밀렸기 때문에 5라는 값을 할당하기 전에 console.log(example)이 실행되어 변경될 값이 아닌 현재의 값 1을 사용한 것이기 때문이다.

이렇게 데이터를 실제로 서버로부터 받아서 사용할 때 시점의 문제가 생긴다. 서버로 받은 데이터를 받아서 사용할 코드의 실행 순서는 비동기 함수를 사용해서 데이터를 받아오기 때문에 항상 먼저일 수 밖에 없는 문제가 생긴다. 그럼 어떻게 해결할까? 받아온 데이터를 사용할 코드도 비동기로 사용해야하나? 그렇지 않다. Promise를 사용하면 된다.

2. Promise는 어머니다: Promise 내부 파헤치기

Promise는 고유의 패턴을 이용해 가정 및 계획표를 세울 수 있다. 패턴이 계획표를 세우는 것이라면 Promise는 Promise로 계획한 계획표가 지켜지는지 감시를 해준다고 (사실은 검사가 맞다) 생각하면 된다. 예를 들어 방학 생활 계획표를 Promise 패턴으로 짰다면 Promise가 어머니의 역할로서 잘 지키는지 감시하고 도와준다. 계획대로 지키지 못하면 지키지 못했다고 잔소리를 (사실상 에러를 catch해주는 아주 좋은 기능) 덧붙혀 준다.

말로하니 어렵다. 역시나 예제 코드와 함께 Promise가 무엇인지 Promise 구조는 어떠한지 Promise 패턴은 무엇인지 Promise가 어떻게 감시를 하는지 하나하나 알아보자.

(Promise와 Promise패턴을 구분해서 정리하면 이해하기 쉽다. Promise 패턴은 Promise를 사용하기 위한 코드 구조라고 생각하면 쉽다.)

//Promise 사용과 Promise 패턴
let someVal = 1
let API_EXAMPLE_PROMISE =() => {
  1️⃣return new Promise(
  2️⃣(resolve,reject)=> {
    setTimeout(()=> {
      if (someVal===1) {
 resolve(someVal + 10)
      } else {reject(console.log("Fail"))}
},3000)
  })3️⃣.then(data=> console.log(data))
}
API_EXAMPLE_PROMISE()
// console: 11

1️⃣ Promise 선언. 2️⃣ resolve는 성공, 즉 조건에 성공했을 때 그리고 reject는 실패, 즉 조건에 실패했을 때 사용하는것.promise 안에서 꺼내 쓰는것이다. 다시 말해 조건에 성공했다면 resolve()안의 인수값을 리턴한다고 일단 생각하자.

3️⃣ Promise chain 즉 패턴의 형식이다. .then을 사용하여 Promise안에 콜백으로 작성한 코드의 응답이 들어오면 이라고 가정하는 거라고 볼 수 있다. promise 패턴으로 api 호출 등으로 받아오는 값을 처리할 수 있다. 이 예제는 resolve의 예제이기 때문에 resolved가 되었고 .then으로 리턴된 값 11을 콘솔에 사용할 수 있었던 것이다. (패턴에 대해서는 밑에 다시 정리할 예정)

위 예제는 Promise 패턴으로 3초 뒤에 실행될 함수가 연산할 값을 사용할 수 있는 형태에 대한 예제이고 가장 기본적인 형태의 Promise 사용법이다. 지금 한줄 한줄 읽어봐도 좋지만 먼저 Promise 내부를 하나하나 살펴보고 그 다음 추가로 다시 예제와 함께 알아보자.

2.1. Promise 상태

위의 코드 형태를 살펴보면 우리가 3초뒤에 연산의 값을 실행하는, API 요청 (response값을 받아오는데까지 시간이 걸리는)에 관한 함수를 Promise의 인수로 넣어줬다. 그 후 if 문으로 조건을 걸어 조건에 일치하면 연산을 실행하고 조건과 다르면 fail이라는 문자열을 콘솔로 보여주라고 코드를 작성했다. 이게 무슨 뜻일까? new Promise()라고 Promise를 선언하고 그 안에 우리가 코드를 작성하면 해당 조건들에 따라 Promise는 상태를 가진다. 먼저 Promise의 상태들 중 3개에 대해서 알아보자.

// pending state
let sampleVal = 1
let pendingState = () => {
  return new Promise(()=> {
    return sampleVal
  })
}
console.log(pendingState())

// fulfilled or resolvesd state
let sampleVal = 1
let pendingState = () => {
  return new Promise((resolve)=> {
     resolve(sampleVal)
  })
}
console.log(pendingState())
// rejected
let sampleVal = 1
let pendingState = () => {
  return new Promise((resolve, reject)=> {

     reject(sampleVal)

  })
}
console.log(pendingState())

위 코드를 한 케이스당 하나씩 콘솔에 찍어보자. 아마 다음처럼 나올 것이다.

pendingfulfilled or resolvesd state rejected

이 세개가 대표적인 Promise의 상태이다.

1) pending: 기본 Promise의 상태로서 수행하기 전의 상태이다. 즉 default 값인 것이다. 2) resolved(fulfilled): 약속이 지켜진, 즉 계획대로 된 상태이다. 3) rejected: 약속이 어겨진, 즉 계획대로 된 것이 아닌 상태이다.

이렇게 Promise는 Promise 패턴에 대해서 지켜지는지 지켜지지 않았는지 일일히 확인해준다. 그리곤 알려준다. 계획대로 잘 됐는지(resolved) 아니면 계획대로 되지 않았는지.

3. Promise 패턴은 계획표다.

그럼 대체 Promise 패턴 무엇일까? 말 그대로 약속이다. 다른말로 하면 가정이라고 볼 수 있다. 위에서 말한 것처럼 자바스크립트 엔진은 특정 함수들의 호출에 대한 실행을 뒤로 미룬다. 언제까지? 다른 일반 함수들의 실행이 모두 끝날 때 까지.

한마디로 Promise 패턴은 계획표이자 가정이다. 초등학교 때 방학이 되면 방학 계획표를 짰던 기억이 난다. 주로 다음과 같은 계획표를 짰다.

1. 아침 9시에 일어난다.
2. 일어나서 아침을 먹는다.
3. 아침을 먹고 수학을 공부한다.
4. 수학 공부를 하고 점심을 먹는다 ... 이런식으로 (물론 지키지 못했지만) 가정을 기반으로 계획을 짰었다. 이게 프로미스다. 무슨말일까? 다시 위의 예제 코드를 가지고 알아보자.

   // API 호출 예제
   let someVal = 1
   let API_EXAMPLE = ()=> {
   setTimeout(function() {
   2️⃣someVal + 10
   },3000)
   3️⃣return someVal
   }
   

4️⃣let someFinalVal = 1️⃣API_EXAMPLE() + 100 console.log(someFinalVal) //expected someFinalVal = 111 // actual someFinalVal = 101

1️⃣의 실행 결과값으로 2️⃣에서 원하는 연산을 하고 3️⃣에서 결과값으로 반환하여 4️⃣의 변수에 할당될 값의 연산값으로 사용하고 싶었는데
2️⃣의 연산값이 적용되지 않았다. 실제로는 1️⃣의 실행 결과는 11이 되게 하고 싶었지만 전역에 선언된 1을 가져와 4️⃣변수의 값은 101로 할당 된 것이다. 

그런 결과는 2️⃣의 연산을 실행할 함수가 비동기 함수여서 자바스트립트가 실행을 다른 곳에 위임했고 
콜 스택에서 쌓인 다음 연산을 실행했기 때문에 반영되지 못한것이다.

그럼 여기에 Promise 패턴을 사용하면 어떤 가정을, 어떤 계획표를 세울 수 있는 것일까?
아마 콜 스텍에 쌓이지 않은 2️⃣의 연산을 할 함수의 실행을 가정할 수 있을것 같다. 
Promise 패턴을 사용하여 가정을, 계획표를 세우면 다음과 같이 해석할 수 있다.
"이거 값을 할당하는 response까지 3초가 걸리는데 그냥 값이 할당되었다고 가정하자."
혹은
"이거 값이 들어올건데 그 값이 들어오면 2️⃣번 연산을 실행 할거야."
이런식으로 가정을 하거나 계획을 세우면 Promise 패턴을 사용하는 것이다. 

## 3.1. 실제로 가정해보기
그럼 실제 `fetch`함수를 사용해서 알아보자.

```json
// 실제 받아올 데이터
//https://jsonplaceholder.typicode.com/users
[
  {
    "id": 1,
    "name": "Leanne Graham",
    "username": "Bret",
    "email": "Sincere@april.biz",
    "address": {
      "street": "Kulas Light",
      "suite": "Apt. 556",
      "city": "Gwenborough",
      "zipcode": "92998-3874",
      "geo": {
        "lat": "-37.3159",
        "lng": "81.1496"
      }
    },
    "phone": "1-770-736-8031 x56442",
    "website": "hildegard.org",
    "company": {
      "name": "Romaguera-Crona",
      "catchPhrase": "Multi-layered client-server neural-net",
      "bs": "harness real-time e-markets"
    }
  },
  {
    "id": 2,
    "name": "Ervin Howell",
    "username": "Antonette",
    "email": "Shanna@melissa.tv",
    "address": {
      "street": "Victor Plains",
      "suite": "Suite 879",
      "city": "Wisokyburgh",
      "zipcode": "90566-7771",
      "geo": {
        "lat": "-43.9509",
        "lng": "-34.4618"
      }
    },
    "phone": "010-692-6593 x09125",
    "website": "anastasia.net",
    "company": {
      "name": "Deckow-Crist",
      "catchPhrase": "Proactive didactic contingency",
      "bs": "synergize scalable supply-chains"
    }
  },
  ...
  ]

위 주소로 접속하면 실제 열개의 객체가 담긴 배열이 나온다. 이 주소로 실제 서버 통신으로 우리가 값을 받아볼 수 있는데 그럼 코드를 작성해보자

let myData =""
let getCollectionData = () => {
  myData = fetch('https://jsonplaceholder.typicode.com/users').then(response=> response.json()).then(response=> response[0])
  return myData
}
getCollectionData()

console.log(myData)

fetch함수를 사용해 서버와의 통신으로 데이터를 받아와서 0번째 인덱스의 객체를 콘솔에 찍어보는 코드다. 그냥 Promise 패턴은 .then이라고 알아두고 (뒤에서 다시 정리할 예정) 콘솔을 확인해보자!

Promise {<pending>}이라는 녀석만 보일 것이다. Promise를 사용해서 문제를 해결하려고 했는데 결과가 그냥 Promise가 찍힌다. 비동기로 처리되어 연산값을 사용할 수 없는 이슈는 해결된 것 같은데 Promise의 사용도 아니고 Promise 패턴만 사용했는데 Promise가 결과로 나오다니 무슨말인가?

잘 살펴보면 위의 Promise 예제와 그전의 Promise를 선언하여 사용한 예제와 다른점이있다. 이 예제에는 Promise 선언부가 없다. 재밌는점은 fetch는 Promise를 반환한다. 그래서 .then, Promise 패턴을 사용할 수 있었던 것이다. 명심할 것은 Promise에만 .then이 적용된다. 그럼 Promise가 리턴되는건 무슨 말일까?

4. Promise는 Promise를 반환한다?

The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing. 출처: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

MDN 공식문서에 나온 내용이다. fetch함수의 실행은 Promise를 반환한다. 하지만 요청 에러 상태에 대해서 reject하지 않고 정상적으로 resolve상태로 반환되며 네트워크 연결 실패시에만 reject한다고 나와있다. 여기서 의문점

1) Promise를 반환한다는것이 무슨뜻일까? 2) 왜 reject 하지 않을까?

그럼 Promise가 Promise를 반환한다는 것이 무슨 뜻이며 왜 그러한것일까? 다시 Promise 사용법을 상기시켜보자.

1. new Promise로 Promise임을 선언해준다. 즉 자바스크립트 내장 함수로 저장된 Promise 객체를 new 키워드를 통해인스턴스화 한것이다.
2. Promise의 인수로 실행하고자 하는 함수를 작성한다.

그럼 이제 Promise 상태와 잘 연결해서 생각해보자.

1. new Promsie로 Promise를 선언하여 인스턴스화 한다.
2. Promise의 인수로 무명 함수를 넣어 우리가 얻고자 하는 실행을 작성한다.
3. 그 결과 값이(resolve 혹은 rejected) Promise로 return되어 Promise를 인스턴스화한 함수의 반환 된다.

역시나 예제를 통해 쉽게 알아보자.

순서대로 pending-resolved-rejected가 콘솔에 찍힌다. Promise의 대표적 상태 3가지를 다시 적어보면

1. pending
2. resolved
3. rejected 인데

1번 사진은 Promise 안에 작성한 함수의 return으로 아무것도 하지않고 값만 반환하였다. 즉 resolve 나 reject로 Promise의 상태를 변화시킬 조건이나 값이 하나도 없는것이다. 그래서 Promise는 아무것도 하지않고 태초의 default인 pending으로 유지되어 현재의 상태를 return 한것이다.

2번과 3번은 resolve 와 reject로 Promise 상태를 바꿀 값 혹은 조건을 넣어줬다. 그랬더니 Promise의 상태가 바뀌어 콘솔에 해당하는 상태가 찍힌것이다.

이렇게 Promise를 사용하면 resolve, reject로 Promise의 상태를 바꿔줘야 한다. 그 이유는 Promise 패턴으로 비동기 함수 실행에 대한 계획표를 짠다고 했는데 Promise의 상태에 따라 우리가 실행하고 싶은 일들을 계획할 수 있기 때문이다.

resolve를 예로 들어, resolve의 조건으로 sampleVal을 넣는다면 이로 인해 Promise 상태가 resolved인 콜백함수가 반환 될 것이고 .then으로 그 콜백함수에 접근할 수 있어 매개변수로서 받아서 사용이 가능해지기 떄문이다.

반대로 reject의 조건으로 sampleVal을 넣어 이에 해당할 때 실행할 일을 .then으로 계획한다고 코드를 짠다면 그 후의 계획은 CALL BACK 함수로써 매개변수로 sampleVal을 사용할 수 있게 되기 때문이다.

정리하자면 Promise를 인스턴스화 해서 사용하면 Promise를 반환하는데 resolve와 reject의 조건에 따른 반환값이나 할당된 값에 각각 대응하여 Promise의 상태를 resolved나 rejected로 바꿔서 콜백함수를 반환한다. (resolve와 reject의 값이 없거나 조건이 없으면 pending 유지) 이에 Promise 패턴을 사용할 때 .then으로 미래의 일을 계획하며 작성을 하는데 이때 Promise의 변한 상태에 따른 각각 실행하고 싶은 코드를 작성할 것이다. 이떄 이들은 call back함수로서 반환한 Promise의 값을 매개변수로 사용할 수 있게된다. 그렇기에 Promise의 상태를 각 조건과 값에 따라 바꿔서 반환해 주는 것이다.

아마 눈치챘겠지만 그렇다. Promise 패턴은 결국 callback을 사용하는 것이다. 그럼 이미 callback으로 해결이 가능한 실행 처리를 왜 굳이 Promise 패턴을 사용하는 것일까?

5. Promise에게 감시받는 방법.

간단하게 말하면 에러 핸들링이 편한다. 왜냐? 어머니의 감시처럼 Promise가 철저하게 에러에 대해서 지켜봐주고 있기 때문이다.

// Promise 패턴을 사용하지 않고 일을 계획하는 것

let sampleVal = 1
let callbackFunc =     (sampleVal)=> {
       return sampleVal+1
     }

let pendingState = (callbackFunc) => {
  return callbackFunc(callbackFunc(callbackFunc(callbackFunc(sampleVal))))
}
console.log(pendingState(callbackFunc))

// Promise 패턴을 사용하여 일을 계획 하는 것
let sampleVal = 1
let callbackFunc =     (sampleVal)=> {
       return sampleVal+1
     }
let pendingState = (callbackFunc) => {
  return new Promise((resolve, reject)=> {

    resolve(callbackFunc(callbackFunc(callbackFunc(callbackFunc(sampleVal)))))



  })
}
console.log(pendingState(callbackFunc))

물론 이번 예제는 Promise의 감시능력에 대해 보기 위해 똑같이 callback으로 실행을 했다. 밑의 코드에서 아무 오타나 한번 내보자. 한번 첫 callbackFunc에 들어가는 sampleVal을 sampleVla로 바꾸고 콘솔창을 지켜보자. Promise에서 오류가 발생하고 그 내용도 자세히 알려준다. 더 나아가 Promise 패턴은 가독성이 좋다. 지금 위의 코드들은 도대체 뭘 하고있는지 추적하기가 쉽지 않다. Promise 패턴의 .then 매소드를 사용해보면 가독성이 훨신 좋아진다.

let sampleVal = 1

let pendingState = () => {
  return new Promise((resolve, reject)=> {

    resolve(sampleVal)



  }).then((val)=> {return val+1}).then((addedVal)=> {return addedVal *10}).then(multipliedVal=> {return multipliedVal + 10})

}
console.log(pendingState())

가독성이 훨신 좋아졌다. 어떤 함수가 무엇을 받아서 뭘 하는지 차례차례 잘 보인다. 콘솔창은 다음과 같을 것이다. 그런데 뭔가가 눈에 거슬린다. 아까는 분명 resolved였는데 .then메소드를 사용해서 계획하고 실제로 실행했는데도 Promise의 상태는 resolved인데 왜 console에는 pending이라고 찍히는 걸까?

6. 돌아온 싱글 settled

그 이유는 Promise가 fulfilled (resolved) 또는 rejected의 상태로 바뀌면 앞선 예제처럼 .then메소드로 다음 실행을 handle 할 수 있게 된다. (그래서 .then이 handler라고도 불린다.) 그런데 Promise가 제공하는 .then/catch/finally등의 여러 핸드러는 Promise가 pending 상태 일때 호출을 기다린다. 그리고 상태가 fulfilled 나 rejected가 되면 Promise의 상태는 바로 settled라는 상태로 바뀐다. 이는 한번 fulfilled나 rejected가 되었던 Promise의 pending 상태를 일컷는 말이다.

이 settled 라는 상태가 되면 .then/catch/finally등의 Promise가 제공하는 여러 핸드러가 즉시 실행이 가능하다. 그 후 핸드러들의 실행이 반환되어 실행이 끝나면 Promise의 상태는 다시 pending이 되는데 처음 Promise를 인스턴스했을 떄의 pending이 아닌 한번 rejected 나 fulfilled로 상태가 바뀐 대기 상태를 말하는 settled상태 인것이다. 쉽게말해 돌싱이라는 이야기다. 그래서 콘솔에 pending이라고 찍히는 것이다.

정리하면 Promise의 실체는 resolve 나 reject를 통해 Promise의 상태를 바꿔준 후 각 상황에 따라 Promise의 상태를 fulfilled(resolved)나 rejected로 바꿔준다. 이렇게 상태가 바뀐 Promise는 즉각 pending 상태로 바뀌는데 이 떄의 pending은 돌싱이다. 즉 한번 상태가 바뀌었다, 즉 사용되었음을 인지하고 있기 때문에 .then 등 Promise가 제공하는 메소드 혹은 핸들러를 즉각 실행을 가능하게 해준다.

그럼 이제 내부를 까봤으니 생각을 머리속에 잘 조립하여 앞서 시도하던 실제 fetch 함수를 Promise 패턴으로 실행해보자.

7. API 호출 실전

자 다시 3.1의 예제코드를 실행해보자.

이제 원리를 알았으니 적용해서 사용해보는 일만 남았다.

// 실제 받아올 데이터
//https://jsonplaceholder.typicode.com/users
[
  {
    "id": 1,
    "name": "Leanne Graham",
    "username": "Bret",
    "email": "Sincere@april.biz",
    "address": {
      "street": "Kulas Light",
      "suite": "Apt. 556",
      "city": "Gwenborough",
      "zipcode": "92998-3874",
      "geo": {
        "lat": "-37.3159",
        "lng": "81.1496"
      }
    },
    "phone": "1-770-736-8031 x56442",
    "website": "hildegard.org",
    "company": {
      "name": "Romaguera-Crona",
      "catchPhrase": "Multi-layered client-server neural-net",
      "bs": "harness real-time e-markets"
    }
  },
  {
    "id": 2,
    "name": "Ervin Howell",
    "username": "Antonette",
    "email": "Shanna@melissa.tv",
    "address": {
      "street": "Victor Plains",
      "suite": "Suite 879",
      "city": "Wisokyburgh",
      "zipcode": "90566-7771",
      "geo": {
        "lat": "-43.9509",
        "lng": "-34.4618"
      }
    },
    "phone": "010-692-6593 x09125",
    "website": "anastasia.net",
    "company": {
      "name": "Deckow-Crist",
      "catchPhrase": "Proactive didactic contingency",
      "bs": "synergize scalable supply-chains"
    }
  },
  ...
  ]

  let myData =""
let getCollectionData = () => {
  myData = fetch('https://jsonplaceholder.typicode.com/users')
  return myData
}
getCollectionData()

console.log(myData)

콘솔을 확인하면 잘 찍히는 것을 알 수 있다. 이게 바로 Promise를 인스턴스화 해서 사용하고 Promise 패턴으로 가독성을 높히고 에러를 잡아내는 방법이다.

1. 총 정리 하면 자바스크립트 엔진이 자바스크립트 코드를 비동기 실행 방식으로 실행하는데, 함수에 있어서, 조금 특이한 방법으로 실행한다.

2. 대표적으로 API 요청 같은 경우에는 실행의 순서가 맨 뒤로 옮겨지기 때문에 코드들을 순서대로 작성하고 API 요청으로 변수에 값을 담으려 해도 결국 값은 담기지 않는다.

3. 그래서 Promise를 사용하고 Promise가 제공하는 핸드러를 사용하여 계획표를 짠다.

4. 이 곳에서는 callback으로써 값을 받아서 사용하기 때문에 에러가 발생하지 않을뿐더러 Promise 패턴을 사용하면 가독성이 좋아져서 디버깅도 쉽고 에러를 찾아내는 것도 수월해진다.

• 다음 블로그에 Promise의 자주 쓰이는 핸들러인 try/ catch/ async/ await를 정리하도록 하고 기본 Promise 정리를 끝내도록 하겠다.