React Native và Expo: chọn đường nào cho dự án

Trả lời nhanh: Cách hiểu gọn nhất: Expo là bộ khung dựng sẵn quanh React Native, lo hộ bạn phần cấu hình dự án, chuỗi công cụ build và rất nhiều thư viện gốc thông dụng. Bản tự dựng thì bạn cầm trực tiếp hai thư mục dự án iOS và Android. Lựa chọn thực tế hôm nay không còn là chọn phe: bắt đầu bằng Expo gần như luôn đúng, vì bạn vẫn chèn được mã gốc khi cần. Chỉ khi dự án phụ thuộc nặng vào thư viện gốc đặc thù thì mới cân nhắc rời đi.

Người mới vào React Native luôn gặp ngã ba này ở ngày đầu tiên, và chọn sai thì phải làm lại kha khá. Tin tốt là ranh giới giữa hai hướng đã mờ đi nhiều so với vài năm trước, nên câu trả lời giờ đơn giản hơn ngày xưa. Bài này nói rõ từng hướng lo hộ bạn cái gì và đổi lại lấy đi cái gì.

Expo thực chất lo hộ những gì

Ba nhóm việc, và đây là lý do người ta dùng:

• Cấu hình dự án. Bạn khai báo tên ứng dụng, biểu tượng, quyền truy cập trong một file cấu hình duy nhất, thay vì sửa file dự án của cả iOS lẫn Android.
• Thư viện gốc thông dụng. Camera, thông báo đẩy, vị trí, lưu trữ an toàn đều có sẵn gói chính thức đã kiểm chứng, khỏi phải tự ghép.
• Chuỗi build và cập nhật. Có dịch vụ dựng bản cài trên máy chủ của họ, và cơ chế đẩy bản cập nhật phần JavaScript không cần qua cửa hàng.

Điểm cuối đáng giá hơn người ta tưởng: sửa một lỗi hiển thị rồi đẩy cho người dùng trong vài phút, thay vì chờ cửa hàng duyệt vài ngày. Lưu ý là chỉ áp dụng cho phần JavaScript, còn thay đổi chạm tới mã gốc thì vẫn phải phát hành bản mới.

Cái giá phải trả

Kích thước ứng dụng lớn hơn so với bản tối giản tự dựng, vì bộ khung mang theo nhiều thứ. Với phần lớn ứng dụng thì chênh lệch này không đáng kể, nhưng nếu bạn nhắm thị trường máy đời cũ và mạng chậm thì nên cân.

Phụ thuộc vào một bên nữa. Bạn nhận thêm một lịch phát hành phải theo, và khi có thay đổi lớn thì phải nâng cấp theo họ.

Thư viện gốc ngoài luồng cần thêm bước. Vẫn dùng được, nhưng phải qua cơ chế cắm thêm và phải dựng bản build riêng chứ không chạy được trong ứng dụng thử nghiệm sẵn có.

Điểm cuối này chính là nơi nhiều đội hiểu nhầm rằng Expo không cho dùng mã gốc. Thực tế là cho, chỉ khác quy trình.

Khi nào nên tự dựng ngay từ đầu

Bốn tình huống rõ ràng:

• Dự án phụ thuộc vào một thư viện gốc đặc thù chưa có gói tương thích, ví dụ thiết bị đọc thẻ chuyên dụng hoặc phần cứng riêng của ngành.
• Ứng dụng ghép vào hệ thống gốc sẵn có, tức bạn thêm màn hình React Native vào một ứng dụng iOS hoặc Android đã tồn tại.
• Yêu cầu kiểm soát chặt về kích thước và quyền, thường gặp ở ngành tài chính và y tế.
• Đội đã có sẵn hạ tầng build riêng và không muốn thêm một lớp trung gian nữa.

Ngoài bốn trường hợp đó, bắt đầu bằng Expo tiết kiệm cho bạn vài ngày cấu hình ở tuần đầu, thời gian mà dự án nào cũng thiếu.

Chi phí build, chỗ nhiều người tính sai

