Câu trả lời ngắn gọn: tùy thuộc vào bạn, làm sao viết code thoải mái để Application State tối giản nhất có thể mà không làm mất tính tin tưởng vào ứng dụng.

(Bài viết này sử dụng cho cả React Js và React Native)

Một số khái niệm

Application State: hay còn gọi là Redux Store chứa trạng thái của ứng dụng bao gồm dữ liệu từ máy chủ, kết quả tương tác/hành động của người dùng, dữ liệu từ thiết bị (GPS, Clock, Accelerometer…)
Local State: là trạng thái nội tại của  component, sự thay đổi bất kỳ trong Local State không làm ảnh hưởng đến Application State

Presentation Component: là component chỉ có nhiệm vụ hiển thị, nhận tương tác từ người dùng.
Container Component: là component bao bọc Stateless/Presentation component và truyền dữ liệu cho các component này bằng props.

Stateless Component: đây là một phiên bản của Presentation Component nhưng không chứa state, thông thường được viết bằng hàm đơn thuần, mọi thứ đều được truyền thông qua function’s arguments (props).

Khi nào nên sử dụng Redux

Trước tiên, xin trích dẫn những câu trả lời từ những người tạo ra React và Redux:

Pete Hunt (Cựu thành viên tạo ra React):

You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.

Dan Abramov (Tác giả Redux):

I would like to amend this: don’t use Redux until you have problems with vanilla React.

Như vậy, chỉ sử dụng Redux/Flux khi và chỉ khi bạn gặp vấn đề với React. Lý thuyết là vậy, nhưng để biết được tình huống nào gọi là “vấn đề” quả thật không hề dễ dàng, và khi đã gặp vấn đề thì lượng code đã viết cũng đã trở nên kha khá, và việc tích hợp Redux sẽ trở nên khó khăn hơn – tất nhiên không phải là quá khó, nhưng thay vì business logic  bạn đặt ở 1 chỗ (có thể chia nhiệm vụ cho từng thành viên trong nhóm khác nhau, có thể test dễ dàng hơn) thì business logic được đặt ngay trong chính React’s component => việc tái cấu trúc luồng hoạt động của dự án ước chừng sẽ khó khăn là vì vậy.

Như hình mô tả dưới đây, mỗi node là 1 component, việc tách ra trạng thái tổng, giúp chúng ta dễ bảo trì phần Model (business logic) và phần View (component) trong mô hình MVC, cũng như dễ dàng sử dụng SSR (Server Side Rendering):

Theo điều kiện nguồn lực, dần dà việc tái cấu trúc dự án để sử dụng Redux dần trở nên bất khả thi, nhất là đối với những dự án không biết tách “Container Component” và “Presentation Component” ra riêng biệt:

Do vậy, yếu tố quyết định là phải phân biệt được “Container Component” và “Presentation Component”, khi đó Container Component sẽ làm việc với Application State, còn Presentation Componnent sẽ có Local State.

Một điều dễ nhận ra là khi áp dụng Redux, mặc dù nó tốt thiệt – giúp cho ứng dụng dễ hiểu, dễ bảo trì, nhưng lượng code phải viết sẽ nhiều lên kha khá. Cứ mỗi chức năng, ta cần phải viết Actions/Events -> Reducers -> Container Component -> Presentation Component, tương ứng bạn cũng sẽ viết Test cho chừng đó bước, vì vậy việc sử dụng Application State một cách hợp lý là điều cực kỳ quan trọng, giúp cho ứng dụng gọn nhẹ về mặt cấu trúc, code, và tài nguyên (bộ nhớ để lưu trữ Store)
Muốn tìm cách cải thiện ứng dụng sao cho dễ hiểu, dễ bảo trì thì đọc tiếp :). Mình cũng từng như bạn, cũng như rất nhiều lập trình viên khác sử dụng Redux bị rối khi thắc mắc không biết là khi nào nên dùng Application State (trạng thái của ứng dụng) khi nào nên dùng Local State (trạng thái của component) để làm sao đạt được mục đích là:

• Application State tối giản nhất có thể
• Sử dụng Local State để viết code ngắn gọn nhất có thể

Nếu bạn đọc xong mà vẫn không thích Redux, thì khi có vấn đề về việc trao đổi dữ liệu giữa component cha-con thì đọc ở bài: “Sử dụng context để giao tiếp giữa các component cha-con trong React”

Sử dụng Redux với React sao cho hiệu quả

