JavaScript có tốt cho giao diện người dùng không?

Có thể bạn đã nghe nói về front-end framework. Những cái tên như React, Vue và Angular có rất nhiều trong các hướng dẫn và các cuộc tranh luận của Hacker News. Nếu bạn thắc mắc tại sao và khi nào các khung này được sử dụng và liệu đã đến lúc bạn triển khai một khung trong dự án của mình hay chưa, thì bạn không đơn độc. Vài năm trước, khi đang thực hiện một dự án phụ, Hackterms, của riêng tôi…

Max Pekarsky Kỹ sư phần mềm

Có thể bạn đã nghe nói về front-end framework. Những cái tên như React, Vue và Angular có rất nhiều trong các hướng dẫn và các cuộc tranh luận của Hacker News. Nếu bạn thắc mắc tại sao và khi nào các khung này được sử dụng và liệu đã đến lúc bạn triển khai một khung trong dự án của mình hay chưa, thì bạn không đơn độc. Một vài năm trước, khi đang thực hiện một dự án phụ, Hackterms, giao diện người dùng của tôi trở nên khó sử dụng. Tôi có cảm giác mơ hồ rằng triển khai một khuôn khổ là bước tiếp theo đúng đắn, nhưng tôi không biết họ đã làm gì. (Chúng ta sẽ quay lại chuyện đó diễn ra như thế nào ở cuối bài viết. ) Đây là lời giải thích mà tôi ước có sau đó. Trong bài đăng này, chúng tôi sẽ xem xét toàn cảnh các vấn đề mà các framework front-end đang cố gắng giải quyết và khi nào bạn có thể muốn sử dụng chúng

Cụ thể, chúng tôi sẽ xem xét

  1. Giao diện người dùng phát triển như thế nào.  
  2. Các vấn đề về kiến ​​trúc mà bạn có thể gặp phải khi mở rộng quy mô
  3. Làm thế nào một khung giao diện người dùng có thể giúp giải quyết những vấn đề này.  
  4. Các lựa chọn thay thế khác mà bạn có thể xem xét

Ngoài lề. "khuôn khổ front-end" có dấu gạch nối vì nó là một tính từ ghép. Tuy nhiên, ứng dụng của bạn có “giao diện người dùng”—danh từ, không có dấu gạch nối. Nhận được nerdy với tôi

Một số điều khoản để xem xét

Chúng ta sẽ nói về một loạt các khuôn khổ front-end (bạn có thể đã nhận được một gợi ý từ tiêu đề), vì vậy hãy cùng tìm hiểu về thuật ngữ


Khung phần mềm là cấu trúc ứng dụng được viết sẵn để bạn xây dựng dựa trên. Trên thực tế, đó là một tập hợp các tệp và thư mục mà bạn thêm mã và tệp của riêng mình vào. Một framework nhằm giúp bạn xây dựng các ứng dụng nhanh hơn bằng cách giải quyết các vấn đề phát triển phổ biến và thường giúp bạn bắt đầu với

  • Mã soạn sẵn, bao gồm các chức năng được sử dụng lại bởi hầu hết các ứng dụng
  • Cấu trúc thư mục, thường tuân theo triết lý thiết kế
  • Một tập hợp các nguyên tắc thiết kế mà loại ứng dụng của bạn thường xuyên gặp phải. Các framework thực thi các nguyên tắc này, như Ruby on Rails, thường được gọi là

Giao diện người dùng là lớp trình bày của ứng dụng của bạn. Nó thường được mô tả là tất cả những thứ mà người dùng nhìn thấy, nhưng nói chung, đó là bất kỳ mã nào chịu trách nhiệm hiển thị dữ liệu cho người dùng một cách hiệu quả. Vì vậy, giao diện người dùng bao gồm việc xây dựng các giao diện trực quan và dễ chịu, cũng như lưu trữ, trình bày và cập nhật dữ liệu nhận được từ giao diện người dùng hoặc API một cách hiệu quả

