Câu hỏi "Suy nghĩ trong AngularJS" nếu tôi có một nền jQuery? [đã đóng]


Giả sử tôi quen thuộc 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 cần thiết không? Dưới đây là một số câu hỏi có thể giúp bạn đặt câu trả lời:

  • Làm thế nào để tôi kiến ​​trúc và thiết kế các ứng dụng web phía máy khách 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ỳ sự cân nhắc / giới hạn phía máy chủ nào không?

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


4525
2018-02-21 04:09


gốc


Đối với những người quen thuộc với "ASP.NET MVC" hoặc "RoR" - chỉ cần nghĩ về Angular là "client-side MVC" và thats it. - Serge Shultz


Các câu trả lời:


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

Trong jQuery, bạn thiết kế một trang, và sau đó bạn làm cho nó năng động. Điều này là do jQuery được thiết kế để tăng cường và đã phát triển vô cùng 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. Thay vì bắt đầu bằng cách suy nghĩ "Tôi có mảnh DOM này và tôi muốn làm nó X", bạn phải bắt đầu với những gì bạn muốn hoàn thành, sau đó đi về thiết kế ứng dụng của bạn, và cuối cùng là thiết kế quan điểm của bạn.

2. Không tăng thêm jQuery với AngularJS

Tương tự như vậy, không bắt đầu với ý tưởng rằng jQuery thực hiện 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. Đây là có thật không 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 chút nào, ít nhất là cho đến khi họ quen với việc làm những thứ theo "Đường hướng".

Tôi đã thấy nhiều nhà phát triển ở đây và trên 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à $applys là khó hiểu và phức tạp; nhưng cuối cùng họ làm cho nó hoạt động! Vấn đề là ở chỗ phần lớn các trường hợp mà jQuery plugin có thể được viết lại trong AngularJS trong một phần nhỏ của mã, nơi mà mọi thứ đột nhiên trở nên dễ hiểu và dễ hiểu.

Điểm mấu chốt là: khi giải pháp, đầu tiên "suy 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ả thì không có giải pháp dễ dàng, sau đó cảm thấy tự do để 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ờ làm chủ AngularJS.

3. Luôn nghĩ về kiến ​​trúc

Đầu tiên biết rằng ứng dụng một trang là các ứng dụng. Họ không phải 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ủ ngoài ra 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 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ó khả năng kiểm thử.

Vậy thì làm sao bạn có làm như vậy không? Làm thế nào để bạn "suy 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 thay đổi chế độ xem theo chương trình. Chúng tôi có thể có một menu thả xuống được định nghĩa là ul như vậy:

<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, trong logic ứng dụng của chúng ta, chúng ta sẽ kích hoạt nó với một cái gì đó như:

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

Khi chúng ta chỉ nhìn vào khung nhìn, nó không rõ ràng ngay lập tức rằng có bất kỳ chức năng nào ở đây. Đối với các ứng dụng nhỏ, điều đó là 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ó duy trì.

Tuy nhiên, trong AngularJS, khung nhìn là bản ghi chính thức của chức năng dựa trên khung nhìn. Của chúng tôi ul tuyên bố sẽ trông như thế này:

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

Cả hai làm điều tương tự, nhưng trong phiên bản AngularJS, bất cứ ai nhìn vào khuôn 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 đến trên tàu, cô ấy có thể xem xét điều này và sau đó biết rằng có một chỉ thị được gọi là dropdownMenu hoạt động trên đó; cô ấy không cần phải intuit câu trả lời đúng hoặc sift thông qua bất kỳ mã. Quan điểm nói với chúng tôi những gì được cho là sẽ xảy ra. Sạch hơn nhiều.

Các nhà phát triển mới cho 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 luôn sửng sốt khi chúng tôi trả lời: bạn không biết. Nhưng lý do bạn không làm điều đó là điều này 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. Chế độ xem  hồ sơ chính thức. Bên ngoài chỉ thị (thêm về điều này bên dưới), bạn chưa bao giờ, không bao giờ thay đổi DOM. Và chỉ thị được áp dụng Theo quan điểm, vì vậy ý ​​định rõ ràng.

Hãy nhớ rằng: không thiết kế, và sau đó đánh dấu lên. 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à cắt ra 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 chế độ xem giống như sau:

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

Ngoài những lo ngại về trộn lẫn, chúng tôi cũng có cùng một vấn đề về ý định biểu thị mà tôi đã đề cập trước đây. Nhưng quan trọng hơn, chúng tôi đã phải tham khảo và cập nhật nút DOM theo cách thủ công. Và nếu chúng tôi muốn xóa một mục nhập nhật ký, chúng tôi cũng phải mã hóa 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ản trình bày thì sao?

Điều này một chút lộn xộn và một trifle yếu đuối. 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 ta 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 ta 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 một 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, không quan trọng Ở đâu hoặc là làm sao nhật ký được cập nhật, chế độ xem cũng sẽ thay đổi. Tự động. Khéo léo!

