jQuery와 AngularJS_AngularJS의 차이점에 대한 간략한 분석

최근에Angularjs를 공부하면서 느낀점은 이전 jQuery와 jQuery를 기반으로 한 다양한 라이브러리 설계 개념과 완전히 다르다는 것입니다. 그렇다면 오랫동안 연구한 후에도 이것이 무엇에 사용될 수 있는지, 어떻게 사용하는지, UI와 결합하는 방법 등을 여전히 알지 못할 가능성이 있습니다. 이에 대해 stackoverflow에서 읽었는데, 이를 바탕으로 모두가 함께 배울 수 있도록 중국어로 번역해 보니 꽤 유익했습니다.

원래 질문: jQuery를 사용하여 클라이언트 애플리케이션을 개발하는 데 익숙하다면, 필요한 패러다임 변경 사항을 설명할 수 있나요?

1. 클라이언트 웹 애플리케이션을 디자인할 때 가장 큰 차이점은 무엇인가요?

2. 어떤 기술을 사용을 중단해야 하며 어떤 기술을 대체해야 합니까?

3. 서버 측에서 고려해야 할 사항이나 제한 사항이 있나요?

정답:

1. 페이지를 먼저 디자인한 뒤 DOM 조작으로 수정하지 마세요

jQuery에서는 먼저 페이지를 디자인한 후 내용을 동적으로 수정합니다. 이는 jQuery가 이러한 전제 하에 내용을 확장하고 크게 늘리고 수정하도록 설계되었지만,Angularjs에서는 먼저 구조를 마음 속으로 디자인해야 하기 때문입니다. ,

처음부터 "DOM 요소가 있고 그 요소가 뭔가를 하길 원합니다"를 버리고 "어떤 작업을 수행해야 합니까?"로 바꾸고 애플리케이션을 디자인하고 마지막으로 뷰 보기를 디자인해야 합니다. 층".

2. jQuery를 확장하기 위해angularjs를 사용하지 마세요

따라서 jQuery가 특정 작업을 수행하도록 한 다음,angularjs의 기능을 추가하여 모델과 컨트롤러를 관리할 수 있다는 생각은 하지 마세요. 따라서 나는 일반적으로 AngularJS 개발 초보자가 적어도 AngularJS 개발 모델에 적응하기 전까지는 jQuery를 동시에 사용하는 것을 권장하지 않습니다. 그러나 실제로 AngularJS 방식에 적응하기 시작하면 이것이 매우 중요하다는 것을 알게 될 것입니다. 유혹적인 것.

Angularjs 콜백과 $apply 메서드를 사용하여 150~200줄의 코드로 jQuery 플러그인을 캡슐화하는 개발자를 많이 보았습니다. 이 방법을 사용하면 코드가 매우 복잡해 보이지만 실제로는 이러한 플러그인이 실행됩니다. 문제는 대부분의 경우 jQuery 플러그인을angularjs로 다시 작성할 수 있고 매우 적은 양의 코드만 사용할 수 있다는 것입니다. 동시에 이렇게 다시 작성하면 코드가 직관적이고 이해하기 쉬워지는데, 이는 분명히 코드를 수행하는 것보다 낫습니다. jQuery 코드를 직접 캡슐화합니다.

결국 문제가 발생하면 먼저 Anglejs 측면에서 생각해야 합니다. 해결책을 찾을 수 없으면 커뮤니티에 도움을 요청할 수 있습니다. jQuery를 사용하세요. jQuery를 버팀목으로 삼지 마세요. 그렇지 않으면 결코 AngularJS를 마스터할 수 없습니다.

3. 건축 중심으로 생각하세요

우선 단일 페이지 애플리케이션은 웹 애플리케이션이라는 점을 알아야 합니다. 전통적인 다중 페이지 웹사이트가 아니기 때문에 서버와 클라이언트 개발자로서 동시에 생각해야 합니다. 애플리케이션을 독립적이고 확장 가능하며 테스트 가능한 부분으로 나누는 방법.