Khung giao diện người dùng là một giàn giáo để xây dựng giao diện người dùng của bạn. Nó thường bao gồm một số cách để cấu trúc các tệp của bạn (ví dụ: thông qua các thành phần hoặc bộ tiền xử lý CSS), tạo các yêu cầu AJAX, tạo kiểu cho các thành phần của bạn và liên kết dữ liệu với các phần tử DOM

Một ứng dụng đang phát triển

Bạn có thể xây dựng một lối vào đơn giản chỉ với ba tệp. HTML, CSS và JavaScript. Tuy nhiên, khi ứng dụng của bạn mở rộng quy mô, các tệp của bạn sẽ phát triển cùng với nó, chứa đầy mã spaghetti khó hiểu và không thể duy trì được

Theo truyền thống, hãy xem một ví dụ ngớ ngẩn. giả sử bạn đang xây dựng MySquare, một bảng xếp hạng dành cho những người chơi bảng cạnh tranh. Trong ứng dụng này, người dùng có thể chia sẻ các trò chơi cờ mà họ đã chơi, kết quả thi đấu do giải đấu chấp thuận của họ (hiện đã có giải đấu, tham gia giải đấu) và đánh giá ngắn về các trận đấu cạnh tranh. Tính năng quan trọng nhất của ứng dụng là trang hồ sơ người dùng

JavaScript có tốt cho giao diện người dùng không?

Bạn xây dựng phiên bản đầu tiên của trang hồ sơ này với ba công nghệ cơ bản là HTML, CSS và JavaScript. Nó hoạt động một cái gì đó như thế này.  

  • Ở lần tải trang đầu tiên, phần cuối ban đầu sẽ gửi qua một trang hồ sơ trống với kiểu dáng tối thiểu. Sau đó, và đối với tất cả các lần tải trong tương lai, giao diện người dùng yêu cầu dữ liệu người dùng qua AJAX
  • Mặt sau gửi một số dữ liệu công khai của người dùng dưới dạng JSON và bạn sử dụng JavaScript để tự động nối thêm các phần tử DOM cho huy hiệu trò chơi và bản ghi trên trang.  
  • Khi bạn quyết định tạo các trang dành riêng cho trò chơi liệt kê tất cả người dùng và hồ sơ của họ, bạn sẽ tạo các tệp JavaScript mới sao chép phần lớn mã vì chúng đang vẽ trên cùng một dữ liệu trò chơi.  
  • Mỗi huy hiệu trò chơi (và huy hiệu trận đấu) sử dụng cùng một HTML, vì vậy, bạn lưu trữ đánh dấu trong chuỗi JavaScript và tìm ra cách đưa dữ liệu dành riêng cho trò chơi vào đó, ví dụ:.

    {{Game Name}}

    . Sau đó, bạn thêm huy hiệu HTML vào trang cho mọi trò chơi
  • Khi người dùng cập nhật một số giá trị trên trang, bạn có thể đọc dữ liệu từ DOM bằng cách truy vấn các thuộc tính hoặc bằng cách đính kèm trình xử lý sự kiện vào mọi phần tử—lấy dữ liệu bằng cách đọc dữ liệu từ DOM

Khi MySquare trở nên phổ biến và tập dữ liệu của bạn phát triển, phương pháp này nhanh chóng trở nên khó sử dụng

  • Bạn thấy mình đang thêm dữ liệu vào trang và sau đó đọc nó từ DOM bằng cách lấy các giá trị
    hoặc đọc id hoặc thuộc tính dữ liệu.  
  • Số lượng bong bóng tệp JavaScript và CSS và có rất nhiều mã lặp lại giữa chúng.  
  • Bạn đang ràng buộc các trình xử lý sự kiện với các phần tử giao diện người dùng phổ biến như các trường nhập liệu và các nút, sau đó viết các hàm để cập nhật các giá trị trong cùng các phần tử đó
  • Khi bạn cần thực hiện một thay đổi nhỏ, bạn lo lắng về việc nó sẽ ảnh hưởng như thế nào đến phần còn lại của ứng dụng
  • Khi bạn của bạn đề nghị giúp đỡ công việc phát triển (tất nhiên là vì một số vốn chủ sở hữu), bạn dành hàng giờ để giải thích cách mã của bạn hoạt động

