8 quyết định quan trọng về React Component

Quyết định 1: Môi trường phát triển

Trước khi viết component đầu tiên, team cần phải thống nhất về môi trường phát triển. Có rất nhiều lựa chọn để tham khảo…

https://twitter.com/housecor/status/913382440911212545

Tất nhiên bạn có thể xây dựng môi trường lập trình JS lại từ đầu. 25% các dev React chỉ làm có thế. Team hiện tại của tôi sử dụng create-react-app với các tính năng bổ sung như mock API thực tế hỗ trợ CRUD, 1 thư viện component reusable, và các cải tiến linting (chúng tôi cũng lint các file test – những files mà create-react-app bỏ qua). Tôi rất thích create-react-app, nhưng có 1 công cụ sẽ giúp bạn so sánh giữa nhiều lựa chọn hấp dẫn. Muốn render trên server? Hãy thử Gatsby hoặc Next.js. Bạn có thể cân nhắc sử dụng công cụ editor online như CodeSandbox.

Quyết định 2: Types

Bạn có thể bỏ qua types, sử dụng prop-types, sử dụng Flow, hoặc sử dụng TypeScript. Lưu ý rằng prop-types được trích xuất trong thư viện độc lập trong React 15.5, vì vậy các posts cũ hơn sẽ hiển thị những imports không còn hoạt động nữa.

Cộng đồng vẫn đang tranh cãi về topic này:

https://twitter.com/housecor/status/911673327240073216?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F071321ad7e2f3d3cfd84ca705d9f3633%3FpostId%3Dcc965db11594

Tôi thì vẫn thích prop-types hơn vì nó cung cấp đủ type safety trong React components với rất ích sai lệch. Khi sử dụng kết hợp Babel, Jest tests, ESLint, và prop-types, tôi hiếm khi nhận ra các vấn đề về runtime type.

Quyết định 3: createClass và ES Class

React.createClass là API gốc, nhưng trong 15.5, React.createClass lại không được duyệt. Một số người cho rằng chúng ta đã chuyển sang ES Classes quá sớm. Tuy nhiên, createClass style đã được chuyển ra khỏi React core & đẩy đến 1 single page là “React không có ES6” trong docs React. Như vậy, 1 thực tế rõ ràng là ES classes chính là tương lai mà chúng ta cần phải cân nhắc. Bạn có thể dễ dàng convert từ createClass sang ES Classes bằng react-codemod.

Quyết định 4: Class vs Functional

Bạn có thể declare các React components bằng class hoặc function. Các classes rất có ích khi bạn cần đến refs, và lifecycle methods. Có 9 lý do cần cân nhắc khi sử dụng functions. Nhưng cần lưu ý rằng các functional components có 1 vài điểm bất lợi mà bạn có thể tham khảo tại đây.

Quyết định 5: State

Bạn có thể sử dụng plain React component state. Lifting state scale rất tốt. Hoặc, bạn có thể sử dụng Redux hoặc MobX:

No flame wars please – honestly curious where the React community is these days.

For new Pr/React projects, I use ___ for state management.

— Adam Rackis (@AdamRackis) March 25, 2017

Tôi là fan của Redux, nhưng thường sử dụng plain React vì nó đơn giản hơn. Với công việc hiện tại, chúng tôi đã cho ra đời cả tá React apps và nhận ra Redux đều phù hợp với cả hai. Tôi thích cho ra đời nhiều ứng dụng nhỏ, độc lập hơn là 1 ứng dụng lớn duy nhất.

Nếu bạn quan tâm đến immutable state, vẫn có ít nhất 4 cách để state của bạn immutable.

Quyết định 6: Binding

Ít nhất cũng có 6 cách giúp bạn xử lý binding trong React components. Đứng về phía React, quyết định này hầu hết là vì JS hiện đại cung cấp nhiều cách để xử lý binding. Bạn có thể bind trong constructor, bind trong render, sử dụng function mũi tên trong render, sử dụng 1 class property, hoặc sử dụng decorators. Đọc thêm comments trong post này để có thêm nhiều lựa chọn nhé! Mỗi cách tiếp cận đều có ưu điểm riêng nhưng nếu bạn đang thích các tính năng thử nghiệm thì tôi khuyến khích sử dụng class properties mặc định (hay còn gọi là property initializers).

Bảng bầu chọn từ tháng 8/2016. Kể từ đó, các class properties đang ngày càng được ưa chuộng hơn & createClass lại ít được sử dụng.

How do you handle binding in #reactjs today?

Examples: https://t.co/z7OKxe39VA

— Cory House (@housecor) August 18, 2016

Lưu ý: Rất nhiều người còn thắc mắc tại sao các arrow functions và bind trong render đều tiềm tàng nguy cơ gây ra vấn đề. Lý do thực sự? Nó khiến shouldComponentUpdate & PureComponent rất khó sử dụng.

Quyết định 7: Styling

Đây là nơi khiến cho các quyết định lựa chọn trở nên cực kì khó khăn. Có hơn 50 cách để style components gồm inline styles của React, CSS truyền thống, Sass/Less, CSS Modules, & các phương án 56 CSS-in-JS. Tôi đã khám phá được chi tiết các bước tiếp cận trong module styling của khóa học này, tóm tắt như sau:

Tại sao có quá nhiều phân mảnh trong các phương án styling của React

Team hiện tại của tôi hài lòng khi sử dụng Sass với BEM nhưng tôi cũng rất thích các styled-components.

Quyết định 8: Reusable Logic

Ban đầu React sử dụng mixins như 1 cơ chế để chia sẻ code giữa các components. Nhưng mixins đã gây ra vài vấn đề. Bạn không thể sử dụng mixins với ES class components, vì vậy nên gần đây cộng đồng tận dụng components higher-order & render props để chia sẻ code giữa các components.

[POLL for devs writing #ReactJS]: Which do you prefer?
HOC: https://t.co/aczxcPUd8j
Render Props: https://t.co/2haYUuGK7z

— Kent C. Dodds (@kentcdodds) September 5, 2017

Higher-order components đang trở nên thông dụng hơn nhưng tôi vẫn thích render props hơn vì dễ đọc, dễ tạo. Xem thêm bài trình bày của Michael Jackson

Và đó không phải là tất cả…

Vẫn còn nhiều quyết định cần xem xét khác

• Bạn sẽ dùng .js hay .jsx extension?
• Bạn sẽ đặt mỗi component vào folder của nó?
• Bạn sẽ enforce 1 component mỗi file? Liệu bạn có đặt 1 file index.js vào mỗi directory?
• Nếu sử dụng propTypes, liệu bạn có declare chúng ở cuối hay trong class bằng static properties? Liệu bạn sẽ declare propTypes sâu nhất có thể?
• Bạn sẽ khởi tạo state 1 cách truyền thống trong constructor hay tận dụng property initializer syntax?

Và vì React hầu hết chỉ là JavaScript, nên bạn sẽ có danh sách dài các quyết định cần căn nhắc liên quan đến style phát triển JS như semicolons, trailing commas, formatting, và event handler naming

Chọn Standard, sau đó automate quá trình enforcement

Những bước tiếp theo sẽ rất quan trọng:

1. Thảo luận những quyết định này với team và ghi lại standard của bạn

2. Đừng lãng phí thời gian tranh luận về tính mâu thuẫn trong code reviews. Thực thi các standards của bạn bằng những công cụ như ESLint, eslint-plugin-react, và prettier.

3. Có cần phải restructure các React components hiện tại không? Hãy sử dụng react-codemod để automate toàn bộ quá trình này.