Expo có dịch vụ dựng bản cài trên máy chủ của họ, tính theo lượt build. Tiện lúc bắt đầu vì không phải dựng gì cả. Nhưng khi đội bạn build vài lượt mỗi ngày thì con số này lớn dần, và đó là lúc đáng so với việc tự dựng máy build.

Phép tính đơn giản: đếm số lượt build một tháng, nhân với đơn giá mỗi lượt, so với giá thuê một máy chủ Linux dựng nhánh Android cộng một máy Mac cho nhánh iOS. Với đội build hằng ngày, tự dựng thường rẻ hơn rõ, và bạn còn không phải xếp hàng chờ tới lượt.

Cách dựng máy Linux nằm ở bài máy build Android, còn ranh giới bắt buộc phải có máy Mac thì ở bài build iOS có cần Mac. Một điểm hay bị quên: bạn dùng được cả hai, xây dịch vụ sẵn có cho lúc gấp và máy riêng cho việc hằng ngày.

Đường chuyển đổi giữa hai hướng

Đây là phần khiến quyết định ban đầu bớt nặng nề. Từ Expo, bạn chạy được lệnh sinh ra hai thư mục dự án gốc và từ đó cầm trực tiếp như bản tự dựng. Việc này một chiều theo nghĩa quay lại sẽ mất công, nhưng nó có nghĩa là bạn không bị nhốt.

Kinh nghiệm thực dụng: bắt đầu bằng Expo, giữ càng lâu càng tốt, và chỉ rời đi khi có nhu cầu cụ thể chứ không phải vì lo xa. Rất nhiều đội rời đi từ tuần đầu vì sợ bị giới hạn, rồi nhận ra mình chỉ chuốc thêm việc cấu hình mà chẳng dùng tới quyền tự do vừa giành được.

Khi so sánh rộng hơn giữa React Native và lựa chọn khác, bài Flutter hay React Native đi vào phần chọn nền tảng, còn bài này chỉ bàn trong phạm vi React Native.

Chi phí dựng, chỗ nhiều người tính sai

Cách đếm đúng: ghi lại số lần dựng thật trong một tháng, không ước theo cảm giác. Nhiều đội tưởng dựng vài lần mỗi tuần, đếm ra mới thấy vài chục lần vì mỗi lần sửa nhỏ đều dựng lại để thử.

Ba cách giảm số lượt dựng

• Thử trên trình giả lập trước, chỉ dựng bản thật khi cần kiểm trên thiết bị thật.
• Gom nhiều thay đổi rồi mới dựng một lần, thay vì dựng sau mỗi lần sửa.
• Chỉ dựng bản phát hành khi thật sự phát hành, còn lại dựng bản gỡ lỗi nhẹ hơn.

Mô hình kết hợp cho đội nhỏ

• Bản Android dựng trên máy chủ Linux của bạn. Chi phí phẳng, và bạn kiểm soát được. Xem bài về dựng ứng dụng Android.
• Bản iOS dùng dịch vụ dựng có sẵn nếu số lượt ít, vì mua máy Mac chỉ để dựng vài lần mỗi tháng là không đáng.
• Khi số lượt dựng iOS tăng lên, lúc đó mới tính tới máy Mac riêng.

Chuyển một chiều, và cái giá của việc quay lại

# Chuyen tu ban co san sang tu quan ly la mot chieu,# quay lai duoc nhung mat cong. # Truoc khi chuyen, kiem ba thu:# 1. Cac thu vien dang dung co ban tu quan ly khong# 2. Doi co ai lam duoc phan cau hinh nen tang khong# 3. Da co may dung cho ca hai nen tang chua # Sau khi chuyen: kiem ky luong dang nhap, thong bao day,# va cac tinh nang cham vao phan cung thiet bi.# Day la ba cho hay hong nhat.

Lời khuyên thực dụng: bắt đầu bằng cách có sẵn để ra sản phẩm nhanh, chuyển sang tự quản lý khi chạm giới hạn thật. Đừng tự quản lý ngay từ đầu vì lo sẽ chạm giới hạn, vì phần lớn dự án không bao giờ chạm tới.