Quản lý những vấn đề này là khả thi với vanilla JavaScript và đủ kiên nhẫn. Với việc lập kế hoạch và suy tính trước, bạn có thể cấu trúc ứng dụng của mình để lường trước một số vấn đề này. Tuy nhiên, khi giao diện người dùng của bạn phát triển, những vấn đề này sẽ chỉ sâu hơn—bạn không bao giờ có thể chắc chắn ứng dụng của mình sẽ phát triển như thế nào.  

Bạn nhận ra rằng việc lưu trữ dữ liệu của mình trong DOM và liên tục nối thêm HTML được lưu trữ trong các chuỗi JavaScript không thể là cách tốt nhất để giải quyết dự án này. May mắn thay, không cần phải phát minh lại bánh xe. Khi bạn thấy mình cần xây dựng một giao diện người dùng mạnh mẽ, có thể bảo trì, đã đến lúc… bạn đoán xem. Khung giao diện người dùng

Nhập, khuôn khổ

Khung giao diện người dùng tồn tại bởi vì đối với nhiều ứng dụng, giao diện người dùng phát triển và căng thẳng theo những cách có thể dự đoán được. Mặc dù mỗi khung phổ biến đưa ra triết lý thiết kế riêng, nhưng tất cả chúng đều đang cố gắng giải quyết các vấn đề chung giống như chúng ta đã gặp trước đó

  • Mã của bạn phải được bảo trì. dễ dàng cho bạn và những người khác đọc, kiểm tra và thay đổi
  • Các giao diện phức tạp thường được làm từ các thành phần giống nhau. Bạn sẽ có thể tạo và sử dụng lại các thành phần này để dễ dàng tạo các trang mới
  • Vì các thao tác DOM diễn ra chậm nên bạn muốn thực hiện càng ít cập nhật phần tử càng tốt
  • Bạn sẽ có thể dễ dàng thao tác giao diện người dùng của mình dựa trên dữ liệu
  • Giao diện người dùng của bạn phải nhất quán và trực quan;
  • Bạn không cần phải phát minh lại bánh xe và viết hàng tấn bản tóm tắt khi giải quyết những thách thức giao diện người dùng phổ biến này
  • Bạn nên có một ngôn ngữ chung để truyền đạt ý tưởng và mẫu của mình với các nhà phát triển khác

Các khuôn khổ khác nhau giải quyết một số, nhưng thường không phải tất cả, những câu hỏi này. Một số, như Bootstrap và SemanticUI, tập trung vào việc tạo HTML và CSS có thể đọc được, có thể bảo trì, nhấn mạnh vào thiết kế trực quan nhất quán. Những người khác, như Vue, React và Angular, thành công trong việc cấu trúc luồng dữ liệu xuyên suốt ứng dụng của bạn, cho phép bạn tập trung vào thao tác dữ liệu thay vì DOM

(Sarah Drasner có phần giới thiệu tuyệt vời thể hiện sự khác biệt giữa đọc dữ liệu từ DOM và lưu trữ dữ liệu trong JS. Mặc dù ví dụ của cô ấy thảo luận về việc chuyển từ jQuery sang Vue, nhưng bạn có thể đọc nó như một sự thay đổi tư duy rộng hơn từ thao tác DOM sang tập trung vào cấu trúc dữ liệu. )

