당신이 React(혹은 프론트엔드개발) 초심자라면 생태계가 혼란스럽다는 사실을 발견할 것입니다. 거기에는 몇 가지 이유가 있습니다.
- React는 역사적으로 얼리어답터와 전문가 집단을 겨냥해서 만들어졌습니다.
- Facebook은 실제로 사용하는 것만을 오픈 소스화 합니다, 그래서 페이스북보다 작은 프로젝트들을 위해 오픈 소스를 다듬어 가는 데 집중하지 않습니다.
- React 개발 지침이라고 자처하지만 홍보를 위한 거짓부렁이 많습니다.
예상하건데, 이 글을 읽다 보면 당신은 HTML, CSS 그리고 JavaScript로 페이지를 작성할 것입니다.
여기저기 React에 대해서 모순되는 충고들이 차고 넘칩니다; 제 얘기를 왜 들어야 할까요?
저는 Facebook에서 React를 오픈소스화한 팀의 원년멤버였습니다. 지금은 Facebook 에서 나와 작은 스타트업에 있습니다. 그래서 Facebook 이 아닌 사람들의 관점도 잘 알고 있습니다.
모든 소프트웨어는 기술의 집합으로 이루어져 있습니다. 그리고 당신이 애플리케이션을 만들기 위해서는 그 기술 요소들을 충분히 이해할 필요가 있습니다. 잘못된 순서로 대부분 이 기술들을 기술되기 때문에 React 생태계의 tooling(자동화 및 툴 개발)이 부담스럽게만 여겨잡니다.
다음과 같은 순서로 배우셔야 합니다. 순서를 뛰어넘거나 동시에 하시면 안됩니다:
React를 잘하기 위해서 이 모든 걸 할 필요는 없습니다. 단지 문제 해결을 위해서만 다음 단계로 이동하세요.
좀더 추가하자면, 안정적이지는 않지만 React 커뮤니티에서 종종 언급되는 (소위 "bleeding edge") 토픽들이 몇 가지 있습니다. 아래 보이는 토픽들은 흥미롭기는 하지만, 이해하기 힘들고 앞에 언급된 토픽들에비해 대중적이지 않습니다. 그리고 대부분의 앱에서는 필요하지 않습니다.
일반적으로 잘못 알려진 이야기가 React를 배우기 시작하기 위한 세팅시간이 많이 걸린다는 것입니다. 공식문서에서 (복사-붙여넣기 용 HTML template) 을 이용해서 .html 파일로 저장해서 바로 시작할 수 있습니다. 이 단계에서는 어떤 툴 및 세팅이 필요없고 기본 React에 익숙해 질때까지는 다른 툴 및 세팅을 시작하지 마십시오
저는 아직도 React를 배우는 가장 쉬운 방법은 공식문서 라고 생각합니다.
npm은 Node.js용 패키지 관리자입니다. 프론트엔드 엔지니어와 디자이너들이 Javascript 코드를 공유하는 가장 보편적인 방법입니다. CommonJS라고 불리는 모듈 시스템을 포함하고 있으며 Javacript 로 작성된 CLI(command-line interface) 기반으로 모듈을 설치 할 수 있습니다. 브라우저를 위해 CommonJS 가 왜 필요한지에 대한 배경을 알기 위해서는 이 글 을 읽어보시고, CommonJS API에 대한 이해를 위해서는 CommonJS Spec Wiki 를 읽어보십시오.
대부분의 React 생태계의 재사용 가능한 컴포넌트, 라이브러리, 툴은 CommonJS 모듈을 통해 사용가능하고 npm으로 설치됩니다.
몇가지 많은 기술적 이유들 때문에 CommonJS 모듈 (npm 에 있는 모든 모듈)들은 브라우저에서 그대로 사용할 수 없습니다. 이 모듈들을 웹페이지의 <script> 태그에 포함된 .js 파일들을 포함하기 위해서는 Javascript 번들러가 필요합니다.
Javascript 번들러의 예를 들자면 webpack 과 browserify가 있습니다. 모두 좋은 선택입니다. 하지만 저는 큰 애플리케이션의 개발을 쉽게 도와주는 기능이 많은 webpack 을 선호합니다. 문서화가 좀 헷갈린다면 개발 시작을 위한 플러그앤 플레이 템플릿이 있고, 조금 더 복잡한 경우에는 제가 작성한 webpack 사용기도 있습니다.
명심할 점 : CommonJS는 require() 함수를 모듈 임포트에 사용합니다. 그래서 많은 사람들이 require.js로 불리는 프로젝트와 뭔가 해야하는 지 헷갈립니다. 여러가지 기술적 이유로 require.js를 쓰지 말것을 추천해 드립니다. React생태계에서도 일반적이지는 않습니다.
React 예제에서 JSX(React 튜토리얼을 배울때 보던)를 감싸고 있던 코드에서 아마 당신은 재미있는 문법들을 보았을 것입니다. ES6 라고 불리는 이것은 Javascript의 최신버전입니다. 그래서 아직 당신은 이것을 배운적이 없었을 겁니다. 브라우저에서 아직은 완전히 지원되지 않지만, 번들러는 적합한 설정과 함께 브라우저가 이해할 수 있게 변환시켜 줍니다.
만약 당신이 작업을 그저 React를 통해 완수하려면 ES6배우는 것은 건너뛰거나 혹은 작업 중에 시도해 볼 수도 있습니다.
React 컴포넌트를 만들기 위해서 더 선호되는 방법이 ES6라는 이야기를 많이 들었을 수도 있습니다. 사실이 아닙니다. 대부분 사람은 (Facebook 엔지니어 포함) React.createClass() 로 클래스를 만듭니다.
(역자 주. ES6에서는 function 처럼 class 키워드를 통해 생성합니다.)
싱글페이지 앱(SPA)은 요즘 일시적인 대 유행입니다. 이들은 한번 페이지를 로딩한 뒤, 사용자가 링크나 버튼을 클릭하면 페이지에서 돌고 있던 javascript 가 주소창을 바꿉니다. 그러나 웹페이지가 갱신되지 않습니다. 주소창의 주소를 관리하는 것은 이른바 router 가 관장합니다.
React 생태계의 가장 유명한 router는 react-router 입니다. 만약 싱글페이지 앱을 만든다면 쓰면 안 되는 좋은 이유가 없는 한 이용하시면 됩니다.
싱글페이지앱을 만들지 않는다면 router를 사용하지 마세요*. 대부분 프로젝트는 어쨌든 더 큰 애플리케이션의 안쪽에서 동작하는 작은 컴포넌트로 시작합니다.
Flux를 아마도 들어보셨을 거라고 봅니다. Flux에 대해서는 엄청나게 많은 잘못 알려진 정보들 투성이입니다.
많은 사람이 애플리케이션을 만들고 자신들의 데이터 모델을 정의하기를 원합니다. 그래서 그 일들을 위해 Flux를 사용하기 원합니다. 이것은 Flux를 적용하는 나쁜 방법입니다. Flux는 오직 많은 컴포넌트가 만들어지고 난 뒤 한 번만 더해져야 합니다.
React 컴포넌트는 계층적으로 정돈됩니다. 대부분의 경우에, 당신의 데이터 모델은 계층구조를 따릅니다. 이런 상황에서는 Flux가 당신에게 쓸모없습니다. 하지만 때때로 당신의 데이터 모델이 계층적이지 않을 수 있습니다. React 컴포넌트가 본 기능에 충실하지 않은 props를 받아야 하는 상황들이 시작된다거나, 작은 컴포넌트들이 매우 복작하게 엉키기 시작한다면 Flux를 고려할 시간입니다.
당신이 Flux가 필요할때 알게 될 것입니다. 만약 당신이 확실한 필요성이 느껴지지 않는 상태면 사용할 필요 없습니다..
Flux를 사용하기로 했다면 가장 유명하고 잘 문서화 되어 있는 Flux 라이브러리는 Redux입니다. 대체할 만한 것들은 많고 일일이 평가해보고 싶은 생각이 드시겠지만, 제 충고는 일단 가장 유명한 것을 사용해 보는 것입니다.
React가 생겨나기 전에, 많은 사람은 CSS 스타일들을 SASS같은 전처리기로 만들어진 복잡한 스타일 시트와 함께 재사용했습니다. React가 재사용 가능한 컴포넌트를 쉽게 만들 수 있게 한 이후로, 스타일 시트는 다소 복잡함이 줄어들 수 있게 되었습니다. 커뮤니티의 다수(나를 포함해서)들은 스타일시트를 완전히 제거하는 실험들을 하고 있습니다.
이것은 여러 가지 이유를 고려하면 상당히 미친 아이디어 입니다. 이렇게 하면 미디어쿼리가 더 어려워지고 이런 기술을 사용하는 데에는 성능의 한계가 있을 수도 있습니다. React를 시작할 때에는 style 관련된 것들은 하던데로 진행하십시오
React가 어떻게 동작하는지 감이 오고 나면 대체 가능한 기술들을 찾아보게 될 것입니다. 그중 유명한 녀석이 BEM입니다. 단계적으로 CSS 전처리기를 폐지하기를 추천합니다. 왜냐하면, React는 당신에게 스타일들을 재사용할 수 있는 강력한 방법들을 (컴포넌트를 재사용하면서) 제공하기 때문이고 Javascript 번들러는 더 효과적인 방법으로 스타일 시트들을 만들어내기 때문입니다. ( OSCON에서 제가 한 발표 를 공유합니다.) 보시면 아시겠지만 다른 Javascript 라이브러리와 마찬가지로 CSS 전처리기와 궁합이 좋습니다.
대안으로 CSS Modules 을 사용할 수도 있고, 조금 더 자세하게는 react-css-modules 를 살펴볼 수도 있습니다. CSS 모듈들과 함께 여전히 CSS (or SASS/LESS/Stylus)를 작성할 수 있지만 React 안의 인라인 스타일로 CSS 파일을 구성할 수 있습니다. BEM 같은 방법론을 사용한다면 class name을 관리하는 것을 걱정할 필요도 없습니다. 이것은 모듈 시스템안에서 다뤄지기 때문입니다.
서버 렌더링은 종종 "유니버설" 혹은 "동형" 자바스크립트로 불립니다. 이것이 의미하는 바는 React 컴포넌트를 사용해 static HTML을 서버에서 그릴 수 있다는 이야기 입니다. 이렇게 하면 첫화면 UI를 보기위해 JS 파일을 다운받는 시간이 절약되고 React는 서버에서 렌더링한 HTML을 재사용해 클라이언트에서 페이지를 만들 필요가 없기 때문에 페이지 초기 진입 과정의 성능을 개선시켜줍니다.
만약 초기 렌더링 속도가 너무 느리다거나 서치엔진의 순위를 개선하고 싶다면 서버 렌더링이 필요합니다. 구글이 클라이언트 렌더링 콘텐츠에 대해 index를 만드는 것은 사실이지만, 2016년 1월까지는 클라이언트 렌더링의 성능에 대한 패널티 때문에 잠재적으로 검색 순위에 부정적인 영향을 미치는 것으로 측정되었습니다.
서버 렌더링은 제대로 하기 위해서는 아직은 많은 세팅을 필요로 합니다. 서버 렌더링을 염두에 두지 않고 React 컴포넌트는 작성되었기 때문에(투명하게 지원하지만), 일단 애플리케이션을 만들고 서버 렌더링은 이후에 생각해야 합니다. 서버 렌더링을 지원하기 위해 모든 컴포넌트를 새로 짤 필요는 없을 것입니다.
Immutable.js 는 React 앱을 만들때 발생하는 특정한 성능 이슈를 해결하는 데 도움을 주는 데이터 구조체들의 집합을 제공합니다. 이 훌륭한 라이브러리를 앞으로 많이 사용하게 될것입니다. 하지만 당신이 성능에 미치는 영향의 진가를 알아볼 때까지는 완전히 불필요할 것입니다.
이 기술들은 AJAX 요청들을 줄여주는 도움을 줄 것입니다. 아직 그것들은 최신 기술에 속하므로 너무 많은 AJAX 요청 때문에 문제가 되는 일이 아니라면 Relay나 Falcor 등은 필요 없습니다.