Mặc dù tôi không hiển thị ở đây, nhưng 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ể chỉnh sửa được trong chế độ xem chỉ bằng cách thực hiện việc 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 là loại giống như mô hình. Nhưng trong AngularJS, chúng ta có một lớp mô hình riêng biệt mà chúng ta có thể quản lý theo bất kỳ cách nào chúng ta muốn, hoàn toàn độc lập khỏi khung nhìn. Điều này giúp cho việc ràng buộc dữ liệu ở trên, duy trì tách mối quan tâmvà giới thiệu khả năng thử nghiệm 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ẽ để nó ở đó.

Tách mối quan tâm

Và tất cả những điều trên buộc vào chủ đề vượt trội này: giữ 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ì được cho là 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 tác vụ có thể tái sử dụng; bạn thực hiện thao tác DOM và tăng cường quan điểm của bạn với các chỉ thị; và bạn dán tất cả cùng với 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 testability, mà tôi thảo luận trong phần khác dưới đây.

Tiêm phụ thuộc

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

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 cá thể của nó và nó sẽ được cấp. Bạn không cần phải biết về việc tải đơn đặt hàng hoặc vị trí tệp hoặc bất kỳ thứ gì như thế. Sức mạnh có thể không hiển thị 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ụ triển khai bộ nhớ phía máy chủ thông qua NGHỈ NGƠI API 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 bộ điều khiển của chúng tôi, chúng tôi không muốn phải liên lạc với máy chủ - chúng tôi đang thử nghiệm bộ điều khiểnsau tất cả. Chúng ta có thể thêm một dịch vụ giả lập có cùng tên với thành phần ban đầu của chúng ta, và bộ phun sẽ đảm bảo rằng bộ điều khiển của chúng ta sẽ tự động giả mạo - bộ điều khiển của chúng ta không cần biết sự khác biệt.

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

4. Phát triển theo hướng 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 đến mức tôi đặt nó là phần cấp cao nhất của 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ộ thử nghiệm đi kèm? Không phải là rất nhiều vì jQuery không phải là rất amenable cho điều đó. Nhưng AngularJS là.

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 / demo mà các thử nghiệm của chúng tôi 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! Vì vậy, phần lớn thời gian, khi phát triển với jQuery, chúng tôi chọn tham gia lặp lại thay vì phát triển theo hướng thử nghiệm. Và ai có thể đổ lỗi cho chúng ta?

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

<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 người không tồn tại when-active chỉ thị:

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

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

.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 hiện đã qua  thực đơn của chúng tôi thực hiện theo yêu cầu. Phát triển của chúng tôi là cả hai lặp lại  thử nghiệm. Wicked-cool.

5. Khái niệm, chỉ thị là không phải jQuery đóng gói

