Tư duy trong AngularJS nếu tôi có một nền tảng jQuery? [đóng cửa]


4514

Giả sử tôi quen với việc phát triển các ứng dụng phía máy khách trong jQuery , nhưng bây giờ tôi muốn bắt đầu sử dụng AngularJS . Bạn có thể mô tả sự thay đổi mô hình là cần thiết? Dưới đây là một vài câu hỏi có thể giúp bạn đóng khung câu trả lời:

  • Làm cách nào để kiến ​​trúc sư và thiết kế các ứng dụng web phía khách hàng khác nhau? Sự khác biệt lớn nhất là gì?
  • Tôi nên ngừng làm gì / sử dụng; Tôi nên bắt đầu làm gì / sử dụng thay thế?
  • Có bất kỳ cân nhắc / hạn chế phía máy chủ?

Tôi không tìm kiếm một so sánh chi tiết giữa jQueryAngularJS.


Đối với những người quen thuộc với "ASP.NET MVC" hoặc "RoR" - chỉ cần nghĩ về Angular như "MVC phía máy khách" và đó là nó.
Serge Shultz

Câu trả lời:


7178

1. Không thiết kế trang của bạn và sau đó thay đổi nó bằng các thao tác DOM

Trong jQuery, bạn thiết kế một trang và sau đó bạn làm cho nó động. Điều này là do jQuery được thiết kế để tăng cường và đã phát triển đáng kinh ngạc từ tiền đề đơn giản đó.

Nhưng trong AngularJS, bạn phải bắt đầu từ đầu với kiến ​​trúc của bạn trong tâm trí. Thay vì bắt đầu bằng cách nghĩ "Tôi có đoạn DOM này và tôi muốn làm cho nó thành X", bạn phải bắt đầu với những gì bạn muốn thực hiện, sau đó đi về thiết kế ứng dụng của bạn và cuối cùng là thiết kế chế độ xem của bạn.

2. Đừng gia tăng jQuery với AngularJS

Tương tự, đừng bắt đầu với ý tưởng rằng jQuery làm X, Y và Z, vì vậy tôi sẽ chỉ thêm AngularJS lên trên đó cho các mô hình và bộ điều khiển. Điều này thực sự hấp dẫn khi bạn mới bắt đầu, đó là lý do tại sao tôi luôn khuyên các nhà phát triển AngularJS mới không sử dụng jQuery, ít nhất là cho đến khi họ quen với việc thực hiện "Angular Way".

Tôi đã thấy nhiều nhà phát triển ở đây và trong danh sách gửi thư tạo ra các giải pháp phức tạp này với các plugin jQuery gồm 150 hoặc 200 dòng mã mà sau đó họ dán vào AngularJS với một bộ sưu tập các cuộc gọi lại và $applygây nhầm lẫn; nhưng cuối cùng họ cũng làm cho nó hoạt động! Vấn đề là trong hầu hết các trường hợp, plugin jQuery có thể được viết lại trong AngularJS trong một phần của mã, trong đó đột nhiên mọi thứ trở nên dễ hiểu và đơn giản.

Điểm mấu chốt là đây: khi giải, trước tiên hãy "nghĩ trong AngularJS"; nếu bạn không thể nghĩ ra giải pháp, hãy hỏi cộng đồng; nếu sau tất cả những điều đó không có giải pháp dễ dàng, thì hãy tiếp cận với jQuery. Nhưng đừng để jQuery trở thành một cái nạng hoặc bạn sẽ không bao giờ thành thạo AngularJS.

3. Luôn suy nghĩ về mặt kiến ​​trúc

Trước tiên hãy biết rằng các ứng dụng một trangcác ứng dụng . Chúng không phải là trang web. Vì vậy, chúng ta cần phải suy nghĩ như một nhà phát triển phía máy chủ bên cạnh việc suy nghĩ như một nhà phát triển phía khách hàng. Chúng ta phải suy nghĩ về cách phân chia ứng dụng của chúng ta thành các thành phần riêng lẻ, có thể mở rộng, có thể kiểm tra được.

Vì vậy, làm thế nào để bạn làm điều đó? Làm thế nào để bạn "nghĩ trong AngularJS"? Dưới đây là một số nguyên tắc chung, tương phản với jQuery.

Quan điểm là "hồ sơ chính thức"

Trong jQuery, chúng tôi lập trình thay đổi khung nhìn. Chúng ta có thể có một menu thả xuống được định nghĩa như ulsau:

<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>

Trong jQuery, theo logic ứng dụng của chúng tôi, chúng tôi sẽ kích hoạt nó bằng một cái gì đó như:

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

Khi chúng ta chỉ nhìn vào khung cảnh, không rõ ràng có bất kỳ chức năng nào ở đây. Đối với các ứng dụng nhỏ, điều đó tốt. Nhưng đối với các ứng dụng không tầm thường, mọi thứ nhanh chóng trở nên khó hiểu và khó bảo trì.

Tuy nhiên, trong AngularJS, chế độ xem là bản ghi chính thức của chức năng dựa trên chế độ xem. ulThay vào đó, tuyên bố của chúng tôi sẽ trông như thế này:

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

Cả hai đều làm điều tương tự, nhưng trong phiên bản AngularJS, bất cứ ai nhìn vào mẫu đều biết điều gì sẽ xảy ra. Bất cứ khi nào một thành viên mới của nhóm phát triển lên tàu, cô ấy có thể nhìn vào điều này và sau đó biết rằng có một lệnh được gọi là dropdownMenuvận hành trên nó; cô ấy không cần phải trả lời đúng hoặc chọn lọc bất kỳ mã nào. Quan điểm cho chúng tôi biết những gì sẽ xảy ra. Sạch sẽ hơn nhiều.

Các nhà phát triển mới sử dụng AngularJS thường hỏi một câu hỏi như: làm thế nào để tôi tìm thấy tất cả các liên kết của một loại cụ thể và thêm một chỉ thị vào chúng. Nhà phát triển luôn lúng túng khi chúng tôi trả lời: bạn không. Nhưng lý do bạn không làm điều đó là vì nó giống như một nửa jQuery, nửa AngularJS và không tốt. Vấn đề ở đây là nhà phát triển đang cố gắng "làm jQuery" trong ngữ cảnh của AngularJS. Điều đó sẽ không bao giờ hoạt động tốt. Quan điểm hồ sơ chính thức. Bên ngoài một chỉ thị (nhiều hơn về điều này dưới đây), bạn sẽ không bao giờ thay đổi DOM. Và các chỉ thị được áp dụng trong quan điểm , vì vậy ý ​​định là rõ ràng.

Hãy nhớ rằng: không thiết kế, và sau đó đánh dấu. Bạn phải kiến ​​trúc sư, và sau đó thiết kế.

Ràng buộc dữ liệu

Đây là một trong những tính năng tuyệt vời nhất của AngularJS và loại bỏ rất nhiều nhu cầu thực hiện các loại thao tác DOM mà tôi đã đề cập trong phần trước. AngularJS sẽ tự động cập nhật chế độ xem của bạn để bạn không phải! Trong jQuery, chúng tôi trả lời các sự kiện và sau đó cập nhật nội dung. Cái gì đó như:

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

Đối với một khung nhìn trông như thế này:

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

Ngoài những lo ngại lẫn lộn, chúng tôi cũng có những vấn đề tương tự về việc biểu thị ý định mà tôi đã đề cập trước đó. Nhưng quan trọng hơn, chúng tôi phải tham khảo thủ công và cập nhật nút DOM. Và nếu chúng ta muốn xóa một mục nhật ký, chúng ta cũng phải mã theo DOM cho điều đó. Làm thế nào để chúng tôi kiểm tra logic ngoài DOM? Và nếu chúng ta muốn thay đổi bài thuyết trình thì sao?

Điều này một chút lộn xộn và một yếu đuối yếu. Nhưng trong AngularJS, chúng ta có thể làm điều này:

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

Và quan điểm của chúng tôi có thể trông như thế này:

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

Nhưng đối với vấn đề đó, quan điểm của chúng tôi có thể trông như thế này:

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

Và bây giờ thay vì sử dụng danh sách không có thứ tự, chúng tôi đang sử dụng các hộp cảnh báo Bootstrap. Và chúng tôi không bao giờ phải thay đổi mã điều khiển! Nhưng quan trọng hơn, bất kể nhật ký được cập nhật ở đâunhư thế nào , chế độ xem cũng sẽ thay đổi. Tự động. Khéo léo!

Mặc dù tôi đã không hiển thị nó ở đây, ràng buộc dữ liệu là hai chiều. Vì vậy, những thông điệp tường trình cũng có thể được chỉnh sửa trong chế độ xem chỉ bằng cách thực hiện điều này : <input ng-model="entry.msg" />. Và đã có nhiều niềm vui.

Lớp mô hình riêng biệt

Trong jQuery, DOM giống như mô hình. Nhưng trong AngularJS, chúng tôi có một lớp mô hình riêng biệt mà chúng tôi có thể quản lý theo bất kỳ cách nào chúng tôi muốn, hoàn toàn độc lập với chế độ xem. Điều này giúp cho việc ràng buộc dữ liệu trên, duy trì sự tách biệt các mối quan tâm và giới thiệu khả năng kiểm tra lớn hơn nhiều. Các câu trả lời khác đề cập đến điểm này, vì vậy tôi sẽ chỉ để nó ở đó.

Tách biệt mối quan tâm

Và tất cả các mối quan hệ trên đây vào chủ đề bao quát này: giữ cho mối quan tâm của bạn riêng biệt. Quan điểm của bạn đóng vai trò là hồ sơ chính thức về những gì sẽ xảy ra (đối với hầu hết các phần); mô hình của bạn đại diện cho dữ liệu của bạn; bạn có một lớp dịch vụ để thực hiện các nhiệm vụ có thể sử dụng lại; bạn thực hiện thao tác DOM và tăng cường quan điểm của bạn bằng các chỉ thị; và bạn dán nó lại với nhau bằng bộ điều khiển. Điều này cũng đã được đề cập trong các câu trả lời khác, và điều duy nhất tôi sẽ thêm liên quan đến khả năng kiểm tra, mà tôi sẽ thảo luận trong phần khác dưới đây.

Phụ thuộc tiêm

Để giúp chúng tôi giải quyết vấn đề là tiêm phụ thuộc (DI). Nếu bạn đến từ ngôn ngữ phía máy chủ (từ Java sang PHP ) thì có lẽ bạn đã quen với khái niệm này, nhưng nếu bạn là một người ở phía máy khách đến từ jQuery, khái niệm này có thể có vẻ như bất cứ điều gì ngớ ngẩn đến thừa thãi đối với hipster . Nhưng nó không phải là. :-)