그럼 다음 작업을 위해 AngularJS 사고를 어떻게 사용할까요? jQuery와 비교한 후 몇 가지 기본 지침은 다음과 같습니다.

다음은 애플리케이션의 뷰 레이어입니다.

jQuery에서는 이 뷰를 동적으로 수정하며 ul을 사용하여 드롭다운 메뉴를 정의합니다

코드 복사 코드는 다음과 같습니다.

• 
  ~           
  
• 
  ~                            > ~                     ~                      ~                       >


• 
  ~                





jQuery에서는 다음 논리를 사용하여 이 드롭다운 메뉴를 사용합니다




코드 복사

코드는 다음과 같습니다.

$('.main-menu').dropdownMenu(); 이 보기를 다시 살펴보면 그 기능이 그다지 간단하지 않다는 것을 알 수 있습니다. 소규모 애플리케이션의 경우에는 괜찮지만 대규모 애플리케이션의 경우 이 접근 방식은 혼란스럽고 유지 관리가 어렵습니다. Angularjs에서 이 뷰는 실제로 뷰 기반 함수이므로 ul을 다음과 같이 정의할 수 있습니다

코드 복사

코드는 다음과 같습니다.

...

두 메서드는 실제로 동일한 작업을 수행하지만 AngularJS 메서드에서는 이 뷰 템플릿을 보는 사람이라면 누구나 다음에 수행할 작업을 알 수 있습니다. 새로운 구성원이 개발 팀에 합류할 때마다 그는 여기를 보고 뷰를 작동하기 위한 dropdownMenu라는 명령이 있다는 것을 알 수 있습니다. 그는 정답을 추측하거나 다른 코드를 검토할 필요가 없으며 뷰가 수행하는 작업을 직접 알려줍니다. , jQuery보다 간단합니다.

일부 AngularJS 초보자는 다음과 같은 질문을 자주 합니다. 특정 유형의 모든 링크를 찾고 이를 기반으로 지시문을 추가하려면 어떻게 해야 합니까? 그런데 "이런 식으로 하면 안 됩니다. jQuery의 절반은 Anglejs 아이디어의 절반입니다." "라고 하면 다들 놀랄 것이다.

문제는 그들이 AngularJS의 맥락에서 jQuery를 사용하여 무언가를 하려고 한다는 것입니다. 이는 일반적으로 추가된 지시문 외부에서 DOM 조작을 수행할 필요가 없습니다. 뷰에 직접적으로 연결되므로 의도가 이미 분명합니다. 먼저 디자인한 다음 수정하지 말고, 먼저 구조를 정한 다음 이 프레임워크 내에서 디자인하세요.

데이터 바인딩

이것은 데이터 바인딩 측면에서 단연코 AngularJS의 가장 눈길을 끄는 기능이며, 이 모든 작업은 뷰를 자동으로 업데이트하기 위해 AngularJS에서 수행됩니다. dom을 작동하는 코드를 작성합니다. jQuery에서는 다음과 같은 방식으로 이벤트에 응답하고 뷰를 수정하는 경우가 많습니다.

코드 복사

코드는 다음과 같습니다.

