etc./StackOverFlow

jQuery 배경이 있는 경우 "AngularJS에서 생각하기"가 필요합니까? [닫은]

청렴결백한 만능 재주꾼 2021. 10. 1. 03:19
반응형

질문자 :Mark Rajcok


jQuery 에서 클라이언트 측 응용 프로그램을 개발하는 데 익숙 하지만 이제 AngularJS 사용을 시작하고 싶습니다. 필요한 패러다임 전환을 설명할 수 있습니까? 다음은 답변을 구성하는 데 도움이 될 수 있는 몇 가지 질문입니다.

  • 클라이언트 측 웹 애플리케이션을 다르게 설계하고 설계하려면 어떻게 해야 합니까? 가장 큰 차이점은 무엇입니까?
  • 무엇을 하거나 사용을 중단해야 하나요? 대신 무엇을 시작/사용해야 합니까?
  • 서버 측 고려 사항/제한 사항이 있습니까?

jQueryAngularJS 간의 자세한 비교를 찾고 있지 않습니다.



1. 페이지를 디자인한 다음 DOM 조작으로 변경하지 마십시오.

jQuery에서는 페이지를 디자인한 다음 동적으로 만듭니다. jQuery가 증강을 위해 설계되었고 그 단순한 전제에서 엄청나게 성장했기 때문입니다.

그러나 AngularJS에서는 아키텍처를 염두에 두고 처음부터 시작해야 합니다. "나는 DOM의 이 부분을 가지고 있고 그것을 X로 만들고 싶다"라고 생각하는 것으로 시작하는 대신에, 당신은 당신이 성취하고자 하는 것부터 시작해서 당신의 애플리케이션을 디자인하고, 마지막으로 당신의 뷰를 디자인해야 합니다.

2. AngularJS로 jQuery를 확장하지 마세요

마찬가지로 jQuery가 X, Y 및 Z를 수행한다는 생각으로 시작하지 마십시오. 모델과 컨트롤러를 위해 그 위에 AngularJS를 추가하겠습니다. 이것은 당신이 막 시작할 때 정말 유혹적입니다. 그래서 저는 항상 새로운 AngularJS 개발자가 "Angular Way" 작업에 익숙해질 때까지 jQuery를 전혀 사용하지 말라고 항상 권장합니다.

여기와 메일링 리스트에 있는 많은 개발자들이 150 또는 200줄의 코드로 된 jQuery 플러그인을 사용하여 이러한 정교한 솔루션을 만든 다음 혼란스럽고 복잡한 $apply 그러나 그들은 결국 그것을 작동시킵니다! 문제는 대부분의 경우 jQuery 플러그인이 AngularJS에서 코드의 일부로 다시 작성될 수 있다는 것입니다.

결론은 다음과 같습니다. 솔루션을 만들 때 먼저 "AngularJS에서 생각하십시오". 해결책이 생각나지 않으면 커뮤니티에 문의하세요. 이 모든 후 더 쉬운 해결책이없는 경우, 다음 jQuery를 도달 주시기 바랍니다. 그러나 jQuery가 버팀목이 되도록 두지 마십시오. 그렇지 않으면 AngularJS를 마스터하지 못할 것입니다.

3. 항상 아키텍처 측면에서 생각하십시오.

먼저 단일 페이지 응용 프로그램응용 프로그램이라는 것을 알아야 합니다. 웹페이지가 아닙니다. 따라서 우리는 클라이언트 측 개발자처럼 생각하는 것 외에 서버 측 개발자처럼 생각해야 합니다. 우리는 애플리케이션을 확장 가능하고 테스트 가능한 개별 구성 요소로 나누는 방법에 대해 생각해야 합니다.

그러면 어떻게 합니까? "AngularJS로 생각"하는 방법은 무엇입니까? 다음은 jQuery와 대조되는 몇 가지 일반적인 원칙입니다.

보기는 "공식 기록"

jQuery에서는 프로그래밍 방식으로 보기를 변경합니다. ul 로 정의된 드롭다운 메뉴를 가질 수 있습니다.

 <ul class="main-menu"> <li class="active"> <a href="#/home">Home</a> </li> <li> <a href="#/menu1">Menu 1</a> <ul> <li><a href="#/sm1">Submenu 1</a></li> <li><a href="#/sm2">Submenu 2</a></li> <li><a href="#/sm3">Submenu 3</a></li> </ul> </li> <li> <a href="#/home">Menu 2</a> </li> </ul>

jQuery의 애플리케이션 로직에서 다음과 같이 활성화합니다.

 $('.main-menu').dropdownMenu();

뷰만 보면 여기에 어떤 기능이 있는지 즉시 명확하지 않습니다. 작은 응용 프로그램의 경우 괜찮습니다. 그러나 중요하지 않은 응용 프로그램의 경우 상황이 빠르게 혼란스러워지고 유지 관리하기 어렵습니다.

그러나 AngularJS에서 보기는 보기 기반 기능의 공식 기록입니다. ul 선언은 다음과 같습니다.

 <ul class="main-menu" dropdown-menu> ... </ul>

이 둘은 같은 일을 하지만 AngularJS 버전에서는 템플릿을 보고 있는 사람이라면 누구나 무슨 일이 일어날지 압니다. 개발 팀의 새로운 구성원이 보드에 올 때마다 그녀는 이것을 보고 dropdownMenu 라는 지시문 이 작동하고 있음을 알 수 있습니다. 그녀는 정답을 직감하거나 코드를 샅샅이 뒤질 필요가 없습니다. 보기는 우리에게 무슨 일이 일어나기로 되어 있는지 말해주었습니다. 훨씬 깨끗합니다.

AngularJS를 처음 접하는 개발자는 종종 다음과 같은 질문을 합니다. 특정 종류의 모든 링크를 찾고 해당 링크에 지시문을 추가하는 방법은 무엇입니까? 개발자는 우리가 대답할 때 항상 당황합니다. 당신은 그렇지 않습니다. 그러나 그렇게 하지 않는 이유는 이것이 절반은 jQuery, 절반은 AngularJS와 같으며 좋지 않기 때문입니다. 여기서 문제는 개발자가 AngularJS 컨텍스트에서 "jQuery를 수행"하려고 한다는 것입니다. 그것은 결코 잘 작동하지 않을 것입니다. 보기 공식 기록입니다. 지시문(아래에서 자세히 설명) 외부에서는 DOM을 절대 변경하지 않습니다. 그리고 지시문이 뷰에 적용되므로 의도가 명확합니다.

기억하십시오: 디자인한 다음 마크업하지 마십시오. 설계한 다음 설계해야 합니다.

데이터 바인딩

이것은 지금까지 AngularJS의 가장 멋진 기능 중 하나이며 이전 섹션에서 언급한 종류의 DOM 조작을 수행할 필요가 없습니다. AngularJS는 뷰를 자동으로 업데이트하므로 그렇게 할 필요가 없습니다! jQuery에서는 이벤트에 응답한 다음 콘텐츠를 업데이트합니다. 다음과 같은 것:

 $.ajax({ url: '/myEndpoint.json', success: function ( data, status ) { $('ul#log').append('<li>Data Received!</li>'); } });

다음과 같은 보기의 경우:

 <ul class="messages" id="log"> </ul>

혼합 문제 외에도 이전에 언급한 의도를 의미하는 것과 동일한 문제가 있습니다. 그러나 더 중요한 것은 DOM 노드를 수동으로 참조하고 업데이트해야 한다는 것입니다. 그리고 로그 항목을 삭제하려면 DOM에 대해서도 코딩해야 합니다. DOM과 별도로 로직을 어떻게 테스트합니까? 프레젠테이션을 변경하려면 어떻게 해야 합니까?

이것은 약간 지저분하고 사소한 것입니다. 그러나 AngularJS에서는 다음과 같이 할 수 있습니다.

 $http( '/myEndpoint.json' ).then( function ( response ) { $scope.log.push( { msg: 'Data Received!' } ); });

그리고 우리의 관점은 다음과 같을 수 있습니다.

 <ul class="messages"> <li ng-repeat="entry in log">{{ entry.msg }}</li> </ul>

그러나 문제에 대해 우리의 견해는 다음과 같을 수 있습니다.

 <div class="messages"> <div class="alert" ng-repeat="entry in log"> {{ entry.msg }} </div> </div>

이제 정렬되지 않은 목록을 사용하는 대신 부트스트랩 경고 상자를 사용하고 있습니다. 그리고 컨트롤러 코드를 변경할 필요가 없었습니다! 그러나 더 중요한 것은 로그가 업데이트되는 위치방법에 관계없이 보기도 변경된다는 것입니다. 자동으로. 정돈 된!

