React 자체만 놓고 보면 프레임워크보다는 템플릿 엔진이나 DOM 조작을 위한 라이브러리와 비슷하다.
React를 UI 일부에만 적용할 수도 있다. jQery로 개발한 웹 페이지를 서서히 React로 개발해 나갈 수도 있고 이렇게 점점 전체를 React로 개발할 수도 있는 것이다.
React로 프론트엔드를 개발할 때 특정 백엔드를 사용할 필요는 없다. 다른 언어로 백엔드를 개발한 경우에도 React를 사용할 수 있다. React는 UI 라이브러리일 뿐 어떤 형태의 백엔드나 프론트엔드 데이터 관리 라이브러리와도 함께 사용될 수 있다.
만약 기존 웹에 적용을 한다면 몇 가지 경우가 있을 수 있다.
UI 라이브러리를 React로, 그리고 이와 관련된 Redux나 React Router를 활용한 단일 페이지 애플리케이션 스택으로의 구성
MVC의 V를 대체하는 UI 라이브러리로 기존 MVC 프레임워크와 결합
jQuery를 기반으로 서버 측 렌더링을 거친 애플리케이션에서 자동완성 등 일부 기능을 위한 UI 컴포넌트로 활용
대부분의 로직을 직접 처리하는 전통적인 방식의 백엔드에서 서버 측 렌더링 템플릿 라이브러리로 활용
백엔드와 프론트엔드에서 모두 자바스크립트를 사용하는 경우
React Native를 UI 라이브러리로 사용하는 모바일 앱
여러 가지 렌더링 대상에 적용할 목적으로 사용하는 UI 라이브러리
이외에도 여러 가지 경우의 수는 있을 수 있다.
React는 다른 프론트엔드 기술과 함께 사용할 수도 있지만, 단일 페이지 애플리케이션에 활용되는 경우가 더 많다. 웹 앱 개발 방법 중 제일 유리하고 인기도 있다.
React 라이브러리와 렌더링 대상
React는 버전 0.14 이후부터는 기존의 React를 'react'와 'react-dom'이라는 두 패키지로 분리해서 npm에 배포했었다. React를 웹 개발 뿐 아니라 UI 개발이 필요한 환경이라면 어디서나 사용할 수 있는 라이브러리로 만들 수 있게 한 것이다.
0.13 버전에서는 React.render() 메서드를 사용해 웹 페이지의 DOM 노드에 엘리먼트를 넣었다. 하지만 0.14 버전 이후부터는 이 부분이 react-dom 패키지로 이전되어 ReactDOM.render() 메서드로 상요했다.
React 커뮤니티에 나와 있는 여러 가지 렌더링 대상에 React를 적용할 수 있는 패키지를 몇 가지 보면,
blessed 터미널 인터페이스용 렌더러 : http://github.com/Yomguithereal/react-blessed
ART 라이브러리용 렌더러 : http://github.com/reactjs/react-art
< canvas> 렌더러: http://github.com/Flipboard/react-canvas
3D 라이브러리 three.js용 렌더러 : https://github.com/Izzimach/react-three
VR과 360도 인터페이스를 위한 렌더러 : https://facebook.github.io/react-vr
위에 예시를 몇 가지 든 렌더러 외에도 react와 react-dom이 분리되면서, 웹용으로 개발된 React 컴포넌트와 네이티브 모바일 앱을 위해 시작한 React Native용 컴포넌트 간에 코드를공유할 수 있게 되었다. 결국 웹 개발에 React를 사용할 때는 react와 react-dom을 사용해야 한다는 소리이다.
여기에 더해 React의 유틸리티 라이브러리가 추가되었다. 15.5 버전 이전에는 이 중 일부가 React의 '부가 기능'으로 제공되었었다. 이런 유틸리티 라이브러리는 불변 데이터를 다루거나, 테스트를 수행할 때 도움이 된다.
그리고 React는 거의 항상 JSX와 함께 사용된다. JSX는 React UI 개발을 편리하게 해주는 간단한 언어이다. 그리고 Babel과 같은 도구를 사용해 JSX를 자바스크립트로 변환한다.
이렇듯, React와 관련된 많은 도구가 모듈화되어다른 패키지로 분리된 것을 알 수 있다. 이 말은 선택과 자유를 개발자들에게 제공한다.
단일 페이지 애플리케이션(SPA)과 React
단일 페이지 애플리케이션(SPA) 아키텍처는 서버보다는 클라이언트, 즉 브라우저 측에 로직이 더 많은 '팻 클라이언트'이다. SPA는 HTML 렌더링, 입력값 검증, UI 변경 등의 기능을 브라우저에서 해결한다.
아래 그림은 일반적인 SPA 아키텍처를 보여준다.
사용자가 요청을 보내고, 마우스로 버튼 클릭, 드래그 앤 드롭 등의 조작을 한다.
위 과정을 쉽게 말하면, SPA 방식은 UI 렌더링을 대부분 브라우저 상에서 해결한다. 모든 렌더링을 서버에서 해결하는 전통적인 방식과 달리, SPA에서는 데이터만 주고 받는다.
SPA 구현 방식에 있어서 MVC 아키텍처가 인기가 가장 좋은 것은 맞지만, 다른 방식도 물론 있다. React를 사용하는 데 MVC가 필수적인 것은 아니다.
아래 그림을 보면 위에 그림과는 확연히 다르다는 것을 알았을 것이다.
내비게이터나 라우팅 라이브러리가 MVC 패러다임의 컨트롤러처럼 데이터를 가져오고 이에 알맞은 템플릿을 지정하는 역할을 맡는다. 내비게이터 or 컨트롤러는 요청을 보내 데이터를 가져오고, 받아온 데이터와 템플릿을 이용해 만든 HTML로 UI를 렌더링한다. UI는 클릭, 마우스 조작, 키 입력 같은 동작을 SPA에 전달한다.
SPA 아키텍처는 브라우저에서 렌더링되어 데이터도 브라우저에서 처리한다. 데이터를 이용해 HTML을 추가하거나 기존에 렌더링한 HTML을 변경한다. 이러한 점 때문에 데스크톱 애플리케이션에 견줄 만큼 훌륭한 웹 애플리케이션을 만들 수 있는 것이다.
위 그림을 다시 보면, React의 위치를 짚어보면 템플릿의 위치를 고를 수 있다. React는 뷰 계층이므로 데이터를 전달해서 HTML을 렌더링하는 목적으로 사용될 수 있다.
React 개발 스택
React는 모든 것을 갖춘 완벽한 프론트엔드 프레임워크가 아니다. 따라서 데이터 모델링, 스타일, 라우팅 등에 대해 정해진 방법이 없다. 이에 해당 기능을 할 수 있는 라이브러리와 React를 결합해서 사용하게 된다.
React와 함께 쓰기 위한 목적으로 개발한 라이브러리 몇 가지를 보면,
React는 컴포넌트를 쉽게 구성할 수 있어 코드 재사용에 큰 도움이 된다. 가장 큰 강점이기도 하다.
많은 컴포넌트가 npm 모듈로 배포되고 있다. 인기 있는 몇 가지 React 컴포넌트를 보면 이러하다.
또 개발 스택에 JSX도 있다. 때로는 JSX가 React를 거부하는 이유가 되는 경우가 있다.
JSX는 문법이 간단하다. XML이나 HTML의 <>를 이용하여 자바스크립트로 작성하는 React 객체를 만든다. JSX와 React가 잘 어울리는 이유는 코드 구현과 가독성 면에서 편하기 때문이다. JSX는 사실 자바스크립트로 변환하는 작은 언어라고 생각하면 쉽다.JSX는 브라우저에서 작동하지 않지만 컴파일 과정의 소스 코드로 활용된다.
JSX 런타임 변환 라이브러리를 통해 브라우저에서 JSX를 사용하는 경우에도 보면, 결론적으로는 이를 변환한 자바스크립트를 실행하는 것이고, JSX를 실행하는 것은 아니다.
즉, 자바스크립트로 변호나하여 이용하고, 자바스크립트보다 편리한 문법과 기능을 쓸 수 있다.
하지만 물론 JSX를 꼭! 써야하는 것은 아니다.