Nếu bạn có sử dụng React Native thì cũng có biết là từ phiên bản 0.25 trở đi, thì cách viết import, creatClass có khác đôi chút:
0.24 trở về trước

import React, { Component, View } from 'react-native';

0.25+

import React, { Component } from 'react';
import { View } from 'react-native';

Qua đó để thấy rằng, React Native quay trở về đúng bản chất của nó khi hệ sinh thái React ra đời, đó là React Native chỉ đóng vai trò phần View, còn React sẽ đóng vai trò xương sống khởi tạo hệ sinh thái React. Mình đưa ra ý này là để nhấn mạnh tầm quan trọng của sự tách biệt giữa các thành phần, càng nhỏ thì càng dễ bảo trì, do vậy nếu vẫn chưa thông ở phần “Khi nào nên sử dụng Redux” thì bạn hãy nghiên cứu thêm rồi đọc tiếp nhé.

Làm sao để sử dụng Redux hiệu quả, thì câu trả lời đơn giản là một Câu hỏi: Có các “thành phần” bất kỳ nào của ứng dụng sử dụng “kết quả” của hành động thay đổi trạng thái hay không?
“Thành phần” ở đây có thể là UI components, hoặc lưu trữ vào local store, hoặc lưu trữ ở server. Chỉ cần mỗi khi bạn bắt đầu viết 1 chức năng, component hãy đặt câu hỏi trên cho những tương tác vào ứng dụng (có thể sự kiện từ nhiều phía khác nhau), thông thường Local State sẽ được sử dụng để quản lý sự tương tác của người dùng, ví dụ những sự kiện sau thì không cần thiết phải sử dụng Application State:

• Toggle một menu, hoặc accordion
• Input text, radio, select..: bình thường sẽ sử dụng Local State
  • Nếu các loại input là dạng search realtime, hoặc freeze search, filter cho mỗi ký tự nhập vào thì dùng Application State, bởi vì nó có tác động đến component khác
• Những tương tác của người dùng đối với ứng dụng chỉ là tạm thời mà có thể khi refresh ứng dụng, bạn không còn quan tâm. Vì nếu quan tâm, nghĩa là cần lưu trữ ở đâu đó, có nghĩa là nó đã tác động đến “thành phần” khác thì nên sử dụng Application State.

Fullstack Station’s Tips

Có nhiều lập trình viên khuyên nên viết Stateless Component bằng hàm thông thường, ví dụ:

import React, { PropTypes } from 'react'

const Todo = ({ onClick, completed, text }) => (
  <li
    onClick={onClick}
    style={{
      textDecoration: completed ? 'line-through' : 'none'
    }}
  >
    {text}
  </li>
)

Bạn thường cũng sẽ viết theo, nhưng do lười biếng nên thiếu đoạn code sau:

Todo.propTypes = {
  onClick: PropTypes.func.isRequired,
  completed: PropTypes.bool.isRequired,
  text: PropTypes.string.isRequired
}

Và nếu tốt hơn nữa thì có thêm defaultProps cho những props không bắt buộc truyền vào. Việc thêm propTypes vào các component là cần thiết, để React sẽ kiểm tra cho bạn tính đúng đắn của component khi thực thi, sẽ báo cho bạn biết nếu props bị thiếu, từ đó giúp cho chất lượng sản phẩm được nâng lên, ít lỗi hơn. Rõ ràng với đoạn mã trên, nếu không ràng buộc bắt  buộc thì sự kiện onClick sẽ bị lỗi nếu truyền props bị thiếu!

Lời kết

Khi bạn áp dụng Redux vào React, những vấn đề về việc khi nào nên sử dụng Application State hay Local State đã được giải đáp phần nào trong bài viết này. Tùy trường hợp vào mỗi dự án có tính chất khác nhau mà việc áp dụng cũng sẽ linh động khác nhau, chứ không nhất thiết phải theo một mô hình nào, bởi vì ngay cả người tạo ra cũng không thể dự tính được hết các tình huống sử dụng thực tế của sản phẩm được. Nếu bạn có ý kiến để hỗ trợ bài viết tốt hơn, vui lòng comment nhé!

Bài viết tới, mình sẽ bàn luận tới 1 vấn đề cũng không có cách giải quyết hoàn hảo, đó là: nên đặt business logic vào actions hay reducers trong Redux?

The post Hướng dẫn sử dụng Redux hiệu quả trong ứng dụng React appeared first on Fullstack Station.

Time traveling là gì

