Tài liệu đọc thêm cho khóa Vibe Code – Lập trình di động với React Native & Expo tại Softech Aptech Đà Nẵng. Thứ tự “phổ biến → hiếm” dựa trên tần suất xuất hiện trong các app di động thông thường, không phải một chuẩn tuyệt đối. Mỗi component đều có ví dụ gắn với app xuyên suốt TaskFlow.

​
Vì sao cần biết tên các component?

Khi vibe code, gọi đúng tên component là một nửa của prompt tốt. So sánh hai cách viết sau:

Prompt mơ hồ

“Làm cái ô bật lên từ dưới để chọn người nhận”

Prompt rõ ràng

“Dùng bottom sheet để chọn người nhận, bên trong là list có search bar và avatar”
Prompt thứ hai giúp AI chọn đúng thư viện, đúng hành vi — và bạn cũng dễ kiểm tra code hơn.

​
Nhóm 1 — Gần như app nào cũng có

Đây là những “viên gạch” cơ bản. Hầu hết đều có sẵn trong React Native core hoặc hệ sinh thái Expo.
  • Vùng chạm của button tối thiểu khoảng 44×44 điểm (theo khuyến nghị của Apple) để dễ bấm.
  • Tab bar chỉ nên có 3–5 mục. Nhiều hơn thì cân nhắc gộp lại.
  • Dùng FlatList thay cho ScrollView + map() khi danh sách dài, vì FlatList chỉ render phần đang hiển thị.

​
Nhóm 2 — Rất phổ biến

Xuất hiện ở đa số app có tương tác, giúp app “trông chuyên nghiệp” hơn hẳn.
  • Màu không phải là kênh thông tin duy nhất. Badge trạng thái nên có cả chữ, không chỉ màu (người mù màu vẫn đọc được).
  • Empty state là cơ hội hướng dẫn, đừng để màn hình trắng trơn.
  • Toast dành cho thông tin không quan trọng. Lỗi nghiêm trọng hoặc cần xác nhận thì dùng Dialog.

​
Nhóm 3 — Dùng thường xuyên nhưng theo ngữ cảnh

Chỉ xuất hiện khi app có nhu cầu cụ thể: form phức tạp, dữ liệu nhiều, thao tác nhanh.
  • Thao tác vuốt là ẩn, người dùng không tự biết. Luôn có cách thứ hai (nút, menu) cho cùng hành động.
  • Date picker trông khác nhau giữa iOS và Android. Phải test trên cả hai nền tảng.
  • Form trên 5–6 trường nên cân nhắc chia bước hoặc nhóm lại.

​
Nhóm 4 — Hiếm dùng hoặc chuyên biệt

Chỉ cần khi app có tính năng đặc thù. Thường phải cài thư viện riêng, có khi cần development build thay vì Expo Go.
Component hiếm thì người dùng cũng ít quen. Chỉ dùng khi thật sự giải quyết vấn đề, đừng dùng vì “trông ngầu”. Mỗi thư viện thêm vào là thêm rủi ro về tương thích phiên bản Expo SDK — trước khi cài, kiểm tra trang Expo SDK compatibility hoặc hỏi AI: “Thư viện này có chạy được trên Expo Go không, hay cần development build?”

​
Cách dùng kiến thức này khi prompt AI

1

Gọi tên component và nêu hành vi

“Tạo component TaskCard dạng card, có badge trạng thái góc phải, progress bar ở dưới, avatar người nhận bên trái.”
2

Chỉ định thư viện khi cần

“Dùng @react-native-community/datetimepicker để chọn deadline. Không dùng thư viện date picker khác.”
3

Yêu cầu xử lý đủ các trạng thái

“Danh sách task phải có loading indicator khi đang tải, empty state khi trống, và pull to refresh.”
4

Hỏi AI về lựa chọn thay thế

“Để chọn người nhận task, nên dùng picker, bottom sheet hay màn hình riêng? So sánh ưu nhược điểm cho trường hợp nhóm có 5–20 thành viên.”

​
Bảng tổng hợp theo buổi học

Ghi chú cho giảng viên: tên và API các thư viện ngoài core (bottom sheet, toast, chart, swipeable) thay đổi khá nhanh. Kiểm tra lại tài liệu chính thức và độ tương thích với Expo SDK đang dùng trước khi đưa vào tài liệu chính thức.

​
Tài liệu tham khảo

React Native Core Components

Expo SDK Reference

Expo Router