Hỏi đáp công nghệ

Flux là gì? Các thành phần và khái niệm tổng quát về Flux

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Table of Contents

Xử lý dữ liệu bên trong ứng dụng client-side là một nhiệm vụ phức tạp. Hôm nay Hỏi đáp Công nghệ sẽ cùng ban xem xét một phương pháp xử lý những dữ liệu phức tạp do Facebook đề xuất có tên là Kiến trúc Flux. Vậy Flux là gì?

flux là gì
Flux là gì?

Khi các ứng dụng của chúng ta ngày càng lớn và phức tạp hơn, chúng ta sẽ cần một phương pháp xử lý dữ liệu tốt hơn. Với nhiều dữ liệu hơn, chúng ta sẽ có nhiều thứ để theo dõi hơn.

Code được yêu cầu để xử lý nhiều dữ liệu và trạng thái ứng dụng với các tính năng mới hơn. Từ phản hồi của máy chủ không đồng bộ đến dữ liệu không đồng bộ, được tạo cục bộ, chúng ta không chỉ phải theo dõi dữ liệu này mà còn phải liên kết dữ liệu đó với view một cách lành mạnh.

Nhận thức được nhu cầu quản lý dữ liệu như trên, nhóm Facebook đã phát hành một pattern xử lý dữ liệu có tên là Flux.

Hôm nay, chúng ta sẽ cùng xem xét kiến ​​trúc Flux là gì và cách nó hoạt động nhé!

Flux là gì?

Flux là kiến ​​trúc ứng dụng mà Facebook sử dụng để xây dựng các ứng dụng web client-side (phía máy khách).

Nó bổ sung cho các view component có thể tổng hợp của React bằng cách sử dụng luồng dữ liệu một chiều. Nó giống một kiểu kiến trúc hỗ trợ React hơn là một framework chính thức và bạn có thể bắt đầu sử dụng Flux ngay lập tức mà không cần nhiều code mới.

Các ứng dụng Flux có ba phần chính: dispatcher (trình điều phối), các store và view (các React component). Bạn không nên nhầm chúng với Model-View-Controller. Controller tồn tại trong một ứng dụng Flux, nhưng chúng là các controller view – các view thường được tìm thấy ở đầu cấu trúc phân cấp và lấy dữ liệu từ các store, sau đó chuyển dữ liệu này xuống cho children.

Ngoài ra, trình action creator – phương thức của trình trợ giúp dispatcher – được sử dụng để hỗ trợ semantic API mô tả tất cả các thay đổi có thể có trong ứng dụng. Có thể hữu ích nếu coi chúng như một phần thứ tư của chu trình cập nhật Flux.

Flux tránh MVC để ủng hộ luồng dữ liệu một chiều. Khi người dùng tương tác với React view, view sẽ truyền một action thông qua dispatcher trung tâm, đến các store lưu giữ dữ liệu của ứng dụng và logic nghiệp vụ khác nhau, nơi cập nhật tất cả các view bị ảnh hưởng. Điều này đặc biệt hiệu quả với phong cách lập trình khai báo của React, cho phép store gửi các bản cập nhật mà không cần chỉ định cách chuyển đổi view giữa các trạng thái.

Ban đầu Facebook đặt ra Flux để giải quyết các dữ liệu dẫn xuất (derived data). Ví dụ: họ muốn hiển thị số lượng unread cho các chuỗi tin nhắn trong khi một view khác hiển thị danh sách các chuỗi, với các chuỗi unread được đánh dấu. Vấn đề này khó xử lý nếu sử dụng MVC – đánh dấu một thread là đã đọc sẽ cập nhật thread model và sau đó cũng cần cập nhật unread count model. Những sự phụ thuộc và cập nhật theo tầng này thường xảy ra trong một ứng dụng MVC lớn, dẫn đến một luồng dữ liệu đan xen rối rắm và kết quả không thể đoán trước được.