Từ góc độ rộng, DI có nghĩa là bạn có thể khai báo các thành phần rất tự do và sau đó từ bất kỳ thành phần nào khác, chỉ cần yêu cầu một thể hiện của nó và nó sẽ được cấp. Bạn không cần phải biết về thứ tự tải, hoặc vị trí tệp hoặc bất cứ thứ gì tương tự. Sức mạnh có thể không được nhìn thấy ngay lập tức, nhưng tôi sẽ chỉ cung cấp một ví dụ (phổ biến): thử nghiệm.

Giả sử trong ứng dụng của chúng tôi, chúng tôi yêu cầu một dịch vụ thực hiện lưu trữ phía máy chủ thông qua API REST và tùy thuộc vào trạng thái ứng dụng, lưu trữ cục bộ. Khi chạy thử nghiệm trên các bộ điều khiển của chúng tôi, chúng tôi không muốn phải giao tiếp với máy chủ - xét cho cùng , chúng tôi đang thử nghiệm bộ điều khiển . Chúng tôi chỉ có thể thêm một dịch vụ giả có cùng tên với thành phần ban đầu của chúng tôi và người tiêm sẽ đảm bảo rằng bộ điều khiển của chúng tôi tự động nhận được dịch vụ giả - bộ điều khiển của chúng tôi không biết và không cần biết sự khác biệt.

Nói về thử nghiệm ...

4. Phát triển dựa trên thử nghiệm - luôn luôn

Đây thực sự là một phần của phần 3 về kiến ​​trúc, nhưng điều quan trọng là tôi đặt nó làm phần cấp cao nhất của chính nó.

Trong số tất cả các plugin jQuery bạn đã thấy, đã sử dụng hoặc đã viết, có bao nhiêu trong số chúng có bộ kiểm tra đi kèm? Không nhiều lắm vì jQuery không thể chấp nhận điều đó. Nhưng AngularJS thì có.

Trong jQuery, cách duy nhất để kiểm tra thường là tạo thành phần độc lập với trang mẫu / trang demo để kiểm tra có thể thực hiện thao tác DOM. Vì vậy, sau đó chúng tôi phải phát triển một thành phần riêng biệt và sau đó tích hợp nó vào ứng dụng của chúng tôi. Thật bất tiện làm sao! Vì vậy, phần lớn thời gian, khi phát triển với jQuery, chúng tôi chọn cách lặp thay vì phát triển dựa trên thử nghiệm. Và ai có thể đổ lỗi cho chúng tôi?

Nhưng bởi vì chúng tôi có sự phân tách các mối quan tâm, chúng tôi có thể thực hiện phát triển dựa trên thử nghiệm lặp đi lặp lại trong AngularJS! Ví dụ: giả sử chúng tôi muốn một chỉ thị siêu đơn giản để chỉ ra trong menu của chúng tôi tuyến đường hiện tại của chúng tôi là gì. Chúng tôi có thể tuyên bố những gì chúng tôi muốn trong quan điểm của ứng dụng của chúng tôi:

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

Được rồi, bây giờ chúng ta có thể viết một bài kiểm tra cho when-activechỉ thị không tồn tại :

it( 'should add "active" when the route changes', inject(function() {
    var elm = $compile( '<a href="https://stackoverflow.com/hello" when-active>Hello</a>' )( $scope );

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

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

Và khi chúng tôi chạy thử nghiệm, chúng tôi có thể xác nhận rằng nó thất bại. Chỉ bây giờ chúng ta nên tạo ra chỉ thị của mình:

.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' );
                }
            });
        }
    };
});

Thử nghiệm của chúng tôi bây giờ vượt qua thực đơn của chúng tôi thực hiện theo yêu cầu. Sự phát triển của chúng tôi là cả lặp đi lặp lại và hướng thử nghiệm. Xấu-lạnh.

5. Về mặt khái niệm, các lệnh không được đóng gói jQuery

Bạn sẽ thường nghe "chỉ thực hiện thao tác DOM trong một lệnh". Đây là một điều cần thiết. Đối xử với nó do sự trì hoãn!

Nhưng hãy lặn sâu hơn một chút ...

Một số chỉ thị chỉ trang trí những gì đã có trong chế độ xem (nghĩ ngClass) và do đó đôi khi thực hiện thao tác DOM ngay lập tức và sau đó về cơ bản được thực hiện. Nhưng nếu một lệnh giống như một "widget" và có một khuôn mẫu, thì nó cũng nên tôn trọng sự phân tách các mối quan tâm. Đó là, mẫu cũng nên độc lập chủ yếu với việc thực hiện nó trong các chức năng liên kết và bộ điều khiển.

AngularJS đi kèm với toàn bộ bộ công cụ để thực hiện việc này rất dễ dàng; với ngClasschúng tôi có thể tự động cập nhật lớp; ngModelcho phép ràng buộc dữ liệu hai chiều; ngShowngHidelập trình hiển thị hoặc ẩn một phần tử; và nhiều hơn nữa - bao gồm cả những người chúng ta tự viết. Nói cách khác, chúng ta có thể làm tất cả các loại tuyệt vời mà không cần thao tác DOM. Thao tác DOM càng ít, các lệnh càng dễ kiểm tra, chúng càng dễ tạo kiểu, chúng càng dễ thay đổi trong tương lai và chúng càng có thể sử dụng lại và phân phối được.

Tôi thấy rất nhiều nhà phát triển mới sử dụng AngularJS bằng cách sử dụng các chỉ thị làm nơi ném một loạt jQuery. Nói cách khác, họ nghĩ rằng "vì tôi không thể thực hiện thao tác DOM trong bộ điều khiển, nên tôi sẽ lấy mã đó để đưa ra lệnh". Mặc dù điều đó chắc chắn tốt hơn nhiều, nhưng nó vẫn thường sai .

Hãy nghĩ về logger mà chúng ta đã lập trình trong phần 3. Ngay cả khi chúng ta đưa nó vào một chỉ thị, chúng ta vẫn muốn thực hiện nó theo "Cách góc". Nó vẫn không mất bất kỳ thao tác DOM nào! Có rất nhiều lần khi DOM thao tác là cần thiết, nhưng đó là một rất nhiều hiếm hơn bạn nghĩ! Trước khi thực hiện thao tác DOM ở bất cứ đâu trong ứng dụng của bạn, hãy tự hỏi nếu bạn thực sự cần. Có thể có một cách tốt hơn.

Đây là một ví dụ nhanh cho thấy mẫu tôi thấy thường xuyên nhất. Chúng tôi muốn một nút bật tắt. (Lưu ý: ví dụ này là một chút giả định và một câu tục ngữ để thể hiện các trường hợp phức tạp hơn được giải quyết theo cùng một cách chính xác.)

.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);
            });
        }
    };
});

Có một vài điều sai với điều này:

  1. Đầu tiên, jQuery không bao giờ cần thiết. Không có gì chúng tôi đã làm ở đây mà cần jQuery cả!
  2. Thứ hai, ngay cả khi chúng tôi đã có jQuery trên trang của mình, không có lý do gì để sử dụng nó ở đây; chúng ta chỉ cần sử dụng angular.elementvà thành phần của chúng ta sẽ vẫn hoạt động khi được đưa vào một dự án không có jQuery.
  3. Thứ ba, ngay cả khi giả sử jQuery được yêu cầu để lệnh này hoạt động, jqLite ( angular.element) sẽ luôn sử dụng jQuery nếu được tải! Vì vậy, chúng tôi không cần sử dụng $- chúng tôi chỉ có thể sử dụng angular.element.
  4. Thứ tư, liên quan chặt chẽ đến thứ ba, là các phần tử jqLite không cần phải được bao bọc $- phần tử elementđược truyền cho linkhàm sẽ một phần tử jQuery!
  5. Và thứ năm, mà chúng ta đã đề cập trong các phần trước, tại sao chúng ta trộn các công cụ mẫu vào logic của chúng tôi?

Lệnh này có thể được viết lại (ngay cả đối với các trường hợp rất phức tạp!) Đơn giản hơn rất nhiều như vậy:

.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;
            };
        }
    };
});

Một lần nữa, công cụ mẫu có trong mẫu, do đó bạn (hoặc người dùng của bạn) có thể dễ dàng trao đổi nó với một kiểu đáp ứng bất kỳ kiểu nào cần thiết và logic không bao giờ phải chạm vào. Tái sử dụng - bùng nổ!

Và vẫn còn tất cả những lợi ích khác, như thử nghiệm - thật dễ dàng! Bất kể là gì trong mẫu, API nội bộ của lệnh không bao giờ được chạm vào, do đó, tái cấu trúc rất dễ dàng. Bạn có thể thay đổi mẫu nhiều như bạn muốn mà không cần chạm vào lệnh. Và bất kể bạn thay đổi điều gì, bài kiểm tra của bạn vẫn vượt qua.

w00t!

Vậy nếu các lệnh không chỉ là tập hợp các hàm giống như jQuery, thì chúng là gì? Chỉ thị thực sự là phần mở rộng của HTML . Nếu HTML không làm điều gì đó bạn cần làm, bạn viết một lệnh để làm điều đó cho bạn, và sau đó sử dụng nó như thể nó là một phần của HTML.

Nói cách khác, nếu AngularJS không làm một cái gì đó ra khỏi hộp, suy nghĩ như thế nào đội sẽ thực hiện nó để phù hợp đúng với ngClick, ngClass, et al.

Tóm lược

Thậm chí không sử dụng jQuery. Thậm chí không bao gồm nó. Nó sẽ giữ bạn lại. Và khi bạn gặp phải một vấn đề mà bạn nghĩ rằng bạn đã biết cách giải quyết trong jQuery, trước khi bạn tiếp cận $, hãy thử nghĩ về cách thực hiện nó trong giới hạn của AngularJS. Nếu bạn không biết, hãy hỏi! 19 trong số 20 lần, cách tốt nhất để làm điều đó không cần jQuery và cố gắng giải quyết nó với kết quả jQuery mang lại nhiều công việc hơn cho bạn.


204
Tôi nghĩ rằng việc kết hợp làm việc với JQuery trong một ứng dụng góc cạnh là trường hợp sử dụng quan trọng vì tất cả các trình cắm JQuery hiện có đã được viết. Tôi không viết lại FancyBox trong jQuery để giữ một ứng dụng Angular thuần túy.
taudep

