Tôi có một buổi trao đổi với nhóm developer tại Seattle để giúp họ chuyển qua dùng React nhanh hơn. Khi tôi đang chia sẻ vài lí do vì sao functional components khá tuyệt vời thì có một vài thành viên cho rằng việc dùng tới chúng nên bị cấm.
Woa! Thật ư? Và chúng tôi đã tranh luận khá sôi nổi. Và sau đây là những lí do cho phát biểu trên:
Chuyển đổi khá là khó khăn và tốn công
Functional component không hỗ trợ state, refs, hay các phương pháp lifecycle. Chúng cũng không thể mở rộng PureComponent. Đôi khi, bạn tạo ra functional component và chợt nhận thấy mình chỉ cần một tính năng duy nhất từ những class đó. Trong những trường hợp như vậy nó cực kì phiền phức khi ta phải thủ công chuyển đổi function thành một class.
Diffs rất lộn xộn
Sau khi đã converse, diff sẽ là kẻ phiền phức tiếp theo. Dù chỉ là thay đổi một dòng thôi cũng dẫn đến hàng loạt dòng code review.
Sau đây là một ví dụ khi ta convert một functional component thành một class để nó có thể được declare là PureComponent.
Nếu component này được declared là một class ngay từ đầu, nó sẽ cần thay đổi như sau:
Conversion còn che dấu lịch sử của component khi tạo ra hiểu nhầm rằng component đã được rewritten trong khi thật ra những thay đổi đó rất nhỏ nhặt. Người viết sẽ bị “đổ tội” bởi đã làm thay đổi quá nhiều nhưng những thay đổi đó lại có tác động rất nhỏ nhặt.
Sự khác biệt không đáng kể
Khi so sánh một class nhỏ với một function, sự khác biệt là rất nhỏ. Luôn nhớ rằng, constructor vốn là optional khi thiếu state.
À mà quên mất là functional style vẫn có thể chỉ dài một dòng với một arrow function đơn giản sau:
const Hello = ({greeting, firstName}) => <div>{greeting} {firstName}</div>
Không nhất quán
Function và class component nhìn khác nhau. Sự không nhất quán này có thể khiến developer bị chậm tiến độ khi phải chuyển qua lại giữa 2 style.
- Trong classes, bạn dùng this.props, trong functions thì là props.
- Trong classes, bạn declare một render function. Trong functions thì không có.
- Trong classes, bạn phá hủy cấu trúc từ trên top của render. Trong function, thì bạn làm điều đó với function’s argument list.
- Trong classes, bạn declare default props dưới component. Trong function, bạn declare default props sử dụng default arguments.
Chính những sự khác biệt nhỏ này sẽ khiến các developer non trẻ bị nhầm lẫn cũng như các developer lão làng mắc lỗi.
OO Developers quen thuộc với Classes
JavaScript’s classes rất khác so với Java và C# classes. Nếu những ai làm việc với OO trong server sẽ hiểu ngay về điều luật sau đây:
“ Một React component là class với khả năng mở rộng React.Component.”
Hơn nữa, là khi sử dụng những functions này sẽ dễ gây nhầm lẫn, OO devs vốn đã quen với việc dùng class cho mọi thứ. Tôi không nghĩ là cách nghĩ này thật sự tốt bởi cộng đồng React thích functional hơn. Và như thế functional component tạo ra mâu thuẫn trong cách làm cho các OO devs.
Vẫn chưa có lợi ích về hiệu năng
Mặc dù React team đã nói rằng functional components sẽ nhanh và hiễu quả hơn trong tương lai, nhưng hiện tại thì nó vẫn chưa thật sự có khác biệt mấy. Vì thế mà ta có thể nói rằng functional component vẫn chưa thật sự đủ chín mùi.
Và vì functional components yêu cầu chuyển đổi thành một class để implement các thay đổi tinh chỉnh như shouldComponentUpdate và PureComponent, chúng thật ra khá là phiền phức để tinh chỉnh để đạt được hiệu năng như mong muốn.
Lại phải đưa ra một quyết định nữa
Cuối cùng, JavaScript developers đã phải bận ngập đầu trong một núi các quyết định cần phải đưa ra. Cấm functional components sẽ giúp bớt đi một bởi nó sẽ luôn tạo ra class.
Nguồn: topdev via Medium
Tham khảo thêm các vị trí tuyển dụng React lương cao hấp dẫn