Control thì ngược lại với các store: các store chấp nhận các bản cập nhật và điều chỉnh chúng sao cho phù hợp, thay vì phụ thuộc vào thứ gì đó bên ngoài để cập nhật dữ liệu của nó một cách nhất quán. Không có gì bên ngoài stores có bất kỳ thông tin chi tiết nào về cách chúng quản lý dữ liệu cho miền của mình, giúp tách biệt rõ ràng các mối quan tâm. Các store không có phương thức setter trực tiếp như setAsRead() , mà thay vào đó chỉ có một cách duy nhất để đưa dữ liệu mới vào thế giới khép kín của chúng – lệnh callback mà chúng đăng ký với dispatcher.

Cấu trúc và Luồng dữ liệu trong Flux

Dữ liệu trong ứng dụng Flux đi theo một hướng:

flux là gì
Flux là gì? Luồng dữ liệu trong Flux

Luồng dữ liệu một chiều (unidirectional data flow) là trung tâm của Flux pattern và sơ đồ trên phải là mô hình tinh thần chính cho người lập trình Flux. Dispatcher, store and view là các nút độc lập với các input và output riêng biệt. Các action là các đối tượng đơn giản chứa dữ liệu mới và thuộc tính identifying type.

Các view có thể khiến một action mới được truyền đi thông qua hệ thống để đáp lại các tương tác của người dùng:

flux là gì
Flux là gì? Action trong Flux

Tất cả dữ liệu đi qua bộ dispatcher như một hub trung tâm. Các action được cung cấp cho dispatcher theo phương pháp action creator và hầu hết thường bắt nguồn từ các tương tác của người dùng với các view. Sau đó, dispatcher sẽ gọi các lệnh callback mà các store đã đăng ký với nó, gửi các action đến tất cả các store.

Trong các lệnh callback đã đăng ký của chúng, các store phản hồi bất kỳ action nào có liên quan đến trạng thái mà chúng duy trì. Sau đó, các store sẽ phát ra một change event để cảnh báo các controller-view rằng một thay đổi đối với lớp dữ liệu đã xảy ra. Controller-view lắng nghe các sự kiện này và truy xuất dữ liệu từ các store trong một trình xử lý sự kiện. Các controller-view gọi phương thức setState() của riêng chúng, dẫn đến re-rendering của chính chúng và tất cả các descendant của chúng trong cây thành phần.

Cấu trúc này cho phép chúng ta dễ dàng suy luận về ứng dụng của mình theo cách gợi nhớ đến functional reactive programming, hoặc cụ thể hơn là data-flow programming (lập trình luồng dữ liệu) hoặc flow-based programming (lập trình dựa trên luồng), trong đó dữ liệu đi qua ứng dụng theo một hướng – không có binding (liên kết) 2 chiều.

Trạng thái ứng dụng chỉ được duy trì trong các store, cho phép các phần khác nhau của ứng dụng vẫn được tách biệt mạnh mẽ. Khi dependency xảy ra giữa các store, chúng được giữ trong một hệ thống phân cấp nghiêm ngặt, với các bản cập nhật đồng bộ do dispatcher quản lý.

Chúng tôi nhận thấy rằng binding dữ liệu hai chiều dẫn đến việc cập nhật theo tầng, trong đó việc thay đổi một đối tượng dẫn đến thay đổi đối tượng khác, làm kích hoạt nhiều bản cập nhật hơn. Khi các ứng dụng phát triển, các bản cập nhật xếp tầng này sẽ gây khó khăn trong việc dự đoán điều gì sẽ thay đổi như kết quả của một lần tương tác với người dùng. Khi các bản cập nhật chỉ có thể thay đổi dữ liệu trong một vòng duy nhất, thì toàn bộ hệ thống trở nên dễ đoán hơn.

Xem thêm >> DBA là gì? Nhiệm vụ quan trọng của DBA trong doanh nghiệp

Dispatcher

Dispatcher là trung tâm trung tâm quản lý tất cả luồng dữ liệu trong một ứng dụng Flux. Về cơ bản, nó là một sổ đăng ký các callback vào các store và không có thông tin thực sự của riêng nó – nó là một cơ chế đơn giản để phân phối các action đến các store. Mỗi store tự đăng ký và cung cấp một callback. Khi action creator cung cấp cho dispatcher một action mới, tất cả các store trong ứng dụng sẽ nhận action đó thông qua lệnh callback trong sổ đăng ký.