119
@taudep Tôi không nghĩ chúng tôi không đồng ý nhiều như bạn nghĩ. Hầu hết các plugin jQuery có thể được viết lại trong AngularJS với giá rẻ và trong những trường hợp đó chúng ta nên làm như vậy. Đối với một cái gì đó phức tạp mà không có tương đương, sau đó đi cho nó. Để trích dẫn từ Phần 2: 'Điểm mấu chốt là đây: khi giải, trước tiên hãy "nghĩ trong AngularJS"; nếu bạn không thể nghĩ ra giải pháp, hãy hỏi cộng đồng; nếu sau tất cả những điều đó không có giải pháp dễ dàng, thì hãy tiếp cận với jQuery . Nhưng đừng để jQuery trở thành một cái nạng hoặc bạn sẽ không bao giờ thành thạo AngularJS. ' [nhấn mạnh thêm]
Josh David Miller

67
một bản dịch tiếng Trung cho câu trả lời tuyệt vời này, hy vọng hữu ích. hanzheng.github.io/tech/angularjs/2013/10/28/ từ
Han Zheng

18
@Benno Điều anh ấy muốn nói là "không có thao tác DOM" là mã của bạn trong lệnh không trực tiếp thực hiện các thao tác DOM. Mã đó không biết gì về DOM, nó chỉ sửa đổi các biến js trong mô hình của bạn. Đúng, kết quả cuối cùng là DOM bị sửa đổi, nhưng đó là do bên ngoài mã chúng ta viết, có các ràng buộc phản ứng với các biến của chúng ta thay đổi, nhưng bên trong chỉ thị chúng ta không biết gì về nó, tạo ra sự tách biệt rõ ràng giữa thao tác DOM và logic kinh doanh. Trong ví dụ jQuery của bạn, bạn đang trực tiếp thay đổi DOM bằng cách nói "nối văn bản này vào thành phần này"
Wired_in

11
@trusktr Nếu một nhà phát triển từng đặt giá trị của phần tử đầu vào bằng jQuery trong ứng dụng AngularJS, cô ấy đang phạm phải một lỗi nghiêm trọng . Loại ngoại lệ duy nhất mà tôi có thể nghĩ là một plugin jQuery hiện có quá khó để tự động chuyển đổi đầu vào, trong trường hợp đó, việc móc vào một cuộc gọi lại hoặc đặt đồng hồ là điều hoàn toàn cần thiết dù sao cũng mang lại những thay đổi nội tuyến với ứng dụng.
Josh David Miller

407

Bắt buộc → khai báo

Trong jQuery, các bộ chọn được sử dụng để tìm các phần tử DOM và sau đó liên kết / đăng ký các trình xử lý sự kiện với chúng. Khi một sự kiện kích hoạt, mã (bắt buộc) đó sẽ thực thi để cập nhật / thay đổi DOM.

Trong AngularJS, bạn muốn nghĩ về các khung nhìn hơn là các thành phần DOM. Lượt xem là HTML (khai báo) có chứa các chỉ thị AngularJS . Các chỉ thị thiết lập các trình xử lý sự kiện đằng sau hậu trường cho chúng ta và cung cấp cho chúng ta cơ sở dữ liệu động. Bộ chọn hiếm khi được sử dụng, do đó nhu cầu về ID (và một số loại lớp) bị giảm đi rất nhiều. Lượt xem được gắn với mô hình (thông qua phạm vi). Lượt xem là một hình chiếu của mô hình. Các sự kiện thay đổi mô hình (nghĩa là dữ liệu, thuộc tính phạm vi) và các chế độ xem dự án các mô hình đó cập nhật "tự động".

Trong AngularJS, hãy nghĩ về các mô hình, thay vì các phần tử DOM do jQuery chọn giữ dữ liệu của bạn. Hãy suy nghĩ về các khung nhìn như các hình chiếu của các mô hình đó, thay vì đăng ký các cuộc gọi lại để thao túng những gì người dùng nhìn thấy.

Tách biệt mối quan tâm

jQuery sử dụng JavaScript không phô trương - hành vi (JavaScript) được tách ra khỏi cấu trúc (HTML).

AngularJS sử dụng các bộ điều khiển và chỉ thị (mỗi bộ điều khiển có thể có bộ điều khiển riêng, và / hoặc các chức năng biên dịch và liên kết) để loại bỏ hành vi khỏi chế độ xem / cấu trúc (HTML). Angular cũng có các dịch vụbộ lọc để giúp tách / tổ chức ứng dụng của bạn.

Xem thêm https://stackoverflow.com/a/14346528/215945

Thiết kế ứng dụng

Một cách tiếp cận để thiết kế ứng dụng AngularJS:

  1. Hãy suy nghĩ về các mô hình của bạn. Tạo các dịch vụ hoặc các đối tượng JavaScript của riêng bạn cho các mô hình đó.
  2. Hãy suy nghĩ về cách bạn muốn trình bày các mô hình của bạn - quan điểm của bạn. Tạo các mẫu HTML cho mỗi chế độ xem, sử dụng các chỉ thị cần thiết để có được cơ sở dữ liệu động.
  3. Đính kèm bộ điều khiển cho mỗi chế độ xem (sử dụng ng-view và định tuyến hoặc ng-điều khiển). Yêu cầu bộ điều khiển tìm / nhận bất kỳ dữ liệu mô hình nào mà khung nhìn cần để thực hiện công việc của nó. Làm cho bộ điều khiển càng mỏng càng tốt.

Di truyền nguyên mẫu

Bạn có thể làm rất nhiều với jQuery mà không cần biết cách kế thừa nguyên mẫu JavaScript hoạt động. Khi phát triển các ứng dụng AngularJS, bạn sẽ tránh được một số cạm bẫy phổ biến nếu bạn hiểu rõ về kế thừa JavaScript. Đề nghị đọc: các sắc thái của thừa kế nguyên mẫu / nguyên mẫu trong AngularJS là gì?


1
bạn có thể xin vui lòng. giải thích làm thế nào một yếu tố dom khác với một quan điểm?
Rajkamal Subramanian

22
@rajkamal, một phần tử DOM (rõ ràng) là một phần tử duy nhất và trong jQuery thường là những gì chúng ta chọn / nhắm mục tiêu / thao tác. Chế độ xem góc là tập hợp / mẫu của các thành phần DOM có liên quan: chế độ xem menu, chế độ xem tiêu đề, chế độ xem chân trang, chế độ xem bên phải, chế độ xem tiểu sử, có thể nhiều chế độ xem nội dung chính (có thể chuyển đổi qua chế độ xem ng). Về cơ bản, bạn muốn chia (các) trang của mình thành các chế độ xem khác nhau. Mỗi khung nhìn có bộ điều khiển liên quan riêng. Mỗi khung nhìn dự án là một phần của mô hình của bạn.
Mark Rajcok

3
jQuery không bắt buộc. onwhenlà các hàm bậc cao hơn, hoạt động trên các thành viên của đối tượng bộ sưu tập jQuery.
Jack Viers

18
Vì vậy, loại mã nào được thực thi trong cuộc gọi lại cho on? Bắt buộc.
cwharris

5
Điều bắt buộc so với khai báo này thực sự chỉ là một câu hỏi trừu tượng. Cuối cùng, tất cả các mã khai báo (phải làm gì) được triển khai bắt buộc (cách thực hiện) bởi nhà phát triển trong chương trình con ở mức độ trừu tượng thấp hơn, bởi khung hoặc trình biên dịch / trình thông dịch. Nói chung, "jQuery là bắt buộc" nói chung là một tuyên bố khá kỳ quặc, đặc biệt khi xem xét rằng nó thực sự cung cấp API khai báo nhiều hơn liên quan đến thao tác DOM "thủ công".
Alex

184

AngularJS so với jQuery

AngularJS và jQuery áp dụng các ý thức hệ rất khác nhau. Nếu bạn đến từ jQuery, bạn có thể thấy một số khác biệt đáng ngạc nhiên. Angular có thể làm bạn tức giận.

Điều này là bình thường, bạn nên đẩy qua. Angular là giá trị nó.

Sự khác biệt lớn (TLDR)

jQuery cung cấp cho bạn một bộ công cụ để chọn các bit tùy ý của DOM và thực hiện các thay đổi đặc biệt đối với chúng. Bạn có thể làm khá nhiều thứ bạn thích từng mảnh.

AngularJS thay vào đó cung cấp cho bạn một trình biên dịch .

Điều này có nghĩa là AngularJS đọc toàn bộ DOM của bạn từ trên xuống dưới và coi nó là mã, theo nghĩa đen là hướng dẫn cho trình biên dịch. Khi nó đi qua DOM, Nó tìm kiếm các chỉ thị cụ thể (chỉ thị của trình biên dịch) cho trình biên dịch AngularJS biết cách ứng xử và phải làm gì. Chỉ thị là các đối tượng nhỏ chứa đầy JavaScript có thể khớp với các thuộc tính, thẻ, lớp hoặc thậm chí là nhận xét.

Khi trình biên dịch Angular xác định rằng một phần của DOM khớp với một lệnh cụ thể, nó gọi hàm chỉ thị, truyền cho nó phần tử DOM, bất kỳ thuộc tính nào, phạm vi $ hiện tại (là một kho lưu trữ biến cục bộ) và một số bit hữu ích khác. Các thuộc tính này có thể chứa các biểu thức có thể được Chỉ thị giải thích và cho biết cách hiển thị và khi nào nó nên vẽ lại.

Các chỉ thị sau đó có thể lần lượt kéo các thành phần Angular bổ sung như bộ điều khiển, dịch vụ, v.v ... Thứ xuất hiện dưới cùng của trình biên dịch là một ứng dụng web được hình thành đầy đủ, có dây và sẵn sàng hoạt động.

Điều này có nghĩa là Angular là Driven Template . Mẫu của bạn điều khiển JavaScript, không phải theo cách khác. Đây là một sự đảo ngược hoàn toàn của các vai trò và hoàn toàn trái ngược với JavaScript không phô trương mà chúng tôi đã viết trong 10 năm qua hoặc lâu hơn. Điều này có thể mất một số làm quen.

Nếu điều này nghe có vẻ như quá mức quy định và giới hạn, không có gì có thể xa hơn sự thật. Vì AngularJS coi HTML của bạn dưới dạng mã, bạn có được mức độ chi tiết của HTML trong ứng dụng web của mình . Mọi thứ đều có thể, và hầu hết mọi thứ đều dễ dàng một cách đáng ngạc nhiên khi bạn thực hiện một vài bước nhảy vọt về mặt khái niệm.

Chúng ta hãy xuống gritty nitty.

Đầu tiên, Angular không thay thế jQuery