$.ajax({ URL: '/myEndpoint.json', 성공: 함수(데이터, 상태) { $('ul#log').append('

데이터 수신됨!

'); } });

그런 관점에 비하면

코드 복사

코드는 다음과 같습니다.

혼란의 문제 외에도 앞서 언급한 의도를 어떻게 표현해야 하는지에 대한 문제도 있습니다. 하지만 더 중요한 것은 이 DOM 노드를 수동으로 참조하고 업데이트해야 한다는 것입니다. 그 중 하나를 삭제하려면 해당 DOM 요소를 프로그래밍 방식으로 작동해야 합니다. 그러면 이 경우 외부 로직은 어떻게 테스트합니까? 표시 방법을 변경하시겠습니까?

위 코드는 지저분하고 취약해 보이지만 AngularJS에서는 다음과 같이 할 수 있습니다.


코드 복사 코드는 다음과 같습니다.

$http( '/myEndpoint.json' ).then( 함수( 응답 ) {
$scope.log.push( { msg: '데이터 수신됨!' } );
});


우리의 뷰는 이런 모습이어야 합니다

코드 복사 코드는 다음과 같습니다.




• {{entry.msg }}




그렇다면 우리의 뷰도 다음과 같을 수 있습니다
코드 복사 코드는 다음과 같습니다.





{{ 항목.msg }}






이제 ul을 사용하지 않고 Bootstrap의 팝업 상자를 사용하지만 컨트롤러에서 코드를 수정할 필요가 없습니다. 더 중요한 것은 데이터가 어떻게 수정되든 뷰 레이어가 자동으로 변경된다는 것입니다. 따라서 매우 간단합니다!

여기서 시연하지는 않겠지만 데이터 바인딩은 양방향이라는 점을 알아야 합니다. 지시문을 추가하여 데이터를 편집할 수 있습니다. 그 밖에도 흥미로운 곳이 많이 있습니다.

차이 모델 레이어

jQuery에서 DOM은 모델과 유사하지만 AngularJS에서는 jQuery와 다른 모델 레이어를 갖고 있어 원하는 방식으로 관리할 수 있습니다. 이 접근 방식은 데이터 바인딩을 수행하고 문제 분리를 유지하는 데 도움이 되며 더 나은 테스트 가능성을 제공합니다.

관심을 분리

위의 내용은 모두 이 전체 주제와 관련되어 있습니다. 분리에 집중하고, 뷰 레이어가 레코드를 표시하고, 모델 레이어가 데이터를 나타내고, 이러한 재사용 가능한 작업을 수행하는 서비스 레이어가 있습니다. 지시문을 사용하여 DOM 작업을 수행하고 뷰를 확장하여 컨트롤러에 연결합니다. 이것이 제가 테스트 가능성 향상에 대해 다른 곳에서 언급한 이유입니다.

의존성 주입

고민의 분리를 해결하는 데 도움이 되는 것은 DI(종속성 주입)입니다. 서버 측 개발자(Java 또는 PHP)라면 이미 이 개념에 익숙할 수도 있지만 클라이언트 측에 종사하고 있다면 개발, 이 개념이 약간 중복되고 순전히 유행이라고 생각할 수도 있지만 실제로는 그렇지 않습니다.

넓은 관점에서 DI는 구성 요소를 자유롭게 선언한 다음 해당 구성 요소에서 인스턴스화할 수 있음을 의미합니다. 로드 순서, 파일 위치 등을 알 필요는 없습니다. 마법이 즉시 드러나지는 않지만 예를 들어 테스트하겠습니다.

애플리케이션에서는 나머지 API를 통해 서버 측 저장을 수행하기 위해 애플리케이션 상태와 로컬 저장에 의존하는 서비스가 필요하다고 말했습니다. 컨트롤러를 테스트할 때 이후에는 서버와 통신할 필요가 없습니다. 모두 컨트롤러를 테스트하는 중입니다. 우리는 원래 구성 요소와 동일한 모의 서비스를 추가하기만 하면 컨트롤러가 더미 서비스를 얻도록 보장합니다. 컨트롤러 자체는 차이점을 알 필요가 없습니다.

테스트에 대해 이야기해 보겠습니다.

4. 테스트 중심 개발

이 부분은 건축의 세 번째 부분이지만 너무 중요해서 가장 중요한 위치에 두어야 합니다.

우리가 보고, 사용하고, 작성한 모든 jQuery 플러그인 중에서 테스트 구성 요소가 있는 플러그인은 몇 개입니까? 사실 그런 경우는 많지 않습니다. 왜냐하면 jQuery는 테스트할 때 제어하기가 쉽지 않은데, AngularJS는 이와 다릅니다.

jQuery에서 테스트하는 유일한 방법은 테스트가 DOM 작업을 수행할 수 있도록 데모 페이지를 사용하여 독립적인 구성 요소를 만드는 것입니다. 다음으로 별도의 구성요소를 개발하여 이를 애플리케이션에 통합해야 합니다. 이는 얼마나 불편한 일입니까! 우리가 jQuery를 사용하여 개발을 할 때 실제로는 테스트 주도 개발보다는 반복적인 개발을 많이 하는 경우가 많습니다.

그러나 AngularJS에서는 분리 지점에 집중할 수 있으므로 테스트 기반 개발을 수행할 수 있습니다. 예를 들어, 메뉴의 현재 경로를 설명하는 지시문이 있습니다.


코드 복사 코드는 다음과 같습니다.

안녕하세요


자, 이제 활성 상태일 때 존재하지 않는 명령어를 테스트하는 테스트를 작성할 수 있습니다.


코드 복사 코드는 다음과 같습니다.

it( '경로가 변경되면 "active"를 추가해야 합니다.', inject(function() {
var elm = $compile( '안녕하세요' )( $scope );

$location.path('/not-matching');
Expect( elm.hasClass('active') ).toBeFalsey();

$location.path( '/hello' );
Expect( elm.hasClass('active') ).toBeTruthy();
}));


테스트 사례를 직접 실행해 보면 실패하는 것을 확인할 수 있습니다. 이때 다음과 같이 이 명령을 생성해야 합니다.

코드 복사 코드는 다음과 같습니다.

.directive( 'whenActive', 함수( $location ) {
복귀 {
범위: true,
         링크: 함수(범위, 요소, 속성) {
               범위.$on( '$routeChangeSuccess', 함수 () {
If ( $location.path() == element.attr( 'href' ) ) {
                     element.addClass( 'active' );
                }
                   그 외 {
                        element.removeClass( 'active' );
                }
            });
}
};
});



이 테스트 사례를 다시 실행하면 테스트가 통과되고 메뉴가 요청한 대로 표시되는 것을 확인할 수 있습니다. 우리의 개발은 반복적이고 테스트 가능합니다. 이는 매우 좋습니다.

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

DOM 작업은 명령어로만 수행할 수 있다는 말을 자주 듣습니다. 이는 필수 사항이며 진지하게 받아들여야 합니다.

자세히 살펴보겠습니다.

일부 지시문은 뷰(예: ngClass)를 장식하기 때문에 때로는 DOM을 직접 조작해도 괜찮지만 지시문이 위젯과 유사하고 자체 템플릿이 있는 경우 별도의 문제로 처리해야 합니다. 요점은 해당 템플릿이 링크 및 기타 컨트롤러 기능의 실행 로직과 분리되어야 함을 의미합니다.

AngularJS에는 이러한 분리를 더 쉽게 할 수 있는 완전한 도구 세트가 있습니다. ngClass 지시어를 사용하면 클래스를 동적으로 업데이트할 수 있고, ngBind를 사용하면 양방향 데이터 바인딩을 수행할 수 있으며, ngShow 및 ngHide를 사용하면

우리가 직접 작성한 많은 지침을 포함하여 프로그래밍 방식으로 요소를 표시하고 숨길 수 있습니다. 즉, DOM 작업 없이 모든 작업을 완료할 수 있으며, DOM 작업이 적을수록 지침을 테스트하기가 더 쉽고, 스타일 속성을 지정하기가 더 쉽고, 나중에 변경하기도 더 쉽습니다. 재사용 및 배포가 더 쉽습니다.

많은 AngularJS 초보자가 지시문을 사용하여 jQuery 코드의 대규모 시퀀스를 캡슐화하는 것을 보았습니다. 즉, 컨트롤러에서 DOM 작업을 수행할 수 없기 때문에 지시문에 넣을 수 있습니다. dom을 직접 운영하지만 여전히 잘못되었습니다.

위의 기록을 보면 지시문에 넣어도 DOM 작업을 수행하지 않는 Angular 방식으로 작업해야 합니다! DOM 조작이 필요한 경우가 많지만 이러한 상황은 생각보다 훨씬 드뭅니다. DOM 작업을 수행해야 할 때 먼저 여기에서 수행해야 하는지 자문합니다. 이것이 더 나은 방법입니다.

다음은 토글 버튼이 필요한 자주 볼 수 있는 패턴을 보여주는 간단한 예입니다.


코드 복사 코드는 다음과 같습니다.

.directive( 'myDirective', 함수 () {
복귀 {
템플릿: 'Toggle me!',
링크: 함수(범위, 요소, 속성) {
          var on = false;

$(요소).click( 함수 () {
on = !on;
                     $(element).toggleClass('active', on);
            });
}
};
});


위 예에는 다음과 같은 오류가 있습니다.

1. 우선 jQuery가 필요하지 않습니다. 여기에서는 jQuery가 전혀 필요하지 않습니다!

2. 둘째, 페이지에 jQuery를 도입했지만 사용할 이유가 없더라도, 이 프로젝트에 jQuery가 도입되지 않아도 angle.element를 사용하면 우리 컴포넌트가 실행될 수 있습니다. .

3. 셋째, 지침에 jquery가 필요하다고 가정하면 jqLite를 사용하여 이를 대체할 수 있습니다. 그러면 $를 사용할 필요 없이 angle.element를 사용하면 됩니다.

4. 넷째, 세 번째 사항과 밀접하게 관련되어 있는 jqLite 요소는 $로 래핑될 필요가 없습니다. 링크 함수에 전달된 요소 요소는 이미 jQuery 개체입니다.

5. 앞서 말했듯이 템플릿과 로직을 혼합해 보는 것은 어떨까요?
위 명령을 다음과 같이 다시 작성할 수 있으므로 가장 복잡한 경우에도 매우 간단해 보입니다.




코드 복사 코드는 다음과 같습니다.
.directive( 'myDirective', 함수 () {
복귀 {
범위: true,
템플릿: 'Toggle me!',
링크: 함수(범위, 요소, 속성) {
범위.온 = 거짓;

범위.토글 = 함수 () {
범위.온 = !scope.on;
            };
}
};
});


템플릿 요소는 템플릿 속성에 있으므로 스타일을 쉽게 바꿀 수 있고 로직을 전혀 변경할 필요가 없어 완전한 재사용이 가능합니다!
테스트하기 쉽고 명령 API는 템플릿에 무엇이 있어도 변경되지 않으므로 리팩터링이 쉽다는 등의 다른 이점도 있습니다. 지침을 변경하지 않고도 원하는 만큼 템플릿을 변경할 수 있으며, 어떻게 변경하더라도 테스트는 항상 통과됩니다!
따라서 명령어는 함수 등의 jQuery 코드 모음이 아니라 HTML 코드의 확장입니다. HTML 코드가 필요한 기능을 달성할 수 없는 경우 이를 구현하는 명령어를 작성할 수 있습니다. 그런 다음 HTML처럼 사용하십시오.
다른 말로 AngularJS가 추가 작업을 수행하지 않는 경우 ngClick 및 ngClass 명령을 어떻게 사용할 수 있는지 생각해 보세요.

요약

항상 jquery를 사용하지 마세요. 참조도 하지 마세요. 문제로 돌아올 때 진행이 중단될 것입니다. AngularJS에서 jquery 방식으로 문제를 해결하는 방법을 알고 계시겠지만, $ 등과 같은 선택기가 실제로 어떻게 AngularJS를 가두는지 생각해야 합니다. jQuery 없이 이를 구현하는 방법을 모른다면 다른 사람에게 계속해서 물어보는 것이 가장 좋은 방법은 jQuery를 사용하지 않는 것입니다. 작업량이 증가할 뿐입니다.