Khi một ứng dụng phát triển, dispatcher trở nên quan trọng hơn, vì nó có thể được sử dụng để quản lý dependency giữa các store bằng cách gọi các lệnh callback đã đăng ký theo một thứ tự cụ thể. Các store có thể chờ đợi các store khác cập nhật xong sau đó tự cập nhật cho phù hợp.

Dispatcher tương tự mà Facebook sử dụng trong bản production đã có sẵn thông qua npmBower hoặc GitHub .

Store

Các store chứa trạng thái và logic của ứng dụng. Vai trò của chúng hơi giống với một mô hình trong MVC truyền thống, nhưng chúng quản lý trạng thái của nhiều đối tượng – chúng không đại diện cho một bản ghi dữ liệu đơn lẻ như các mô hình ORM. Chúng cũng không giống với các bộ sưu tập của Backbone. Không chỉ đơn giản là quản lý một tập hợp các đối tượng kiểu ORM, các store quản lý trạng thái ứng dụng cho một miền cụ thể trong ứng dụng.

Ví dụ: Trình chỉnh sửa video lookback của Facebook đã sử dụng TimeStore để theo dõi vị trí thời gian phát và trạng thái phát lại. Mặt khác, ImageStore của ứng dụng tương tự theo dõi một bộ sưu tập hình ảnh. TodoStore trong ví dụ TodoMVC tương tự ở chỗ nó quản lý một tập hợp các mục việc cần làm. Một store chỉ ra các đặc điểm của cả một bộ sưu tập các mô hình và một mô hình đơn lẻ của một miền logic.

Như đã đề cập ở trên, một store tự đăng ký với dispatcher và cung cấp cho nó một lệnh callback. Lệnh callback này nhận action như một tham số. Trong lệnh callback đã đăng ký của store, một câu lệnh chuyển đổi dựa trên loại của action được sử dụng để diễn giải store đó và cung cấp các móc nối thích hợp vào các phương thức nội bộ của store.

Điều này cho phép một action đưa đến cập nhật trạng thái của store, thông qua dispatcher. Sau khi các store được cập nhật, chúng truyền phát một event tuyên bố rằng trạng thái của chúng đã thay đổi, vì vậy các view có thể truy vấn trạng thái mới và tự cập nhật.

Views và Controller-Views

React cung cấp loại view có thể tổng hợp và có thể tự do re-render mà chúng ta cần cho view layer. Gần phía trên cùng của hệ thống phân cấp nested view, một loại view đặc biệt sẽ lắng nghe các event được phát bởi các store mà nó phụ thuộc vào. Đây được gọi là controller-view, vì nó cung cấp glue code để lấy dữ liệu từ các controller-view và chuyển dữ liệu này xuống chuỗi descendant của nó. Một trong các controller-view này có thể chi phối bất kỳ phần quan trọng nào của trang.

Khi nhận được event từ controller-view, trước tiên nó sẽ yêu cầu dữ liệu mới mà nó cần thông qua các phương thức lấy công khai của store. Sau đó, nó gọi các phương thức setState() hoặc forceUpdate() của chính nó, khiến phương thức render() của nó và phương thức render() của tất cả các descendant dưới nó chạy.

Toàn bộ trạng thái của store thường được chuyển xuống chuỗi view trong một đối tượng duy nhất, cho phép các descendant khác nhau sử dụng những gì chúng cần. Ngoài việc giữ hành vi giống như controller ở đầu phân cấp và do đó giữ cho các descendant view thuần túy về mặt chức năng nhất có thể, việc chuyển toàn bộ trạng thái của store trong một đối tượng duy nhất cũng có tác dụng giảm số lượng prop cần quản lý.

Đôi khi, các controller-view bổ sung có thể cần được thêm sâu hơn trong hệ thống phân cấp để giữ cho các thành phần đơn giản. Điều này có thể giúp đóng gói tốt hơn một phần của cấu trúc phân cấp liên quan đến một miền dữ liệu cụ thể. Tuy nhiên, hãy lưu ý rằng các controller-view sâu hơn trong hệ thống phân cấp có thể vi phạm luồng dữ liệu đơn lẻ bằng cách giới thiệu một entry point mới, có khả năng xung đột cho luồng dữ liệu.