Angular và jQuery làm những việc khác nhau. AngularJS cung cấp cho bạn một bộ công cụ để sản xuất các ứng dụng web. jQuery chủ yếu cung cấp cho bạn các công cụ để sửa đổi DOM. Nếu jQuery có mặt trên trang của bạn, AngularJS sẽ tự động sử dụng nó. Nếu không, AngularJS vận chuyển với jQuery Lite, đây là phiên bản rút gọn nhưng vẫn hoàn toàn có thể sử dụng được của jQuery.

Misko thích jQuery và không phản đối bạn khi sử dụng nó. Tuy nhiên, bạn sẽ thấy rằng bạn tiến bộ rằng bạn có thể hoàn thành khá nhiều công việc của mình bằng cách sử dụng kết hợp phạm vi, mẫu và chỉ thị, và bạn nên thích quy trình công việc này khi có thể vì mã của bạn sẽ rời rạc hơn, dễ cấu hình hơn và hơn thế nữa Góc cạnh.

Nếu bạn sử dụng jQuery, bạn không nên rắc nó khắp nơi. Vị trí chính xác cho thao tác DOM trong AngularJS là trong một lệnh. Thêm về những điều này sau.

JavaScript không phô trương với Bộ chọn so với Mẫu khai báo

jQuery thường được áp dụng không phô trương. Mã JavaScript của bạn được liên kết trong tiêu đề (hoặc chân trang) và đây là nơi duy nhất được đề cập. Chúng tôi sử dụng các công cụ chọn để chọn ra các bit của trang và viết các plugin để sửa đổi các phần đó.

JavaScript nằm trong tầm kiểm soát. HTML có một sự tồn tại hoàn toàn độc lập. HTML của bạn vẫn còn ngữ nghĩa ngay cả khi không có JavaScript. Thuộc tính Onclick là thực hành rất xấu.

Một trong những điều đầu tiên bạn sẽ chú ý về AngularJS là các thuộc tính tùy chỉnh có ở mọi nơi . HTML của bạn sẽ được lấp đầy với các thuộc tính ng, về cơ bản là các thuộc tính onClick trên steroid. Đây là các chỉ thị (chỉ thị của trình biên dịch) và là một trong những cách chính trong đó mẫu được nối với mô hình.

Khi bạn lần đầu tiên nhìn thấy điều này, bạn có thể muốn viết AngularJS như JavaScript xâm nhập trường học cũ (như tôi đã làm lúc đầu). Trên thực tế, AngularJS không chơi theo những quy tắc đó. Trong AngularJS, HTML5 của bạn là một mẫu. Nó được biên soạn bởi AngularJS để sản xuất trang web của bạn.

Đây là sự khác biệt lớn đầu tiên. Đối với jQuery, trang web của bạn là một DOM cần được thao tác. Đối với AngularJS, HTML của bạn là mã được biên dịch. AngularJS đọc trong toàn bộ trang web của bạn và thực sự biên dịch nó thành một trang web mới bằng trình biên dịch tích hợp.

Mẫu của bạn nên được khai báo; ý nghĩa của nó nên rõ ràng đơn giản bằng cách đọc nó. Chúng tôi sử dụng các thuộc tính tùy chỉnh với tên có ý nghĩa. Chúng tôi tạo ra các yếu tố HTML mới, một lần nữa với các tên có ý nghĩa. Một nhà thiết kế có kiến ​​thức HTML tối thiểu và không có kỹ năng mã hóa có thể đọc mẫu AngularJS của bạn và hiểu những gì nó đang làm. Anh ấy hoặc cô ấy có thể sửa đổi. Đây là cách Angular.

Các mẫu là trong ghế lái xe.

Một trong những câu hỏi đầu tiên tôi tự hỏi mình khi bắt đầu AngularJS và chạy qua các hướng dẫn là "Mã của tôi ở đâu?" . Tôi đã viết không có JavaScript và tôi có tất cả hành vi này. Câu trả lời là rõ ràng. Vì AngularJS biên dịch DOM, AngularJS đang coi HTML của bạn dưới dạng mã. Đối với nhiều trường hợp đơn giản, chỉ cần viết một mẫu và để AngularJS biên dịch nó thành một ứng dụng cho bạn là đủ.

Mẫu của bạn điều khiển ứng dụng của bạn. Nó được coi là DSL . Bạn viết các thành phần AngularJS và AngularJS sẽ đảm nhiệm việc kéo chúng vào và làm cho chúng có sẵn vào đúng thời điểm dựa trên cấu trúc của mẫu của bạn. Điều này rất khác với một mẫu MVC tiêu chuẩn , trong đó mẫu chỉ dành cho đầu ra.

Nó giống với XSLT hơn là Ruby on Rails chẳng hạn.

Đây là một sự đảo ngược triệt để của kiểm soát mà một số làm quen.

Ngừng cố gắng lái ứng dụng của bạn từ JavaScript của bạn. Hãy để mẫu điều khiển ứng dụng và để AngularJS đảm nhiệm việc nối các thành phần lại với nhau. Đây cũng là cách Angular.

HTML ngữ nghĩa so với mô hình ngữ nghĩa

Với jQuery, trang HTML của bạn sẽ chứa nội dung có ý nghĩa ngữ nghĩa. Nếu JavaScript bị tắt (bởi người dùng hoặc công cụ tìm kiếm), nội dung của bạn vẫn có thể truy cập được.

Bởi vì AngularJS coi trang HTML của bạn dưới dạng mẫu. Mẫu không được coi là ngữ nghĩa vì nội dung của bạn thường được lưu trữ trong mô hình của bạn, cuối cùng xuất phát từ API của bạn. AngularJS biên dịch DOM của bạn với mô hình để tạo ra một trang web ngữ nghĩa.

Nguồn HTML của bạn không còn là ngữ nghĩa, thay vào đó, API và DOM được biên dịch của bạn là ngữ nghĩa.

Trong AngularJS, có nghĩa là sống trong mô hình, HTML chỉ là một mẫu, chỉ để hiển thị.

Tại thời điểm này, bạn có thể có tất cả các loại câu hỏi liên quan đến SEO và khả năng truy cập, và đúng như vậy. Có những vấn đề mở ở đây. Hầu hết các trình đọc màn hình bây giờ sẽ phân tích JavaScript. Công cụ tìm kiếm cũng có thể lập chỉ mục nội dung AJAXed . Tuy nhiên, bạn sẽ muốn đảm bảo rằng bạn đang sử dụng URL đẩy và bạn có một sơ đồ trang web phù hợp. Xem ở đây để thảo luận về vấn đề: https://stackoverflow.com/a/23245379/687677

Phân tách mối quan tâm (SOC) so với MVC

Tách biệt mối quan tâm (SOC) là một mô hình phát triển qua nhiều năm phát triển web vì nhiều lý do bao gồm SEO, khả năng truy cập và không tương thích trình duyệt. Nó trông như thế này:

  1. HTML - Ý nghĩa ngữ nghĩa. HTML nên đứng một mình.
  2. CSS - Kiểu dáng, không có CSS, trang vẫn có thể đọc được.
  3. JavaScript - Hành vi, không có tập lệnh, nội dung vẫn còn.

Một lần nữa, AngularJS không chơi theo luật của họ. Trong một cơn đột quỵ, AngularJS đã loại bỏ một thập kỷ khôn ngoan nhận được và thay vào đó thực hiện một mô hình MVC trong đó mẫu không còn là ngữ nghĩa, thậm chí không một chút.

Nó trông như thế này:

  1. Mô hình - mô hình của bạn chứa dữ liệu ngữ nghĩa của bạn. Các mô hình thường là các đối tượng JSON . Các mô hình tồn tại dưới dạng các thuộc tính của một đối tượng được gọi là $ scope. Bạn cũng có thể lưu trữ các hàm tiện ích tiện dụng trên $ scope mà mẫu của bạn có thể truy cập.
  2. Chế độ xem - Quan điểm của bạn được viết bằng HTML. Khung nhìn thường không phải là ngữ nghĩa vì dữ liệu của bạn nằm trong mô hình.
  3. Trình điều khiển - Trình điều khiển của bạn là một hàm JavaScript nối khung nhìn vào mô hình. Chức năng của nó là khởi tạo $ scope. Tùy thuộc vào ứng dụng của bạn, bạn có thể hoặc không cần tạo bộ điều khiển. Bạn có thể có nhiều bộ điều khiển trên một trang.

MVC và SOC không nằm ở hai đầu đối diện của cùng một tỷ lệ, chúng nằm trên các trục hoàn toàn khác nhau. SOC không có ý nghĩa trong bối cảnh AngularJS. Bạn phải quên nó và đi tiếp.

Nếu, giống như tôi, bạn đã sống qua các cuộc chiến trình duyệt, bạn có thể thấy ý tưởng này khá phản cảm. Hãy vượt qua nó, nó sẽ có giá trị, tôi hứa.

Plugin so với chỉ thị

Các plugin mở rộng jQuery. AngularJS Chỉ thị mở rộng khả năng của trình duyệt của bạn.

Trong jQuery, chúng tôi xác định các plugin bằng cách thêm các hàm vào jQuery.prototype. Sau đó, chúng tôi nối chúng vào DOM bằng cách chọn các thành phần và gọi plugin trên kết quả. Ý tưởng là mở rộng các khả năng của jQuery.

Ví dụ: nếu bạn muốn một băng chuyền trên trang của mình, bạn có thể xác định một danh sách các số liệu không có thứ tự, có thể được bọc trong một yếu tố điều hướng. Sau đó, bạn có thể viết một số jQuery để chọn danh sách trên trang và sắp xếp lại nó dưới dạng một bộ sưu tập với thời gian chờ để thực hiện hoạt hình trượt.

Trong AngularJS, chúng tôi xác định các chỉ thị. Lệnh này là một hàm trả về một đối tượng JSON. Đối tượng này cho AngularJS biết các phần tử DOM cần tìm và những thay đổi để thực hiện đối với chúng. Các chỉ thị được nối vào mẫu bằng cách sử dụng các thuộc tính hoặc thành phần mà bạn phát minh ra. Ý tưởng là mở rộng khả năng của HTML với các thuộc tính và thành phần mới.

Cách AngularJS là mở rộng khả năng của HTML tìm kiếm gốc. Bạn nên viết HTML trông giống như HTML, được mở rộng với các thuộc tính và thành phần tùy chỉnh.

Nếu bạn muốn một băng chuyền, chỉ cần sử dụng một <carousel />yếu tố, sau đó xác định một lệnh để lấy một mẫu và làm cho trình hút đó hoạt động.

Rất nhiều chỉ thị nhỏ so với các plugin lớn có công tắc cấu hình

Xu hướng với jQuery là viết các plugin lớn như hộp đèn mà sau đó chúng ta định cấu hình bằng cách chuyển qua nhiều giá trị và tùy chọn.

