알면 신통방통 편리한데 모르면 정말 깜깜한 자바스크립트 라이브러리. 자바스크립트 "라이브러리가 왜 태어 났는지" 를 알면, 해당 라이브러리를 프로젝트에 채용할지 말지를 결정할 수 있지요. 뿐만 아니라, 일부기능만이 필요해서 막연히 사용했던 라이브러리의 다른 기능들도 참조할 수 있겠습니다.
그래서 이 포스트에서는
- 어떤 기존의 문제가 있었는지
- 해당 라이브러리가 어떻게 해결해 주었는지
를 정리해 봤습니다.
React
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| SPA는 데이터 바인딩이 복잡해서 UI구축이 힘들다. | 표시 할 내용을 HTML처럼 (JSX에서) 선언으로 쓰며 간단해 졌다. |
| HTML의 표준 기능 컴포넌트를 재사용 할 수없다. | 구성 요소 (컴포넌트) 의 재사용을 가능하도록 했다. |
| SPA는 표시 내용을 업데이트해야 할 부분을 모두 클라이언트 측에서 계산해야한다. | 전체를 다시 그리기 같은 요청을 던져도 정말 업데이트가 필요한 부분 (차이)를 자동으로 계산하여주기 때문에 낭비없이 빠른 화면 갱신이 가능하다. |
Flux 아키텍처
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| MVC에서 역할을 분담해서 각각이 밀접하게 연계하기 위해 결국 디자인이 복잡하다 | 연계의 방향을 한 방향으로 한정하여 설계를 단순화 했다. |
참고 : Flux | Application Architecture for Building User Interfaces
Redux
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| 관리해야 하는 "상태 (state)" 가 복잡하다. | 하나의 스토어를 만들어 어디에서나 상태를 관리하도록 했다. |
| 상태 전이 (mutation)와 비동기 성 (asynchronicity)을 동시에 취급하려고하면 어렵고 인간에게 이해하기 어려워진다. | 상태 전이를 인간에게 이해 정의하기 쉽게 한 ( (oldState, action) => newState라는 함수에서 상태 전이를 표현했다.) |
참고 : Motivation | Redux
react-router
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| SPA의 경우 클라이언트 측에서 라우팅 할 필요가있다 | 라우팅 기능을 제공 했다. |
| React의 강점 중 하나 "서버 사이드 렌더링" 를 클라이언트 측 라우터가 방해 | 서버 사이드 렌더링을 지원했다. |
React의 구성 요소로 구성된 라우터이므로 당연히 React와 궁합이 좋습니다. 또한 서버 사이드 렌더링을 지원하고 있으며, React의 장점을 충분히 활용할 수 있습니다.
material-ui
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| MaterialUI을 사용하고 싶은데 구현이 매우 복잡하다. | MaterialUI을 구현 한 React 구성 요소를 제공 했다. |
React의 재사용성을 높여 주었습니다.
ES2015
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| jQuery와 underscore 등 다양한 유틸리티 라이브러리로 보강했지만 소용이 의존성을 늘리고 싶지 않다 | 여러가지 기능을 브라우저 표준으로 제공 했다. |
| 라이브러리를 쓰면 느리다. | 브라우저 기본 구현이므로 빠르다 |
| 클래스 상속 기능 원한다. 함유 구현이 어렵다 | class 구문 지원 |
| 비동기 처리 귀찮다. jQuery.Deferred! | Promise |
| 함수에 기본 인수 설정할 없다 | 기본 인수 지원 |
| 다른 많은 요구 | 요망에 대답! |
classe 등 기능면에서 큰 향상을 볼 수있었습니다.
Babel
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| ES2015를 쓰고 싶지만 대응 브라우저가 적다 | ES2015에서 작성한 코드를 ES5 이전코르로 변환해 준다 |
| jsx로 작성된 코드는 일단 js로 변환하지 않으면 안됨 | Babel가 직접 jsx을 지원한다 |
Browserify
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| Node.js 용으로 쓴 코드를 브라우저로 이동하고 | Node.js 표준 라이브러리 브라우저 버전 구현을 제공 |
| Node.js에서 require 의한 라이브러리로드가 기본이지만 여러 js 파일을 따로 가져 오면 요청이 다발하고 느린 | js 파일을 하나로 묶어주는 |
| 프런트 엔드 JavaScript 코드의 비대화에 따라 변경이 미치는 영향을 쫓아 어려워진다 | jQuery 등 기존 모듈을 npm 패키지함으로써 전체 CommonJS module 화를 실현 함과 동시에 프런트 엔드 코드로 関心の分離을 실현 |
webpack
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| js 파일 모듈로드 방법이 난립 많아. | 모두 하나의 js 파일에 정리했습니다. |
| js 파일 이외에도 정리 버리면 더 읽어 빨리되는 것은? | 이미지도 css도 js도 하나의 파일에 정리했습니다. |
ESLint
| 기존의 문제 · 요구 | 어떻게 해결했나 |
| 코드의 오류를 알고 싶다. | 코드 스타일과 정적으로 검사 가능한 오류를 찾아 줬다. |
| JS는 과도기에 있고, 오래된 규칙이 불필요한 오류를 감지 될 수있다 | 높은 커스터마이즈 성을 제공 |