Thảo luận

đã bình luận cho bài viết

Làm việc với static assets trong kiến trúc Microfrontend của

khoảng 2 giờ trước

Tiện về các static assets, em xin bổ sung thêm về FONT và DESIGN TOKENS (em research từ AI, có gì anh @maitrungduc1410 review em vs nhá). Em chưa rõ ví dụ muốn dùng chung common component (ví dụ BUTTON) thì làm thế nào ? Và nếu là common component dễ như INPUT hay BUTTON thì dễ làm common, vậy đối với Table thì nên xử lý thế nào để đồng bộ UI và action logic a nhỉ ?

Trong trường hợp ví dụ có 1 host/shell app dùng Angular và remote-app/ React:

Về FONT:

Trong PROD: Font CẦN được load bởi Angular host => Load remoteEntry.js (React remote-app => React mount vào DOM => React dùng font-family: 'xxx' (React chỉ cần dùng, không duplicate request).
Trong DEV LOCAL: React phải tự load font khi chạy standalone (Import trong file index.html => Vite dev server => có FONT để dev) => Mặc dù import ở cả 2 apps, tuy nhiên khi build để integrate vào host thì file index.html của REACT không được sử dụng nữa, nên React module sẽ tự động dùng font từ Angular host.

Về DESIGN TOKENS (vì Angular và React có runtime khác nhau nên việc sharecomponent trực tiếp giữa hai framework là không phù hợp, ví dụ dùng chung common component BUTTON):

Trong PROD: định nghĩa một bộ CSS Variables chứa toàn bộ mã màu, typography và spacing chuẩn và import trên Angular host. Ví dụ define :root => Các CSS variable này trở thành global variables của toàn bộ document. => React nhận luôn được CSS global (do React app không tạo document mới, nó chỉ render vào một div trong DOM của Angular).
Trong DEV LOCAL: Tạo fallback tokens cho dev để check nếu là env.DEV thì import folder styles từ Angular host.

HTA

đã bình luận cho bài viết

Giao tiếp giữa các thành phần trong kiến trúc Microfrontend của

Mai Trung Đức

khoảng 6 giờ trước

@maitrungduc1410 Tiện thể, anh có thể cho em 1 ví dụ or 1 vấn đề ở dự án thực tế về lý do: "TẠI SAO CẦN APPLY KIẾN TRÚC MFE" không ạ anh ?

Sau khi đọc full series, theo em hiểu anh đang giải thích lý do dùng MFE ở bài đầu tiên chủ yếu là từ phần NGỌN: "Ta cần build một app (ta gọi là App shell), ở đó ta có nhiều app con, mỗi app con này được gọi là 1 widget, mỗi widget này có thể là 1 component nhỏ, trên màn hình, nhưng cũng có thể là nguyên 1 app đầy đủ với cả routing các thứ của riêng nó."

Em muốn hiểu thêm về phần GỐC để có thể cải thiện về tư duy KHI NÀO NÊN NGHĨ TỚI DÙNG MFE (vì có thể không cần dùng MFE mà vẫn có thể chia module theo web repo riêng hoặc sử dụng Nx monorepo gì đó, authen thì có thể share qua Cookie nếu trùng sub-domain, routing có thể direct web, share data thì có thể lấy từ APIs, deploy thì vẫn có nhiều cơ chế deploy độc lập khác).

Sau khi research AI, theo em hiểu lý do gốc về việc nên apply MFE là như sau (trong trường hợp đã 1 có DỰ ÁN GỐC - ví dụ Portal, giờ cần trả lời câu hỏi tại sao nên dùng MFE cho các modules tiếp theo):

Tách các module thành các product độc lập để có thể triển khai linh hoạt cho từng khách hàng.. (ví dụ công ty muốn bán riêng module này hoặc sau này cần tách Portal ra thành các module nhỏ và bán theo gói module tới từng doanh nghiệp). ==> Em nghĩ đây là LÝ DO QUAN TRỌNG NHẤT
Liên quan tới Teams và con người (Team mạnh về tech-stack React/Vue/Angular) ==> vẫn có thể có cách khắc phục

THẢO LUẬN