MySquare sẽ trông như thế nào nếu bạn triển khai một khung giao diện người dùng phổ biến, như React?

  1. Bạn sẽ tạo các thành phần HTML/CSS/JavaScript có thể tái sử dụng với các trình giữ chỗ dữ liệu cho huy hiệu trò chơi, bản ghi trận đấu và các thành phần phổ biến khác. Sau đó, khung sẽ hiển thị các phần tử này dựa trên dữ liệu đến (JSON chúng tôi nhận được từ máy chủ hoặc API). Ví dụ: nếu JSON có chín bản ghi trò chơi, chúng tôi sẽ hiển thị chín thành phần , với dữ liệu trận đấu được chèn tự động
  2. Bạn sẽ tuân theo cấu trúc thư mục soạn sẵn để tạo các thành phần, tập lệnh và biểu định kiểu theo cách dễ theo dõi và duy trì. Bạn cần thay đổi cấu trúc và kiểu dáng của bản ghi trò chơi?
  3. Bạn sẽ có thể tận dụng hầu hết các tính năng JavaScript mới nhất cũng như bộ tiền xử lý CSS như SASS để viết mã ngắn gọn, biểu cảm và hiện đại. Khung sẽ chuyển mã này sang HTML/CSS/JavaScript mà trình duyệt hiểu được
  4. Với cơ sở hạ tầng này, bạn có thể tập trung vào thao tác dữ liệu thay vì lo lắng về DOM. Các tính năng liên kết dữ liệu của khung của chúng tôi sẽ tự động hiển thị lại các thành phần có liên quan khi dữ liệu thay đổi. Ví dụ: nếu bạn nhận được dữ liệu về kết quả đối sánh mới từ máy chủ, khung sẽ tự động thêm một thành phần khác vào màn hình
  5. Nếu bạn thấy mình bị mắc kẹt trong một vấn đề, bạn có thể tận dụng cộng đồng khung để nhận trợ giúp. Việc giải thích vấn đề của bạn thậm chí còn dễ dàng hơn vì bạn đang tuân theo các quy ước khung giúp xây dựng các tính năng giao diện người dùng phổ biến
  6. Bởi vì các framework phổ biến thường tuân theo các nguyên tắc thiết kế tương tự, nên việc cộng tác với các nhà phát triển khác sẽ dễ dàng hơn, ngay cả những người không phát triển trong framework cụ thể của bạn—bạn sẽ không cần hướng dẫn các nhà phát triển mới thông qua cấu trúc mã tùy chỉnh của riêng mình

Tách mối quan tâm

Lý tưởng nhất là bạn muốn giao diện người dùng của mình hoạt động như một ứng dụng độc lập, yêu cầu dữ liệu từ giao diện người dùng phía sau, xử lý và hiển thị dữ liệu đó (bạn có thể nghe điều này được gọi là "sử dụng API"). Nguyên tắc củng cố điều này được gọi là "tách biệt các mối quan tâm" và nó nói rằng mỗi phần trong chương trình của bạn phải hoạt động độc lập, có mục đích rõ ràng, duy nhất và giao tiếp thông qua một giao diện được xác định rõ ràng. Mặc dù giao diện người dùng của bạn không phải triển khai khung để tuân theo nguyên tắc phân tách mối quan tâm, nhưng hầu hết các khung đều khuyến khích mẫu kiến ​​trúc này

Lợi thế của thiết kế mô-đun kết quả là các nhà phát triển có thể làm việc độc lập trên các phần khác nhau của ứng dụng của bạn miễn là thành phần của họ chấp nhận các đầu vào có thể dự đoán được và cung cấp các đầu ra có thể dự đoán được. Có giao diện người dùng với một trách nhiệm duy nhất (được tạo thành từ các thành phần mô-đun tuân theo cùng một nguyên tắc) giúp dễ dàng thích ứng với thay đổi. Ví dụ, nếu bạn quyết định chuyển từ Angular sang React, bạn có thể tự tin làm điều đó;

Là lớp chế độ xem dành riêng cho ứng dụng của bạn, giao diện người dùng của bạn phải tự chịu trách nhiệm về logic xung quanh.