Time traveling là “du hành thời gian” ngay trong nghĩa đen của nó, như cái cỗ máy vượt thời gian của Đôrêmon vậy đó. Khái niệm này thường được hiểu theo khái niệm về vật lý không gian, thời gian, ánh sáng nhiều hơn là liên quan đến lập trình. Trong lập trình ứng dụng phần mềm, Time traveling là kỹ thuật giúp cho ứng dụng có tính Undo/Redo, hay Replay (tưởng tượng như bàn cờ có ghi lại các nước đi nên dễ dàng replay), kỹ thuật này chính là mục tiêu hướng tới của Redux (Xem Redux js là gì) do Dan Abramov giới thiệu tại React Conf Euro 2015 và nhanh chóng lan toả trong giới lập trình.

Kỹ thuật này chỉ có được, khi ta áp dụng thư viện Redux, hoặc các thư viện khác mà đi theo hướng của Flux (các thư viện khác thì mình không chắc là có Time traveling hay không). Trong lập trình ứng dụng giao tiếp với người sử dụng hay cả với server thì trạng thái của phần mềm là rất quan trọng, nhất là các ứng dụng có giao tiếp với người dùng, và đặc biệt là ứng dụng web với các điều kiện có thể xảy ra làm thay đổi trạng thái như sau:

• Dữ liệu trực tuyến được cập nhật từ máy chủ một cách tự động
• Dữ liệu sự kiện từ thao tác của người dùng: nhấn chuột, di chuyển con trỏ, nhập dữ liệu..
• Dữ liệu từ bộ định tuyến URL (Router) nếu người dùng nhấn vào 1 liên kết
• Dữ liệu từ thời gian
• Dữ liệu có được từ lời gọi API bất đồng bộ

Như vậy, trong một ứng dụng SPA (Single Page Application) có tính chất trực tuyến, thì tất cả các loại dữ liệu có thể đều có thể xảy ra bất kỳ lúc nào. Vấn đề đặt ra là: tại mỗi thời điểm đó (giả sử như thời gian ngưng lại), làm sao biết được trạng thái của ứng dụng đang như thế nào, và làm sao để quay lại 1 số sự kiện trước đó – tức là áp dụng khái niệm rollback, undo.

Với các kỹ thuật lập trình hiện tại, hầu như không thể có giải pháp, nên việc ra đời thư viện Redux được xem như một bước đột phá của ngành lập trình ứng dụng. Với ứng dụng web không phải là SPA, thường đơn giản hơn 1 bước do URL được lược giản đi rồi, bản chất URL cũng là 1 trạng thái (state) của ứng dụng.

Bạn có thể xem ví dụ trên, toàn bộ thao tác của người dùng, đều được lưu vào cây bên phải (Redux Dev Tool – xem phần tiếp theo bên dưới), khi ta click vào cột bên phải, ở 1 dòng nào đó và bị gạch đi, có nghĩa là bỏ sự kiện đó ra khỏi trạng thái của ứng dụng.

Nhờ có tính năng này, giả sử code bị lỗi – đây là điều đau khổ nhất khi debug – thì vì cây sự kiện vẫn còn, nên khi bạn thay đổi code thành code đúng, thì Redux sẽ apply toàn bộ sự kiện đó với code mới và giúp chúng ta không cần phải thực hiện lại hàng loạt thao tác phức tạp để reprodure lại các dữ liệu cũ để xem code đúng chưa. Hoặc là thay đổi một giá trị tính toán nào đó, ví dụ như ở trên, thay vì click là +-1, thì sửa giá trị thành +-2 chẳng hạn, thì trạng thái mới sẽ được cập nhật dựa trên “sự kiện đã thao tác”.

Time traveling – Redux có lợi gì

Đoạn trên giải thích hơi dài một chút, nói tóm lại với Time traveling của Redux thì có các điểm:

• Dễ dàng debug
• Dễ dàng phát triển nhanh ứng dụng vì không phải mất thời gian nhập sự kiện lại
• Dòng chảy của chương trình dễ hiểu – giúp cho việc cộng tác nhóm dễ dàng
• Dòng sự kiện giúp cho chương trình tuân theo một logic chặt chẽ, chỉ cần nhìn vào cây sự kiện là bạn có thể đoán được hoạt động của chương trình, vì vậy còn được gọi là Predict container

Bạn chỉ cần áp dụng Redux là có thể đạt được những lợi ích này rồi. Redux được xem là dành cho ReactJs nhưng bạn hoàn toàn có thể kết hợp với những framework,thư viện bất kỳ như React Native, AngularJs, BackboneJs…

