Khi thiết lập môi trường phát triển Angular ban đầu của bạn bằng cách sử dụng Angular CLI, bạn sẽ nhận ra CLI hiện đã trở nên cần thiết đến mức nào
Điều này là do ngày nay chúng ta cần thiết lập nhiều hơn rất nhiều so với những gì chúng ta đã có trước đây - và đây là trường hợp không chỉ đối với Angular mà còn đối với bất kỳ hệ sinh thái tương đương nào khác
Một vài câu hỏi chính
Trong thế giới mới của các trình tải mô-đun này, các hệ thống xây dựng nâng cao mà chúng tôi không còn tự thiết lập từ đầu nữa và nơi mọi thứ được dịch xuống Javascript ES5 đơn giản từ các ngôn ngữ cấp cao hơn, sẽ không ngạc nhiên nếu tại một thời điểm nhất định, bạn sẽ tự hỏi mình
Tôi có thực sự cần tất cả các công cụ và phụ thuộc này không?
Bạn thậm chí có thể tự hỏi mình, tại sao không làm mọi thứ trong một công nghệ đã tồn tại trước đó, như jQuery chẳng hạn?
Có nhiều trường hợp sử dụng ngày nay vẫn được giải quyết tốt bằng cách tiếp cận đó, nhưng điều đó dẫn chúng ta đến câu hỏi
Angular cải thiện các công nghệ hiện có trước đây theo cách nào?
Những vấn đề nào mà Angular giải quyết theo cách tốt hơn về cơ bản và tại sao nó lại tốt hơn?
Mọi thứ xảy ra dưới mui xe
Hãy cùng tìm hiểu. Điều quan trọng về những lợi thế chính của Angular và MVC là mọi thứ diễn ra rất nhiều dưới mui xe đến nỗi đôi khi khó nhận ra rằng những lợi thế đó thậm chí còn ở đó
Để hiểu được lợi ích của cách tiếp cận MVC, chúng ta sẽ xây dựng một ứng dụng nhỏ trong jQuery chẳng hạn, sau đó xây dựng ứng dụng tương đương trong Angular - và sự khác biệt giữa cả hai sẽ nhanh chóng trở nên rõ ràng
Mục tiêu ở đây không phải là so sánh Angular với jQuery, mà là so sánh cách tiếp cận MVC để phát triển giao diện người dùng với cách tiếp cận trước MVC
jQuery được sử dụng ở đây vì đây là một ví dụ rất nổi tiếng và ngày nay nó vẫn rất hữu ích cho nhiều trường hợp sử dụng
Một ví dụ về Ứng dụng jQuery
Để hiểu những lợi thế mà cả Angular và MVC mang lại, hãy đưa ra một ví dụ đơn giản. Hãy bắt đầu với một ứng dụng đơn giản chỉ hiển thị danh sách các bài học trên màn hình
Các bài học sẽ được tải thông qua yêu cầu HTTP GET từ url này. Trên thực tế, dữ liệu này đến từ Firebase thông qua API HTTP thay thế của nó [tìm hiểu thêm về nó trong Khóa học về sự cố Firebase]
Và đây là danh sách các bài học sẽ như thế nào
Mô hình trong MVC là gì?
Như chúng ta có thể thấy, dữ liệu ở trên chỉ đơn giản là Đối tượng Javascript cũ đơn giản hoặc POJO
Những mã định danh duy nhất mà bạn thấy là các phím đẩy của Firebase, hãy tìm hiểu thêm về chúng trong Khóa học về sự cố góc và Firebase
Đối tượng JSON ở trên là dữ liệu của ứng dụng của chúng ta, còn được gọi là Model và chúng ta muốn hiển thị nó trên màn hình - do đó chúng ta cần tạo HTML dựa trên Model này
Vì vậy, trước tiên hãy bắt đầu bằng cách làm như vậy trong jQuery, sau đó triển khai logic tương tự trong Angular
Ứng dụng jQuery trông như thế nào?
Hãy xây dựng một ứng dụng jQuery nhỏ để hiển thị dữ liệu này [ứng dụng có sẵn tại đây]
Vì vậy, trong ứng dụng jQuery của chúng tôi, điều đầu tiên chúng tôi cần làm là truy vấn phụ trợ API REST của chúng tôi bằng cách thực hiện một yêu cầu jQuery Ajax
Lưu ý rằng chúng tôi đã gọi Object.values[]
, điều này chỉ để chuyển đổi kết quả trả về là một đối tượng [và do đó là một từ điển khóa-giá trị] thành một danh sách các bài học
Ghi chú. thứ tự các bài học không đảm bảo được giữ nguyên
Với điều này, giờ đây chúng ta đã có Mô hình của mình trong trình duyệt, sẵn sàng để hiển thị - danh sách các bài học. Như bạn có thể thấy, chúng tôi đã không gửi HTML qua dây từ máy chủ trở lại máy khách, thay vào đó, chúng tôi đã yêu cầu máy chủ và chỉ trả lại dữ liệu
Đây là một khái niệm quan trọng vì HTML không chỉ là dữ liệu. HTML là một đại diện cụ thể của Mô hình, mà chúng ta có thể gọi là Chế độ xem và cùng một dữ liệu có thể có nhiều chế độ xem
Sự khác biệt giữa Mô hình và Chế độ xem
Cùng một Mô hình [danh sách các bài học] mà chúng tôi đã trình bày ở trên, có thể có nhiều Chế độ xem. Đây là vài ví dụ
Như chúng ta có thể thấy, một View của mô hình là một bảng HTML, nhưng một View khác có thể chỉ đơn giản là tổng số bài học
Ngoài ra, bản thân mỗi bài học có thể được sử dụng làm Mô hình, với các chế độ xem khác nhau. chúng ta có thể có một màn hình chi tiết bài học hiển thị tất cả chi tiết của bài học, chỉ một hàng trong bảng - hiển thị tóm tắt bài học
Cách hiển thị Chế độ xem bằng jQuery?
Bây giờ chúng tôi có dữ liệu trên giao diện người dùng, vì vậy chúng tôi cần sử dụng nó để tạo nhiều Chế độ xem. Đây là cách chúng ta có thể tạo một bảng HTML với danh sách các bài học trong jQuery
Đánh giá ứng dụng jQuery
Như chúng ta có thể thấy, chúng ta đang viết khá nhiều mã để lấy mô hình và chuyển đổi nó thành nhiều chế độ xem dữ liệu. Chúng ta có thể thấy rằng mã này mặc dù viết đơn giản nhưng có các đặc điểm sau
- Mã này không dễ đọc lắm, nó trộn lẫn một số mối quan tâm
- loại mã này không dễ bảo trì
- đây là rất nhiều mã, nó chiếm một phần quan trọng trong ứng dụng của chúng tôi
- chúng tôi đang xây dựng HTML bằng cách nối chuỗi và sau đó chuyển nó tới trình duyệt, trình duyệt này sẽ vẫn phải phân tích cú pháp nó
Điểm cuối cùng này rất quan trọng để so sánh về hiệu suất, chúng tôi sẽ nói thêm về điều này sau
Nhập Angular, nó khác như thế nào?
Vì vậy, bây giờ hãy viết lại phần này của ứng dụng của chúng ta trong Angular [có thể tìm thấy ứng dụng tại đây]
Đây chỉ là phần quan trọng của ứng dụng, sẽ có cấu trúc thư mục CLI góc xung quanh nó, nhưng tiêu chuẩn của nó và được tạo cho chúng tôi. Tương đương với góc sau đó sẽ như sau
Vì vậy, hãy chia nhỏ điều này và so sánh nó với phiên bản jQuery
- ở đây chúng ta có một lớp biết cả về dữ liệu được lấy từ phần phụ trợ và mẫu HTML cần thiết để hiển thị nó
- yêu cầu HTTP đang được thực hiện thông qua mô-đun HTTP góc
- dữ liệu được lưu trữ trong một biến có tên là
lessons
Nhưng sự khác biệt lớn nhất rõ ràng là không có dấu vết của HTML trong đoạn mã này
Quá trình tạo chế độ xem góc
Vậy thì HTML được tạo ra như thế nào?
Như chúng ta có thể thấy, đây là nơi lưu giữ HTML hiện tại. Và nó được tách ra khỏi mã thành phần vì nó nằm trong một tệp riêng biệt hoàn toàn
Lưu ý rằng mẫu này có một số biểu thức và cú pháp không giống với HTML mà chúng ta viết hàng ngày, chẳng hạn như
- chỉ thị
ngFor
lặp qua danh sách các bài học - biểu thức
{{lesson.description}}
, đó là cách chúng ta có thể xuất dữ liệu ra dạng xem
Các biểu thức này là cách Angular liên kết dữ liệu và chế độ xem với nhau
Thuật ngữ MVC
Dựa trên ứng dụng Angular ở trên, hãy định nghĩa một số thuật ngữ
- đối tượng JSON đơn giản là Mô hình Ứng dụng của chúng tôi
- mẫu [hoặc đầu ra của quá trình xử lý] là Chế độ xem
- Góc
AppComponent
liên kết Chế độ xem và Mô hình với nhau
Angular vs jQuery - so sánh hai phiên bản của ứng dụng
Bây giờ chúng ta có hai ứng dụng được viết bằng cả jQuery và Angular, hãy bắt đầu so sánh chúng
Ngay trong giai đoạn đầu này, chúng ta có thể thấy một số khác biệt
- mẫu của Angular dễ đọc hơn nhiều so với mã jQuery
- mã
AppComponent
không tạo HTML, nó chỉ lấy dữ liệu từ phần phụ trợ
Sự khác biệt lớn nhất khi nhìn vào mã là trong phiên bản Angular có sự tách biệt về mối quan tâm không tồn tại trên phiên bản jQuery
Trong phiên bản Góc, Mô hình và Chế độ xem được tách biệt rõ ràng và tương tác thông qua lớp AppComponent
, trong khi ở phiên bản jQuery, tất cả những mối quan tâm này được trộn lẫn trong cùng một mã
Nhưng đó không phải là lợi thế duy nhất của việc sử dụng khung MVC. sự khác biệt sẽ trở nên rõ ràng hơn nhiều nếu chúng ta bắt đầu sửa đổi dữ liệu
Điều gì sẽ xảy ra nếu bây giờ chúng ta Sửa đổi Mô hình?
Việc tách các mối quan tâm của phiên bản Angular là một điều tuyệt vời cần có và cần thiết trong một ứng dụng lớn hơn
Nhưng có nhiều điều đang diễn ra trong ví dụ nhỏ này vẫn chưa rõ ràng. Nếu bây giờ chúng ta muốn cập nhật Model thì sao?
Để làm cho nó đơn giản, hãy làm điều này để đáp lại một nút. Đây là giao diện của phiên bản jQuery
Vì vậy, hãy chia nhỏ những gì đang diễn ra trong phiên bản mã mới này
- chúng tôi đã trích xuất mã để tạo HTML thành một chức năng riêng biệt có tên là
generateHtml[]
, để chúng tôi có thể sử dụng lại nó [xem chức năng bên dưới] - chúng tôi đã lưu trữ dữ liệu bài học bên trong một mô-đun để nó không gây ô nhiễm phạm vi toàn cầu
- chúng tôi đã thêm một trình xử lý nhấp chuột vào một nút để sửa đổi dữ liệu và sau đó gọi lại hàm
generateHtml[]
Hàm mà chúng tôi đã tạo để sử dụng lại logic tạo HTML trông giống như sau
Vấn đề với loại mã này
Nó có thể không giống như vậy, nhưng mã này thực sự dễ vỡ và khó bảo trì. một trích dẫn duy nhất ở sai vị trí và chúng tôi vẫn sẽ có một chuỗi Javascript hợp lệ trông sẽ bị hỏng hoàn toàn khi được trình duyệt hiển thị, vì đó không phải là HTML hợp lệ
Đây là loại mã mà chúng tôi không muốn phải tự viết. nó thực sự giòn, mặc dù thoạt nhìn nó có vẻ đơn giản
So sánh với phiên bản Angular
Bây giờ chúng ta hãy xem phiên bản Angular tương đương của mã này
Hàm lessons
0 đang được gọi bằng một nút mà chúng tôi đã thêm vào mẫu
Xem lại phiên bản sửa đổi dữ liệu Angular
Giống như đối tác jQuery của nó, phiên bản ứng dụng này cũng thêm một chỉ mục vào phần mô tả của mỗi khóa học [hãy xem các tính năng ngFor này để biết giải pháp thay thế]
Những gì chúng tôi đã làm trong phiên bản Angular này là. chúng tôi chỉ cần cập nhật Mô hình và Angular đã tự động phản ánh sửa đổi Mô hình trực tiếp trong Chế độ xem cho chúng tôi
Chúng tôi không phải gọi hàm tạo HTML, áp dụng HTML vào đúng vị trí của tài liệu, v.v. Đây là một trong những tính năng sát thủ của Angular
chúng tôi không phải viết bất kỳ mô hình nào để xem mã Đồng bộ hóa theo cách thủ công, việc đồng bộ hóa đó đã được thực hiện bằng cách nào đó cho chúng tôi dưới mui xe
Vì vậy, làm thế nào để làm việc này?
Angular luôn giữ cho Chế độ xem đồng bộ với mô hình cho chúng tôi thông qua cơ chế phát hiện thay đổi minh bạch của nó
Cách thức hoạt động của nó là Angular sẽ tự động kiểm tra Mô hình, để xem liệu nó có thay đổi hay không và nếu có, nó sẽ phản ánh những thay đổi đó trong chế độ xem
Nhưng bên cạnh việc phân tách các mối quan tâm và tự động phát hiện các thay đổi và đồng bộ hóa, có một số khác về cơ bản giữa các phiên bản jQuery và Angular
Có lẽ sự khác biệt lớn nhất giữa góc và jQuery?
Chúng ta không thể biết chỉ bằng cách nhìn vào mã Angular vì tất cả đều diễn ra minh bạch, nhưng một trong những điểm khác biệt chính là không giống như jQuery, Angular đang thực hiện sửa đổi tài liệu theo cách hiệu quả hơn nhiều so với phiên bản jQuery
Angular không tạo HTML và sau đó chuyển nó tới trình duyệt để phân tích cú pháp, thay vào đó Angular đang trực tiếp tạo cấu trúc dữ liệu DOM
Điều này hoạt động nhanh hơn nhiều so với việc xây dựng HTML thủ công và sau đó chuyển nó tới DOM để phân tích cú pháp. Bằng cách trực tiếp xây dựng các nút DOM, Angular bỏ qua hoàn toàn bước phân tích cú pháp HTML. Vì vậy, trình duyệt chỉ cần lấy cây DOM sẵn sàng sử dụng và hiển thị nó ra màn hình
Và hơn thế nữa, nó sẽ làm như vậy theo cách tối ưu, bằng cách cố gắng chỉ thay đổi HTML thực sự cần thay đổi
Angular sẽ không thay thế toàn bộ cây DOM mỗi lần, nó cập nhật DOM theo cách tối ưu, tùy thuộc vào phần nào của Mô hình đã thay đổi
Làm cách nào để Angular hiển thị Chế độ xem dưới mui xe?
Để hiểu rõ hơn về những gì Angular đang làm, hãy làm như sau. hãy quay lại phiên bản jQuery và thử làm điều gì đó tương tự như những gì Angular đang làm - thao tác DOM trực tiếp
Mã trình xử lý nhấp chuột bây giờ trông giống như thế này
Vì vậy, như chúng ta có thể thấy, chúng ta đang sử dụng trực tiếp DOM API để loại bỏ các nút trong lessons
Div. Sau đó, chúng tôi sẽ thay thế bảng bằng một bảng mới được tạo bằng hàm lessons
2
Và đây là chức năng đó trông như thế nào
Nếu bạn muốn thấy điều này hoạt động, hãy sao chép và thử cục bộ hai ứng dụng mẫu [một ứng dụng trong Angular và ứng dụng kia trong jQuery]
Ưu điểm của quy trình tạo chế độ xem góc
Trên thực tế, đây chỉ là một ước tính rất sơ bộ về những gì mà Angular đang thực hiện.
Chức năng này đang tái tạo toàn bộ bảng, nhưng điều mà Angular làm với các mẫu của nó là nó sẽ chỉ thay thế các phần của cây DOM cần được sửa đổi, chỉ theo dữ liệu đã được sửa đổi
Vì vậy, ví dụ: nếu chỉ một biểu thức trên tiêu đề trang bị sửa đổi, thì đó là phần duy nhất của DOM sẽ bị ảnh hưởng, danh sách các bài học sẽ không thay đổi
Thật không thực tế khi làm thủ công những gì Angular đang làm
Và đây là nơi nó sẽ trở nên gần như không thể và chắc chắn là không thực tế khi làm với jQuery giống như điều mà Angular đang làm một cách minh bạch.
Đơn giản là không thực tế khi tự viết loại Mô hình này để Xem mã tạo DOM theo cách thủ công như lessons
2, bất chấp những lợi ích của phương pháp đó
Ví dụ: lưu ý rằng hàm lessons
2 mặc dù nó tạo trực tiếp các nút DOM, nhưng nó không được tối ưu hóa và tạo toàn bộ bảng mỗi lần
Tóm tắt và Kết luận
Vì vậy, hãy tóm tắt. những lợi thế của việc sử dụng khung MVC như Angular như chúng ta đã thấy là rất lớn, vì vậy hãy liệt kê từng cái một
Tách Mối Quan Tâm
Chúng tôi có thể xây dựng các ứng dụng giao diện người dùng với ít mã hơn nhiều so với các công nghệ thế hệ trước. Điều này là do chúng tôi không phải viết mã đồng bộ hóa Mô hình và Chế độ xem theo cách thủ công - mã đó được tạo tự động cho chúng tôi
Mã mà chúng ta cần viết sẽ dễ đọc và dễ bảo trì hơn rất nhiều, do sự phân tách rõ ràng giữa Mô hình và Chế độ xem
Mô hình trong suốt để xem đồng bộ hóa
Việc đồng bộ hóa giữa Mô hình và Chế độ xem không chỉ minh bạch mà còn được tối ưu hóa theo cách không thể đạt được trong thực tế bằng cách thủ công
Hiệu suất giao diện người dùng
Chế độ xem được sửa đổi bằng cách tạo trực tiếp các cây đối tượng DOM theo cách tương thích với nhiều trình duyệt, thay vì bằng cách tạo HTML rồi chuyển nó tới trình duyệt để phân tích cú pháp - điều này hoàn toàn bỏ qua bước phân tích cú pháp
HTML vẫn cần được phân tích cú pháp, nhưng nó chỉ được thực hiện một lần cho mỗi mẫu bởi Angular và bởi trình duyệt mỗi lần. Việc phân tích cú pháp được thực hiện tại thời điểm khởi động ứng dụng [Just In Time hoặc JIT] hoặc trước thời hạn [AOT] khi xây dựng ứng dụng
Và đây là một trong những lý do chính tại sao rất đáng để có một môi trường phát triển tiên tiến hơn như CLI. bởi vì sử dụng nó, chúng tôi có thể có tất cả các tính năng và lợi ích này hoạt động rõ ràng ngay lập tức
Ngoài ra, việc tạo và sửa đổi chế độ xem được thực hiện theo cách tối ưu hóa, nghĩa là chỉ những phần của cây DOM có dữ liệu sửa đổi sẽ bị ảnh hưởng, trong khi phần còn lại của trang vẫn giữ nguyên
Tại sao MVC trở nên cần thiết cho sự phát triển giao diện người dùng
Với Angular và MVC, chúng ta có thể tập trung vào việc xây dựng các ứng dụng theo cách khai báo hơn, bằng cách chỉ cần xác định một mẫu HTML giống như chúng ta đã quen.
Chúng ta có thể liên kết mẫu với dữ liệu Mô hình và xử lý dữ liệu thông qua một lớp thành phần
Có thể không sử dụng MVC không?
Việc chọn không sử dụng khung MVC có nghĩa là chúng ta sẽ phải đồng bộ hóa Mô hình và Chế độ xem theo cách thủ công, điều này thoạt nhìn có vẻ đơn giản nhưng rất nhanh chúng ta sẽ kết thúc với một chương trình không thể duy trì được
Tôi hy vọng rằng điều này mang đến cho bạn lời giải thích thuyết phục về lý do tại sao chúng ta cần một khung MVC như Angular và loại công nghệ này giải quyết cho chúng ta một số lượng lớn vấn đề theo cách hoàn toàn minh bạch
Và tại sao việc thiết lập một môi trường làm việc tiên tiến hơn lại thực sự mang lại kết quả, để có thể tận hưởng tất cả những lợi ích này và trải nghiệm tuyệt vời dành cho nhà phát triển
Tôi hy vọng rằng bài đăng này đã giúp hiểu được một số lợi ích chính của việc sử dụng một khung như Angular và bạn thích nó