여기에 표시하지는 않았지만 데이터 바인딩은 양방향입니다. <input ng-model="entry.msg" /> 를 수행하여 보기에서 편집할 수도 있습니다. 그리고 많은 기쁨이 있었습니다.

고유 모델 레이어

jQuery에서 DOM은 일종의 모델과 같습니다. 그러나 AngularJS에는 뷰와 완전히 독립적으로 원하는 방식으로 관리할 수 있는 별도의 모델 레이어가 있습니다. 이것은 위의 데이터 바인딩에 도움이 되고, 관심사의 분리를 유지하고, 훨씬 더 큰 테스트 가능성을 도입합니다. 다른 답변에서 이 점을 언급했으므로 그대로 두겠습니다.

우려의 분리

그리고 위의 모든 사항은 이 중요한 주제와 연결되어 있습니다. 관심사를 분리하십시오. 당신의 견해는 (대부분의 경우) 일어날 일에 대한 공식 기록으로 작용합니다. 귀하의 모델은 귀하의 데이터를 나타냅니다. 재사용 가능한 작업을 수행하는 서비스 계층이 있습니다. DOM 조작을 수행하고 지시문으로 보기를 보강합니다. 컨트롤러로 모두 함께 붙입니다. 이것은 다른 답변에서도 언급되었으며 내가 추가할 유일한 것은 테스트 가능성과 관련이 있습니다. 이에 대해서는 아래의 다른 섹션에서 논의합니다.

의존성 주입

관심사 분리에 도움이 되는 것은 의존성 주입 (DI)입니다. 서버 측 언어( Java 에서 PHP로 )에서 온 경우 이미 이 개념에 익숙할 것입니다. . 하지만 그렇지 않습니다. :-)

넓은 관점에서 DI는 구성 요소를 매우 자유롭게 선언할 수 있고 다른 구성 요소에서 인스턴스를 요청하면 부여된다는 의미입니다. 로딩 순서나 파일 위치 등에 대해 알 필요가 없습니다. 전원이 즉시 표시되지 않을 수 있지만 테스트라는 하나의 (일반적인) 예만 제공하겠습니다.

애플리케이션에서 REST API를 통해 서버 측 스토리지를 구현하고 애플리케이션 상태에 따라 로컬 스토리지도 구현하는 서비스가 필요하다고 가정해 보겠습니다. 컨트롤러에서 테스트를 실행할 때 서버와 통신할 필요가 없습니다 . 결국 컨트롤러를 테스트하는 것입니다. 원래 구성 요소와 같은 이름의 모의 서비스를 추가하기만 하면 인젝터가 컨트롤러가 가짜 서비스를 자동으로 가져오도록 합니다. 컨트롤러는 차이를 알 수 없고 알 필요도 없습니다.

테스트 얘기를 하자면...

4. 테스트 주도 개발 - 항상

이것은 아키텍처에 대한 섹션 3의 일부이지만 매우 중요하므로 자체 최상위 섹션으로 지정합니다.

당신이 보거나, 사용하거나, 작성한 모든 jQuery 플러그인 중에서 테스트 스위트가 포함된 플러그인은 몇 개입니까? jQuery가 이에 적합하지 않기 때문에 많지 않습니다. 하지만 AngularJS는 그렇습니다.

jQuery에서 테스트하는 유일한 방법은 종종 테스트에서 DOM 조작을 수행할 수 있는 샘플/데모 페이지를 사용하여 구성 요소를 독립적으로 만드는 것입니다. 따라서 구성 요소를 별도로 개발한 다음 응용 프로그램에 통합해야 합니다. 얼마나 불편한가! 대부분의 경우 jQuery로 개발할 때 테스트 주도 개발 대신 반복적 개발을 선택합니다. 누가 우리를 비난할 수 있겠습니까?

하지만 관심사가 분리되어 있기 때문에 AngularJS에서 테스트 주도 개발을 반복적으로 수행할 수 있습니다! 예를 들어, 메뉴에 현재 경로가 무엇인지 나타내기 위해 매우 간단한 지시문을 원한다고 가정해 봅시다. 애플리케이션의 관점에서 원하는 것을 선언할 수 있습니다.

 <a href="/hello" when-active>Hello</a>

자, 이제 존재하지 않는 when-active 지시문에 대한 테스트를 작성할 수 있습니다.

 it( 'should add "active" when the route changes', inject(function() { var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope ); $location.path('/not-matching'); expect( elm.hasClass('active') ).toBeFalsey(); $location.path( '/hello' ); expect( elm.hasClass('active') ).toBeTruthy(); }));

그리고 테스트를 실행할 때 실패했음을 확인할 수 있습니다. 이제 지시문을 만들어야 합니다.

 .directive( 'whenActive', function ( $location ) { return { scope: true, link: function ( scope, element, attrs ) { scope.$on( '$routeChangeSuccess', function () { if ( $location.path() == element.attr( 'href' ) ) { element.addClass( 'active' ); } else { element.removeClass( 'active' ); } }); } }; });

이제 테스트를 통과 하고 메뉴가 요청한 대로 작동합니다. 우리의 개발은 반복과 테스트 주도 모두이다. 사악한 - 멋진.

5. 개념적으로 지시문은 jQuery로 패키징 되지 않습니다.

"디렉티브에서 DOM 조작만 수행"이라는 말을 자주 듣게 됩니다. 이것은 필수입니다. 예의 바르게 대하십시오!

하지만 조금 더 깊이 들어가 보자...

일부 지시문은 이미 보기에 있는 것을 장식 ngClass 생각) 때로는 DOM 조작을 바로 수행한 다음 기본적으로 완료됩니다. 그러나 지시문이 "위젯"과 같으며 템플릿이 있는 경우 관심사 분리 도 존중해야 합니다. 즉, 템플릿 링크 및 컨트롤러 기능에서의 구현과 크게 독립적이어야 합니다.

AngularJS는 이를 매우 쉽게 만드는 전체 도구 세트와 함께 제공됩니다. ngClass 를 사용하면 클래스를 동적으로 업데이트할 수 있습니다. ngModel 은 양방향 데이터 바인딩을 허용합니다. ngShowngHide 프로그래밍 방식으로 요소를 표시하거나 숨깁니다. 우리가 직접 작성하는 것을 포함하여 훨씬 더 많습니다. 즉, DOM 조작 없이 모든 종류의 멋진 작업을 수행할 수 있습니다. DOM 조작이 적을수록 지시문이 테스트하기 쉽고 스타일 지정이 더 쉽고 미래에 변경이 더 쉽고 재사용 및 배포가 더 쉬워집니다.

AngularJS를 처음 접하는 많은 개발자들이 많은 jQuery를 던질 장소로 지시문을 사용하는 것을 봅니다. 다시 말해, 그들은 "컨트롤러에서 DOM 조작을 할 수 없기 때문에 그 코드를 지시문에 넣을 것"이라고 생각합니다. 확실히 훨씬 낫긴 하지만 여전히 잘못된 경우가 많습니다.

우리는 우리가 지시어에 그것을 넣어 경우에도 3 절에 프로그램 된 로거의 생각, 우리는 여전히 그에게 "각도의 방법"을 수행 할. 여전히 DOM 조작이 필요하지 않습니다! DOM 조작이 필요한 경우가 많이 있지만 생각보다 훨씬 드뭅니다! 애플리케이션의 어느 곳에서든 DOM 조작을 수행하기 전에 정말로 필요한지 자문해 보십시오. 더 좋은 방법이 있을 수 있습니다.

다음은 내가 가장 자주 보는 패턴을 보여주는 빠른 예입니다. 우리는 토글 가능한 버튼을 원합니다. (참고: 이 예제는 정확히 같은 방식으로 해결되는 더 복잡한 경우를 나타내기 위해 약간 인위적이고 장황합니다.)

 .directive( 'myDirective', function () { return { template: '<a class="btn">Toggle me!</a>', link: function ( scope, element, attrs ) { var on = false; $(element).click( function () { on = !on; $(element).toggleClass('active', on); }); } }; });

여기에는 몇 가지 잘못된 점이 있습니다.

  1. 첫째, jQuery는 결코 필요하지 않았습니다. 여기서 jQuery가 필요한 작업은 전혀 없었습니다!
  2. 둘째, 페이지에 이미 jQuery가 있더라도 여기에서 사용할 이유가 없습니다. angular.element 를 사용할 수 있으며 jQuery가 없는 프로젝트에 놓을 때 구성 요소가 계속 작동합니다.
  3. 셋째, 이 지시문이 작동하려면 jQuery가 필요하다고 가정하더라도 angular.element ) 는 로드된 경우 항상 jQuery를 사용합니다! $ 사용할 필요가 없습니다. angular.element 만 사용할 수 있습니다.
  4. 넷째, 세 번째와 밀접하게 관련된 것은 jqLite 요소가 $ 로 래핑될 필요가 없다는 것입니다. link 함수에 전달되는 element 는 이미 jQuery 요소일 것입니다!
  5. 그리고 다섯 번째, 이전 섹션에서 언급한 것처럼 템플릿 항목을 로직에 혼합하는 이유는 무엇입니까?