Đây là một sai lầm trong AngularJS.

Lấy ví dụ về một thả xuống. Khi viết một trình đơn thả xuống, bạn có thể muốn viết mã trong trình xử lý nhấp chuột, có thể là một chức năng để thêm một chevron lên hoặc xuống, có thể thay đổi lớp của phần tử chưa mở, hiển thị ẩn menu, tất cả nội dung hữu ích.

Cho đến khi bạn muốn thực hiện một thay đổi nhỏ.

Giả sử bạn có một menu mà bạn muốn mở ra khi di chuột. Bây giờ chúng tôi có một vấn đề. Plugin của chúng tôi có dây trong trình xử lý nhấp chuột cho chúng tôi, chúng tôi sẽ cần thêm tùy chọn cấu hình để làm cho nó hoạt động khác đi trong trường hợp cụ thể này.

Trong AngularJS chúng tôi viết các chỉ thị nhỏ hơn. Chỉ thị thả xuống của chúng tôi sẽ rất nhỏ. Nó có thể duy trì trạng thái gấp và cung cấp các phương thức để gập (), mở ra () hoặc chuyển đổi (). Các phương thức này chỉ đơn giản là cập nhật $ scope.menu.visible, một boolean giữ trạng thái.

Bây giờ trong mẫu của chúng tôi, chúng tôi có thể kết nối này:

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

Cần cập nhật trên mouseover?

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

Mẫu điều khiển ứng dụng để chúng tôi có được mức độ chi tiết HTML. Nếu chúng ta muốn tạo trường hợp ngoại lệ theo từng trường hợp, mẫu sẽ làm điều này dễ dàng.

Đóng cửa so với phạm vi $

Các plugin JQuery được tạo trong một bao đóng. Quyền riêng tư được duy trì trong phạm vi đóng cửa đó. Tùy thuộc vào bạn để duy trì chuỗi phạm vi của bạn trong phạm vi đóng cửa đó. Bạn chỉ thực sự có quyền truy cập vào tập hợp các nút DOM được jQuery truyền vào plugin, cộng với bất kỳ biến cục bộ nào được xác định trong bao đóng và bất kỳ toàn cục nào bạn đã xác định. Điều này có nghĩa là các plugin khá khép kín. Đây là một điều tốt, nhưng có thể bị hạn chế khi tạo toàn bộ ứng dụng. Cố gắng truyền dữ liệu giữa các phần của trang động trở thành một việc vặt.

AngularJS có các đối tượng $ scope. Đây là những đối tượng đặc biệt được tạo và duy trì bởi AngularJS nơi bạn lưu trữ mô hình của mình. Một số chỉ thị nhất định sẽ sinh ra một phạm vi $ mới, theo mặc định kế thừa từ phạm vi gói của nó bằng cách sử dụng kế thừa nguyên mẫu JavaScript. Đối tượng $ scope có thể truy cập được trong bộ điều khiển và khung nhìn.

Đây là phần thông minh. Do cấu trúc của thừa kế phạm vi $ gần như theo cấu trúc của DOM, nên các phần tử có quyền truy cập vào phạm vi riêng của chúng và mọi phạm vi có chứa liền mạch, cho đến phạm vi toàn cầu $ (không giống với phạm vi toàn cầu).

Điều này giúp việc truyền dữ liệu xung quanh dễ dàng hơn và lưu trữ dữ liệu ở mức phù hợp. Nếu một danh sách thả xuống được mở ra, chỉ có phạm vi $ thả xuống cần biết về nó. Nếu người dùng cập nhật tùy chọn của họ, bạn có thể muốn cập nhật phạm vi $ toàn cầu và mọi phạm vi lồng nhau lắng nghe tùy chọn người dùng sẽ tự động được cảnh báo.

Điều này nghe có vẻ phức tạp, trên thực tế, một khi bạn thư giãn vào nó, nó giống như đang bay. Bạn không cần phải tạo đối tượng $ scope, AngularJS khởi tạo và định cấu hình nó cho bạn, một cách chính xác và phù hợp dựa trên hệ thống phân cấp mẫu của bạn. AngularJS sau đó làm cho nó có sẵn cho thành phần của bạn bằng cách sử dụng phép thuật tiêm phụ thuộc (nhiều hơn về điều này sau).

Thay đổi DOM thủ công so với liên kết dữ liệu

Trong jQuery, bạn thực hiện tất cả các thay đổi DOM của mình bằng tay. Bạn xây dựng các phần tử DOM mới theo chương trình. Nếu bạn có một mảng JSON và bạn muốn đặt nó vào DOM, bạn phải viết một hàm để tạo HTML và chèn nó vào.

Trong AngularJS bạn cũng có thể làm điều này, nhưng bạn được khuyến khích sử dụng ràng buộc dữ liệu. Thay đổi mô hình của bạn và vì DOM được liên kết với nó thông qua một mẫu mà DOM của bạn sẽ tự động cập nhật, không cần can thiệp.

Vì liên kết dữ liệu được thực hiện từ mẫu, sử dụng thuộc tính hoặc cú pháp dấu ngoặc nhọn, nên việc này rất dễ thực hiện. Có rất ít chi phí nhận thức liên quan đến nó vì vậy bạn sẽ thấy mình làm việc đó mọi lúc.

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

Liên kết các yếu tố đầu vào $scope.user.name. Cập nhật đầu vào sẽ cập nhật giá trị trong phạm vi hiện tại của bạn và ngược lại.

Tương tự như vậy:

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

sẽ xuất tên người dùng trong một đoạn văn. Đó là một ràng buộc trực tiếp, vì vậy nếu $scope.user.namegiá trị được cập nhật, mẫu cũng sẽ cập nhật.

Ajax mọi lúc

Trong jQuery, việc thực hiện một cuộc gọi Ajax khá đơn giản, nhưng đây vẫn là điều bạn có thể nghĩ hai lần. Có thêm sự phức tạp để suy nghĩ và một đoạn kịch bản hợp lý để duy trì.

Trong AngularJS, Ajax là giải pháp đi đến mặc định của bạn và nó xảy ra mọi lúc, hầu như bạn không nhận ra. Bạn có thể bao gồm các mẫu với ng-gộp. Bạn có thể áp dụng một mẫu với chỉ thị tùy chỉnh đơn giản nhất. Bạn có thể gói một cuộc gọi Ajax trong một dịch vụ và tạo cho mình một dịch vụ GitHub hoặc dịch vụ Flickr mà bạn có thể truy cập một cách dễ dàng đáng kinh ngạc.

Đối tượng dịch vụ và chức năng trợ giúp

Trong jQuery, nếu chúng ta muốn thực hiện một nhiệm vụ không liên quan nhỏ như lấy nguồn cấp dữ liệu từ API, chúng ta có thể viết một hàm nhỏ để thực hiện điều đó trong phần đóng của chúng ta. Đó là một giải pháp hợp lệ, nhưng nếu chúng ta muốn truy cập nguồn cấp dữ liệu đó thường xuyên thì sao? Điều gì xảy ra nếu chúng ta muốn sử dụng lại mã đó trong một ứng dụng khác?

AngularJS cung cấp cho chúng tôi các đối tượng dịch vụ.

Dịch vụ là các đối tượng đơn giản có chứa các chức năng và dữ liệu. Họ luôn là những người độc thân, có nghĩa là không bao giờ có thể có nhiều hơn một trong số họ. Giả sử chúng tôi muốn truy cập API Stack Overflow, chúng tôi có thể viết một StackOverflowServiceđịnh nghĩa các phương thức để làm như vậy.

Hãy nói rằng chúng tôi có một giỏ hàng. Chúng tôi có thể xác định một ShoppingCartService duy trì giỏ hàng của chúng tôi và chứa các phương thức để thêm và xóa các mục. Bởi vì dịch vụ là một singleton và được chia sẻ bởi tất cả các thành phần khác, bất kỳ đối tượng nào cần có thể ghi vào giỏ hàng và lấy dữ liệu từ nó. Nó luôn luôn là cùng một giỏ hàng.

Các đối tượng dịch vụ là các thành phần AngularJS độc lập mà chúng ta có thể sử dụng và tái sử dụng khi chúng ta thấy phù hợp. Chúng là các đối tượng JSON đơn giản chứa các hàm và Dữ liệu. Chúng luôn là các singletons, vì vậy nếu bạn lưu trữ dữ liệu trên một dịch vụ ở một nơi, bạn có thể lấy dữ liệu đó ra một nơi khác chỉ bằng cách yêu cầu cùng một dịch vụ.

Tiêm phụ thuộc (DI) so với Instatiation - còn gọi là khử spaghettization

AngularJS quản lý các phụ thuộc của bạn cho bạn. Nếu bạn muốn một đối tượng, chỉ cần tham khảo nó và AngularJS sẽ lấy nó cho bạn.

Cho đến khi bạn bắt đầu sử dụng cái này, thật khó để giải thích thời gian khổng lồ này là gì. Không có gì giống như AngularJS DI tồn tại trong jQuery.

DI có nghĩa là thay vì viết ứng dụng của bạn và nối nó với nhau, thay vào đó bạn xác định một thư viện các thành phần, mỗi thành phần được xác định bởi một chuỗi.

Giả sử tôi có một thành phần gọi là 'FlickrService', định nghĩa các phương thức để lấy nguồn cấp JSON từ Flickr. Bây giờ, nếu tôi muốn viết một bộ điều khiển có thể truy cập Flickr, tôi chỉ cần tham khảo 'FlickrService' theo tên khi tôi khai báo bộ điều khiển. AngularJS sẽ đảm nhiệm việc khởi tạo thành phần và cung cấp nó cho bộ điều khiển của tôi.

Ví dụ: ở đây tôi định nghĩa một dịch vụ:

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

Bây giờ khi tôi muốn sử dụng dịch vụ đó, tôi chỉ cần gọi nó bằng tên như thế này:

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

AngularJS sẽ nhận ra rằng một đối tượng FlickrService là cần thiết để khởi tạo bộ điều khiển và sẽ cung cấp một đối tượng cho chúng ta.

Điều này làm cho việc kết nối mọi thứ với nhau rất dễ dàng và khá nhiều loại bỏ mọi xu hướng phát triển. Chúng tôi có một danh sách các thành phần phẳng và AngularJS trao chúng cho chúng tôi từng cái một và khi chúng tôi cần chúng.

Kiến trúc mô đun dịch vụ

jQuery nói rất ít về cách bạn nên tổ chức mã của mình. AngularJS có ý kiến.