Khi đưa ra quyết định có thêm controller-view sâu hay không, hãy đánh giá mức độ thu được của các thành phần đơn giản hơn so với sự phức tạp của nhiều bản cập nhật dữ liệu đi vào hệ thống phân cấp tại các điểm khác nhau. Nhiều cập nhật dữ liệu này có thể dẫn đến các hiệu ứng kỳ lạ, với phương thức kết xuất của React được gọi liên tục bởi các bản cập nhật từ các controller-view khác nhau, có khả năng làm tăng độ khó trong quá trình gỡ lỗi.

Action

Dispatcher đưa ra một phương pháp cho phép kích hoạt một dispatch đến các store và bao gồm một khối lượng dữ liệu được gọi là một action. Việc tạo action có thể được đóng gói thành một phương thức trợ giúp semantic để gửi hành động đến dispatcher.

Ví dụ: chúng tôi có thể muốn thay đổi text của một to-do item trong ứng dụng to-do list. Chúng tôi sẽ tạo một action với một function signature như updateText(todoId, newText)trong mô-đun TodoActions của chúng tôi. Phương thức này có thể được gọi từ bên trong trình xử lý sự kiện của viêw, vì vậy chúng tôi có thể gọi nó để đáp ứng với một tương tác của người dùng.

Phương thức tạo action này cũng thêm một type vào action để khi action được diễn giải trong store, nó có thể phản hồi một cách thích hợp. Trong ví dụ của chúng tôi, type này có thể được đặt tên là TODO_UPDATE_TEXT chẳng hạn.

Các action cũng có thể đến từ những nơi khác, chẳng hạn như máy chủ. Điều này xảy ra, ví dụ, trong quá trình khởi tạo dữ liệu. Nó cũng có thể xảy ra khi máy chủ trả về mã lỗi hoặc khi máy chủ có các bản cập nhật để cung cấp cho ứng dụng.

Xem thêm >> Top 8 font chữ việt hóa cho powerpoint đẹp mắt nhất

Thông tin thêm về Dispatcher

Như đã đề cập trước đó, dispatcher cũng có thể quản lý các dependency giữa các store. Chức năng này có sẵn thông qua phương thức waitFor trong Dispatcher class. Phương pháp này không được sử dụng trong ứng dụng cực kì đơn giản như TodoMVC, nhưng nó trở nên quan trọng trong một ứng dụng lớn hơn, phức tạp hơn.

Trong lệnh callback đã đăng ký của TodoStore, chúng tôi có thể đợi cho mọi dependency cập nhật lần đầu trước khi tiếp tục:

case 'TODO_CREATE':
  Dispatcher.waitFor([

    PrependedTextStore.dispatchToken,
    YetAnotherStore.dispatchToken
  ]);

  TodoStore.create(PrependedTextStore.getText() + ' ' + action.text);
  break;

waitFor()chấp nhận một đối số duy nhất là một mảng các chỉ mục đăng ký dispatcher, thường được gọi là dispatch token. Do đó, store đang gọi waitFor() có thể phụ thuộc vào trạng thái của store khác để thông báo cách nó nên cập nhật trạng thái của chính mình.

Mã dispatch token được trả lại register() khi đăng ký các lệnh callback cho Dispatcher:

PrependedTextStore.dispatchToken = Dispatcher.register(function (payload) {
  // ...
});

Ưu nhược điểm của Flux

Ưu điểm

Kiến trúc Flux tốt hơn trong một ứng dụng mà các viêw không ánh xạ trực tiếp đến các store miền. Nói một cách khác, khi các view có thể tạo ra các action sẽ cập nhật nhiều store và các store có thể kích hoạt các thay đổi sẽ cập nhật nhiều view.

Các action có thể được duy trì và sau đó phát lại.

Nhược điểm

Flux có thể thêm sự phức tạp không cần thiết vào một ứng dụng trong đó mỗi view lại ánh xạ đến một store. Trong loại ứng dụng này, chỉ cần tách biệt giữa view và store là đủ.

