Tìm hiểu về REDUX
=> Để hiểu rõ về REDUX chúng ta sẽ cùng đi đến một ví dụ thực tế từ đó có thể hiểu và sử dụng thành thạo REDUX.
Ví dụ : Chúng ta cần mô tả quá trình hoạt động của một công ty bảo hiểm.
+ Nếu bạn không quen thuộc với công ty bảo hiểm thì hiểu đơn giản rằng công ty đề nghị bạn trả một số tiền nhất định hàng tháng và sau đó nếu có chuyện tồi tệ xảy ra với bạn thì công ty sẽ tiến hành đền bù cho bạn.
=> Trước hết bạn cần hiểu 2 khái niệm cơ bản này.
- Giao Kèo hay giao kèo (Policy) : Trước hết muốn làm khách hàng của một công ty bảo hiểm bạn cần phải có Giao Kèo tức là bạn với công ty sẽ thống nhất về mức phí đền bù khi có điều không may xảy ra với bạn.
- Yêu Cầu (Claim): Khi có điều không may xảy ra với bạn thì bạn sẽ gửi yêu cầu (Claim) đến công ty để nhận mức phí đền bù.
=> Mô tả sơ bộ quá trình hoạt động của một công ty bảo hiểm :
- Như trên hình mình mô tả hoạt động cơ bản của một công ty bảo hiểm=> Chúng ta đi qua toàn bộ sơ đồ từ trái sang phải
B1: Chúng ta có một khách hàng A, giả sử trong trường hợp này A muốn đến công ty để tạo ra một Policy mới với công ty mục đích nhằm trong trường hợp A bị tai nạn hay gì đó thì ông sẽ được công ty trả một khoản tiền.
B2: Khách hàng A gửi một form đến công ty bằng cách gửi form cho FormReceiver (người nhận from) anh chàn này sẽ nhận được form sau đó sao chép nó thành 3 bản để gửi đến lần lượt các phòng trong công ty.
- 3 Phòng lần lượt là Claims History , Accounting , Policies.
+ Claims History : Lưu trữ tất cả các yêu cầu, khiếu nại đền bù từng được gửi nên họ chẳng quan tâm đến form kiểu policy như thế này nhưng họ vẫn sẽ nhận được một bản sao của form
+ Accouting : Kế toán khi công ty cần dùng để tiền sẽ phải thông qua phòng kế toán , nó lưu trữ toàn bộ tiền của công ty.
+ Policies : Lưu trữ các bản giao kèo, hợp đồng của công ty với khách hàng,bạn cũng có thể đoán được đây chính là phòng ban đứng ra xử lý form được gửi.
=> Nghiên cứu hoạt động của Policies
- Policies Department : Lưu trữ thông tin của toàn bộ khách hàng đã có giao kèo với công ty.
- Ví dụ như Juliet muốn làm một giao kèo với công ty thì cô ấy sẽ gửi một Form để đăng kí đến phòng này.
=> Giả sử bây giớ có một nhóm quản lý (Management) luôn đến gõ cửa phòng Policies và muốn cập nhật liên tục danh sách khách hàng có giao kèo với công ty mục đích có thể như thu thập, tổng hợp số liệu.
Nhóm quản lý (management) đã quá mệt mỏi với việc liên tục phải đi cập nhật dữ liệu. Lúc này công ty thực hiện một thay đổi nhỏ về nơi lưu trữ các giao kèo (Policies), tất cả các phòng sẽ lưu trữ toàn bộ dữ liệu của nó trong một kho dữ liệu trung tâm của công ty được lưu trữ độc lập bên ngoài (All Department Data). Lúc này Nhóm Quản Lý không phải liên tục đi lại giữa các phòng nữa mà chỉ cần đến kho dữ liệu trung tâm để cập nhật dữ liệu.
=> Toàn bộ mô hình hoạt động.
- Mỗi phòng nhận được form và data và giả sử trong trường hợp này form có hiểu Policies.
- Bạn thấy rằng rõ ràng lúc này cần phải cập nhật danh sách của Policies trong AllDepartMentData.
- Policies Department khi thấy có yêu cầu tạo giao kèo sẽ lấy dữ liệu từ All Departmentdata.
(tức là nó có toàn bộ danh sách khách hàng đã đăng kí giao kèo từ All Departmentdata)
- Sau khi đã đăng kí giao kèo thành công với khách hàng (khách hàng mới được tạo ra) thì nó sẽ trả về danh sách (đã được thêm khách hàng mới) cho All Department Data để nó lưu trữ.
- Policies Department không quản lý thông tin khách hàng mà mỗi lần có khách hàng mới đăng kí nó phải yêu cầu dữ liệu từ AllDepartmentData , nhiệm vụ của nó chỉ là thêm mới khách hàng vào danh sách.
- Manegement sẽ có thể quản lý được thông tin của toàn bộ các phòng ban thông qua mô hình này.
=> Tìm hiểu về form
Ví dụ về form :
Form có 2 phần
+ Type : khai báo để xác định loại form được gửi cho phòng ban nào.
+ Payload : cho biết nội dung form (tên khách hàng , số tiền yêu cầu đền bù).
=> Tiếp tục đi sâu vào quá trình hoạt động của từng phòng ban
- Trong hình ảnh này bạn thấy rằng có một form được tạo ra, FormRecive sẽ tạo 3 bản sao gửi cho từng phòng đồng thời lấy data trong AllDepartment của từng phòng ban và gửi cho từng phòng.
- Lấy ví dụ bạn đang ở phòng ClaimHistory, dữ liệu đầu vào của phòng có 2 thứ là form và ListData
+ Như vậy dữ liệu đầu vào có 2 thứ Một bản danh sách các claim và một form.
+ Tiếp theo khi form được gửi đến thì phòng sẽ kiểm tra xem đây có phải form dạng claims không bằng cách kiểm tra type của nó, nếu không thì chẳng làm gì cả , gửi lại danh sách claim cho AllDapartmentdata thôi còn nếu đúng là form thì push payload vào danh sách các claims vào gửi lại cho AllDepartmentData.
=> Hoạt động của phòng kế toán (Accountting Department).
+ Nếu form dạng Claim thì xem trong payload số tiền phải đền bù là bao nhiêu rồi trừ đi
+ Nếu form dạng Policy (như vậy người dùng cần đóng phí hàng tháng để duy trì giao kèo) => cộng tiền vào tổng số tiền của công ty
+ Gửi trả dữ liệu cho All...
=> Hoạt động của phòng đăng kí chính sách (Policies Department)
=> Hoạt động của phòng đăng kí giao kèo cũng khá giống với các phòng ban trên
+ Dữ liệu đầu vào nó là (một danh sách các khách hàng lấy từ AllDepartMentData , một form)
+ Nếu type không phải dạng (polici) thì chẳng làm gì cả gửi lại list name cho All..
+ Nếu type == polici => lúc này sẽ có 2 dạng yêu cầu , đăng kí polici hoặc hủy polici tùy theo yêu cầu phòng sẽ thêm tên khách hàng hoặc loại bỏ khách hàng khỏi list name..sau đó gửi trả list name cho AllDepartmentData.
Nhận xét
Đăng nhận xét