AngularJS cung cấp cho bạn các mô-đun để bạn có thể đặt mã của mình. Ví dụ: nếu bạn đang viết tập lệnh nói chuyện với Flickr, bạn có thể muốn tạo mô-đun Flickr để bọc tất cả các chức năng liên quan đến Flickr của mình. Các mô-đun có thể bao gồm các mô-đun khác (DI). Ứng dụng chính của bạn thường là một mô-đun và điều này sẽ bao gồm tất cả các mô-đun khác mà ứng dụng của bạn sẽ phụ thuộc vào.

Bạn có thể sử dụng lại mã đơn giản, nếu bạn muốn viết một ứng dụng khác dựa trên Flickr, bạn chỉ cần bao gồm mô-đun Flickr và voila, bạn có quyền truy cập vào tất cả các chức năng liên quan đến Flickr trong ứng dụng mới của mình.

Các mô-đun chứa các thành phần AngularJS. Khi chúng tôi bao gồm một mô-đun, tất cả các thành phần trong mô-đun đó sẽ có sẵn cho chúng tôi dưới dạng một danh sách đơn giản được xác định bởi các chuỗi duy nhất của chúng . Sau đó chúng ta có thể tiêm các thành phần đó vào nhau bằng cơ chế tiêm phụ thuộc của AngularJS.

Tóm lại

AngularJS và jQuery không phải là kẻ thù. Có thể sử dụng jQuery trong AngularJS rất độc đáo. Nếu bạn đang sử dụng AngularJS tốt (mẫu, liên kết dữ liệu, $ phạm vi, chỉ thị, vv), bạn sẽ tìm thấy bạn cần một nhiều ít jQuery hơn bạn khác có thể yêu cầu.

Điều chính để nhận ra là mẫu của bạn điều khiển ứng dụng của bạn. Ngừng cố gắng viết các plugin lớn làm mọi thứ. Thay vào đó hãy viết các chỉ thị nhỏ làm một việc, sau đó viết một mẫu đơn giản để nối chúng lại với nhau.

Nghĩ ít hơn về JavaScript không phô trương và thay vào đó hãy nghĩ về các phần mở rộng HTML.

Cuốn sách nhỏ của tôi

Tôi đã rất hào hứng với AngularJS, tôi đã viết một cuốn sách ngắn về nó mà bạn rất hoan nghênh khi đọc trực tuyến http://nicholasjohnson.com/angular-book/ . Tôi hy vọng nó hữu ích.


6
Ý tưởng rằng "Tách biệt các mối quan tâm" khác với "MVC (Model, View, Controller)" là hoàn toàn không có thật. Mô hình ngôn ngữ web phân tách mối quan tâm (HTML, CSS và JS) làm như vậy bằng cách cho phép mọi người đặt nội dung lên trang web (đánh dấu / HTML) mà không cần quan tâm đến giao diện của nó (kiểu dáng / bố cục / CSS) hoặc "nó làm gì" (Sự kiện DOM / AJAX / JavaScript). MVC cũng phân tách mối quan tâm. Mỗi "lớp" trong mẫu MVC có một vai trò riêng - dữ liệu, định tuyến / logic hoặc kết xuất. Các lớp được ghép bởi các cuộc gọi lại, các tuyến và các ràng buộc mô hình. Về lý thuyết, một người có thể chuyên về từng lớp, thường là trường hợp.

Là một người đến từ nền tảng SOC nghiêm ngặt và là người ủng hộ lâu dài cho các tiêu chuẩn web có từ thời chiến tranh trình duyệt, ban đầu tôi thấy các mẫu phi ngữ nghĩa, không xác thực của Angular gây phiền hà. Tôi chỉ muốn làm rõ rằng để viết Angular cần phải từ bỏ SOC vì nó thường được thực hành. Đây có thể là một quá trình chuyển đổi khó khăn.
siêu sáng

Bạn nói đúng. SOC là một thuật ngữ rộng, nhưng trong thế giới web SOC có (hoặc có thể có) một ý nghĩa rất cụ thể: HTML ngữ nghĩa, CSS trình bày và JavaScript cho hành vi. Tôi đang đưa ra một số giả định về đối tượng của mình có lẽ không hợp lý, vì vậy tôi cũng nên xin lỗi.
siêu sáng

Tôi tìm thấy câu trả lời của bạn rõ ràng nhất và khai sáng. Tôi khá là người mới ở đây, vì vậy, nếu tôi có tiện ích mở rộng để thay đổi trang hiện có (mà tôi không kiểm soát), tôi có nên giữ JQuery không?
Daniel Möller

152

Bạn có thể mô tả sự thay đổi mô hình là cần thiết?

Bắt buộc vs Tuyên bố

Với jQuery, bạn nói với DOM những gì cần xảy ra, từng bước một. Với AngularJS bạn mô tả kết quả bạn muốn nhưng không phải làm thế nào để làm điều đó. Thêm về điều này ở đây . Ngoài ra, hãy xem câu trả lời của Mark Rajcok.

Làm cách nào để kiến ​​trúc sư và thiết kế các ứng dụng web phía khách hàng khác nhau?

AngularJS là toàn bộ khung công tác phía máy khách sử dụng mẫu MVC (kiểm tra biểu diễn đồ họa của chúng ). Nó tập trung rất nhiều vào việc tách các mối quan tâm.

Sự khác biệt lớn nhất là gì? Tôi nên ngừng làm gì / sử dụng; Tôi nên bắt đầu làm gì / sử dụng thay thế?

jQuery là một thư viện

AngularJS là một khung công tác phía máy khách đẹp, có khả năng kiểm tra cao, kết hợp hàng tấn công cụ tuyệt vời như MVC, tiêm phụ thuộc , ràng buộc dữ liệu và nhiều hơn nữa.

Nó tập trung vào việc tách các mối quan tâm và thử nghiệm (thử nghiệm đơn vịthử nghiệm đầu cuối), tạo điều kiện cho sự phát triển dựa trên thử nghiệm.

Cách tốt nhất để bắt đầu là trải qua hướng dẫn tuyệt vời của họ . Bạn có thể đi qua các bước trong một vài giờ; tuy nhiên, trong trường hợp bạn muốn nắm vững các khái niệm đằng sau hậu trường, chúng bao gồm vô số tài liệu tham khảo để đọc thêm.

Có bất kỳ cân nhắc / hạn chế phía máy chủ?

Bạn có thể sử dụng nó trên các ứng dụng hiện có nơi bạn đang sử dụng jQuery thuần túy. Tuy nhiên, nếu bạn muốn tận dụng tối đa các tính năng của AngularJS, bạn có thể xem xét mã hóa phía máy chủ bằng cách sử dụng phương pháp RESTful .

Làm như vậy sẽ cho phép bạn tận dụng nhà máy tài nguyên của họ , điều này tạo ra sự trừu tượng hóa API RESTful phía máy chủ của bạn và thực hiện các cuộc gọi phía máy chủ (nhận, lưu, xóa, v.v.) cực kỳ dễ dàng.


27
Tôi nghĩ rằng bạn đang làm vấy bẩn vùng biển bằng cách nói về cách jQuery là một "thư viện" và Angular là một "khung" ... vì một điều, tôi nghĩ có thể tranh luận rằng jQuery một khung ... đó là một sự trừu tượng thao tác DOM và xử lý sự kiện. Nó có thể không phải là khuôn khổ cho cùng một loại mà Angular là, nhưng đó là vấn đề nan giải mà người hỏi đặt ra: họ không thực sự biết sự khác biệt giữa Angular và jQuery và đối với tất cả những người hỏi đều biết, jQuery một khuôn khổ để xây dựng các trang web nặng khách hàng. Vì vậy, tranh luận về thuật ngữ sẽ không làm sáng tỏ mọi thứ.
Zando

15
Tôi nghĩ bạn là người đang bị lẫn lộn. Câu hỏi này giải quyết chính xác stackoverflow.com/questions/7062775 này . Ngoài ra, câu trả lời này có thể giúp làm rõ sự khác biệt giữa khung và thư viện: stackoverflow.com/a/148759/620448
Ulises

6
Một thư viện không trở thành một "khung" chỉ vì bộ sưu tập các hàm của nó đặc biệt hữu ích hoặc lớn. Một khuôn khổ đưa ra quyết định cho bạn. Khi bạn bắt đầu sử dụng AngularJS, bạn có khả năng trở nên gắn kết với nó bởi bản chất của nó. (Ví dụ: Bạn chỉ nên cập nhật DOM theo chỉ thị, nếu không sẽ có thứ gì đó gây rối.) Đó là vì AngularJS là một khung. Khi bạn sử dụng jQuery, bạn có thể trộn và kết hợp các công cụ tương đối dễ dàng với rủi ro xung đột tối thiểu. Đó là bởi vì jQuery là một thư viện và cũng ít nhất là một nửa.

8
Một thư viện là mã mà bạn gọi. Một khung là mã gọi mã của bạn. Theo định nghĩa này Angular là một khung. Bạn cung cấp cho nó các thành phần và Angular thấy rằng các thành phần của bạn được khởi tạo với các phụ thuộc mà chúng cần.
siêu sáng

84

Để mô tả "sự thay đổi mô hình", tôi nghĩ rằng một câu trả lời ngắn có thể đủ.

AngularJS thay đổi cách bạn tìm thấy các yếu tố

Trong jQuery , bạn thường sử dụng các bộ chọn để tìm các phần tử và sau đó nối chúng lại:
$('#id .class').click(doStuff);

Trong AngularJS , bạn sử dụng các chỉ thị để đánh dấu các phần tử trực tiếp, để nối chúng:
<a ng-click="doStuff()">

AngularJS không cần (hoặc muốn) bạn tìm các phần tử bằng cách sử dụng các bộ chọn - điểm khác biệt chính giữa jqLite của AngularJS so với jQuery toàn diện là jqLite không hỗ trợ các bộ chọn .

Vì vậy, khi mọi người nói "hoàn toàn không bao gồm jQuery", chủ yếu là vì họ không muốn bạn sử dụng các công cụ chọn; thay vào đó họ muốn bạn học cách sử dụng chỉ thị. Trực tiếp, không chọn!


13
Cũng giống như từ chối trách nhiệm, có NHIỀU sự khác biệt lớn hơn giữa Angular và jQuery. Nhưng tìm kiếm các yếu tố là một trong đó đòi hỏi sự thay đổi lớn nhất về tư duy.
Scott Rippey

1
Hãy tha thứ cho tôi nếu tôi sai, nhưng tôi nghĩ rằng bộ chọn là thứ bạn sử dụng để tìm phần tử DOM? Bạn muốn giữ mọi phần của giao diện người dùng mới được tải của mình trong tài liệu tham khảo, thay vì chỉ chọn một hoặc 2 yếu tố mà người dùng có thể nhấp vào, đang di chuyển bằng bộ chọn? Nghe có vẻ khó hơn đối với tôi ..
RozzA