Hi vọng bài viết trên của Hỏi đáp Công nghệ đã giúp bạn hiểu rõ hơn về Flux là gì. Nếu cảm thấy hài lòng với bài viết, hãy chia sẻ nó đến bạn bè của mình nhé!

Các bài viết liên quan

3 thoughts on “Flux là gì? Các thành phần và khái niệm tổng quát về Flux”

  1. I must thank you for the efforts you have put in writing this blog. Im hoping to check out the same high-grade blog posts from you in the future as well. In fact, your creative writing abilities has encouraged me to get my own, personal site now 😉

  2. גם אתם הייתם רוצים שיגיע מעסה
    עד לבית שלכם, יביא איתו את כל הציוד הדרוש
    ויעניק לכם טיפול מקצועי, בידיים מיומנות, שיטפל בכל חלק כואב ודואב בגוף שלכם?
    🌷בעיסוי טנטרי משתמשים בטכניקות שונות (מגע, נשימה, קול,
    תנועה) כדי לתמוך בזרימה של אנרגיית החיים בגוף המטופל וכתוצאה מכך זרימה של האנרגיה
    המינית. אבל גם אנשים הסובלים ממתח נפשי מסיבות
    שונות ואפיו חולים במחלות קשות יכולים ליהנות מהיתרונות הרבים של עיסוי עד הבית בכפר סבא, רעננה והסביבה.

    מאחר והמון אנשים סבורים כי את העיסוי מפנק
    הם יוכלו לקבל רק במסגרת יום פינוק מפנק
    בנתניה/השרון , הם מונעים מעצמם ליהנות מהעיסוי מפנק.
    אנו מזמינים אתכם ליהנות מעולם שלם ואיכותי של תוכן למבוגרים כאשר המודעות עצמן לא
    מרמזות ו/או מספקות ו/או
    מפרסמות. מדעות באתר למספקות שרותי זנות / דירות דיסקטיות או מכוני
    ספא לעיסוי אירוטי / אינטימי, הן מספקות רק שירותי ליווי ללו מין.
    לסיכום, דירות דיסקרטיות בכפר סבא יכולות לשמש למספר מטרות עבורכם, השכרת הדירות
    למספר שעות היא נהדרת למי שלא
    מעוניין לבלות לילה במלון, אלא רק מספר שעות מועטות
    של חוויה.

  3. כמובן, שבכדי ליהנות בצורה הטובה ביותר
    מאותם השירותים המוצעים
    בדירות דיסקרטיות בטבריה, חשוב מאוד לבחור את הדירה בקפידה ולעשות שימוש בכל הכלים
    אשר עומדים לרשותכם ומאפשרים לכם לדעת שבחרתם את הדירה אשר תענה על כל הדרישות שלכם – הן
    מבחינת המיקום של הדירה בעיר, הן מבחינת המראה החיצוני של הבחורות אשר מעניקות שירותים באותה דירה,
    הן מבחינת רמת האירוח, המחירים וכל פרט אחר אשר יהיה לכם חשוב באותן דירות דיסקרטיות בטבריה.
    המטופלים חייבים לדעת ולקבל הסבר מדויק לגבי
    הטיפול שהם עומדים לחוות, באילו חלקים מגופם המטפל מתכוון לגעת ובאילו אמצעים (ידיים, לשון, כפפות, ויברטורים וכו’), ומתקיים תיאום ציפיות באשר לכך.

    הזין שלו כל כך קשה שהוא בקלות מנתב את האגן שלך ומחליק את הזין
    שלו לכוס שלך, בלי ידיים, בבת אחת,
    חזק. מתחמי בילוי נוספים בירושלים ממתינים לכם באזור בנייני האומה, שם תוכלו למצוא
    את מתחם בתי הקולנוע סינמה סיטי ואולמות תיאטרון.
    ישנם מכוני עיסויים בירושלים מעוצבים ומזמינים שניתן להגיע אליהם.
    ישנם עיסויים בתל אביב שונים המתמקדים בעוצמות שונות, ולכן
    חשוב לתאם ציפיות עם המעסה טרם אתם
    מגיעים אל מכון העיסוי.

Leave a Comment

Email của bạn sẽ không được hiển thị công khai.

Bài viết liên quan