Bạn sẽ thường nghe thấy "chỉ thực hiện thao tác DOM trong một chỉ thị". Đây là một điều cần thiết. Hãy đối xử với nó với sự tôn trọng đúng đắ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 tầm nhìn (suy 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 chỉ thị giống như một "widget" và có một mẫu, nó nên cũng thế tôn trọng sự phân tách mối quan tâm. Tức là, mẫu quá nên duy trì phần lớn độc lập với việc thực hiện nó trong các hàm liên kết và điều khiển.

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

Tôi thấy rất nhiều nhà phát triển mới với AngularJS sử dụng chỉ thị là 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, tôi sẽ lấy mã đó đưa nó vào một chỉ thị". Trong khi đó chắc chắn là tốt hơn nhiều, nó thường vẫn sai.

Hãy suy nghĩ về logger chúng tôi lập trình trong phần 3. Ngay cả khi chúng tôi đặt nó trong một chỉ thị, chúng tôi vẫn muốn làm điều đó theo cách "Góc". Nó vẫn không thực hiện bất kỳ thao tác DOM nào! Có rất nhiều lần khi thao tác DOM là cần thiết, nhưng đó là 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 liệu bạn có thực sự cần. Có thể có một cách tốt hơn.

Dưới đây là 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 toggleable. (Lưu ý: ví dụ này là một chút contrived và một skosh tiết để đại diện cho các trường hợp phức tạp hơn được giải quyết trong 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 trái 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 cần jQuery chút nào!
  2. Thứ hai, ngay cả khi chúng tôi đã có jQuery trên trang của chúng tôi, không có lý do gì để sử dụng nó ở đây; chúng ta có thể sử dụng đơn giản angular.element và thành phần của chúng tôi sẽ vẫn hoạt động khi bị bỏ vào một dự án không có jQuery.
  3. Thứ ba, thậm chí giả sử jQuery  cần thiết cho chỉ thị này để làm việc, jqLite (angular.element) sẽ luôn luôn sử dụng jQuery nếu nó đã được nạp! Vì vậy, chúng ta không cần sử dụng $ - chúng ta 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 trong $ - các element được chuyển đến link chức năng sẽ đã là một yếu tố jQuery!
  5. Và thứ năm, mà chúng tôi đã đề 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 ta?

Chỉ thị 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 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ác công cụ mẫu có trong mẫu, vì vậy bạn (hoặc người dùng của bạn) có thể dễ dàng hoán đổi nó cho một mẫu đáp ứng mọi kiểu cần thiết, và logic không bao giờ phải xúc động. Reusability - 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! Không có vấn đề gì trong mẫu, API nội bộ của chỉ thị không bao giờ được chạm vào, vì vậy việc tái cấu trúc lại 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 chỉ thị. Và không có vấn đề gì bạn thay đổi, kiểm tra của bạn vẫn vượt qua.

w00t!

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

Nói cách khác, nếu AngularJS không làm điều gì đó ra khỏi hộp, hãy nghĩ xem đội sẽ hoàn thành nó như thế nào để phù hợp 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 vấn đề mà bạn nghĩ bạn biết cách giải quyết trong jQuery, trước khi bạn tiếp cận $, cố gắng suy 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 lần trong số 20, 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 trong nhiều công việc cho bạn.


7187
2018-02-21 21:26



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 là trường hợp sử dụng quan trọng vì tất cả các trình cắm thê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
@taudep Tôi không nghĩ rằng 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ó một tương đương, sau đó đi cho nó. Để trích dẫn từ Phần 2: 'Điểm mấu chốt là: khi giải pháp, đầu tiên "suy 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 khi tất cả điều đó không có giải pháp dễ dàng, sau đó cảm thấy tự do để 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ờ làm chủ AngularJS. ' [nhấn mạnh thêm] - Josh David Miller
một người Trung Quốc dịch sang câu trả lời tuyệt vời này, hy vọng có ích. hanzheng.github.io/tech/angularjs/2013/10/28/… - Han Zheng
@ Benno Những gì ông có nghĩa là "không có thao tác DOM" là mã của bạn trong chỉ thị 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. Có, kết quả cuối cùng là DOM bị sửa đổi, nhưng đó là vì 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 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 "chắp thêm văn bản này vào phần tử này" - wired_in
@trusktr Nếu một phát triển bao giờ đặt giá trị của phần tử đầu vào bằng cách sử dụng jQuery trong một ứng dụng AngularJS, thì cô ta đang cam kết đau đớn lỗi. Loại ngoại lệ duy nhất mà tôi có thể nghĩ là một plugin jQuery hiện có quá khó để chuyển đổi đầu vào tự động, trong trường hợp đó, việc móc nối vào một cuộc gọi lại hoặc thiết lập đồng hồ là điều cần thiết để mang lại những thay đổi nội tuyến với ứng dụng. - Josh David Miller


Bắt buộc → khai báo

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

Trong AngularJS, bạn muốn suy nghĩ về lượt xem thay vì các phần tử DOM. Lượt xem là (khai báo) HTML chứa AngularJS chỉ thị. Chỉ thị thiết lập trình xử lý sự kiện phía sau hậu trường cho chúng tôi và cung cấp cho chúng tôi dữ liệu động. Selectors 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à phép chiếu của mô hình. Sự kiện thay đổi mô hình (có nghĩa là, dữ liệu, thuộc tính phạm vi) và các chế độ xem dự đoán các mô hình đó sẽ cập nhật "tự động".

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

Tách mối quan tâm

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

AngularJS sử dụng bộ điều khiển và các chỉ thị (mỗi trong số đó có thể có bộ điều khiển riêng, và / hoặc biên dịch và liên kết các hàm) để loại bỏ hành vi khỏi khung nhìn / cấu trúc (HTML). Góc cũng có dịch vụ và bộ lọc để giúp tách biệt / 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ế một ứ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 mô hình của mình - 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 dữ liệu động.
  3. Gắn bộ điều khiển vào mỗi khung nhìn (sử dụng ng-view và routing, hoặc ng-controller). 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.

Prototypal inheritance

Bạn có thể làm rất nhiều với jQuery mà không biết về cách thức hoạt động của JavaScript prototypal inheritance. 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 phạm vi prototypal / nguyên mẫu thừa kế trong AngularJS là gì?


408
2018-02-21 04:09



bạn có thể xin. giải thích cách phần tử dom khác với chế độ xem? - rajkamal
@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 / target / manipulate. Khung nhìn Angular là tập hợp / mẫu các phần tử DOM có liên quan: chế độ xem trình đơn, chế độ xem đầu trang, chế độ xem chân trang, chế độ xem bên phải, chế độ xem tiểu sử, có thể có nhiều chế độ xem nội dung chính (có thể chuyển đổi qua ng-view). Về cơ bản, bạn muốn chia nhỏ (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 của nó. Mỗi chế độ xem chiếu một phần (các) mô hình của bạn. - Mark Rajcok
jQuery là KHÔNG PHẢI bắt buộc. on và when là các hàm bậc cao hơn, hoạt động trên các thành viên của một đối tượng bộ sưu tập jQuery. - Jack Viers
Vì vậy, loại mã nào được thực hiện trong hàm gọi lại cho on? Bắt buộc. - cwharris
Điều này bắt buộc so với tuyên bố 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 thực hiện một cách bất hợp pháp (cách thực hiện nó) hoặc bởi nhà phát triển trong một chương trình con ở mức trừu tượng thấp hơn, bởi khung công tác hoặc trình biên dịch / phiên dịch. Để nói rằng "jQuery là bắt buộc" nói chung là một tuyên bố khá kỳ lạ, đặc biệt là xem xét rằng nó thực sự cung cấp một API khai báo nhiều hơn liên quan đến "thủ công" DOM ​​thao tác. - Alex


AngularJS so với jQuery

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

Điều này là bình thường, bạn nên vượt qua. Góc 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 cho 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à xử lý nó như là mã, theo nghĩa đen là các hướng dẫn cho trình biên dịch. Khi nó đi ngang qua DOM, nó sẽ tìm kiếm chỉ thị (chỉ thị của trình biên dịch) cho trình biên dịch AngularJS biết cách xử lý và phải làm gì. Chỉ thị là các đối tượng nhỏ đầy JavaScript có thể khớp với các thuộc tính, thẻ, lớp hoặc thậm chí là các 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 chỉ thị cụ thể, nó gọi hàm chỉ thị, chuyển nó thành 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 diễn giải bởi Chỉ thị và cho biết cách hiển thị và khi nào nó sẽ tự vẽ lại.

Các chỉ thị sau đó có thể kéo thêm các thành phần Angular bổ sung như bộ điều khiển, dịch vụ, vv Điều gì xảy ra ở dưới cùng của trình biên dịch là một ứng dụng web hoàn chỉnh, được kết nối và sẵn sàng hoạt động.

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

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

Hãy đi xuống với 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ụ để tạo ra 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 nó không phải là, AngularJS tàu với jQuery Lite, đó là một cắt giảm, nhưng vẫn hoàn toàn có thể sử dụng phiên bản của jQuery.

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

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à một chỉ thị. Thêm về những điều này sau.

JavaScript không phô trương với các bộ chọn so với các 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 nó được đề cập. Chúng tôi sử dụng bộ chọn để chọn các bit của trang và viết 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. Các thuộc tính onclick là thực hành rất tồi.

Một trong những điều đầu tiên bạn sẽ nhận thấy về AngularJS là thuộc tính tùy chỉnh ở mọi nơi. HTML của bạn sẽ được rải rác với các thuộc tính ng, chủ yếu là các thuộc tính onClick trên các steroid. Đây là những chỉ thị (chỉ thị của trình biên dịch), và là một trong những cách chính mà khuôn 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ể bị cám dỗ để viết AngularJS tắt như JavaScript xâm nhập trường học cũ (như tôi đã làm lúc đầu). Trong thực tế, AngularJS không chơi theo các quy tắc đó. Trong AngularJS, HTML5 của bạn là một mẫu. Nó được biên soạn bởi AngularJS để tạo ra trang web của bạn.

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

Mẫu của bạn phải khai báo; ý nghĩa của nó phải 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 các tên có ý nghĩa. Chúng tôi tạo nên các phần 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ế với 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 nó đang làm gì. Người đó có thể sửa đổi. Đây là cách góc.

Mẫu nằm trong ghế lái.

Một trong những câu hỏi đầu tiên tôi tự hỏi 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, nhưng tôi có tất cả các hành vi này. Câu trả lời là hiển nhiên. Vì AngularJS biên dịch DOM, AngularJS đang xử lý HTML của bạn dưới dạng mã. Đối với nhiều trường hợp đơn giản, nó thường đủ để chỉ viết một mẫu và để AngularJS biên dịch nó thành một ứng dụng cho bạn.

Mẫu của bạn thúc đẩy ứng dụng của bạn. Nó được coi là một DSL. Bạn viết các thành phần AngularJS, và AngularJS sẽ chăm só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 khuôn mẫu của bạn. Điều này rất khác với tiêu chuẩn MVC mẫu, nơi mẫu chỉ dành cho đầu ra.

Nó tương tự như XSLT hơn Viên ngọc trên tay vịn ví dụ.

Đây là một sự đảo ngược triệt để của kiểm soát mà phải mất một số nhận được sử dụng để.

Ngừng cố gắng thúc đẩy ứng dụng của bạn từ JavaScript của bạn. Để cho mẫu chạy ứng dụng, và để AngularJS xử lý các thành phần kết nối với nhau. Đây cũng là cách góc cạnh.

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

Với jQuery, trang HTML của bạn nên 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.

Vì AngularJS coi trang HTML của bạn là một 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 mà cuối cùng đến 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 nữa, thay vào đó, API của bạn và DOM được biên dịch là ngữ nghĩa.

Trong AngularJS, nghĩa là cuộc 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 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 giờ đây sẽ phân tích cú pháp JavaScript. Công cụ tìm kiếm cũng có thể lập chỉ mục AJAXed Nội dung. Tuy nhiên, bạn sẽ muốn chắc chắn rằng bạn đang sử dụng các URL pushstate và bạn có một sitemap khá. Xem ở đây để thảo luận về vấn đề này: https://stackoverflow.com/a/23245379/687677

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

Tách mối quan tâm (SOC) là một mô hình lớn lê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 phải đứ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 đột quỵ, AngularJS làm đi với một thập kỷ nhận được sự khôn ngoan và thay vào đó thực hiện một mẫu MVC trong đó khuôn mẫu không còn là ngữ nghĩa nữa, thậm chí không một chút.

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

  1. Mô hình - các mô hình của bạn chứa dữ liệu ngữ nghĩa của bạn. Mô hình thường JSON các đối tượng. 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ó tên là phạm vi $. Bạn cũng có thể lưu trữ các chức năng tiện ích tiện dụng trên phạm vi $ mà sau đó các mẫu của bạn có thể truy cập.
  2. Xem - Chế độ xem của bạn được viết bằng HTML. Chế độ xem thường không có ngữ nghĩa vì dữ liệu của bạn sống trong mô hình.
  3. Bộ điều khiển - Bộ điều khiển của bạn là một chức năng JavaScript để đưa khung nhìn vào mô hình. Chức năng của nó là để khởi tạo phạm vi $. 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 trên các đầu đối diện với 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 ngữ cảnh AngularJS. Bạn phải quên nó và tiếp tục.

Nếu, 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á xúc phạm. Vượt qua nó, nó sẽ đáng giá, tôi hứa.

Plugin so với chỉ thị

Plugins 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 ta định nghĩa các trình bổ sung bằng cách thêm các hàm vào jQuery.prototype. Sau đó, chúng ta móc chúng vào DOM bằng cách chọn các phần tử và gọi plugin trên kết quả. Ý tưởng là để mở rộng khả năng của jQuery.

Ví dụ: nếu bạn muốn băng chuyền trên trang của mình, bạn có thể xác định danh sách các số liệu không theo thứ tự, có thể được bao bọc trong phần 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à đặt lại nó làm thư viện với thời gian chờ để thực hiện hoạt ảnh trượt.

Trong AngularJS, chúng ta định nghĩa các chỉ thị. Chỉ thị 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 gì thay đổi để tạo cho chúng. Các chỉ thị được nối vào khuôn mẫu bằng cách sử dụng các thuộc tính hoặc các phần tử 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à các phần tử 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 giống 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 <carousel /> phần tử, sau đó xác định một chỉ thị để kéo vào một khuôn mẫu, và làm cho sucker đó 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 tuyệt vời như lightbox mà sau đó chúng tôi định cấu hình bằng cách chuyển 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 trình đơn thả xuống. Khi viết plugin thả xuống, bạn có thể bị cám dỗ mã trong trình xử lý nhấp chuột, có thể là một hàm để thêm vào chữ v hoặc là lên hoặc xuống, có thể thay đổi lớp của phần tử chưa mở, hiển thị menu ẩn, 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 ta có một vấn đề. Plugin của chúng tôi đã có sẵn trong trình xử lý nhấp chuột của chúng tôi cho chúng tôi, chúng tôi sẽ cần thêm một tùy chọn cấu hình để làm cho nó hoạt động khác nhau trong trường hợp cụ thể này.

Trong AngularJS chúng ta 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 (). Những phương thức này sẽ chỉ cập nhật $ scope.menu.visible, đây là một boolean giữ trạng thái.

Hiện nay trong mẫu của chúng tôi chúng ta có thể nối dây này lên:

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

Cần cập nhật khi di chuột qua?

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

Mẫu sẽ thúc đẩy ứng dụng để chúng tôi có được mức chi tiết cấp HTML. Nếu chúng ta muốn làm cho từng trường hợp ngoại lệ, mẫu sẽ làm cho việc này trở nên dễ dàng.

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

Các plugin JQuery được tạo trong một đóng. Quyền riêng tư được duy trì trong thời gian đóng cửa đó. Bạn có thể duy trì chuỗi phạm vi của mình trong thời gian đó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 chuyển vào plugin của jQuery, cộng với bất kỳ biến cục bộ nào được xác định trong phần đóng và bất kỳ hình cầu nào bạn đã xác định. Điều này có nghĩa là các plugin khá tự chứa. Đâ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 sẽ trở thành 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 ra và duy trì bởi AngularJS, trong đó bạn lưu trữ mô hình của mình. Một số chỉ thị sẽ sinh ra một phạm vi $ mới, theo mặc định kế thừa từ gói $ scope của nó bằng cách sử dụng JavaScript nguyên mẫu thừa kế. Đố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. Bởi vì cấu trúc của kế thừa $ scope xấp xỉ theo cấu trúc của DOM, các phần tử có quyền truy cập vào phạm vi của riêng chúng và bất kỳ phạm vi nào có chứa liền mạch, tất cả các con đường lên đến phạm vi $ toàn cầu (không giống với phạm vi toàn cục).

Điều này giúp việc truyền dữ liệu dễ dàng hơn nhiều 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ỉ phạm vi $ dropdown cần phải 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 của 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ư bay. Bạn không cần phải tạo đối tượng $ scope, AngularJS instantiates và 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 ma 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 Gắ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 bị ràng buộc với mô hình thông qua mẫu mà DOM của bạn sẽ tự động cập nhật, không cần can thiệp.

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

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

Liên kết phần tử đầu vào với $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 ra 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.name giá trị được cập nhật, mẫu sẽ cập nhật quá.

Ajax tất cả thời gian

Trong jQuery thực hiện một cuộc gọi Ajax khá đơn giản, nhưng nó vẫn là một cái gì đó bạn có thể suy nghĩ hai lần. Có thêm sự phức tạp để suy nghĩ, và một đoạn văn bản công bằng để duy trì.

Trong AngularJS, Ajax là giải pháp go-to mặc định của bạn và nó xảy ra mọi lúc, hầu như không có bạn nhận thấy. Bạn có thể bao gồm các mẫu với ng-include. Bạn có thể áp dụng 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 GitHub dịch vụ, hoặc một Flickr dịch vụ mà bạn có thể truy cập dễ dàng.

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

Trong jQuery, nếu chúng ta muốn hoàn thành một nhiệm vụ nhỏ không liên quan đến dom như kéo một nguồn cấp dữ liệu từ một API, chúng ta có thể viết một hàm nhỏ để làm đ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 tôi muốn sử dụng lại mã đó trong một ứng dụng khác?

AngularJS cho chúng ta các đối tượng dịch vụ.

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

Giả sử chúng ta có một giỏ mua 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 pháp để 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 phải 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 khép kín 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. Họ luôn là những người độc thân, 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 - aka de-spaghettification

AngularJS quản lý sự 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ẽ nhận được nó cho bạn.

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

DI có nghĩa là thay vì viết ứng dụng của bạn và kết nối nó với nhau, bạn thay vào đó 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ằng một chuỗi.

Giả sử tôi có một thành phần được gọi là 'FlickrService', nó định nghĩa các phương thức để lấy các nguồn cấp dữ liệu 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ẽ chăm sóc instantiating thành phần và làm cho nó có sẵ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ập đến nó theo tên như sau:

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 nối dây lại với nhau rất dễ dàng, và loại bỏ khá nhiều bất kỳ xu hướng nào đối với việc hóa lỏng. Chúng ta có một danh sách các thành phần phẳng, và AngularJS trao chúng cho chúng ta từng cái một và khi chúng ta cần chúng.

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

jQuery nói rất ít về cách bạn nên tổ chức mã của bạn. 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 một kịch bản nói chuyện với Flickr, bạn có thể muốn tạo một mô-đun Flickr để bao bọc tất cả các chức năng liên quan đến Flickr của bạn. 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 có thể chỉ bao gồm mô-đun Flickr và thì đấy, 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 module 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 danh sách đơn giản được xác định bằng 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 sử dụ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, dữ liệu ràng buộc, $ 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 có thể yêu cầu.

Điều chính để nhận ra là mẫu của bạn thúc đẩy ứ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.

Hãy suy 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 vui mừng về AngularJS, tôi đã viết một cuốn sách ngắn về nó mà bạn rất hoan nghênh đọc trực tuyến http://nicholasjohnson.com/angular-book/. Tôi hy vọng nó hữu ích.


184
2018-05-12 10:22



Ý tưởng cho rằng "Tách 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 tách các 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 trên trang web (đánh dấu / HTML) mà không quan tâm đến giao diện (kiểu / bố cục / CSS) hay "làm" (Sự kiện DOM / AJAX / JavaScript). MVC cũng phân biệt mối quan tâm. Mỗi "lớp" trong mẫu MVC có vai trò riêng biệt - dữ liệu, định tuyến / logic hoặc hiển thị. Các lớp được kết hợp với các cuộc gọi lại, các tuyến đường 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. - Alexander Pritchard
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ừ cuộc chiến trình duyệt, ban đầu tôi thấy các mẫu không ngữ nghĩa, không xác thực của Angular phiền hà. Tôi chỉ muốn nói rõ ràng rằng để viết Angular nó là cần thiết để cho đi SOC như nó thường được thực hành. Đây có thể là một quá trình chuyển đổi khó khăn. - superluminary
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ể: Ngữ nghĩa HTML, CSS trình diễn và JavaScript cho hành vi. Tôi đang đưa ra một số giả định về khán giả có lẽ không hợp lý, vì vậy tôi cũng nên xin lỗi. - superluminary
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 là một newbie ở đây, vì vậy, nếu tôi có một phần mở rộng để thay đổi một trang hiện có (mà tôi không kiểm soát), tôi nên giữ JQuery sau đó? - Daniel Möller


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

Bắt buộc so với Tuyên bố

Với jQuery bạn nói với DOM những gì cần phải xảy ra, từng bước. Với AngularJS bạn mô tả những kết quả bạn muốn nhưng không phải là cách để làm điều đó. Thêm thông tin 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 và thiết kế các ứng dụng web phía máy khách khác nhau?

AngularJS là một khung công tác toàn bộ phía máy khách sử dụng MVC mẫu (kiểm tra -biểu diễn đồ họa). Nó tập trung rất nhiều vào việc tách 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ế?

jQuerylà một thư viện

AngularJS là một khung công tác phía khách hàng đẹp, có khả năng kiểm tra cao, kết hợp nhiều thứ 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 tách mối quan tâm và thử nghiệm (kiểm tra đơn vị và thử nghiệm từ đầu đến cuối), tạo điều kiện phát triển theo hướng 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ể thực hiện 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ố tham chiếu để đọc thêm.

Có bất kỳ sự cân nhắc / giới hạn phía máy chủ nào không?

Bạn có thể sử dụng nó trên các ứng dụng hiện có mà bạn đang sử dụng jQuery thuần túy. Tuy nhiên, nếu bạn muốn tận dụng triệt để 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 một Yên tĩnh tiếp cận.

Làm như vậy sẽ cho phép bạn tận dụng nhà máy tài nguyên, tạo ra sự trừu tượng về phía máy chủ của bạn RESTful API 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.


152
2018-02-21 04:29



Tôi nghĩ rằng bạn đang lúng túng trên mặt nước bằng cách nói về cách jQuery là một "thư viện" và Angular là một "khung" ... cho một điều, tôi nghĩ rằng có thể lập luận rằng jQuery Là một khung công tác ... đó là một sự trừu tượng của thao tác DOM và xử lý sự kiện. Nó có thể không phải là một khuôn khổ cho cùng một loại điều mà Angular là, nhưng đó là tiến thoái lưỡng nan mà người hỏi câu hỏi đang ở: họ không thực sự biết sự khác biệt giữa Angular và jQuery, và cho tất cả những người hỏi, jQuery Là một khuôn khổ để xây dựng các trang web khách hàng nặng. Vì vậy, tranh luận về thuật ngữ sẽ không xóa mọi thứ. - Zando
Tôi nghĩ bạn là người đang bối rối. Câu hỏi này giải quyết chính xác điều này stackoverflow.com/questions/7062775. 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 công tác và thư viện: stackoverflow.com/a/148759/620448 - Ulises
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 kết hợp với nó theo bản chất của nó. (Ví dụ: Bạn chỉ nên cập nhật DOM trong các chỉ thị, nếu không một cái gì đó sẽ gây rối.) Đó là bởi vì AngularJS là một khung công tác. 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à một thư viện ít nhất là một nửa. - Alexander Pritchard
A thư viện là mã mà bạn gọi. A khuôn khổ là mã gọi mã của bạn. Theo định nghĩa này Angular là một khuôn khổ. Bạn cung cấp nó với các thành phần và Angular nhìn thấy nó 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à họ cần. - superluminary


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

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

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

Trong AngularJS, bạn dùng chỉ thị để đánh dấu các phần tử trực tiếp, để nối chúng lên:
<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 - sự khác biệt chính giữa AngularJS's jqLite so với toàn diện jQuery đó là jqLite không hỗ trợ bộ chọn.

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


84
2018-02-21 07:57



Cũng giống như tuyên bố từ chối trách nhiệm, có nhiều sự khác biệt lớn giữa Angular và jQuery. Nhưng tìm yếu tố là người yêu cầu thay đổi tư duy lớn nhất. - Scott Rippey
tha thứ cho tôi nếu tôi sai, nhưng tôi nghĩ rằng một bộ chọn là những gì 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 tải trong tham chiếu, thay vì chỉ chọn một hoặc 2 phần tử mà người dùng có thể nhấp vào, khi đang di chuyển bằng bộ chọn? âm thanh khó hơn với tôi .. - RozzA
@AlexanderPritchard Điểm của Angular là bạn không chọn từ JavaScript của bạn, bạn trực tiếp từ mẫu của bạn. Đó là một sự đảo ngược của kiểm soát mà đặt sức mạnh trong tay của nhà thiết kế. Đây là một nguyên tắc thiết kế có chủ ý. Thành thật được Góc bạn cần phải suy nghĩ về mã của bạn theo cách này tròn. Đó là một sự thay đổi khó khăn để thực hiện. - superluminary
@superluminary Thật là một câu nói tuyệt vời! "không chọn; trực tiếp!" Nghiêm túc, tôi sẽ dùng nó. - Scott Rippey
Đâ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ề đội ngũ 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, tôi sử dụng chỉ thị, thời gian. Tôi không bỏ lỡ bộ chọn một chút. - adam0101


jQuery

jQuery làm cho các lệnh JavaScript dài lố bịch như getElementByHerpDerp ngắn hơn và trình duyệt 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 để thực hiện những điều 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).

Chỉnh sửa:

Nói "Tôi có một nền jQuery làm thế nào để tôi nghĩ rằng trong AngularJS?" giống như nói "Tôi có một nền HTML làm thế nào để tôi nghĩ trong JavaScript?" Thực tế là bạn đang đặt câu hỏi cho thấy bạn rất có thể 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 hơn là xem danh sách nói rằng "AngularJS sử dụng các chỉ thị trong khi jQuery sử dụng bộ chọn CSS để tạo một đối tượng jQuery thực hiện điều này và v.v ..." . Câu hỏi này không đòi hỏi 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. Lệnh ngắn hơn, trình duyệt chéo, v.v.

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


69
2018-02-04 05:07



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


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

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

Ví dụ, khi bạn nhận được dữ liệu từ máy chủ mà bạn định hiển thị ở một số định dạng trong DOM, trong jQuery, bạn cần phải '1. TÌM 'trong DOM bạn muốn đặt dữ liệu này ở đâu,' 2. CẬP NHẬT / PHỤ LỤC 'nó ở đó bằng cách tạo một nút mới hoặc chỉ cần thiết lập innerHTML. Sau đó, khi bạn muốn cập nhật chế độ xem này, sau đó bạn '3. TÌM 'vị trí và' 4. CẬP NHẬT '. Chu kỳ tìm và cập nhật tất cả được thực hiện trong cùng một 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 bạn (các đối tượng JavaScript 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ề khung nhìn, và một thao tác trên mô hình tự động truyền đến 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 phải suy nghĩ về bộ chọn CSS, đó là, ở đâu div hoặc là td có một lớp hoặc thuộc tính, vv, để tôi có thể nhận được 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 true. Bạn không làm phiền bản thân của mình cho dù xem phản ánh giá trị này là một hộp kiểm tra hoặc cư trú trong một td yếu tố (chi tiết bạn sẽ thường cần để suy nghĩ về trong jQuery).

Và với thao tác DOM trong AngularJS, bạn thấy mình thêm chỉ thị và bộ lọc, mà bạn có thể coi là các phần 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 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 thì đáng giá, nên học AngularJS thường có nghĩa là tìm hiểu 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 bạn và nó sẽ gọi nó cho phù hợp. Đây là một trong những điều làm cho AngularJS trở thành một khuôn khổ hơn là một thư viện.


61
2017-11-02 16:53





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

Tóm lại kinh nghiệm của tôi:

  1. Bộ điều khiển và nhà cung cấp (dịch vụ, nhà máy, vv) là để sửa đổi mô hình dữ liệu, KHÔNG HTML.
  2. HTML và các chỉ thị xác định cách bố trí 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 một nhà máy - chúng là các trình đơn đượ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 chỉ thị.
  5. Nếu bạn có một số dữ liệu và hiện đang cố cập nhật HTML ... STOP! cập nhật mô hình và đảm bảo rằng HTML của bạn bị ràng buộc với mô hình.

46
2018-05-16 21:50





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

AngularJS là một khung công tác MV *.

Trong thực tế, AngularJS là một trong số ít các khung công tác JavaScript MV * (nhiều công cụ JavaScript MVC vẫn nằm trong thư viện thể loại).

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

AngularJS chính nó bao gồm một phiên bản jQuery-lite bên trong nó. Vì vậy, đối với một số 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 giao diện người dùng có thể tái sử dụng, 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 phải thực hiện thao tác liên quan đến DOM (chỉ thị chỉ là nơi bạn nên viết mã jQuery 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ư một ngôn ngữ lớp học đầu tiên trước khi nhảy vào một khung làm việc phong phú như AngularJS!" Tôi đã học được điều trên một cách khó khăn.

Chúc may mắn.


45
2017-10-10 08:58





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 đã có jQuery Lite được xây dựng trong đó cho phép bạn thực hiện thao tác DOM cơ bản mà không cần kể cả phiên bản jQuery đầy đủ.

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

Một điều tốt đẹp về AngularJs là nó cho phép bạn tách biệt / cô lập thao tác DOM trong các chỉ thị. Có sẵn các chỉ thị tích hợp sẵn để 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 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 bộ điều khiển hoặc dịch vụ cần quản lý logic nghiệp vụ.

Góc 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òn một điều nữa, đó là chỉ thị. Đó là một thuộc tính mà bạn có thể gắn vào bất kỳ phần tử DOM nào và bạn có thể đi hạt với jQuery bên trong nó mà không lo lắng về jQuery của bạn bao giờ xung đột với các thành phần AngularJs hoặc gây rối với kiến ​​trúc của nó.

Tôi đã nghe từ một buổi gặp mặt mà tôi đã tham dự, một trong những người sáng lập của Angular cho biết họ đã làm việc rất chăm chỉ để tách ra các thao tác DOM vì vậy đừng cố đưa chúng trở lại.


34
2017-08-14 14:19





Nghe podcast JavaScript Jabber: Tập # 32 có 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 tạo ra trong podcast đã tạo ra rất nhiều thứ cho tôi với các khía cạnh cho câu hỏi của bạn:

MISKO: [...] Một trong những điều mà chúng tôi nghĩ về Angular rất khó, chúng tôi cung cấp rất nhiều cửa thoát hiểm để 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, đối với chúng tôi, câu trả lời là điều này được gọi là "Chỉ thị". 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ĩ chỉ thị như hướng dẫn cho trình biên dịch cho biết khi nào bạn gặp yếu tố nào đó 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 thành phần đó trong cây DOM.

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

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

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


31
2017-11-08 16:08



Tôi không chắc chắn tôi sẽ hoàn toàn đồng ý Angular là VERY ý kiến. Bạn muốn có ý kiến, hãy nhìn Ember. Tôi sẽ miêu tả Angular như đã có ý kiến ​​của goldilocks - cho rất nhiều những gì tôi thấy, jQuery có quá ít ý kiến ​​và Ember có quá nhiều. Angular có vẻ đúng. - fool4jesus