🎈 Chapter 1: 입문자를 위한 지식

리액트는 왜 필요한가요?

한마디로 업데이트 때문입니다.

웹의 기능이 늘면서 웹에서 우수한 사용자 경험을 제공하려는 포부도 커졌습니다.
새 페이지가 렌더링되고 로딩되기까지 기다릴 필요 없이, 즉시 업데이트되어 내용을 바로 확인하고 싶어 했습니다. 웹과 웹 페이지가 '즉각적인' 느낌을 주길 원했습니다. 그러나 즉각적인 업데이트를 대규모로 수행하기에는 다음과 같은 이유로 상당히 어려웠습니다.

• 성능
  • 웹 페이지를 업데이트하면 보통 브라우저가 페이지의 레이아웃을 다시 계산하고(이를 리플로우라고 합니다) 그리는 작업을 수행하기 때문에 성능 병목 현상이 자주 발생했습니다.
• 신뢰성
  • 풍부한 웹 경험 전반에서 상태를 추적해 일관되게 유지하기가 어려웠습니다. 상태를 여러 곳에서 추적해 모든 곳에서 일관되게 유지해야 했기 때문입니다.
• 보안
  • 크로스 사이트 스크립팅(XSS) 및 크로스 사이트 요청 위조(CSRF) 같은 악용을 방지하기 위해 페이지에 삽입하는 HTML과 자바스크립트를 모두 소독해야만(sanitize) 했습니다.

리액트 이전의 세계

자바스크립트를 사용하면 DOM API에 접근할 수 있습니다.
시간이 지나 이런 식으로 확장하려는 애플리케이션을 구축할 때 발목을 잡는 요소가 있습니다.

• 오류가 쉽게 생긴다
• 예측이 불가하다
• 비효율적이다

jQuery, Backbone.js, Knockout, Angular.js, etc.

리액트 등장

리액트가 제시한 핵심 아이디어 하나는 컴포넌트 기반 아키텍처였습니다.
웹을 비롯한 여러 플랫폼에서 사용자 인터페이스를 작성할 때 재사용 가능한 컴포넌트를 조합하는 것이 가장 최적화된 방법입니다.

리액트는 단방향 데이터 흐름 패턴을 도입해 개발자가 애플리케이션을 더 잘 제어하고 시간에 따라 데이터가 어떻게 변화하는지 더 쉽게 이해할 수 있게 했습니다.
리액트는 가상 DOM이라는 개념을 채택해 직접적인 DOM 조작을 최소화함으로써 성능을 향상했습니다.

리액트의 핵심 가지

선언적 코드와 명령형 코드

리액트는 DOM에 대한 선언적 추상화를 제공합니다.
기본적으로 리액트는 우리가 보고자하는 것을 코드로 표현하는 방법을 제공하고 실제로 어떻게 할지는 리액트가 알아서 합니다.

컴포넌트의 역할은 사용자 인터페이스에서 이 영역이 어떤 모습이어야 하는지에 대해 설명을 반환하는 것뿐이며, 이러한 설명은 의도한 UI 구조를 가볍게 기술하는 가상 DOM을 사용해 이루어집니다. 리액트는 업데이트 발생 전과 후의 가상 DOM을 비교하고, 실제 DOM의 작은 부분만 성능 좋은 방식으로 업데이트해서 변경된 가상 DOM과 일치시킵니다. 리액트는 이러한 방식으로 DOM을 업데이트합니다.

가상 DOM

가상 DOM은 실제 DOM을 자바스크립트 책체로 표현하는 프로그래밍 개념입니다. 리액트는 가상 DOM을 사용해 컴포넌트의 변경 사항을 추적하고 필요할 때만 컴포넌트를 다시 랜더링합니다.
리액트에서 가상 DOM은 실제 DOM 트리를 가볍게 표현한 것인데, UI 요소의 구조와 속성을 나타내는 평범한 자바스크립트 객체입니다. 리액트는 실제 DOM 트리와 일치하도록 가상 DOM을 생성하고 업데이트하며, 가상 DOM에서 발생한 모든 변경 사항은 재조정(reconciliation)이라는 과정을 통해 실제 DOM에 적용됩니다.

컴포넌트 모델

리액트는 애플리케이션을 작은 조각으로 나누고 이를 커다란 트리에 추가해 애플리케이션을 구성하는 '컴포넌트 단위로 생각하기'를 적극 권장합니다.

불변 상태

리액트의 설계 철학은 애플리케이션 상태를 불변하는 값의 집합으로 기술하는 패러다임을 강조합니다. 각각의 상태 업데이트는 새로운 독립된 스냅샷과 메모리 참조로 취급합니다.
리액트는 불변성을 강제함으로써 UI 컴포넌트가 특정 시점의 특정 상태를 반영하도록 보장합니다. 상태가 변경되면 원래 있던 상태를 직접 변경하는 대신 새로운 상태를 표현하는 새 객체를 반환합니다.

