AngularJS에서 React로 전환한 이유
게시 됨: 2022-03-112011년에 내 코드가 jQuery 선택기 및 콜백으로 복잡해지기 시작했을 때 AngularJS는 더 나은 관리, 신속한 개발 및 기본적으로 더 많은 기능을 도운 생명의 은인으로 등장했습니다. AngularJS의 양방향 바인딩과 "단일 출처의 사실로서의 모델" 철학은 저를 놀라게 했고 내 애플리케이션 전체에서 데이터 중복성을 줄였습니다.
그러나 시간이 지남에 따라 AngularJS 자체에 몇 가지 문제점이 있음을 발견했습니다. 결국 이것들은 나에게 충분한 좌절감을 안겨주었고 대안 솔루션을 찾기 시작했습니다.
AngularJS 1.x의 문제점
실행을 위한 DOM
Angular는 실행 흐름을 위해 DOM에 크게 의존합니다. 응용 프로그램의 기본 부트스트래핑에서 DOM을 스캔하고 지시문 우선 순위로 컴파일하므로 실행 순서를 디버그하고 테스트하기 어렵습니다.
자체 의존성 주입
JavaScript에는 자체 패키지 관리자와 종속성 해석기가 없습니다. 그러나 최근에는 AMD, UMD 및 CommonJS와 같은 구현이 이 문제를 매우 잘 해결하고 있습니다. 슬프게도 AngularJS는 이들 중 어느 것에도 유용하지 않습니다. 오히려 자체적으로 종속성 주입(DI)을 도입합니다. RequireJS를 사용하는 비공식 AngularJS DI 구현이 있지만.
쌍방향 바인딩은 양날의 검
양방향 바인딩을 사용하고 싶지만 구성 요소가 복잡해지면 성능이 저하될 수 있습니다.
양방향 바인딩은 성능에 어떤 영향을 줍니까? 글쎄요, JavaScript ES5에는 변수나 객체에 대한 변경 사항을 알리는 구현이 없으므로 Angular는 "더티 검사"라는 것을 사용하여 데이터 변경 사항을 추적하고 UI와 동기화합니다. Dirty-checking은 Angular의 범위($digest cycle) 내에서 수행된 모든 작업 후에 수행되므로 바인딩 수가 증가할수록 성능이 느려집니다.
양방향 바인딩의 또 다른 문제는 페이지의 여러 다른 구성 요소가 데이터를 변경할 수 있어 데이터 입력의 여러 소스로 이어질 수 있다는 것입니다. 잘 처리하지 않으면 모호한 상황이 발생할 수 있습니다. 그러나 공정하게 말하면 이것은 순전히 구현의 문제입니다.
Angular에는 자체 세계가 있습니다.
Angular의 모든 작업은 다이제스트 주기를 거쳐야 합니다. 그렇지 않으면 구성 요소가 데이터 모델과 동기화되지 않습니다. 따라서 타사의 기존 JavaScript 라이브러리를 사용하는 경우 데이터 변경이 포함된 경우 Angular의 $apply 함수로 래핑하거나 유틸리티 라이브러리인 경우 서비스로 변환해야 합니다. Angular에 사용 가능한 모든 JavaScript 모듈을 다시 발명하는 것과 같습니다.
너무 많은 개념과 가파른 학습 곡선
Angular를 배우려면 모듈, 컨트롤러, 지시문, 범위, 템플릿, 연결 기능, 필터 및 종속성 주입을 비롯한 수많은 개념을 배워야 합니다.
리액트를 만나다
Facebook과 Instagram의 새로운 오픈 소스 JS 라이브러리인 React는 JavaScript 앱을 작성하는 다른 방법입니다. 2013년 5월 JSConf EU에서 소개되었을 때 청중은 "단방향 데이터 흐름" 및 "가상 DOM"과 같은 일부 설계 원칙에 충격을 받았습니다.
공식 React 웹 사이트에는 "React는 사용자 인터페이스를 구축하기 위한 JavaScript 라이브러리입니다."라고 나와 있으며 예, 인터페이스만 있고 다른 것은 없습니다. AngularJS와 같은 프레임워크가 아닙니다. 그러나 Angular 지시문에 비해 다소 독립적인 구성 요소를 작성할 수 있습니다. 빠른 개요
React는 웹 개발의 모범 사례를 다시 생각합니다. Reach는 단방향 데이터 흐름을 장려하고 구성 요소가 데이터에 의해 구동되는 상태 머신이라는 철학을 믿습니다. DOM으로 작업하고 직접 조작하는 것과 같은 대부분의 다른 프레임워크와 달리 React는 DOM을 싫어하고 개발자를 DOM으로부터 보호합니다. React는 UI 구성 요소를 정의하는 데 필요한 기본 API만 제공하고 다른 것은 제공하지 않습니다. Reach는 UNIX 철학을 따릅니다. 작은 것이 아름답습니다. 한 가지만 하고 최선을 다하십시오.
이것은 Pete Hunt(인스타그램 팀에서 제공)가 두 가지를 아주 잘 비교한 것입니다.
그냥 도서관입니다. React에 프레임워크가 필요합니까?
짧은 대답: 당신의 선택.
React를 사용하여 사용자 인터페이스를 구축할 수 있지만 여전히 종속성을 관리하고 AJAX 호출을 하고 데이터 필터를 적용해야 합니다. 프레임워크가 필요한 경우 AngularJS를 버리는 이유는 무엇입니까?
프레임워크는 패키지 세트와 규칙 세트입니다. 일부 패키지가 필요하지 않거나 다른 패키지로 교체하려면 어떻게 합니까? 어떻게 해야 하나요? 패키지 관리자가 필요합니다. AngularJS에서 패키지를 어떻게 관리합니까? 그것은 당신의 선택이지만 Angular에는 고유한 세계가 있습니다. 모든 외부 패키지를 Angular의 세계로 래핑한 다음 사용해야 합니다. 그러나 React는 JavaScript일 뿐이며 JavaScript로 작성된 모든 패키지는 React에서 래핑할 필요가 없습니다.
따라서 npm과 같은 패키지 저장소에서 자체 패키지를 선택하고 원하는 대로 구성하는 것이 좋습니다. 좋은 소식은 React가 바로 사용할 수 있는 패키지가 많이 있는 npm의 사용을 권장한다는 것입니다. React를 시작하려면 다음 풀스택 스타터 키트 중 하나를 사용하는 것이 좋습니다.
리액트의 장점
그렇다면 내가 정말로 React로 전환한 이유는 무엇입니까?
반응이 빨라요!
React는 다른 프레임워크와 다른 접근 방식을 취합니다. DOM으로 직접 작업할 수 없습니다. 오히려 JavaScript 로직과 실제 DOM 사이에 가상 DOM 레이어를 도입합니다. 이는 속도를 크게 향상시키는 데 도움이 됩니다. 연속적인 렌더링에서 React는 가상 DOM에 대해 diff를 수행하고 업데이트해야 하는 실제 DOM의 해당 부분만 업데이트합니다.
Virtual DOM은 Internet Explorer 8에서도 작동하는 통합 브라우저 간 API를 제공하므로 브라우저 간 문제를 해결하는 데도 도움이 됩니다. (휴!)
모든 것이 구성 요소입니다(UI 위젯).
자체 포함된 UI 구성 요소를 작성하면 응용 프로그램을 모듈화하고 각 구성 요소에 대한 문제를 분리합니다. 모든 구성 요소는 개별적으로 개발 및 테스트할 수 있으며 차례로 다른 구성 요소를 사용하여 유지 관리 가능성을 높일 수 있습니다.
승리를 위한 단방향 데이터 흐름!
Flux는 JavaScript 애플리케이션에서 단방향 데이터 계층을 생성하기 위한 아키텍처입니다. React 보기 라이브러리와 함께 Facebook에서 설계되었습니다. 개발을 더 간단하게 만들고 버그를 더 쉽게 추적하고 수정할 수 있습니다. Flux는 구현보다 개념에 가깝습니다. 다른 프레임워크에서도 구현할 수 있습니다. Alex Rattray는 React에서 Backbone Collection과 Model을 사용하여 Flux를 아주 훌륭하게 구현했습니다.
JavaScript 및 기타
최신 웹 앱은 기존 웹과 다른 방식으로 작동합니다. View 레이어는 서버에 영향을 주지 않고 사용자 상호작용으로 업데이트되어야 합니다. 따라서 View와 Controller는 서로 크게 의존해야 합니다. 다른 많은 프레임워크는 View 레이어에 Handlebars 및 Mustache와 같은 템플릿 엔진을 사용하지만 React는 두 부분이 너무 상호 의존적이어서 타사 템플릿 엔진을 사용하지 않고 자바스크립트.
동형 자바스크립트
단일 페이지 JavaScript 웹 앱의 가장 큰 단점은 검색 엔진에서 크롤링할 때 제한이 있다는 것입니다. React에는 이에 대한 솔루션이 있습니다. React는 브라우저로 보내기 전에 서버에서 앱을 미리 렌더링할 수 있으며 서버에서 미리 렌더링된 정적 콘텐츠에서 라이브 애플리케이션으로 동일한 상태를 복원할 수도 있습니다. 검색 엔진 크롤러는 JavaScript 실행보다 서버 응답에 크게 의존하므로 이러한 앱을 미리 렌더링하면 검색 엔진 최적화에 도움이 됩니다.
React는 RequireJS, Browserify 및 Webpack과 잘 어울립니다.
로더와 번들러는 대규모 애플리케이션을 빌드할 때 많이 필요합니다. 불행히도 현재 버전의 JavaScript는 모듈 번들러 또는 로더를 제공하지 않지만 향후 EcmaScript 6(System.import) 버전에서 제안됩니다. 다행스럽게도 RequireJS 및 Webpack과 같은 몇 가지 대안이 있으며 꽤 괜찮습니다.
React는 Browserify로 빌드되지만 이미지 자산을 주입하고 LESS 또는 CoffeeScript를 컴파일하려는 경우 Webpack이 더 나은 옵션이 될 것입니다.
나는 약간의 고통과 함께 React로 전환했습니다.
AngularJS는 프레임워크이므로 $http 서비스의 AJAX 래퍼, 약속 서비스인 $q, 제어 문으로 ng-show, ng-hide, ng-class 및 ng-if를 포함하는 많은 장점이 있습니다. 템플릿용.
React는 프레임워크가 아니라 UI를 빌드하는 라이브러리이므로 다른 모든 부분은 스스로 생각해야 합니다. 저는 개발을 용이하게 하기 위해 React와 함께 사용할 수 있는 오픈 소스 프로젝트를 진행 중이며 커뮤니티에서도 유사한 재사용 가능한 구성 요소에 적극적으로 기여하고 있습니다.
React-components.com은 이러한 오픈 소스 구성 요소를 찾을 수 있는 비공식 디렉토리 웹 사이트입니다.
React의 철학은 양방향 바인딩을 사용하도록 권장하지 않습니다. 이는 양식 요소와 편집 가능한 데이터 그리드를 다룰 때 많은 고통을 가져다줍니다. 그러나 Flux 데이터 흐름과 Stores를 이해하기 시작하면 상황이 더 명확하고 단순해지고 쉬워집니다.
React는 새롭기 때문에 커뮤니티가 성장하는 데 시간이 걸립니다.
Angular는 최근에 큰 인기를 얻었으며 AngularUI 및 Restangular와 같이 비교적 많은 수의 확장을 사용할 수 있습니다. React의 오픈 소스 커뮤니티는 새롭지만 React Bootstrap과 같은 확장을 통해 빠르게 성장하고 있습니다. 더 많은 구성 요소를 사용할 수 있게 되는 것은 시간 문제일 뿐이며 빠른 웹 앱 개발에 React를 쉽게 사용할 수 있습니다.
결론
이전에 AngularJS를 사용한 적이 있다면 처음에는 React를 싫어할 수 있습니다. 주로 단방향 데이터 흐름이고 다른 많은 것을 스스로 처리해야 하는 "프레임워크"가 부족하기 때문입니다. 그러나 Flux 디자인 패턴과 React의 철학에 익숙해지면 그것이 아름다움임을 깨닫게 될 것입니다.
Facebook과 Instagram은 모두 React를 사용합니다. Github의 새로운 Atom Editor는 React를 사용하여 구축되었습니다. 다가오는 Yahoo Mail은 React에서 재구축되고 있습니다. 어떤 다른 예가 필요합니까? 지금 React를 사용해 보세요.