Mặc dù bạn có thể học ReactJs mà không cần quan tâm đến Redux, nhưng mình khuyên là nên xem chung Redux vì nó giúp cho việc lập trình dễ hiểu hơn. Có thể nói React hay ở vòng đời component thì có thể xem Redux hay ở vòng đời “sự kiện” của ứng dụng.

Redux Dev Tool

Công cụ này do chính tác giả của Redux viết, giúp bạn hiểu hơn về dòng sự kiện của ứng dụng, cũng như debug dễ dàng hơn, bao gồm cả tính năng Time traveling nữa.

Kết

Redux rất là tuyệt, bản chất hoạt động một cách độc lập nên bạn có thể áp dụng cho bất kỳ dự án nào, sử dụng bất kỳ nền tảng, thư viện javascript nào. Nếu bạn vẫn chưa áp dụng Redux, lời khuyên thật tình là phải áp dụng sớm nhất có thể, có 2 nguồn để học tốt:

• http://learnredux.com
• https://egghead.io/courses/building-react-applications-with-idiomatic-redux

The post Kỹ thuật lập trình Time traveling là gì appeared first on Fullstack Station.

Trạng thái (state) của ứng dụng là gì

Cùng lướt qua các ví dụ cho dễ:

Ví dụ 1: Để hình dung đơn giản nhất, trạng thái của ứng dụng tương tự như cái nút Lui (Back)/Tới (Forward) lịch sử của trình duyệt của trình duyệt web. Bạn mở web nhấn vào vòng vòng một hồi, rồi nhấn quay lại các trang trước, mỗi trang như vậy còn được gọi là trạng thái. Nhưng, với các ứng dụng SPA (Single Page Application) thì chuyện Lui/Tới cũng là cả vấn đề rồi.

Ví dụ 2: Không liên quan đến web nhưng rất điển hình đó là trạng thái của bàn cờ tướng hay cờ vua chẳng hạn. Mỗi khi người chơi đi một nước – trong thi đấu – họ phải ghi lại từng nước đi, bằng cách này sau khi chơi xong người ta có thể tái hiện lại bàn cờ một cách dễ dàng. Ứng với mỗi nước đi, đó chính là trạng thái của bàn cờ.

Vậy thì nó liên quan gì đến trạng thái của ứng dụng?

Một ứng dụng web hoạt động cần dữ liệu từ phía máy chủ, thao tác của người dùng,…tổng hợp các thứ này lại ta được trạng thái của ứng dụng. Nếu biết trạng thái này, có nghĩa là tại thời điểm X ta biết được máy chủ đã trả về dữ liệu gì, người dùng đã thao tác những gì, nhập vào dữ liệu gì.

Việc biết trạng thái này có quan trọng không?

Các ứng dụng web hiện nay ngày càng phức tạp, việc biết được trạng thái này giúp cho công việc kiểm soát lỗi dễ dàng hơn, nhất là nó làm cho cách chúng ta lập trình cũng đơn giản hơn. Ví dụ, nếu bạn có một biểu mẫu mua hàng, giả sử có 5 bước: xác nhận đơn hàng, áp dụng mã khuyến mãi, điền thông tin giao hàng, thanh toán, hoàn tất. Với một ứng dụng web thông thường, nếu xảy ra lỗi ở bước 4, lập trình viên sẽ kiểm tra lại và nhập dữ liệu từ 1->4, tìm lỗi sau đó sửa lỗi, công đoạn này lặp đi lặp lại n lần!!! Nếu sử dụng Redux, mỗi công đoạn xem như một trạng thái và bạn không cần phải lặp lại bước 1->4 nữa.

Các nguyên tắc cơ bản của Redux

Nguồn dữ liệu tin cậy duy nhất

Như mình đã giới thiệu cơ bản ở trên, trong quá trình hoạt động của ứng dụng, bị phụ thuộc khá nhiều yếu tố: dữ liệu từ máy chủ ban đầu, thao tác của người dùng (nhập dữ liệu, click menu, button…), dữ liệu cập nhật từ máy chủ, dữ liệu được tính toán trong ứng dụng (Ví dụ: tính toán số dư tài khoản dựa trên biến động của tỉ giá)…những yếu tố này còn gọi là nguồn dữ liệu. Những nguồn dữ liệu này đến từ những nơi khác nhau, bất kỳ khi nào, khiến cho ứng dụng của chúng ta rất khó kiểm soát, chúng tác động đến những thành phần đơn lẻ, hoặc nhiều thành phần trên ứng dụng, hoặc hiệu ứng dây chuyền. Chính vì sự phức tạp đó, là vấn đề mà Redux muốn giải quyết, tất cả các nguồn dữ liệu cần phải được quản lý và tạo thành một nguồn duy nhất, tin cậy.