플럭스 아키텍처

플럭스는 클라이언트 측 웹 애플리케이션 구축을 위한 아키텍처 디자인 패턴이며, 페이스북(현재 메타)에서 발표했습니다. 단방향 데이터 흐름을 강조해 애플리케이션 데이터의 흐름을 더욱 예측 가능하게 만듭니다.

• 액션
  • 새 데이터와 액션의 종류를 식별하는 속성을 포함하는 단순한 객체입니다.
  • 사용자 상호 작용, 서버 응답, 양식 입력 등 시스템에 대한 내외부 입력을 표현합니다.
  • 액션은 중심의 디스패처를 통해 여러 스토어로 보내집니다.

// 액션 객체 예시
{
  type: 'ADD_TODO',
  text: '플럭스 아키텍처 연습',
}

• 디스패처
  • 플럭스 아키텍처의 중심입니다. 액션을 받아서 애플리케이션에 등록된 스토어로 보냅니다.
  • 모든 스토어는 디스패처에 스토어 자신과 콜백을 등록해 두는데, 이 콜백 목록을 관리하는 것도 디스패처입니다.
  • 액션을 디스패칭하면 등록된 모든 콜백으로 해당 액션을 전송합니다.

// 액션 디스패칭의 예시
Dispatcher.dispatch(action);

• 스토어
  • 애플리케이션 상태와 로직을 포함합니다.
  • MVC 아키텍처의 모델과 다소 유사하지만, 스토어는 다수 객체의 상태를 관리합니다.
  • 스토어 자신을 디스패처에 등록하고 액션을 처리하는 콜백도 제공합니다.
  • 스토어 상태가 업데이트되면 변경 이벤트를 발생시켜 뷰에 변경된 사항을 알립니다.

// 스토어 예시
class TodoStore extends EventEmitter {
  constructor() {
    super();
    this.todos = [];
  }
  handleActions(action) {
    switch (action.type) {
      case 'ADD_TODO':
        this.todos.push(action.text);
        this.emit('change');
        break;
      default:
        // 아무 동작 없음
        break;
    }
  }
}

• 뷰
  • 리액트 컴포넌트입니다. 스토어에서 변경 이벤트를 받으며, 의존하는 데이터가 변경되면 스스로 업데이트합니다.
  • 플럭스 아키텍처는 시스템 전반에 걸쳐 단방향 데이터 흐름을 사용하도록 해서 시간 경과에 따른 변화를 추적하기 쉽게 만듭니다.

플럭스 아키텍처의 장점

• 단일 정보 출처
  • 플럭스에서는 애플리케이션의 상태에 대한 단일 정보 출처(source of truth)가 스토어에 저장되는 것이 중요합니다.
  • 이러한 중앙 집중식 상태 관리는 애플리케이션의 동작을 더 예측하기 쉽고 이해하기 쉽게 만듭니다.
• 테스트 가능성
  • 플럭스의 잘 정의된 구조와 예측 가능한 데이터 흐름은 애플리케이션의 테스트 가능성을 높입니다.
  • 시스템의 여러 부분(액션, 디스패처, 스토어, 뷰 등) 간에 관심사를 부리하면 각 부부분을 독립적으로 단위 테스트할 수 있습니다.
  • 데이터 흐름이 단방향이고 상태가 예측 가능한 특정 위치에 저장되어있다면 테스트를 더 쉽게 작성할 수 있습니다.
• 관심사 분리
  • 플럭스는 시스템 여러 부분의 관심사 분리가 명확합니다.
  • 각 부분에는 명확하게 정의된 역할이 있으며, 단방향 데이터 흐름 덕분에 이러한 부분들이 어떻게 상호 작용하는지 분명하게 이해할 수 있습니다.

그래서... 리액트는 왜 필요한가요?

리액트는 개발자들이 더 예측 가능하고 신뢰성 있는 방식으로 사용자 인터페이스를 작성할 수 있게 하고, 우리가 화면에 나타내고자 하는 바를 선언적으로 표현할 수 있게 합니다.
화면에 어떻게 나타날지 신경 쓰지 않아도 리액트가 알아서 효율적인 방식으로 DOM에 점진적인 업데이트를 수행합니다. 또 컴포넌트 단위로 생각하도록 장려해 관심사를 분리하고 코드를 더 쉽게 재사용하도록 도와줍니다.

결론적으로 리액트의 핵심 가치는 컴포넌트 기반 아키텍처, 선언적 프로그래밍 모델, 가상 DOM, JSX, 광범위한 생태계, 플랫폼을 가리지 않는 특성, 메타의 지원을 중심으로 이루어집니다.