Flux trong giới Javascript không chỉ là chủ đề nổi tiếng nhất mà còn là chủ đề khó nắm bắt nhất. Bài viết này sẽ cố gắng giải thích một cách dễ hiểu cho tất cả mọi người.

Flux là gì

Flux và ReactJS cùng được tạo ra bởi Facebook để giải quyết một số những vấn đề rất đặc thù của bản thân Facebook, Tuy vậy 2 công cụ này có thể được sử dụng hoàn toàn riêng biệt.

Facebook thời gian đầu có một notification bug rất phổ biến. Khi bạn login vào Facebook, bạn thấy một notification ở phần message. Khi click vào tin nhắn thì notification biến mất nhưng không hề có một tin nhắn mới nào. Sau một vài phút lướt Facebook thì hiện tượng trên lại lặp lại: notification lại hiện ra và click xong thì lại không có tin nhắn nào....

Bug này cứ lặp đi lặp lại trong một vòng luẩn quẩn. Vòng luẩn quẩn không chỉ ở phía người dùng Facebook mà còn ở phía team phát triển của chính Facebook: họ cố gắng fix và bug biến mất, nhưng ngay sau đó lại xuất hiện trở lại trước khi bị fix và xuất hiện tiếp ....

Từ đó Facebook đã quyết định đi tìm giải pháp giải quyết triệt để vấn đề này.

Hiểu sâu hơn vấn đề

Vấn đề thực sự nằm ở bên dưới, ở cách mà dữ liệu luân chuyển bên trong web app của Facebook. Dưới đây là mô tả sơ khai và lược tắt nhất mà tôi hiểu được sau khi nghe Facebook trình bày, và chắc chắn rằng vấn đề thật sự còn lớn hơn thế này nhiều

Facebook từng xây dựng Model để chứa dữ liệu và View để hiển thị. Bởi vì tương tác của người dùng là ở View nên đôi khi View cần phải update ngược lại dữ liệu ở Model khác. Điều này dẫn đến hiệu ứng "thác nước" khi một hành động của người dùng trigger một loạt các thay đổi, mỗi thay đổi lại có thể trigger ra một loạt các thay đổi khác, và tất cả các thay đổi là quá trình bất đồng bộ.

Và cuối cùng là khó khăn rất lớn khi debug các luồng dữ liệu như thế này

Giải pháp: Luồng dữ liệu một hướng

Và Facebook quyết định thử một kiến trúc hoàn toàn khác, khi mà dữ liệu luôn chỉ di chuyển theo một và chỉ một hướng duy nhất. Khi một dữ liệu mới xuất hiện, luồng sẽ bắt đầu lại từ đầu.

Facebook gọi kiến trúc này là Flux.

Rất tuyệt! Tuy vậy có thể bạn sẽ không hiểu hết Flux nếu chỉ nhìn vào hình trên. Tôi sẽ giúp bạn hiểu Flux sâu hơn bằng cách đi theo một loạt các hình tượng nhân vật minh họa.
Chúng ta sẽ thử tưởng tượng một team làm việc chung với nhau để cùng giải quyết một vấn đề. Tôi sẽ giới thiệu từng thành viên một trước khi nói xem họ tương tác với nhau thế nào để giải quyết vấn đề chung của họ.

The Action Creator

Nhân vật đầu tiên gọi là The Action Creator. Anh ta giữ nhiệm vụ tạo ra các action, là bước đầu tiên trong luồng mà các thay đổi và tương tác đều đi qua. Bất cứ khi nào trạng thái của web app hay là render của view thay đổi thì đầu tiên là một hành động sẽ được tạo ra.

Bạn hãy nghĩ anh này như một anh chàng đánh máy, anh ta biết bạn cần truyền đạt điều gì và cần phải đánh ra văn bản theo định dạng nào cho mọi người đều hiểu được.

The Action Creator tạo ra một action cùng với type và payload của action đó. Type thường sẽ là một hằng số được định nghĩa trước, kiểu như MESSAGE_CREATE hay MESSAGE_READ.