Trạng thái là chỉ được phép đọc (read-only)

Trạng thái của ứng dụng không được phép thay đổi “trực tiếp”, trạng thái cũng chỉ là một đối tượng thôi mà, nên việc thay đổi là được. Tuy nhiên, với Redux hay Flux thì trạng thái chỉ thay đổi khi và chỉ khi có một sự kiện xảy ra, giống như ra trận thì chỉ được phép nghe lời từ chỉ huy, mọi tin tức tình báo đều được gởi tới chỉ huy, nếu không có lệnh từ chỉ huy thì tất cả không được phép manh động.

Thay đổi chỉ bằng hàm thuần tuý

Điều may mắn là việc sử dụng Redux js là không quá khó, việc thay đổi trạng thái của ứng dụng, được thực hiện thông qua các hàm thuần tuý. Đưa vào giá trị sự kiện, trạng thái hiện tại và hàm trả về trạng thái tiếp theo. Dù tương lai ứng dụng của bạn có thể rất lớn, nhưng các hàm reducer này thì chỉ cần nhỏ gọn thay đổi trên từng lá của cây trạng thái, và chúng hoàn toàn có thể kết hợp với nhau tạo thành chuỗi sự kiện. Ví dụ: người click vào menu (một sự kiện => thay đổi trạng thái), sau đó router cũng cần thay đổi để phù hợp với ngữ cảnh.

Tính ứng dụng của Redux js là gì

Theo mình thấy Redux có 3 ứng dụng quan trọng nhất:

• Quản lý trạng thái: như một bản replay có thể undo/redo trạng thái của ứng dụng, phải nói là “Không thể tin được”, cá nhân mình rất thích tính tin cậy của ứng dụng mà Redux mang lại.
• Tăng tốc phát triển: với webpack đã có Hot Module Replacement, khi kết hợp với Redux, tạo thành sự kết hợp ăn ý, bạn có thể viết code và debug rất dễ dàng, hãy quay lại ví dụ về biểu mẫu mua hàng 5 bước ở trên, nếu bạn không áp dụng Redux, đồng nghĩa bạn phải debug lặp đi lặp lại việc nhập dữ liệu, mà chưa chắc lỗi do code gây ra mà do dữ liệu nhập vào.
• Ứng dụng offline: tất cả các thao tác của người dùng được lưu vào một cây trạng thái, khi có kết nối Internet, cây này sẽ được đồng bộ lên server bởi một loạt các sự kiện.

Sự khác biệt giữa Redux và Flux

Redux phát triển dựa trên Flux, nhưng đã lượt bỏ phần Dispatcher, và chỉ có duy nhất 1 store, …blah …blah, thôi nói nghe này: “Quên Flux đi“.
Nếu bạn chưa bao giờ nghe đến Flux hay Redux, thì đừng mất thời gian để tìm hiểu: Flux là gì, Flux khác Redux như thế nào, điểm yếu của Redux js là gì? Mình cũng đã từng mất thời gian như vậy, nhưng bây giờ mình tin chỉ cần nghiên cứu Redux là đủ. Đây là các lý do để chỉ nghiên cứu “Redux js là gì“:

• Hiện tại Redux đã đạt ~20k stars Github khi chưa đầy 1 năm
• Ứng dụng F8 của Facebook không sử dụng Flux mà sử dụng Redux:
• Dan Abramov, người tạo ra Redux đã gia nhập Facebook từ tháng 11/2015

Kết

Mình hi vọng qua bài “Redux js là gì” này, mình đã truyền tình yêu của mình dành cho Redux đến bạn. Cái hay của Redux là nó không phụ thuộc vào việc bạn sử dụng framework nào, nó là kiến trúc giúp cho ứng dụng phát triển nhanh, đáng tin cậy, và dễ hiểu khi làm việc nhóm. Cách người ta ghi lại nước cờ, làm cho tất cả mọi người đều dễ dàng hiểu và trình bày lại bàn cờ ra sao, thì Redux cũng như vậy!

The post Redux js là gì appeared first on Fullstack Station.

Phần 1: Bài toán

