리액트가 등장하게 된 배경에 대해 이해하다 보면,
리액트가 등장하기 전 주로 사용되던 Angular.js 에 어떤 문제가 있었는지,
리액트를 개발한 메타(이전 페이스북)가 어떤 문제를 직면했었고 왜 이걸 해결해야 했는지를 이해할 수 있다!
리액트 이전에는 "양방향 바인딩"을 하는 자바스크립트 프레임워크들이 존재했다
양방향 바인딩
React가 지원하는 '단방향 바인딩'과 반대되는 개념으로,
Model 과 View 간 서로 변경할 수 있는 구조
양방향 바인딩의 특징
- 뷰의 변화가 컴포넌트에 영향을 미칠 수도, 반대로 컴포넌트의 상태가 변경되면 뷰의 상태도 변할 수 있다
- 코드의 규모가 커질수록 이 같은 상태의 변화가 무엇으로 인해 일어났는지 파악하기가 어려워진다
양방향 바인딩의 단점 = 변경된 DOM 추적이 어려움
- 예) Angular.js
// Angular의 경우, input 의 입력으로 name 이 변경되거나,
// AppComponent 클래스 내부에서 직접 name을 변경할 수 있다
// name이 변경된 이유를 알고 싶다면 template이나 클래스 내부에서
// name 을 변경하는 곳을 다 찾아봐야 한다
import { Component } from '@angular/core'
// View
@Component({
selector: 'app-root',
template: `<input type='text' [(ngModel)]="name" />`,
})
// Model
export class AppComponent {
name = ''
}참고) Angular.js 에서는 MVC 와 MVVM 패턴이 모두 사용된다.
MVVM 패턴 (Model + View + ViewModel)
MVC 패턴 (Model + View + Controller)
-
모델: 데이터와 비즈니스 로직을 관
- 앱이 포함해야할 데이터가 무엇인지를 정의
-
뷰: 레이아웃과 화면을 처리
- 앱의 데이터를 보여주는 방식을 정의
-
컨트롤러: 모델과 뷰로 명령을 전달
- 앱의 사용자로부터의 입력에 대한 응답으로 모델 및/또는 뷰를 업데이트하는 로직을 포함
리액트는 "단방향 바인딩" 지원
리액트의 상태 변화는 '단방향'(
model->view)으로, '명시적'으로 이뤄진다
- 명시적인 상태 변경
- 단방향 바인딩만 지원: 말 그대로 데이터의 흐름이 한쪽으로만 간다
단방향 바인딩은 양방향 바인딩에 비해 데이터 흐름의 변화가 단순하기 때문에 코드를 읽기가 쉽고 버그를 야기할 가능성이 비교적 적다.
상태가 변화했다면 그 상태 변화를 명시적으로 일으키는 함수만 찾으면 된다
// 리액트의 경우 name 이 변경되는 경우는 setName 이 호출되는 경우 뿐이다
// name 이 변경된 이유를 찾고 싶다면 setName 을 호출하는 곳을 찾으면 된다
function App {
const [name, setName] = useState('') // model
function onChange(e) {
setName(e.target.value)
}
return (<>{name}</>) // view
}JSX 구문과 Flux 패턴에 대한 아이디어 등장
기존 MVC 패턴의 단점
기존의 MVC 패턴은 다음처럼 단 하나의 Controller 로 여러가지 View와 Model 을 관리하는 상황이 복잡했다.
또, 한 View 에서 일어난 상호작용으로, 여러 Model이 변경되거나, 그 반대의 일도 벌어지기에, 코드가 복잡해지는 경향이 있었다.
Flux 패턴이란?
어디서 어느 방향으로 데이터가 전달될지 알기에 복잡한 MVC 패턴의 단점 해소하고자,
Flux 패턴은 데이터가 한 방향으로만 흐르도록 한다.
위 그림과 같이, 어떤 Action 이 발생하면, Dispatcher에서 이를 받아와 해석한 후 Store(=Model) 에 저장된 정보에 변경을 가하고, 그 결과가 View로 다시 전달되도록 한다.
어디에서든 Action 이 발생하면, Dispatcher 를 통해 단방향으로 흘러간다.
처음에 반응 안 좋았던 JSX
당시에는 HTML과 JS는 항상 다른 파일에 존재했고,
이를 컴퓨터 공학에서 말하는 관심사 분리의 원칙을 지키기 위한 기초적 사실로 받아들여졌기 때문에,
HTML과 JS가 함께 존재하는 JSX는 말도 안 되는 것으로 비쳤다.
"템플릿이 반드시 애플리케이션 로직과 함께 있어야 하나요? 이것은 끔찍한 결정입니다."
"render()를 매번 호출하고, HTML의 일부를 계속해서 새로 빌드하는 것은 기기 성능에 좋지 않을 것 같습니다."하지만, 리액트 점점 빛을 보기 시작
메타, 인스타그램, 넷플릭스 등 대형 IT 회사들이 리액트 도입하면서,
프런트엔드 커뮤니티에서도 점차 리액트에 환호하기 시작했다.
(바벨(Babel) 같은 초대형 오픈소스 프로젝트도 재정난을 겪는 것을 보면, 역설적이지만 오픈소스가 빠르고 안정적으로 성장하기 위해서는 중심이 되는 메인 스폰서(리액트 핵심 개발은 메타가 적극 지원)의 역할이 중요하다)
이후, 다양한 리액트향 라이브러리 등장했다.
- 상태 관리: Redux, Zustand, Recoil
- 서버 사이드 렌더링: Next.js
- 애니메이션: framer Motion
- 차트: Recharts
- 폼: React Hook Form정리)
단방향 바인딩 등장 이유 요약
리액트 등장 전, 대부분의 프레임워크는 양방향 바인딩 구조를 채택해 모델과 뷰가 밀접한 관계를 맺고 서로가 서로를 변경할 수 있는 구조였다.
이는, 코드를 작성하기 쉽지만, 변경된 DOM을 추적하는 것이 어렵고,
왜 이렇게 변경됐는지 역시 추적하기 어려워 수많은 버그가 발생했다.
이 문제 개선하고자, 기존의 양방향 바인딩 대신, 모델이 뷰를 변경하는 "단뱡향 방식" 제안했다.
즉, 모델의 데이터가 변경되어 뷰가 변경되어야 하면, 이전 DOM을 버리고 새롭게 렌더링하는 방식이 제안되었다.
리액트의 현재
개발자들이 현재 가장 집중적으로 역량을 쏟고 있는 것은 "서버에서의 리액트 활용"
클라이언트에서는 할 수 없는 서버에서의 작업, 서버 환경이 갖고 있는 가능성에 무게를 두어,
서버에서 리액트를 효율적으로 사용할 수 있는 다양한 기능을 추가할 것으로 보인다.
참고