Việc định nghĩa trước các type của action thành một loạt hằng số có sẵn là một cách làm tốt, bởi khi một dev mới nhảy vào team sẽ có thể mở file định nghĩa ra và nhìn qua một lượt được tất cả các type của action tồn tại trong app.

Sau khi The Action Creator tạo ra action, anh ta sẽ gửi nó cho The dispatcher.

The dispatcher

The dispatcher về cơ bản là một tập hợp rất nhiều các callbacks. Hãy nghĩ nhân vật này như một anh trực điện thoại cùng với một bảng mạch và luôn biết trước một danh sách các store để gửi action đến. Khi một action được gửi đến The dispatcher, anh ta sẽ gửi nó đến store tương ứng theo quy tắc đồng bộ.

Flux dispatcher khác với dispatcher ở rất nhiều các kiến trúc khác. Action được gửi đến toàn bộ các store đăng ký với dispatcher không kể type là gì. Mỗi store sẽ nhận "nghe" từ tất cả các action và tự filter để xử lý.

The store

Và cuối cùng là The store, giữ toàn bộ các trạng thái và logic chuyển trạng thái của app.

Hãy tưởng tưởng lão này là một công chức chính phủ đầy quyền lực. Tất cả mọi thay đổi trạng thái đều được thực thi trực tiếp ở đây. Mỗi khi bạn muốn thay đổi một trạng thái, bạn cần phải tạo một action, submit vào The action creator, đi qua The dispatcher rồi mới được The store xử lý.

Như nói ở phần trên thì một store sẽ nhận rất nhiều các action, và trong store thường sẽ có một cấu trúc switch để quyết định xem có cần phải quan tâm đến action hay không.

The controller view and the view

The view có nhiệm vụ thu nhận lệnh thay đổi trạng thái và render hiển thị, cũng như nhận input từ người dùng.

Một view như là một nhân viên trình bày. Anh ta chỉ biết đến dữ liệu và biểu diễn dữ liệu đó (thành HTML) cho người dùng. Controller view như là một nhà quản lý cấp nhỏ đứng giữa store và view, nhận thông báo khi trạng thái thay đổi, tổng hợp những nội dung cần thay đổi và truyền đến những view trực thuộc.

Phối hợp giữa các nhân vật kể trên

Chúng ta hãy xem team trên giải quyết công việc ra sao nhé!

Setup

Sau đây là phần setup chỉ diễn ra 1 lần lúc lần đầu vào app.

1) Lão Store nhắn với anh dispatcher

Ê ku, đây là số điện thoại của tao. Khi nào có "hàng" thì nhắn tao đấy!

"Số điện thoại" ở đây là callback, "hàng" là action.

2) Controller hỏi Store về trạng thái cuối.
3) Sau khi Store đưa trạng thái cuối cho Controller, Controller đưa cho View để render hiển thị.

4) Controller và View cũng nhắn với Store

Anh ơi có gì mới nhắn bọn em với nhá

Luồng dữ liệu

Sau phần setup thì web app đã sẵn sàng nhận input từ người dùng. Nếu khi này trigger một action bằng cách để người dùng tạo ra một sự thay đổi.

1) View nói với Action Creator tạo ra một action

2) Action Creator tạo ra một action và chuyển qua dispatcher

3) Action dispatcher gửi lại action cho tất cả các Store liên quan. Mỗi Store nhận thông báo xong tự quyết định xem có thay đổi trạng thái nào dựa vào action hay không.

4) Sau khi thay đổi trạng thái, Store lại thông báo tiếp cho View controller đã đăng ký.

5) View controller hỏi lại Store cụ thể về trạng thái mới

6) Sau khi Store đưa lại thông tin cụ thể. View controller sẽ nói với các View của mình render lại hiển thị.

Bạn có thấy dễ hiểu hơin chút nào chưa :)
Bài gốc: A cartoon guide to Flux.