Nếu bạn chưa sử dụng Flux cho dự án của mình, và có một vài vấn đề khó khăn liên quan đến việc giao tiếp giữa các components có quan hệ cha – con: component con muốn cập nhật dữ liệu cho component cha hoặc ông nội, ông cố… hoặc truyền dữ liệu thông qua props từ components ông cố -> ông nội -> cha -> con …thì bạn có thể sử dụng context để khắc phục vấn đề trên.

Context là một khái niệm thuộc phần nâng cao và đang trong quá trình thử nghiệm của React Js. Mặc dù API được khuyến cáo là có thể thay đổi, tuy nhiên với những xử lý Form phức tạp (có nhiều component con lồng nhau) thì mình nhận thấy dùng context khá dễ dàng và tiện lợi hơn so với Flux.

Context: https://facebook.github.io/react/docs/context.html

Ở tài liệu trên của Facebook, đã nói đến khía cạnh truyền dữ liệu từ Cha -> Con không thông qua props, bài viết này, mình giới thiệu với các bạn cách cập nhật dữ liệu cho component ông cố từ component con

Nếu bạn đã có khái niệm hiểu Flux là gì rồi, thì có thể tưởng tượng thay vì Store nằm ở một đối tượng khác – một nơi nào đó thì context tương tự store nằm trong Component ông cố, và khi khởi tạo component con sẽ lấy được dữ liệu từ Component ông cố thông qua Props, và mọi Action từ component con sẽ cập nhật component cố nội.

Giao diện

Xét Form sau: Để đơn giản, mình chỉ vẽ 3 cấp (ông nội – cha – con), còn component level 4, 5 sử dụng modal, xử lý dữ liệu và trả về cho component level 3 không hiển thị ở đây.

Cơ sở dữ liệu

Tương ứng dữ liệu trong MongoDB có thể như sau:

{
  "title": "Good places near your house",
  "description": "Hospital, Supermarket, Kindergarden, Stadium...",
  "places": [
      { 
          "location": {
              "type": "Point",
              "coordinates": [1234, 4567]
           },
           "imageId": "feYddeqw12jx",
           "recommends": [
              "Open 10:00 - 19:00", "Good services"
           ]
      },
      {...},
      ....
   ]
  
}

Sử dụng MongoDB với embedded document thường sẽ làm cho React có cấu trúc component như trên – khá phức tạp đúng không? Nếu bạn sử dụng chung nguyên bộ React – Relay – GraphQL thì vấn đề trên chắc sẽ giải quyết gọn hơn, hoặc Flux/Redux.

Tuy nhiên, mình đã áp dụng Context trong dự án thực tế để giải quyết vấn đề trên, với form khá phức tạp ở các components, nhất là trong component level 2:

• Map (component level 3): sử dụng Component Modal level 4 để chọn location
• Image (component level 3) sử dụng Component Modal level 4 để dùng Google Custom Search chọn hình ảnh
• Recommends (component level 3): mỗi component đều có nút xoá

Tất cả các dữ liệu component đều lưu trong 1 state thuộc component level 1, các component con ứng với mỗi action sẽ cập nhật state này (setState), state thay đổi kích hoạt render lại toàn bộ component con (chỉ những phần thay đổi).

Sơ đồ trao đổi dữ liệu

(Làm biếng vẽ hình quá, xem thô tạm nha)

———–Database (API)

————–↑          ↓

(Autosave)  ↑          ↓   (Reactive)

————–↑          ↓

(State) Component Cha → Props→(Render) Component con →Action

↑                                                                                                                        ↓

↑                                                                                                                        ↓

←———————-Context——————————————–←

Mô hình sử dụng context này, không những giúp cho component con có tính tái sử dụng, mà còn giúp cho ta tạo ra một ánh xạ document của MongoDB, việc Save document này sau đó khá là dễ dàng. Component Root có nhiệm vụ giao tiếp với Database và truyền props xuống các component con, mỗi khi có action từ component, ta cập nhật state cho component ông và có thể kích hoạt autosave lưu vào database. Nếu trong ứng dụng realtime, 2-n người tương tác với nhau thì Database sẽ reactive dữ liệu xuống, trong ứng dụng thực tế, mình sử dụng React – Meteor đã có sẵn tính năng reactive từ database.

Phần 1 đến đây là kết thúc, phần 2 mình sẽ trình bày cách lập trình để sử dụng context xử lý component con cấp n cập nhật dữ liệu cho component root.

The post Sử dụng context để giao tiếp giữa component cha – con trong ReactJs appeared first on Fullstack Station.