이 지시문은 다음과 같이 훨씬 더 간단하게 다시 작성할 수 있습니다(매우 복잡한 경우에도!).

 .directive( 'myDirective', function () { return { scope: true, template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>', link: function ( scope, element, attrs ) { scope.on = false; scope.toggle = function () { scope.on = !scope.on; }; } }; });

다시 말하지만, 템플릿 항목은 템플릿에 있으므로 귀하(또는 귀하의 사용자)는 필요한 스타일을 충족하는 것으로 쉽게 교체할 수 있으며 논리 를 건드릴 필요가 없습니다. 재사용성 - 붐!

테스트와 같은 다른 모든 이점은 여전히 있습니다. 쉽습니다! 템플릿에 무엇이 있든 지시어의 내부 API는 절대 건드리지 않으므로 리팩토링이 쉽습니다. 디렉티브를 건드리지 않고 원하는 만큼 템플릿을 변경할 수 있습니다. 무엇을 변경하든 테스트는 여전히 통과합니다.

w00t!

따라서 지시문이 jQuery와 유사한 함수의 모음이 아니라면 무엇입니까? 지시문은 실제로 HTML의 확장입니다 . HTML이 필요한 작업을 수행하지 않는 경우 이를 수행하는 지시문을 작성한 다음 HTML의 일부인 것처럼 사용합니다.

다시 말해, ngClass ngClick 수행하지 않는 경우 팀이 ngClick , ngClass , et al.

요약

jQuery를 사용하지 마십시오. 포함하지 마십시오. 그것은 당신을 다시 잡아 것입니다. 그리고 jQuery에서 해결하는 방법을 이미 알고 있다고 생각하는 문제에 도달하면 $ 도달하기 전에 AngularJS의 범위 내에서 해결하는 방법에 대해 생각하십시오. 모르면 물어봐! 20번 중 19번, 가장 좋은 방법은 jQuery가 필요하지 않으며 jQuery로 해결하려고 하면 더 많은 작업이 수행됩니다.


Josh David Miller

명령 → 선언

jQuery에서 선택기 는 DOM 요소를 찾은 다음 이벤트 핸들러를 바인딩/등록하는 데 사용됩니다. 이벤트가 트리거되면 해당 (필수) 코드가 실행되어 DOM을 업데이트/변경합니다.

AngularJS에서는 DOM 요소보다 에 대해 생각하고 싶습니다. 보기는 AngularJS 지시문 을 포함하는 (선언적) HTML입니다. 지시문은 우리를 위해 뒤에서 이벤트 핸들러를 설정하고 동적 데이터 바인딩을 제공합니다. 선택기는 거의 사용되지 않으므로 ID(및 일부 유형의 클래스)에 대한 필요성이 크게 줄어듭니다. 보기는 범위를 통해 모델 에 연결됩니다. 보기는 모델의 투영입니다. 이벤트는 모델(즉, 데이터, 범위 속성)을 변경하고 해당 모델을 투영하는 보기는 "자동으로" 업데이트됩니다.

AngularJS에서는 데이터를 보유하는 jQuery 선택 DOM 요소보다는 모델에 대해 생각하십시오. 사용자가 보는 것을 조작하기 위해 콜백을 등록하기 보다는 보기를 해당 모델의 투영으로 생각하십시오.

우려의 분리

jQuery는 눈에 거슬리지 않는 JavaScript를 사용합니다. 동작(JavaScript)은 구조(HTML)와 분리됩니다.

AngularJS는 컨트롤러 와 지시문(각각 자체 컨트롤러 및/또는 컴파일 및 연결 기능을 가질 수 있음)을 사용하여 뷰/구조(HTML)에서 동작을 제거합니다. Angular에는 애플리케이션을 분리/구성하는 데 도움 이 되는 서비스필터도 있습니다.

https://stackoverflow.com/a/14346528/215945도 참조하십시오.

애플리케이션 디자인

AngularJS 애플리케이션을 설계하는 한 가지 접근 방식:

  1. 당신의 모델에 대해 생각해보십시오. 해당 모델에 대한 서비스 또는 고유한 JavaScript 개체를 만듭니다.
  2. 당신의 모델, 즉 당신의 관점을 어떻게 표현하고 싶은지 생각해보세요. 동적 데이터 바인딩을 가져오는 데 필요한 지시문을 사용하여 각 보기에 대한 HTML 템플릿을 만듭니다.
  3. 컨트롤러를 각 보기에 연결합니다(ng-view 및 라우팅 또는 ng-controller 사용). 컨트롤러가 뷰가 작업을 수행하는 데 필요한 모델 데이터만 찾거나 가져오도록 합니다. 컨트롤러를 가능한 한 얇게 만드십시오.

프로토타입 상속

JavaScript 프로토타입 상속이 작동하는 방식을 몰라도 jQuery로 많은 일을 할 수 있습니다. AngularJS 애플리케이션을 개발할 때 JavaScript 상속에 대해 잘 이해하고 있다면 몇 가지 일반적인 함정을 피할 수 있습니다. 추천 자료: AngularJS에서 범위 프로토타입/프로토타입 상속의 뉘앙스는 무엇입니까?


Mark Rajcok

AngularJS 대 jQuery

AngularJS와 jQuery는 매우 다른 이데올로기를 채택합니다. jQuery를 사용 중이라면 놀라운 차이점을 발견할 수 있습니다. Angular는 당신을 화나게 할 수 있습니다.

이것은 정상입니다. 통과해야 합니다. 각도는 그만한 가치가 있습니다.

큰 차이(TLDR)

jQuery는 DOM의 임의 비트를 선택하고 임시로 변경할 수 있는 툴킷을 제공합니다. 당신은 당신이 좋아하는 거의 모든 것을 조각으로 할 수 있습니다.

AngularJS는 대신 컴파일러 를 제공합니다.

이것이 의미하는 바는 AngularJS가 위에서 아래로 전체 DOM을 읽고 이를 코드로, 말 그대로 컴파일러에 대한 명령으로 취급한다는 것입니다. DOM을 탐색할 때 AngularJS 컴파일러에게 어떻게 동작하고 무엇을 해야 하는지 알려주는 특정 지시문(컴파일러 지시문)을 찾습니다. 지시문은 속성, 태그, 클래스 또는 주석과 일치시킬 수 있는 JavaScript로 가득 찬 작은 개체입니다.

Angular 컴파일러는 DOM의 일부가 특정 지시문과 일치한다고 판단하면 지시문 함수를 호출하여 DOM 요소, 모든 속성, 현재 $scope(로컬 변수 저장소) 및 기타 유용한 비트를 전달합니다. 이러한 속성은 지시문에 의해 해석될 수 있는 표현식을 포함할 수 있으며 렌더링 방법과 자체를 다시 그려야 하는 시기를 지시합니다.

그런 다음 지시문은 컨트롤러, 서비스 등과 같은 추가 Angular 구성 요소를 가져올 수 있습니다. 컴파일러의 맨 아래에서 나오는 것은 완벽하게 구성된 웹 응용 프로그램이며, 연결되어 바로 사용할 수 있습니다.

이것은 Angular가 템플릿 기반이라는 것을 의미합니다 . 템플릿은 그 반대가 아니라 JavaScript를 구동합니다. 이것은 역할의 근본적인 역전이며 지난 10여 년 동안 우리가 작성해 온 눈에 거슬리지 않는 JavaScript와 완전히 반대입니다. 익숙해지는 데 시간이 걸릴 수 있습니다.

이것이 지나치게 규범적이고 제한적인 것처럼 들린다면 진실에서 더 멀어질 수는 없습니다. AngularJS는 HTML을 코드로 취급하기 때문에 웹 애플리케이션에서 HTML 수준의 세분성 을 얻을 수 있습니다. 모든 것이 가능하며 몇 가지 개념적 도약을 하면 대부분의 일이 놀라울 정도로 쉽습니다.

핵심 내용으로 들어가 보겠습니다.

먼저 Angular는 jQuery를 대체하지 않습니다.

Angular와 jQuery는 다른 일을 합니다. AngularJS는 웹 애플리케이션을 생성하기 위한 도구 세트를 제공합니다. jQuery는 주로 DOM을 수정하기 위한 도구를 제공합니다. 페이지에 jQuery가 있으면 AngularJS가 자동으로 사용합니다. 그렇지 않은 경우 AngularJS는 축소되었지만 여전히 완벽하게 사용 가능한 jQuery 버전인 jQuery Lite와 함께 제공됩니다.

Misko는 jQuery를 좋아하고 당신이 그것을 사용하는 것을 반대하지 않습니다. 그러나 진행하면서 범위, 템플릿 및 지시문의 조합을 사용하여 거의 모든 작업을 완료할 수 있다는 것을 알게 될 것이며 코드가 더 분리되고 구성 가능하며 더 많아지기 때문에 가능한 경우 이 워크플로를 선호해야 합니다. 모난.

jQuery를 사용하는 경우 여기저기에 뿌릴 필요가 없습니다. AngularJS에서 DOM 조작을 위한 올바른 위치는 지시문에 있습니다. 이에 대한 자세한 내용은 나중에 설명합니다.

선택자가 있는 눈에 잘 띄지 않는 JavaScript와 선언적 템플릿

jQuery는 일반적으로 눈에 거슬리지 않게 적용됩니다. JavaScript 코드는 머리글(또는 바닥글)에 연결되어 있으며 이것이 언급되는 유일한 위치입니다. 선택기를 사용하여 페이지의 일부를 선택하고 해당 부분을 수정하는 플러그인을 작성합니다.

JavaScript가 제어됩니다. HTML은 완전히 독립적인 존재입니다. 귀하의 HTML은 JavaScript 없이도 의미를 유지합니다. Onclick 속성은 매우 나쁜 습관입니다.

AngularJS에 대해 가장 먼저 알 수 있는 것 중 하나는 사용자 정의 속성이 어디에나 있다는 것 입니다. HTML은 본질적으로 스테로이드의 onClick 속성인 ng 속성으로 가득 차 있습니다. 이것은 지시문(컴파일러 지시문)이며 템플릿이 모델에 연결되는 주요 방법 중 하나입니다.

이것을 처음 봤을 때 AngularJS를 구식의 방해가 되는 JavaScript로 작성하고 싶은 유혹을 받을 수 있습니다(처음에 했던 것처럼). 사실 AngularJS는 이러한 규칙을 따르지 않습니다. AngularJS에서 HTML5는 템플릿입니다. AngularJS에 의해 컴파일되어 웹 페이지를 생성합니다.

이것이 첫 번째 큰 차이점입니다. jQuery에게 웹 페이지는 조작해야 하는 DOM입니다. AngularJS에게 HTML은 컴파일할 코드입니다. AngularJS는 전체 웹 페이지를 읽고 내장 컴파일러를 사용하여 말 그대로 새 웹 페이지로 컴파일합니다.

템플릿은 선언적이어야 합니다. 읽기만 해도 그 의미가 명확해야 합니다. 의미 있는 이름을 가진 사용자 정의 속성을 사용합니다. 의미 있는 이름으로 다시 새로운 HTML 요소를 구성합니다. 최소한의 HTML 지식과 코딩 기술이 없는 디자이너는 AngularJS 템플릿을 읽고 수행하는 작업을 이해할 수 있습니다. 그 또는 그녀는 수정할 수 있습니다. 이것이 Angular 방식입니다.

템플릿은 운전석에 있습니다.

AngularJS를 시작하고 튜토리얼을 실행할 때 스스로에게 던진 첫 번째 질문 중 하나는 "내 코드는 어디에 있습니까?"입니다. . 저는 JavaScript를 작성하지 않았지만 이 모든 동작이 있습니다. 답은 분명합니다. AngularJS는 DOM을 컴파일하기 때문에 AngularJS는 HTML을 코드로 취급합니다. 많은 간단한 경우에 템플릿을 작성하고 AngularJS가 이를 응용 프로그램으로 컴파일하도록 하는 것으로 충분합니다.

템플릿이 애플리케이션을 구동합니다. DSL 로 취급됩니다. AngularJS 구성 요소를 작성하면 AngularJS가 템플릿 구조에 따라 적절한 시간에 구성 요소를 가져와서 사용할 수 있도록 합니다. 이것은 템플릿이 출력만을 위한 표준 MVC 패턴과 매우 다릅니다.

예를 들어 Ruby on Rails 보다 XSLT 와 더 유사합니다.

이것은 어느 정도 익숙해져야 하는 급진적인 통제 역전입니다.

JavaScript에서 애플리케이션을 구동하려는 시도를 중지하십시오. 템플릿이 애플리케이션을 구동하도록 하고 AngularJS가 구성 요소를 함께 연결하도록 합니다. 이것은 또한 Angular 방식입니다.

시맨틱 HTML 대 시맨틱 모델

jQuery를 사용하면 HTML 페이지에 의미 있는 의미 있는 콘텐츠가 포함되어야 합니다. JavaScript가 꺼져 있는 경우(사용자 또는 검색 엔진에 의해) 귀하의 콘텐츠는 계속 액세스할 수 있습니다.

AngularJS는 HTML 페이지를 템플릿으로 취급하기 때문입니다. 콘텐츠는 일반적으로 궁극적으로 API에서 제공되는 모델에 저장되므로 템플릿은 의미가 없어야 합니다. AngularJS는 시맨틱 웹 페이지를 생성하기 위해 모델과 함께 DOM을 컴파일합니다.

HTML 소스는 더 이상 의미가 없습니다. 대신 API와 컴파일된 DOM이 의미가 있습니다.

AngularJS에서 의미는 모델에 산다는 것을 의미하며 HTML은 단지 표시를 위한 템플릿일 뿐입니다.

이 시점에서 SEO 및 접근성에 관한 모든 종류의 질문이 있을 수 있습니다. 여기에 미해결 문제가 있습니다. 이제 대부분의 화면 판독기가 JavaScript를 구문 분석합니다. 검색 엔진은 AJAX 처리된 콘텐츠도 색인화할 수 있습니다. 그럼에도 불구하고 pushstate URL을 사용하고 있고 적절한 사이트맵이 있는지 확인하고 싶을 것입니다. 문제에 대한 논의는 여기를 참조하십시오: https://stackoverflow.com/a/23245379/687677

관심 분리(SOC) 대 MVC

SOC(Separation of Interest)는 SEO, 접근성 및 브라우저 비호환성을 포함한 다양한 이유로 웹 개발의 수년 동안 성장한 패턴입니다. 다음과 같습니다.

  1. HTML - 의미론적 의미. HTML은 독립적이어야 합니다.
  2. CSS - CSS 없이도 페이지를 읽을 수 있습니다.
  3. JavaScript - 스크립트 없이 동작이 그대로 유지됩니다.

다시 말하지만, AngularJS는 규칙에 따라 작동하지 않습니다. 획에서 AngularJS는 10년 동안 받아들여진 지혜를 없애고 대신 템플릿이 더 이상 의미 체계가 아닌 MVC 패턴을 구현합니다.

다음과 같습니다.

  1. 모델 - 귀하의 모델에는 의미론적 데이터가 포함됩니다. 모델은 일반적으로 JSON 객체입니다. 모델은 $scope라는 개체의 속성으로 존재합니다. 템플릿이 액세스할 수 있는 $scope에 편리한 유틸리티 기능을 저장할 수도 있습니다.
  2. 보기 - 보기는 HTML로 작성됩니다. 데이터가 모델에 있기 때문에 보기는 일반적으로 의미가 없습니다.
  3. 컨트롤러 - 컨트롤러는 뷰를 모델에 연결하는 JavaScript 기능입니다. 그 기능은 $scope를 초기화하는 것입니다. 애플리케이션에 따라 컨트롤러를 생성해야 할 수도 있고 생성하지 않을 수도 있습니다. 한 페이지에 많은 컨트롤러가 있을 수 있습니다.

MVC와 SOC는 같은 규모의 반대쪽 끝에 있지 않고 완전히 다른 축에 있습니다. SOC는 AngularJS 컨텍스트에서 의미가 없습니다. 잊어버리고 진행해야 합니다.

나처럼 브라우저 전쟁을 겪었다면 이 아이디어가 상당히 불쾌할 수 있습니다. 그만한 가치가 있을 거에요. 약속해요.

플러그인 대 지시문

플러그인은 jQuery를 확장합니다. AngularJS 지시문은 브라우저의 기능을 확장합니다.

jQuery에서 우리는 jQuery.prototype에 기능을 추가하여 플러그인을 정의합니다. 그런 다음 요소를 선택하고 결과에서 플러그인을 호출하여 이를 DOM에 연결합니다. 아이디어는 jQuery의 기능을 확장하는 것입니다.

예를 들어 페이지에 캐러셀이 필요한 경우 nav 요소로 래핑된 순서 없는 그림 목록을 정의할 수 있습니다. 그런 다음 jQuery를 작성하여 페이지에서 목록을 선택하고 슬라이딩 애니메이션을 수행하기 위해 시간 초과가 있는 갤러리로 스타일을 다시 지정할 수 있습니다.

AngularJS에서는 지시문을 정의합니다. 지시자는 JSON 객체를 반환하는 함수입니다. 이 객체는 AngularJS가 찾아야 할 DOM 요소와 변경 사항을 알려줍니다. 지시문은 사용자가 만든 속성이나 요소를 사용하여 템플릿에 연결됩니다. 아이디어는 새로운 속성과 요소로 HTML의 기능을 확장하는 것입니다.

AngularJS 방식은 기본적으로 보이는 HTML의 기능을 확장하는 것입니다. 사용자 정의 속성 및 요소로 확장된 HTML처럼 보이는 HTML을 작성해야 합니다.

캐러셀을 원하면 <carousel /> 요소를 사용한 다음 템플릿을 가져오는 지시문을 정의하고 해당 빨판을 작동시키십시오.

많은 작은 지시문과 구성 스위치가 있는 큰 플러그인

jQuery의 경향은 라이트박스와 같은 큰 플러그인을 작성한 다음 수많은 값과 옵션을 전달하여 구성하는 것입니다.

이것은 AngularJS의 실수입니다.

드롭다운을 예로 들어 보겠습니다. 드롭다운 플러그인을 작성할 때 클릭 핸들러에서 코딩하고 싶을 수 있습니다. 아마도 위 또는 아래에 있는 갈매기 모양에 추가하는 기능, 펼쳐진 요소의 클래스 변경, 메뉴 표시 숨기기, 모든 유용한 것들입니다.

당신이 작은 변화를 만들고 싶을 때까지.

마우스 오버 시 펼치고 싶은 메뉴가 있다고 가정해 보겠습니다. 자, 이제 문제가 생겼습니다. 플러그인이 클릭 핸들러에 연결되어 있으므로 이 특정 경우에 다르게 작동하도록 구성 옵션을 추가해야 합니다.

AngularJS에서는 더 작은 지시문을 작성합니다. 우리의 드롭다운 지시문은 엄청나게 작을 것입니다. 접힌 상태를 유지하고 fold(), expand() 또는 toggle() 메서드를 제공할 수 있습니다. 이러한 메서드는 상태를 보유하는 부울인 $scope.menu.visible을 업데이트하기만 하면 됩니다.

이제 템플릿에서 이것을 연결할 수 있습니다.

 <a ng-click="toggle()">Menu</a> <ul ng-show="menu.visible"> ... </ul>

마우스 오버 시 업데이트가 필요하십니까?

 <a ng-mouseenter="unfold()" ng-mouseleave="fold()">Menu</a> <ul ng-show="menu.visible"> ... </ul>

템플릿은 애플리케이션을 구동하므로 HTML 수준의 세분성을 얻을 수 있습니다. 케이스 바이 케이스 예외를 만들고 싶다면 템플릿을 사용하면 쉽게 할 수 있습니다.

클로저 대 $scope

JQuery 플러그인은 클로저에서 생성됩니다. 개인 정보는 해당 폐쇄 내에서 유지됩니다. 해당 클로저 내에서 범위 체인을 유지 관리하는 것은 사용자에게 달려 있습니다. jQuery에 의해 플러그인에 전달된 DOM 노드 세트와 클로저에 정의된 모든 로컬 변수 및 정의한 전역 변수에만 실제로 액세스할 수 있습니다. 이것은 플러그인이 상당히 독립적이라는 것을 의미합니다. 이것은 좋은 일이지만 전체 응용 프로그램을 만들 때 제한적일 수 있습니다. 동적 페이지의 섹션 간에 데이터를 전달하려는 시도는 번거로운 작업이 됩니다.

AngularJS에는 $scope 객체가 있습니다. 이들은 모델을 저장하는 AngularJS에서 만들고 유지 관리하는 특수 객체입니다. 특정 지시문은 기본적으로 JavaScript 프로토타입 상속을 사용하여 래핑 $scope에서 상속하는 새 $scope를 생성합니다. $scope 개체는 컨트롤러와 보기에서 액세스할 수 있습니다.

이것은 영리한 부분입니다. $scope 상속의 구조는 대략 DOM의 구조를 따르기 때문에 요소는 자체 범위와 포함하는 모든 범위에 원활하게 액세스할 수 있습니다.

이렇게 하면 데이터를 전달하고 적절한 수준에서 데이터를 저장하는 것이 훨씬 쉬워집니다. 드롭다운이 펼쳐진 경우 드롭다운 $scope만 이에 대해 알아야 합니다. 사용자가 기본 설정을 업데이트하면 전역 $scope를 업데이트할 수 있으며 사용자 기본 설정을 수신하는 모든 중첩 범위는 자동으로 경고를 받습니다.

이것은 복잡하게 들릴 수 있습니다. 사실, 일단 긴장을 풀면 비행하는 것과 같습니다. $scope 객체를 생성할 필요가 없습니다. AngularJS는 템플릿 계층을 기반으로 정확하고 적절하게 이를 인스턴스화하고 구성합니다. 그런 다음 AngularJS는 종속성 주입의 마법을 사용하여 구성 요소에서 사용할 수 있도록 합니다(나중에 자세히 설명).

수동 DOM 변경 대 데이터 바인딩

jQuery에서는 모든 DOM 변경을 손으로 수행합니다. 프로그래밍 방식으로 새 DOM 요소를 구성합니다. JSON 배열이 있고 이를 DOM에 넣으려면 HTML을 생성하고 삽입하는 함수를 작성해야 합니다.

AngularJS에서도 이 작업을 수행할 수 있지만 데이터 바인딩을 사용하는 것이 좋습니다. 모델을 변경하면 DOM이 템플릿을 통해 모델에 바인딩되므로 DOM이 자동으로 업데이트하므로 개입이 필요하지 않습니다.

데이터 바인딩은 속성이나 중괄호 구문을 사용하여 템플릿에서 수행되기 때문에 수행하기가 매우 쉽습니다. 이와 관련된 인지 오버헤드가 거의 없으므로 항상 수행하고 있는 자신을 발견하게 될 것입니다.

 <input ng-model="user.name" />

입력 요소를 $scope.user.name 합니다. 입력을 업데이트하면 현재 범위의 값이 업데이트되고 그 반대의 경우도 마찬가지입니다.

비슷하게:

 <p> {{user.name}} </p>

단락에서 사용자 이름을 출력합니다. 라이브 바인딩이므로 $scope.user.name 값이 업데이트되면 템플릿도 업데이트됩니다.

항상 아약스

jQuery에서 Ajax 호출을 만드는 것은 매우 간단하지만 여전히 두 번 생각할 수 있는 문제입니다. 생각해야 할 복잡성이 추가되고 유지 관리해야 할 스크립트가 상당히 많습니다.

AngularJS에서 Ajax는 기본 솔루션이며 거의 눈치 채지 못한 채 항상 발생합니다. ng-include로 템플릿을 포함할 수 있습니다. 가장 간단한 사용자 지정 지시문으로 템플릿을 적용할 수 있습니다. Ajax 호출을 서비스로 래핑하고 GitHub 서비스 또는 Flickr 서비스를 직접 생성하여 놀랍도록 쉽게 액세스할 수 있습니다.

서비스 객체와 도우미 함수

jQuery에서 API에서 피드를 가져오는 것과 같이 DOM과 관련되지 않은 작은 작업을 수행하려는 경우 클로저에서 이를 수행하는 작은 함수를 작성할 수 있습니다. 이는 유효한 솔루션이지만 해당 피드에 자주 액세스하려면 어떻게 해야 할까요? 다른 응용 프로그램에서 해당 코드를 재사용하려면 어떻게 해야 합니까?

AngularJS는 서비스 객체를 제공합니다.

서비스는 기능과 데이터를 포함하는 단순한 개체입니다. 그것들은 항상 싱글톤입니다. 즉, 둘 이상은 절대 있을 수 없습니다. 스택 오버플로 API에 액세스하려는 경우 이를 위한 메서드를 정의 StackOverflowService

장바구니가 있다고 가정해 보겠습니다. 장바구니를 유지하고 항목을 추가 및 제거하는 메서드를 포함하는 ShoppingCartService를 정의할 수 있습니다. 이 서비스는 싱글톤이고 다른 모든 구성 요소에서 공유되기 때문에 장바구니에 써야 하는 모든 개체는 장바구니에서 데이터를 가져올 수 있습니다. 항상 같은 카트입니다.

서비스 객체는 우리가 적합하다고 생각하는 대로 사용하고 재사용할 수 있는 자체 포함된 AngularJS 구성 요소입니다. 함수와 데이터를 포함하는 간단한 JSON 객체입니다. 항상 싱글톤이므로 서비스에 데이터를 한 곳에 저장하면 동일한 서비스를 요청하는 것만으로 해당 데이터를 다른 곳으로 가져올 수 있습니다.

DI(종속성 주입 ) 대 Instatation - 스파게티 제거라고도 함

AngularJS는 의존성을 관리합니다. 객체를 원하는 경우 해당 객체를 참조하기만 하면 AngularJS가 객체를 가져옵니다.

이것을 사용하기 전에는 이것이 얼마나 큰 시간 혜택인지 설명하기 어렵습니다. AngularJS DI와 같은 것은 jQuery 내부에 존재하지 않습니다.

DI는 응용 프로그램을 작성하고 함께 연결하는 대신 각각 문자열로 식별되는 구성 요소 라이브러리를 정의한다는 것을 의미합니다.

Flickr에서 JSON 피드를 가져오는 방법을 정의하는 'FlickrService'라는 구성 요소가 있다고 가정해 보겠습니다. 이제 Flickr에 액세스할 수 있는 컨트롤러를 작성하려면 컨트롤러를 선언할 때 이름으로 'FlickrService'를 참조하기만 하면 됩니다. AngularJS는 구성 요소를 인스턴스화하고 컨트롤러에서 사용할 수 있도록 처리합니다.

예를 들어 다음과 같이 서비스를 정의합니다.

 myApp.service('FlickrService', function() { return { getFeed: function() { // do something here } } });

이제 해당 서비스를 사용하고 싶을 때 다음과 같이 이름으로 참조합니다.

 myApp.controller('myController', ['FlickrService', function(FlickrService) { FlickrService.getFeed() }]);

AngularJS는 컨트롤러를 인스턴스화하는 데 FlickrService 개체가 필요하다는 것을 인식하고 이를 제공합니다.

이것은 배선을 매우 쉽게 만들고 스파게티화 경향을 거의 제거합니다. 우리는 구성 요소의 평면 목록을 가지고 있으며 AngularJS는 필요할 때 하나씩 우리에게 전달합니다.

모듈식 서비스 아키텍처

jQuery는 코드를 구성하는 방법에 대해 거의 언급하지 않습니다. AngularJS에는 의견이 있습니다.

AngularJS는 코드를 넣을 수 있는 모듈을 제공합니다. 예를 들어 Flickr와 통신하는 스크립트를 작성하는 경우 모든 Flickr 관련 기능을 래핑하는 Flickr 모듈을 생성할 수 있습니다. 모듈에는 다른 모듈(DI)이 포함될 수 있습니다. 기본 응용 프로그램은 일반적으로 모듈이며 여기에는 응용 프로그램이 의존하는 다른 모든 모듈이 포함되어야 합니다.

간단한 코드 재사용이 가능합니다. Flickr를 기반으로 다른 응용 프로그램을 작성하려는 경우 Flickr 모듈을 포함하기만 하면 됩니다. 그러면 새 응용 프로그램에서 모든 Flickr 관련 기능에 액세스할 수 있습니다.

모듈에는 AngularJS 구성 요소가 포함되어 있습니다. 모듈을 포함하면 해당 모듈의 모든 구성 요소는 고유한 문자열로 식별되는 간단한 목록으로 사용할 수 있습니다 . 그런 다음 AngularJS의 종속성 주입 메커니즘을 사용하여 이러한 구성 요소를 서로 주입할 수 있습니다.

요약하자면

AngularJS와 jQuery는 적이 아닙니다. AngularJS 내에서 jQuery를 매우 멋지게 사용할 수 있습니다. AngularJS(템플릿, 데이터 바인딩, $scope, 지시문 등)를 잘 사용하고 있다면 필요로 하는 것보다 훨씬 적은 jQuery가 필요하다는 것을 알게 될 것입니다.

가장 중요한 것은 템플릿이 애플리케이션을 구동한다는 것입니다. 모든 것을 수행하는 큰 플러그인을 작성하려는 시도를 중지하십시오. 대신 한 가지 작업을 수행하는 작은 지시문을 작성한 다음 함께 연결하는 간단한 템플릿을 작성하십시오.

눈에 거슬리지 않는 JavaScript에 대해 덜 생각하고 대신 HTML 확장의 관점에서 생각하십시오.

내 작은 책

저는 AngularJS에 대해 매우 흥분하여 이에 대한 짧은 책을 썼습니다. http://nicholasjohnson.com/angular-book/ 온라인에서 읽을 수 있습니다. 도움이 되기를 바랍니다.


superluminary

필요한 패러다임 전환을 설명할 수 있습니까?

명령적 대 선언적

jQuery 를 사용하면 어떤 일이 일어나야 하는지를 DOM에 단계별로 알려줍니다. AngularJS 를 사용하면 원하는 결과를 설명하지만 수행 방법은 설명하지 않습니다. 이에 대한 자세한 내용은 여기를 참조하십시오 . 또한 Mark Rajcok의 답변을 확인하십시오.

클라이언트 측 웹 앱을 다르게 설계하고 설계하려면 어떻게 해야 합니까?

AngularJS는 MVC 패턴을 사용하는 전체 클라이언트 측 프레임워크입니다 (그래픽 표현 확인 ). 관심의 분리에 크게 중점을 둡니다.

가장 큰 차이점은 무엇입니까? 무엇을 하거나 사용을 중단해야 하나요? 대신 무엇을 시작/사용해야 합니까?

jQuery 는 라이브러리다

AngularJS 는 MVC, 종속성 주입 , 데이터 바인딩 등과 같은 수많은 멋진 기능을 결합한 테스트 가능성이 매우 높은 아름다운 클라이언트 측 프레임워크입니다.

테스트 중심 개발을 용이하게 하는 관심사 및 테스트( 단위 테스트 및 종단 간 테스트)의 분리에 중점을 둡니다.

시작하는 가장 좋은 방법은 멋진 튜토리얼을 진행하는 것입니다. 몇 시간 안에 단계를 완료할 수 있습니다. 그러나 배후의 개념을 마스터하려는 경우 추가 읽기를 위한 참조가 무수히 포함되어 있습니다.

서버 측 고려 사항/제한 사항이 있습니까?

이미 순수 jQuery를 사용하고 있는 기존 애플리케이션에서 사용할 수 있습니다. 그러나 AngularJS 기능을 최대한 활용하려면 RESTful 접근 방식을 사용하여 서버 측 코딩을 고려할 수 있습니다.

그렇게 하면 서버 측 RESTful API 의 추상화를 생성하고 서버 측 호출(가져오기, 저장, 삭제 등)을 매우 쉽게 만드는 리소스 팩토리를 활용할 수 있습니다.


Ulises

"패러다임 시프트"를 설명하려면 짧은 대답으로 충분하다고 생각합니다.

AngularJS는 요소를 찾는 방식을 변경합니다.

jQuery 에서는 일반적으로 선택기 를 사용하여 요소를 찾은 다음 연결합니다.
$('#id .class').click(doStuff);

AngularJS 에서 지시문 을 사용하여 요소를 직접 표시하고 연결합니다.
<a ng-click="doStuff()">

본격적인 jQuery를 대 AngularJS와의 jqLite 사이의 주요 차이점이다 - AngularJS와 당신은 선택기를 사용하여 요소를 찾을 필요 (또는 원하는)하지 않는 jqLite가 선택기를 지원하지 않습니다 .

따라서 사람들이 "jQuery를 전혀 포함하지 마십시오"라고 말하는 것은 주로 선택기를 사용하는 것을 원하지 않기 때문입니다. 그들은 당신이 지시어를 대신 사용하는 법을 배우기를 원합니다. 선택이 아닌 직접!


Scott Rippey

제이쿼리

getElementByHerpDerp 와 같은 엄청나게 긴 JavaScript 명령을 더 짧고 크로스 브라우저로 만듭니다.

AngularJS

AngularJS를 사용하면 동적 웹 응용 프로그램과 잘 작동하는 작업을 수행하는 고유한 HTML 태그/속성을 만들 수 있습니다(HTML은 정적 페이지용으로 설계되었으므로).

편집하다:

"저는 jQuery 배경이 있습니다. AngularJS에서 어떻게 생각합니까?" "나는 HTML 배경 지식이 있습니다. JavaScript에서 어떻게 생각합니까?" 당신이 질문을 하고 있다는 사실은 당신이 이 두 리소스의 근본적인 목적을 이해하지 못할 가능성이 높다는 것을 보여줍니다. 이것이 내가 "AngularJS는 지시문을 사용하는 반면 jQuery는 CSS 선택기를 사용하여 이것과 저것 등을 수행하는 jQuery 객체를 만드는 데 사용합니다...." . 이 질문은 긴 대답이 필요하지 않습니다.

jQuery는 브라우저에서 JavaScript를 더 쉽게 프로그래밍할 수 있는 방법입니다. 더 짧은 브라우저 간 명령 등

AngularJS는 HTML을 확장하므로 애플리케이션을 만들기 위해 <div> 를 여기저기에 둘 필요가 없습니다. HTML이 실제로는 정적인 교육용 웹 페이지용으로 설계된 것이 아니라 응용 프로그램에서 작동하도록 합니다. JavaScript를 사용하여 우회적으로 이 작업을 수행하지만 근본적으로 JavaScript가 아니라 HTML의 확장입니다.


Nick Manning

jQuery: DOM 요소에 대한 'DOM 쿼리' 및 작업 수행에 대해 많이 생각합니다.

AngularJS: 모델은 진실이며 항상 그 각도에서 생각합니다.

예를 들어, DOM에서 어떤 형식으로 표시하려는 서버에서 데이터를 가져올 때 jQuery에서는 '1. DOM에서 이 데이터를 배치하려는 위치인 '2. 새 노드를 만들거나 innerHTML을 설정하여 거기에 업데이트/추가'하십시오. 그런 다음 이 보기를 업데이트하려면 '3. 찾기'와 '4. 업데이트'. 서버에서 데이터를 가져오고 형식을 지정하는 동일한 컨텍스트 내에서 모두 수행되는 이 찾기 및 업데이트 주기는 AngularJS에서 사라졌습니다.

AngularJS를 사용하면 모델(이미 익숙한 JavaScript 개체)이 있고 모델의 값은 모델(분명히)과 뷰에 대해 알려줍니다. 모델에 대한 작업은 자동으로 뷰에 전파되므로 그것에 대해 생각해야 합니다. AngularJS에서 더 이상 DOM에서 물건을 찾지 못하는 자신을 발견하게 될 것입니다.

다시 말해서 jQuery에서 CSS 선택자, 즉 div 또는 td 가 어디에 있는지 생각해야 합니다. 그래야 HTML이나 색상 또는 값을 얻을 수 있지만 AngularJS를 사용하면 다음과 같이 생각하게 될 것입니다. 내가 다루고 있는 모델이 무엇인지, 모델의 값을 true로 설정하겠습니다. 이 값을 반영하는 뷰가 체크 박스인지 또는 td 요소에 있는지 여부에 대해 스스로 고민하지 않아도 됩니다(세부 사항은 jQuery에서 종종 생각해야 했을 것입니다).

그리고 AngularJS의 DOM 조작을 사용하면 유효한 HTML 확장이라고 생각할 수 있는 지시문과 필터를 추가하게 됩니다.

AngularJS에서 경험할 수 있는 또 하나의 사항: jQuery에서는 jQuery 함수를 많이 호출합니다. AngularJS에서는 AngularJS가 함수를 호출하므로 AngularJS가 '작업 방법을 알려줍니다'. 그러나 이점은 그만한 가치가 있으므로 AngularJS를 배우는 것 일반적으로 AngularJS가 원하는 것이 무엇인지 또는 AngularJS가 함수를 제시하고 그에 따라 호출할 것을 요구하는 방식을 배우는 것을 의미합니다. 이것은 AngularJS를 라이브러리가 아닌 프레임워크로 만드는 것 중 하나입니다.


Samuel

그것들은 매우 훌륭하지만 긴 답변입니다.

내 경험을 요약하자면:

  1. 컨트롤러와 공급자(서비스, 공장 등)는 HTML이 아니라 데이터 모델을 수정하기 위한 것입니다.
  2. HTML과 지시문은 레이아웃과 모델에 대한 바인딩을 정의합니다.
  3. 컨트롤러 간에 데이터를 공유해야 하는 경우 서비스 또는 팩토리를 만드십시오. 이는 애플리케이션 전체에서 공유되는 싱글톤입니다.
  4. HTML 위젯이 필요한 경우 지시문을 작성하십시오.
  5. 데이터가 있고 이제 HTML을 업데이트하려는 경우... 중지! 모델을 업데이트하고 HTML이 모델에 바인딩되어 있는지 확인하십시오.

Dan

jQuery는 DOM 조작 라이브러리입니다.

AngularJS는 MV* 프레임워크입니다.

사실 AngularJS는 몇 안 되는 JavaScript MV* 프레임워크 중 하나입니다(많은 JavaScript MVC 도구가 여전히 카테고리 라이브러리에 속함).

프레임워크이기 때문에 코드를 호스팅하고 무엇을 언제 호출할지 결정하는 데 소유권을 갖습니다!

AngularJS 자체에는 jQuery-lite 에디션이 포함되어 있습니다. 따라서 일부 기본 DOM 선택/조작의 경우 jQuery 라이브러리를 포함할 필요가 없습니다(네트워크에서 실행하기 위해 많은 바이트를 절약함).

AngularJS는 DOM 조작 및 재사용 가능한 UI 구성 요소 설계를 위한 "지시문"의 개념을 가지고 있으므로 DOM 조작 관련 작업이 필요할 때마다 사용해야 합니다. 지시문은 AngularJS를 사용하면서 jQuery 코드를 작성해야 하는 곳일 뿐입니다.

AngularJS에는 약간의 학습 곡선이 포함됩니다(jQuery보다 더 :-).

-->jQuery를 배경으로 하는 개발자에게 첫 번째 조언은 "AngularJS와 같은 풍부한 프레임워크에 뛰어들기 전에 JavaScript를 일급 언어로 배우십시오!"라는 것입니다. 나는 위의 사실을 어렵게 배웠다.

행운을 빕니다.


Anand

사과와 오렌지입니다. 당신은 그들을 비교하고 싶지 않습니다. 그들은 두 가지 다른 것입니다. AngularJs에는 완전한 jQuery 버전을 포함하지 않고도 기본 DOM 조작을 수행할 수 있는 jQuery 라이트가 이미 내장되어 있습니다.

jQuery는 DOM 조작에 관한 모든 것입니다. 그렇지 않으면 처리해야 하는 모든 크로스 브라우저 문제를 해결하지만 앱을 AngularJS와 같은 구성 요소로 나눌 수 있는 프레임워크는 아닙니다.

AngularJs의 좋은 점은 지시문에서 DOM 조작을 분리/격리할 수 있다는 것입니다. ng-click과 같이 사용할 수 있는 내장 지시문이 있습니다. 모든 보기 논리 또는 DOM 조작을 포함하는 고유한 사용자 지정 지시문을 만들 수 있으므로 비즈니스 논리를 처리해야 하는 컨트롤러나 서비스에서 DOM 조작 코드가 뒤섞이지 않도록 할 수 있습니다.

Angular는 앱을 컨트롤러 - 서비스 - 보기 등으로 나눕니다.

그리고 한 가지 더 있습니다. 그것은 지시문입니다. 이것은 모든 DOM 요소에 첨부할 수 있는 속성이며 jQuery가 AngularJs 구성 요소와 충돌하거나 아키텍처를 엉망으로 만드는 것에 대해 걱정하지 않고 jQuery를 사용할 수 있습니다.

내가 참석한 모임에서 Angular의 창립자 중 한 명이 DOM 조작을 분리하기 위해 정말 열심히 일했으므로 다시 포함시키려고 하지 않는다고 말했습니다.


Jin

AngularJS의 원래 제작자인 Misko Hevery와 Igor Minar가 등장하는 팟캐스트 JavaScript Jabber: Episode #32를 들어보십시오. 그들은 다른 JavaScript 배경, 특히 jQuery에서 AngularJS로 오는 것이 어떤 것인지에 대해 많이 이야기합니다.

팟캐스트의 요점 중 하나는 귀하의 질문과 관련하여 많은 것을 클릭하게 했습니다.

MISKO : [...] 우리가 Angular에서 거의 생각하지 않은 것 중 하나는 어떻게 많은 탈출 해치를 제공하여 기본적으로 이 문제에서 빠져나갈 수 있도록 하는 것입니다. 그래서 우리에게 대답은 "지침"이라고 불리는 것입니다. 그리고 지시문을 사용하면 기본적으로 일반 jQuery JavaScript가 되어 원하는 모든 작업을 수행할 수 있습니다.

IGOR : 따라서 지시문을 템플릿에서 이 특정 요소나 이 CSS를 발견할 때마다 알려주는 컴파일러에 대한 명령이라고 생각하십시오. 이러한 종류의 코드를 유지하고 해당 코드는 요소와 해당 요소 아래의 모든 것을 담당합니다. DOM 트리에서.

전체 에피소드의 대본은 위에 제공된 링크에서 볼 수 있습니다.

따라서 귀하의 질문에 직접 답하자면: AngularJS는 -매우-독립적이며 진정한 MV* 프레임워크입니다. 그러나 지시문 내에서 jQuery를 사용하여 알고 있고 좋아하는 모든 멋진 작업을 여전히 수행할 수 있습니다. "내가 jQuery에서 하던 일을 어떻게 합니까?"의 문제가 아닙니다. "내가 jQuery에서 하던 모든 작업으로 AngularJS를 어떻게 보완합니까?"

그것은 정말로 두 가지 매우 다른 마음 상태입니다.


codevinsky

JavaScript 프로그래밍에 대한 나의 첫 번째 진지한 노출은 Node.js 와 AngularJS였기 때문에 이 질문이 흥미롭습니다. 나는 jQuery를 배운 적이 없으며, 아무것도 배울 필요가 없기 때문에 그것이 좋은 일이라고 생각합니다. 사실, 나는 내 문제에 대한 jQuery 솔루션을 적극적으로 피하고 대신 문제를 해결하기 위해 "AngularJS 방식"만 찾습니다. 따라서 이 질문에 대한 내 대답은 본질적으로 "제이쿼리를 배운 적이 없는 사람처럼 생각하십시오"로 요약되고 jQuery를 직접 통합하려는 유혹을 피할 것입니다(분명히 AngularJS는 배후에서 어느 정도 사용함).


Evan Zamir

AngularJS 및 jQuery:

AngularJs와 JQuery는 JQLite 기능을 제외하고 모든 수준에서 완전히 다르며 AngularJs 핵심 기능을 배우기 시작하면 볼 수 있습니다(아래에서 설명했습니다).

AngularJs는 독립적인 클라이언트 측 애플리케이션을 빌드하도록 제공하는 클라이언트 측 프레임워크입니다. JQuery는 DOM 주변에서 재생되는 클라이언트 측 라이브러리입니다.

AngularJs Cool Principle - UI를 변경하고 싶다면 모델 데이터 변경 관점에서 생각하십시오. 데이터를 변경하면 UI가 다시 렌더링됩니다. 거의 필요하지 않고 Angular 지시문을 통해 처리되어야 하는 경우가 아니면 DOM을 매번 다룰 필요가 없습니다.

이 질문에 답하기 위해 AngularJS를 사용한 첫 번째 엔터프라이즈 애플리케이션에 대한 경험을 공유하고 싶습니다. 이것들은 우리가 jQuery 사고 방식을 바꾸기 시작하고 라이브러리가 아닌 프레임워크처럼 Angular를 얻는 Angular가 제공하는 가장 멋진 기능입니다.

양방향 데이터 바인딩은 놀랍습니다. UPDATE, DELTE, INSERT 기능이 모두 있는 그리드가 있습니다. ng-repeat를 사용하여 그리드의 모델을 바인딩하는 데이터 개체가 있습니다. 삭제 및 삽입을 위한 간단한 JavaScript 코드 한 줄만 작성하면 됩니다. 그리드 모델이 즉시 변경되면 그리드가 자동으로 업데이트됩니다. 업데이트 기능은 코드가 없는 실시간입니다. 당신은 놀라운 느낌!!!

재사용 가능한 지시문은 최고입니다. 지시문을 한 곳에서 작성하고 애플리케이션 전체에서 사용하십시오. 어머나!!! 페이징, 정규식, 유효성 검사 등에 이 지시문을 사용했습니다. 정말 멋집니다!

강력한 라우팅: 사용 방법은 구현에 달려 있지만 HTML 및 컨트롤러(JavaScript)를 지정하기 위해 요청을 라우팅하는 데 필요한 코드 줄은 매우 적습니다.

컨트롤러는 훌륭합니다. 컨트롤러는 자체 HTML을 처리하지만 이러한 분리는 일반 기능에서도 잘 작동합니다. 마스터 HTML에서 버튼 클릭으로 동일한 기능을 호출하려면 각 컨트롤러에 동일한 기능 이름을 작성하고 개별 코드를 작성하면 됩니다.

플러그인: 앱에 오버레이를 표시하는 것과 같은 유사한 기능이 많이 있습니다. 코드를 작성할 필요가 없으며 wc-overlay로 제공되는 오버레이 플러그인을 사용하기만 하면 모든 XMLHttpRequest (XHR) 요청이 자동으로 처리됩니다.

RESTful 아키텍처에 이상적 : 완전한 프레임워크이기 때문에 AngularJS는 RESTful 아키텍처와 함께 작업하기에 적합합니다. REST CRUD API를 호출하는 것은 매우 쉽고

서비스: 서비스를 사용하여 공통 코드를 작성하고 컨트롤러에서 적은 수의 코드를 작성합니다. 서비스를 사용하여 컨트롤러 간에 공통 기능을 공유할 수 있습니다.

확장성 : Angular는 Angular 지시문을 사용하여 HTML 지시문을 확장했습니다. html 내부에 표현식을 작성하고 런타임에 평가하십시오. 별도의 노력 없이 자신만의 지시문과 서비스를 만들고 다른 프로젝트에서 사용할 수 있습니다.


Sanjeev Singh

JavaScript MV* 초보자이자 순전히 애플리케이션 아키텍처(서버/클라이언트 측 문제가 아님)에 초점을 맞추고 있는 저는 다음 리소스를 확실히 추천합니다(아직 언급되지 않은 것에 놀랐습니다): Addy Osmani의 JavaScript Design Patterns , 다양한 JavaScript 디자인 패턴에 대한 소개입니다. 이 답변에 사용된 용어는 위의 링크된 문서에서 가져왔습니다. 나는 받아 들여진 대답에 정말 잘 쓰여진 것을 반복하지 않을 것입니다. 대신 이 답변은 AngularJS(및 기타 라이브러리) 를 지원하는 이론적 배경으로 다시 연결됩니다.

저처럼 AngularJS(또는 Ember.js , Durandal 및 기타 MV* 프레임워크)가 여러 다양한 JavaScript 디자인 패턴을 조합하는 하나의 복잡한 프레임워크라는 것을 빨리 깨닫게 될 것입니다.

나는 시험 (1) 기본 자바 스크립트 코드와는 별도로 하나의 글로벌 프레임 워크에 다이빙을하기 전에 이러한 패턴의 각각에 대해 (2) 작은 도서관, 쉽게 또한 그것을 발견했다. 이를 통해 프레임워크가 어떤 중요한 문제를 해결하는지 더 잘 이해할 수 있었습니다(당신이 개인적으로 문제에 직면했기 때문입니다).

예를 들어:

  • JavaScript 객체 지향 프로그래밍 (Google 검색 링크입니다). 라이브러리는 아니지만 확실히 모든 애플리케이션 프로그래밍의 전제 조건입니다. 프로토타입, 생성자, 싱글톤 및 데코레이터 패턴 의 기본 구현을 가르쳐주었습니다.
  • 파사드 패턴을 위한 jQuery / 밑줄 (DOM 조작을 위한 WYSIWYG와 같은)
  • 프로토 타입/생성자/믹스인 패턴을 위한 Prototype.js
  • RequireJS / 모듈 패턴Curl.js / AMD
  • 관찰 가능한 게시/구독 패턴을 위한 KnockoutJS

주의: 이 목록은 완전하지도 않고 '최고의 라이브러리'도 아닙니다. 그것들은 내가 사용한 라이브러리일 뿐입니다. 이러한 라이브러리에는 더 많은 패턴이 포함되어 있습니다. 언급된 패턴은 주요 초점 또는 원래 의도일 뿐입니다. 이 목록에서 빠진 것이 있다고 생각되면 댓글에 언급해 주시면 기꺼이 추가하겠습니다.


Tyblitz

사실 AngularJS를 사용하고 있다면 더 이상 jQuery가 필요하지 않습니다. AngularJS 자체에는 바인딩 및 지시문이 있으며 이는 jQuery로 할 수 있는 대부분의 작업을 "대체"할 수 있는 매우 좋은 기능입니다.

저는 보통 AngularJS와 Cordova를 사용하여 모바일 애플리케이션을 개발합니다. jQuery에서 내가 필요한 유일한 것은 선택기입니다.

인터넷 검색을 통해 독립형 jQuery 선택기 모듈이 있음을 알 수 있습니다. 시즐입니다.

그리고 jQuery Selector(Sizzle 사용)의 강력한 기능으로 AngularJS를 사용하여 웹사이트를 빠르게 시작하는 데 도움이 되는 작은 코드 조각을 만들기로 결정했습니다.

내 코드를 여기에 공유했습니다: https://github.com/huytd/Sizzular


Huy Tran

출처 : 여기를 클릭하세요


출처 : http:www.stackoverflow.com/questions/14994391/thinking-in-angularjs-if-i-have-a-jquery-background

반응형