3
@AlexanderPritchard Điểm của Angular là bạn không chọn từ JavaScript, bạn trực tiếp từ mẫu của bạn. Đó là một sự đảo ngược của sự kiểm soát đặt quyền lực vào tay nhà thiết kế. Đây là một nguyên tắc thiết kế có chủ ý. Để thực sự có được Angular, bạn cần phải suy nghĩ về mã của mình theo cách này. Đó là một sự thay đổi khó khăn để thực hiện.
siêu sáng

3
@superluminary Thật là một trích dẫn tuyệt vời! "không chọn; trực tiếp!" Nghiêm túc mà nói, tôi sẽ sử dụng nó.
Scott Rippey

1
Đây là một trong những điều yêu thích của tôi về AngularJS. Tôi không phải lo lắng về việc đội UX phá vỡ chức năng của tôi hoặc tôi phá vỡ phong cách của họ. Họ sử dụng các lớp học, tôi sử dụng chỉ thị, thời gian. Tôi không bỏ lỡ các lựa chọn một chút.
adam0101

69

jQuery

jQuery tạo ra các lệnh JavaScript dài một cách lố bịch như getElementByHerpDerptrình duyệt ngắn hơn và chéo.

AngularJS

AngularJS cho phép bạn tạo các thẻ / thuộc tính HTML của riêng bạn, hoạt động tốt với các ứng dụng web động (vì HTML được thiết kế cho các trang tĩnh).

Biên tập:

Nói rằng "Tôi có một nền tảng jQuery làm thế nào để tôi nghĩ trong AngularJS?" giống như nói "Tôi có một nền tảng HTML tôi nghĩ như thế nào về JavaScript?" Thực tế là bạn đang đặt câu hỏi cho thấy rất có thể bạn không hiểu mục đích cơ bản của hai tài nguyên này. Đây là lý do tại sao tôi chọn trả lời câu hỏi bằng cách chỉ ra sự khác biệt cơ bản thay vì đi qua danh sách nói rằng "AngularJS sử dụng các lệnh trong khi jQuery sử dụng các bộ chọn CSS để tạo một đối tượng jQuery thực hiện điều này và vv ...." . Câu hỏi này không yêu cầu một câu trả lời dài.

jQuery là một cách để làm cho lập trình JavaScript trong trình duyệt dễ dàng hơn. Các lệnh trình duyệt chéo ngắn hơn, v.v.

AngularJS mở rộng HTML, vì vậy bạn không cần phải đặt <div>khắp nơi chỉ để tạo một ứng dụng. Nó làm cho HTML thực sự hoạt động cho các ứng dụng thay vì những gì nó được thiết kế cho, đó là các trang web giáo dục tĩnh. Nó thực hiện điều này theo cách xoay vòng bằng JavaScript, nhưng về cơ bản, nó là một phần mở rộng của HTML, không phải JavaScript.


@Robert phụ thuộc vào những gì bạn đang làm. $(".myclass")là cực kỳ phổ biến và dễ dàng hơn một chút trong jQuery so với PO-Javascript.
Rob Grant

61

jQuery: bạn nghĩ rất nhiều về 'HỎI DOM ' cho các phần tử DOM và làm một cái gì đó.

AngularJS: Mô hình là sự thật và bạn luôn nghĩ từ ANGLE đó.

Ví dụ: khi bạn lấy dữ liệu từ máy chủ THE mà bạn dự định hiển thị ở một số định dạng trong DOM, trong jQuery, bạn cần phải '1. TÌM 'nơi trong DOM bạn muốn đặt dữ liệu này,' 2. CẬP NHẬT / PHỤ LỤC 'nó ở đó bằng cách tạo một nút mới hoặc chỉ thiết lập bên trongHTML của nó . Sau đó, khi bạn muốn cập nhật chế độ xem này, bạn sẽ '3. TÌM 'vị trí và' 4. CẬP NHẬT '. Chu trình tìm và cập nhật tất cả được thực hiện trong cùng bối cảnh nhận và định dạng dữ liệu từ máy chủ đã biến mất trong AngularJS.

Với AngularJS, bạn có mô hình của mình (các đối tượng JavaScript mà bạn đã quen) và giá trị của mô hình cho bạn biết về mô hình (rõ ràng) và về chế độ xem, và một thao tác trên mô hình sẽ tự động truyền tới khung nhìn, vì vậy bạn không ' T phải suy nghĩ về nó. Bạn sẽ thấy mình trong AngularJS không còn tìm thấy những thứ trong DOM.

Nói cách khác, trong jQuery, bạn cần suy nghĩ về các bộ chọn CSS, nghĩa là, nơi có divhoặc tdcó một lớp hoặc thuộc tính, v.v., để tôi có thể lấy HTML hoặc màu hoặc giá trị của chúng, nhưng trong AngularJS, bạn sẽ thấy mình suy nghĩ như thế này: tôi đang xử lý mô hình nào, tôi sẽ đặt giá trị của mô hình thành đúng. Bạn không bận tâm về việc khung nhìn phản ánh giá trị này là hộp được chọn hay nằm trong một tdphần tử (chi tiết bạn thường cần phải suy nghĩ trong jQuery).

Và với thao tác DOM trong AngularJS, bạn thấy mình thêm các chỉ thị và bộ lọc mà bạn có thể nghĩ là các tiện ích mở rộng HTML hợp lệ.

Một điều nữa bạn sẽ trải nghiệm trong AngularJS: trong jQuery bạn gọi các hàm jQuery rất nhiều, trong AngularJS, AngularJS sẽ gọi các hàm của bạn, vì vậy AngularJS sẽ 'cho bạn biết cách làm mọi thứ', nhưng lợi ích là đáng giá, vì vậy hãy học AngularJS thường có nghĩa là học những gì AngularJS muốn hoặc cách AngularJS yêu cầu bạn trình bày các chức năng của mình và nó sẽ gọi nó phù hợp. Đây là một trong những điều làm cho AngularJS trở thành một khung chứ không phải là một thư viện.


46

Đó là một số câu trả lời rất hay, nhưng dài.

Tổng hợp kinh nghiệm của tôi:

  1. Bộ điều khiển và nhà cung cấp (dịch vụ, nhà máy, v.v.) là để sửa đổi mô hình dữ liệu, KHÔNG phải HTML.
  2. HTML và các chỉ thị xác định bố cục và ràng buộc với mô hình.
  3. Nếu bạn cần chia sẻ dữ liệu giữa các bộ điều khiển, hãy tạo một dịch vụ hoặc nhà máy - chúng là các singletons được chia sẻ trên ứng dụng.
  4. Nếu bạn cần một tiện ích HTML, hãy tạo một lệnh.
  5. Nếu bạn có một số dữ liệu và hiện đang cố cập nhật HTML ... DỪNG! cập nhật mô hình và đảm bảo HTML của bạn được liên kết với mô hình.

45

jQuery là một thư viện thao tác DOM.

AngularJS là một khung MV *.

Trên thực tế, AngularJS là một trong số ít các khung JavaScript MV * (nhiều công cụ JavaScript MVC vẫn thuộc thư viện danh mục).

Là một khung công tác, nó lưu trữ mã của bạn và có quyền quyết định về những gì sẽ gọi và khi nào!

Bản thân AngularJS bao gồm một phiên bản jQuery-lite bên trong nó. Vì vậy, đối với một số thao tác lựa chọn / thao tác DOM cơ bản, bạn thực sự không cần phải bao gồm thư viện jQuery (nó tiết kiệm nhiều byte để chạy trên mạng.)

AngularJS có khái niệm "Chỉ thị" cho thao tác DOM và thiết kế các thành phần UI có thể sử dụng lại, vì vậy bạn nên sử dụng nó bất cứ khi nào bạn cảm thấy cần thực hiện các công cụ liên quan đến thao tác DOM (chỉ thị là nơi bạn nên viết mã jQuery trong khi sử dụng AngularJS).

AngularJS liên quan đến một số đường cong học tập (nhiều hơn jQuery :-).

-> Đối với bất kỳ nhà phát triển nào đến từ nền jQuery, lời khuyên đầu tiên của tôi là "học JavaScript như ngôn ngữ hạng nhất trước khi nhảy vào một khung công tác phong phú như AngularJS!" Tôi đã học được thực tế ở trên một cách khó khăn.

Chúc may mắn.


34

Chúng là táo và cam. Bạn không muốn so sánh chúng. Chúng là hai thứ khác nhau. AngularJs đã tích hợp sẵn jQuery cho phép bạn thực hiện thao tác DOM cơ bản mà không bao gồm phiên bản jQuery đầy đủ.

jQuery là tất cả về thao tác DOM. Nó giải quyết tất cả nỗi đau của trình duyệt chéo nếu không bạn sẽ phải đối phó nhưng đó không phải là một khung cho phép bạn chia ứng dụng của mình thành các thành phần như AngularJS.

Một điều thú vị về AngularJs là nó cho phép bạn tách / tách biệt thao tác DOM trong các lệnh. Có các chỉ thị tích hợp sẵn sàng để bạn sử dụng như ng-click. Bạn có thể tạo các chỉ thị tùy chỉnh của riêng mình, nó sẽ chứa tất cả logic xem hoặc thao tác DOM của bạn để bạn không kết thúc mã thao tác DOM trong các bộ điều khiển hoặc dịch vụ cần xử lý logic nghiệp vụ.

Angular chia nhỏ ứng dụng của bạn thành - Bộ điều khiển - Dịch vụ - Lượt xem - v.v.

và có một điều nữa, đó là chỉ thị. Đây là một thuộc tính bạn có thể đính kèm với bất kỳ thành phần DOM nào và bạn có thể sử dụng jQuery trong đó mà không phải lo lắng về việc jQuery của bạn có xung đột với các thành phần AngularJs hay làm rối tung kiến ​​trúc của nó.

Tôi đã nghe từ một cuộc họp mà tôi tham dự, một trong những người sáng lập Angular nói rằng họ đã làm việc rất chăm chỉ để tách ra các thao tác DOM vì vậy đừng cố gắng đưa họ trở lại.


31

Nghe podcast JavaScript Jabber: Tập # 32 có sự góp mặt của những người sáng tạo ban đầu của AngularJS: Misko Hevery & Igor Minar. Họ nói rất nhiều về những gì nó muốn đến với AngularJS từ các nền tảng JavaScript khác, đặc biệt là jQuery.

Một trong những điểm được thực hiện trong podcast đã tạo ra rất nhiều điều cho tôi với sự tôn trọng câu hỏi của bạn:

MISKO : [...] một trong những điều chúng tôi nghĩ rất khó về Angular là, làm thế nào để chúng tôi cung cấp nhiều lối thoát để bạn có thể thoát ra và về cơ bản tìm ra cách thoát khỏi điều này. Vì vậy, với chúng tôi, câu trả lời là điều này được gọi là Direct Directives. Và với các chỉ thị, về cơ bản bạn trở thành một jQuery JavaScript nhỏ thông thường, bạn có thể làm bất cứ điều gì bạn muốn.

IGOR : Vì vậy, hãy nghĩ về chỉ thị như là hướng dẫn cho trình biên dịch nói với nó bất cứ khi nào bạn gặp phần tử này hoặc CSS này trong mẫu, và bạn giữ loại mã này và mã đó chịu trách nhiệm về phần tử và mọi thứ bên dưới phần tử đó trong cây DOM.

Một bản ghi của toàn bộ tập phim có sẵn tại liên kết được cung cấp ở trên.

Vì vậy, để trả lời trực tiếp câu hỏi của bạn: AngularJS được đánh giá cao và là một khuôn khổ MV * thực sự. Tuy nhiên, bạn vẫn có thể thực hiện tất cả những thứ thực sự thú vị mà bạn biết và yêu thích với jQuery bên trong các chỉ thị. Đây không phải là vấn đề "Làm thế nào để tôi làm những gì tôi đã sử dụng trong jQuery?" nhiều như vấn đề "Làm cách nào để bổ sung AngularJS với tất cả những thứ tôi từng làm trong jQuery?"

Đó thực sự là hai trạng thái tâm trí rất khác nhau.


2
Tôi không chắc chắn tôi sẽ hoàn toàn đồng ý Angular là RẤT ý kiến. Bạn muốn có ý kiến, hãy nhìn vào Ember. Tôi sẽ miêu tả Angular là có ý kiến ​​goldilocks - đối với nhiều thứ tôi thấy, jQuery có quá ít ý kiến ​​và Ember có quá nhiều. Angular có vẻ vừa phải.
lừa4jesus

30

Tôi thấy câu hỏi này rất thú vị, vì lần đầu tiên tôi tiếp xúc nghiêm túc với lập trình JavaScript là Node.js và AngularJS. Tôi chưa bao giờ học jQuery và tôi đoán đó là một điều tốt, vì tôi không phải học bất cứ điều gì. Trên thực tế, tôi chủ động tránh các giải pháp jQuery cho các vấn đề của mình và thay vào đó, chỉ tìm kiếm một "cách AngularJS" để giải quyết chúng. Vì vậy, tôi đoán rằng câu trả lời của tôi cho câu hỏi này về cơ bản sẽ sôi nổi, "nghĩ như một người chưa bao giờ học jQuery" và tránh mọi cám dỗ để kết hợp trực tiếp với jQuery (rõ ràng AngularJS sử dụng nó ở một mức độ nào đó đằng sau hậu trường).


23

AngularJS và jQuery:

AngularJs và JQuery hoàn toàn khác nhau ở mọi cấp độ ngoại trừ chức năng JQLite và bạn sẽ thấy nó khi bạn bắt đầu tìm hiểu các tính năng cốt lõi của AngularJs (tôi đã giải thích bên dưới).

AngularJs là một khung công tác phía máy khách cung cấp để xây dựng ứng dụng phía máy khách độc lập. JQuery là một thư viện phía máy khách chơi xung quanh DOM.

Nguyên tắc tuyệt vời của AngularJs - Nếu bạn muốn một số thay đổi trên giao diện người dùng của mình, hãy suy nghĩ từ quan điểm thay đổi dữ liệu mô hình. Thay đổi dữ liệu của bạn và giao diện người dùng sẽ tự kết xuất lại. Bạn không cần phải chơi xung quanh DOM mỗi lần trừ khi và cho đến khi hầu như không cần thiết và điều đó cũng cần được xử lý thông qua Chỉ thị Angular.

Để trả lời câu hỏi này, tôi muốn chia sẻ kinh nghiệm của mình trên ứng dụng doanh nghiệp đầu tiên với AngularJS. Đây là những tính năng tuyệt vời nhất mà Angular cung cấp khi chúng ta bắt đầu thay đổi tư duy jQuery của mình và chúng ta có được Angular giống như một khung công tác chứ không phải thư viện.

Liên kết dữ liệu hai chiều thật tuyệt vời: Tôi có một lưới với tất cả các chức năng CẬP NHẬT, DELTE, INSERT. Tôi có một đối tượng dữ liệu liên kết mô hình của lưới bằng ng-repeat. Bạn chỉ cần viết một dòng mã JavaScript đơn giản để xóa và chèn và đó là nó. lưới tự động cập nhật khi mô hình lưới thay đổi ngay lập tức. Cập nhật chức năng là thời gian thực, không có mã cho nó. Bạn cảm thấy tuyệt vời!!!

Chỉ thị tái sử dụng là siêu: Viết chỉ thị ở một nơi và sử dụng nó trong suốt ứng dụng. CHÚA ƠI!!! Tôi đã sử dụng các chỉ thị này để phân trang, regex, xác nhận, vv Nó thực sự tuyệt vời!

Định tuyến rất mạnh: Tùy thuộc vào cách triển khai của bạn, bạn muốn sử dụng nó như thế nào, nhưng nó yêu cầu rất ít dòng mã để định tuyến yêu cầu chỉ định HTML và trình điều khiển (JavaScript)

Bộ điều khiển rất tuyệt: Bộ điều khiển chăm sóc HTML của riêng chúng, nhưng phần tách này hoạt động tốt cho chức năng chung cũng như. Nếu bạn muốn gọi cùng một chức năng khi nhấp vào nút trên HTML chính, chỉ cần viết cùng tên chức năng trong mỗi bộ điều khiển và viết mã riêng.

Plugin: Có nhiều tính năng tương tự khác như hiển thị lớp phủ trong ứng dụng của bạn. Bạn không cần phải viết mã cho nó, chỉ cần sử dụng một plugin lớp phủ có sẵn dưới dạng lớp phủ wc và điều này sẽ tự động xử lý tất cả các yêu cầu XMLHttpRequest (XHR).

Lý tưởng cho kiến trúc RESTful : Trở thành một khung hoàn chỉnh làm cho AngularJS trở nên tuyệt vời khi làm việc với kiến ​​trúc RESTful. Để gọi API REST CRUD rất dễ dàng và

Dịch vụ : Viết mã phổ biến sử dụng dịch vụ và ít mã hơn trong bộ điều khiển. Dịch vụ có thể được sử dụng để chia sẻ các chức năng phổ biến giữa các bộ điều khiển.

Khả năng mở rộng : Angular đã mở rộng các chỉ thị HTML bằng cách sử dụng các chỉ thị góc. Viết biểu thức bên trong html và đánh giá chúng trong thời gian chạy. Tạo các chỉ thị và dịch vụ của riêng bạn và sử dụng chúng trong một dự án khác mà không cần nỗ lực thêm.


20

Là người mới bắt đầu MV MV * và hoàn toàn tập trung vào kiến ​​trúc ứng dụng (không phải vấn đề phía máy chủ / máy khách), tôi chắc chắn sẽ đề xuất tài nguyên sau (điều tôi ngạc nhiên chưa được đề cập): Các mẫu thiết kế JavaScript , bởi Addy Osmani , như một giới thiệu về các mẫu thiết kế JavaScript khác nhau . Các thuật ngữ được sử dụng trong câu trả lời này được lấy từ tài liệu được liên kết ở trên. Tôi sẽ không lặp lại những gì đã được diễn đạt thực sự tốt trong câu trả lời được chấp nhận. Thay vào đó, câu trả lời này liên kết trở lại với nền tảng lý thuyết cung cấp năng lượng cho AngularJS (và các thư viện khác).

Giống như tôi, bạn sẽ nhanh chóng nhận ra rằng AngularJS (hoặc Ember.js , Durandal và các khung MV * khác cho vấn đề đó) là một khung phức tạp lắp ráp nhiều mẫu thiết kế JavaScript khác nhau.

Tôi tìm thấy nó dễ dàng hơn cũng có, để kiểm tra (1) mã JavaScript bản địa và (2) các thư viện nhỏ cho mỗi một trong những mô hình riêng biệt trước khi lặn vào một khuôn khổ toàn cầu. Điều này cho phép tôi hiểu rõ hơn vấn đề quan trọng nào mà một khung xử lý (vì bạn phải đối mặt với vấn đề cá nhân).

Ví dụ:

  • Lập trình hướng đối tượng JavaScript (đây là liên kết tìm kiếm của Google). Nó không phải là một thư viện, nhưng chắc chắn là điều kiện tiên quyết cho bất kỳ chương trình ứng dụng nào. Nó dạy tôi cách triển khai nguyên mẫu của các mẫu nguyên mẫu, hàm tạo, mẫu đơn & trang trí
  • jQuery / Underscore cho mẫu mặt tiền (như WYSIWYG để thao tác DOM)
  • Prototype.js cho mẫu nguyên mẫu / constructor / mixin
  • RequireJS / Curl.js cho mẫu mô-đun / AMD
  • KnockoutJS cho mẫu có thể quan sát, xuất bản / đăng ký

NB: Danh sách này không đầy đủ, cũng không phải 'các thư viện tốt nhất'; chúng chỉ là những thư viện tôi đã sử dụng. Các thư viện này cũng bao gồm nhiều mẫu hơn, những mẫu được đề cập chỉ là trọng tâm chính hoặc ý định ban đầu của chúng. Nếu bạn cảm thấy thiếu một cái gì đó từ danh sách này, xin vui lòng đề cập đến nó trong các bình luận, và tôi sẽ rất vui khi thêm nó.


12

Thực tế, nếu bạn đang sử dụng AngularJS, bạn không cần jQuery nữa. Bản thân AngularJS có ràng buộc và chỉ thị, đây là một "sự thay thế" rất tốt cho hầu hết mọi thứ bạn có thể làm với jQuery.

Tôi thường phát triển các ứng dụng di động bằng AngularJS và Cordova . Thứ DUY NHẤT từ jQuery tôi cần là Bộ chọn.

Bằng cách googling, tôi thấy rằng có một mô-đun bộ chọn jQuery độc lập ngoài kia. Đó là Sizzle.

Và tôi đã quyết định tạo một đoạn mã nhỏ giúp tôi nhanh chóng bắt đầu một trang web bằng AngularJS với sức mạnh của jQuery Selector (sử dụng Sizzle).

Tôi đã chia sẻ mã của mình tại đây: https://github.com/huytd/Sizzular

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.