Học từ mã nguồn Facebook: cách đọc code minify (mở đầu series)

Facebook là một trong những ứng dụng web lớn nhất thế giới, chạy hàng triệu dòng JavaScript trên đủ loại thiết bị và mạng. Họ không open-source frontend của facebook.com, nhưng bundle JavaScript gửi xuống trình duyệt thì ai cũng tải về đọc được. Repo facebook-codebase chứa hơn 1.600 file như vậy, tải từ bản "Comet" (bản React hiện tại của facebook.com). Để tìm cho đủ, mình đã lập chỉ mục mọi lời gọi __d(...) trong repo: khoảng 25.000 khai báo module trong 1.451 file, tương ứng hơn 17.000 tên module khác nhau (một module thường có mặt ở nhiều bundle).

Series này đi qua những module mình thấy hay nhất và dễ mang sang dự án khác nhất. Mỗi bài có 4 phần:

1. Facebook giải quyết vấn đề gì và giải quyết thế nào, kèm phân tích code gốc.
2. Code viết lại bằng React 19 + TypeScript, gọn và có comment.
3. Demo chạy ngay trong bài: bấm, cuộn, hover thử luôn.
4. Bên trong trình duyệt, các bẫy, edge case và cách kiểm thử khi đưa vào production.

Trước khi vào từng kỹ thuật, ta cần hiểu cách "đọc" đống code này. Phần dưới đây dài, nhưng đọc một lần thì cả 105 bài sau sẽ dễ đọc hơn nhiều.

#Hệ module của facebook.com

Facebook không dùng ES module (import/export) hay webpack runtime ở production. Họ có hệ module riêng, đi kèm một runtime nhỏ được nạp đầu tiên trong trang (trong repo là file 000/entry.js). Mỗi file JS gửi xuống là một chuỗi lời gọi __d(...):

__d("useDelayedState", ["React", "clearTimeout", "emptyFunction", "setTimeout"], (function (a, b, c, d, e, f) {
  "use strict";
  e.exports = a;
  var g = b("React");
  function a(a) { /* ... */ }
}), null);

#__d chỉ đăng ký, chưa chạy

__d(id, deps, factory, flags) viết tắt của define. Đọc runtime trong 000/entry.js, ta thấy nó chỉ lưu một bản ghi gồm id, danh sách dependency và hàm factory vào một map toàn cục. Factory chưa chạy. Factory chỉ chạy ở lần đầu tiên có ai đó require(id). Kết quả được giữ lại trong module.exports, lần require sau trả về luôn.

Hệ quả thực tế: tải về 2MB JS không có nghĩa là phải thực thi 2MB JS lúc khởi động. Phần đắt nhất của JavaScript trên điện thoại yếu thường là parse và execute, không phải tải. Module nào chưa cần thì chỉ tốn chi phí parse cú pháp, chưa tốn chi phí chạy.

Vài chi tiết khác đọc được từ runtime:

• require của module chưa từng chạy sẽ tự bọc trong ErrorGuard.applyWithGuard (xem bài #6). Factory nào throw thì module bị đánh dấu hasError, các lần require sau ném lại lỗi Requiring module "X" which threw an exception. Lỗi không bị nuốt.
• Mỗi module có refcount. Khi mọi nơi cần nó đã require xong, bản ghi trong map bị xoá cho nhẹ bộ nhớ. Ai cần thì đã giữ exports rồi.
• Khi bật cờ profile_require_factories, runtime đo factoryStart/factoryEnd của từng module. Đây là cách họ biết module nào làm chậm lúc khởi động.
• Nếu exports là function chưa có displayName, runtime gắn thêm "(tên hàm) [from ModuleName]". Nhờ vậy React DevTools vẫn hiện tên dễ đọc dù code đã minify.

#6 tham số (a, b, c, d, e, f)

Factory luôn nhận 6 tham số chuẩn theo đúng thứ tự runtime truyền vào:

Nếu factory khai báo nhiều hơn 6 tham số, runtime truyền thêm exports của các dependency theo đúng thứ tự trong mảng deps. Ví dụ module gkx có deps ["invariant", "BanzaiLazyQueue", "emptyFunction"] và factory (a, b, c, d, e, f, g). Lúc đó g chính là invariant, nên trong code bạn sẽ thấy c != null || g(0, 3444, a). Đó là invariant(c != null, ...) với mã lỗi số thay cho message, vì message bị bỏ khỏi bản production để giảm dung lượng.

#Bảng tra nhanh khi đọc

#Gatekeeper: gkx("1475760")

Facebook bật/tắt tính năng theo người dùng bằng gatekeeper (GK). Đọc module gkx, ta thấy:

• Server nhúng sẵn kết quả của các GK mà trang cần vào HTML (file gkxData trong repo), dạng { "1475760": { result: false, hash: "AT7..." } }. Client không tự tính điều kiện, chỉ đọc kết quả.
• Lần đầu một GK được đọc, gkx gửi một event gk2_exposure (qua BanzaiLazyQueue, xem bài #7). Mỗi GK chỉ gửi một lần. Đây là exposure logging cho A/B test: chỉ người dùng thực sự chạm tới đoạn code có GK mới được tính vào thí nghiệm, nên kết quả thí nghiệm không bị loãng.

Bài học mang đi được: feature flag nên log exposure ở thời điểm đọc flag, không phải lúc tải trang.

#requireCond và cr:1234: chọn module lúc build

Bạn sẽ thấy những dependency kỳ lạ như "cr:1142206" và b("cr:1142206"). Đây là kết quả của requireCond: chọn module ở bước build/serve, tuỳ điều kiện (bản dev hay prod, đang trong thí nghiệm nào…). Module requireCond gốc trong runtime chỉ có một dòng throw new Error("Cannot use raw untransformed requireCond."), nghĩa là mọi lời gọi đều phải được compiler biến đổi trước.

Ví dụ trong CometInfiniteScrollSuspenseList, b("cr:1142206") là một công cụ debug cho việc tải thêm ở cuối danh sách. Code luôn viết b("cr:1142206") != null && b("cr:1142206").log(...), nghĩa là điều kiện có thể chọn null cho slot đó. Với người dùng thường, module debug có thể không hề có mặt trong bundle. Với nhân viên nội bộ, slot đó là module thật. Đây là phiên bản "build-time" của if (process.env.NODE_ENV !== 'production') mà ta quen dùng.

#JSResource: code splitting kiểu Facebook

React.lazy(() => import("./X")) là cách ta code-split. Ở Facebook là JSResource("X"):

• JSResource("X") trả về một reference (JSResourceReference), được cache theo tên module. Gọi bao nhiêu lần cũng ra cùng một object.

• .preload() báo Bootloader tải trước, chưa chạy. .load() trả về Promise của module.

• Có hai hàm lấy module đồng bộ, trả về null nếu chưa được:

  • getModuleIfRequireable(): code đã tải về (module đã được __d) thì require luôn và trả về, kể cả khi factory chưa từng chạy.
  • getModuleIfRequired(): chỉ trả về nếu module đã được require ở đâu đó rồi.

  Nhờ hai hàm này, component có thể render đồng bộ khi code đã có sẵn thay vì suspend. BootloaderResource.read dùng getModuleIfRequireable, và ta sẽ gặp lại đúng ý tưởng này trong bài #3.

• Bootloader biết mỗi module nằm trong file JS/CSS nào (qua "resource map" server gửi xuống), gom nhiều module vào ít request, tải CSS đi kèm và theo dõi lỗi tải.

flowchart LR
  A[HTML từ server] --> B[runtime entry.js]
  A --> C[gkxData + resource map]
  B --> D[__d đăng ký factory]
  D --> E{require lần đầu?}
  E -- có --> F[chạy factory, lưu exports]
  E -- không --> G[trả exports đã cache]
  H[JSResource.preload] --> I[Bootloader tải file JS]
  I --> D

#Giải mã một module từ đầu tới cuối

Lấy module nhỏ useDelayedState (thư mục hooks/ của repo) làm ví dụ. Phần lõi trông như sau:

a = g.useCallback(function (a, c, f) {
  c === void 0 && (c = 0), f === void 0 && (f = b("emptyFunction")),
  b("clearTimeout")(e.current), e.current = null,
  c === 0 ? (d(a), f(a)) : e.current = b("setTimeout")(function () {
    d(a), f(a), e.current = null
  }, c)
}, []);
return [c, a]

Bước 1: tìm xem biến nào là gì. Phía trên đoạn này có a = g.useState(a); var c = a[0], d = a[1], e = g.useRef(null);. Vậy c là state, d là setState, e là ref giữ timer. Trong useCallback, tham số a, c, f che các biến bên ngoài: a là giá trị mới, c là độ trễ, f là callback.

Bước 2: tách các biểu thức nối bằng dấu phẩy thành từng câu lệnh, và đổi x === void 0 && (x = ...) thành tham số mặc định.

Bước 3: đổi cond ? (A, B) : C thành if/else.

Bước 4: đặt tên và thêm type:

function useDelayedState<T>(initial: T) {
  const [state, setState] = useState(initial);
  const timerRef = useRef<ReturnType<typeof setTimeout> | null>(null);

  // unmount thì huỷ timer đang chờ
  useEffect(() => () => clearTimeout(timerRef.current ?? undefined), []);

  const setDelayedState = useCallback(
    (value: T, delay = 0, callback: (value: T) => void = () => {}) => {
      clearTimeout(timerRef.current ?? undefined); // lần set mới huỷ lần đang chờ
      timerRef.current = null;
      if (delay === 0) {
        setState(value);
        callback(value);
      } else {
        timerRef.current = setTimeout(() => {
          setState(value);
          callback(value);
          timerRef.current = null;
        }, delay);
      }
    },
    [],
  );

  return [state, setDelayedState] as const;
}

Đọc ra rồi thì thấy đây là một hook rất hữu ích: setOpen(true, 300) để tooltip chỉ hiện khi hover đủ lâu, setOpen(false) để tắt ngay và huỷ luôn lần hiện đang chờ. Đây chính là cơ chế chống "nháy" tooltip khi rê chuột qua nhanh.

Mẹo đọc nhanh cho mọi module:

• Đọc danh sách dependency trước. ["CometMouseActivity", "JSScheduler", "setTimeout"] đã cho biết module này làm gì với chuột, có lập lịch, có hẹn giờ.
• Tìm chuỗi. Tên lỗi, tên event, tên log ("Network switched to offline", "COMPONENT_UNMOUNTED") là manh mối tốt nhất.
• Đọc theo cụm. Một tính năng thường gồm 5–15 module có tên giống nhau (CometToaster*, Error*). Đọc cả cụm dễ hiểu hơn đọc lẻ từng file.
• Kiểm chứng bằng cách viết lại và chạy thử. Đó là cách mình làm cho cả series này.

#105 kỹ thuật trong series

Series chia làm mười lăm phần. Phần 1 (#1–#8) tập trung vào hạ tầng chạy ngầm: observer, logging, lỗi, mạng, focus. Phần 2 (#9–#20) đi sang những thứ người dùng nhìn thấy: mẹo CSS không cần JS, thanh cuộn, modal, popover, tab, khung chat, bố cục ảnh. Cuối phần 2 là các kỹ thuật giữ cho một SPA chạy lâu vẫn nhanh và ổn định. Phần 3 (#21–#37) là đợt đọc lại toàn bộ bundle, từng thư mục và từng file: Smart Compose, MQTT ngay trong trình duyệt, đo thời gian dùng, engine animation, bootloader, xử lý ảnh trong worker, kéo-thả và các module hạ tầng nhỏ. Ba phần tiếp theo đi sâu thêm một lượt nữa: Phần 4 (#38–#42) là Messenger và realtime (đồng bộ tin nhắn theo seqID, ID sinh ở client, đo thời gian gửi tin, bộ điều phối request); Phần 5 (#43–#50) là các module sản phẩm như composer, thanh toán, quảng cáo, Pages; Phần 6 (#51–#57) là hạ tầng sâu: phát hiện script lạ, localStorage đầy quota, cache tuyến, lưới phím 2D, tách emoji, gom đọc/ghi DOM, hàng đợi lệnh video.

Bốn phần sau cùng là lượt đọc thứ ba, dựa trên chỉ mục toàn bộ khai báo module. Phần 7 (#58–#62) là video và upload: ước lượng băng thông, chọn bitrate, prefetch segment DASH, đọc metadata MP4 và upload tiếp tục được. Phần 8 (#63–#70) là thuật toán thuần: Fenwick tree, vạch trục "đẹp", khoảng cách sửa chữ, PRNG có seed, heap đôi, memo nhiều khoá, thống kê cửa sổ trượt, số 64 bit và UTF. Phần 9 (#71–#74) là thời gian, chuỗi và URL: múi giờ IANA ngay trên client, semver, auto-link và parser query kiểu PHP. Phần 10 (#75–#82) là hạ tầng, bảo mật và hình học: popover tự lật, tiền tố chống JSON hijacking, chống lộ referrer, setImmediate tự viết, phát hiện tab crash, cookie DPR và che khoá trong log, Flux waitFor, crop và xoay sticker.

Năm phần cuối là lượt đọc thứ tư, quét tiếp khoảng 1.900 module còn lại. Phần 11 (#83–#86) là kết nối và realtime: các tab chia nhau subdomain bằng lease, MQTT QoS1 gửi lại khi kết nối lại, cache Promise và lịch retry. Phần 12 (#87–#91) mở bên trong Relay: giữ tham chiếu nhánh không đổi, store optimistic, chỉ mục subscription, phân trang connection và profiler kiểu middleware. Phần 13 (#92–#95) là trình phát video: đọc EBML/WebM, stream Range tạm dừng được, bảng khoảng thời gian gắn nhãn, SourceBuffer và đồng bộ video với animation. Phần 14 (#96–#100) là Messenger và văn bản: gom tin nhắn thành cụm, chính sách mở tab chat, phím tắt Markdown, offset code point và typeahead không nhảy. Phần 15 (#101–#105) là canvas, bản đồ, dò tính năng trình duyệt và các bug kinh điển về locale và dispose.

Tất cả demo được gom trong một project Vite nhỏ: examples/facebook-patterns. Bạn có thể clone về chạy npm install && npm run dev, hoặc mở trên StackBlitz để sửa code ngay trên trình duyệt.

▶ Mở demo toàn màn hình ↗ · Sửa code trên StackBlitz ↗

#Điểm chung của các kỹ thuật

Đọc xong cả series, bạn sẽ thấy vài nguyên tắc Facebook lặp đi lặp lại:

• Tách state khỏi React. Toast, network status, logger đều là object/class thuần với subscribe + getSnapshot. React chỉ là một "view" cắm vào qua useSyncExternalStore. Nhờ vậy code nào cũng gọi được (toast.push() trong một hàm fetch chẳng hạn) và test được mà không cần render.
• Dùng chung tài nguyên đắt. Một IntersectionObserver cho hàng trăm element, một listener keydown cho mọi layer, một hàng đợi cho mọi log, một bản ghi module cho mọi lần require.
• Làm muộn nhất có thể. Factory chỉ chạy khi cần, observer chỉ được tạo khi có người observe, listener chỉ gắn khi có người subscribe.
• Không tin trình duyệt 100%. navigator.onLine có thể sai. isIntersecting chưa có nghĩa là người dùng đang xem. unload thường không chạy trên mobile.
• Đo trước, tối ưu sau. Rất nhiều module chỉ để log: thời gian chạy factory, exposure của gatekeeper, thời gian hiển thị, guard stack lúc lỗi.
• Tận dụng thời gian chờ của người dùng. Từ lúc đưa chuột lên nút tới lúc click thường mất vài trăm mili-giây. Đó là khoảng thời gian miễn phí để tải trước.

Bắt đầu với bài đầu tiên: Shared IntersectionObserver.

Bài này thuộc series Học từ mã nguồn Facebook (106 bài, đọc theo thứ tự).

Code + demo: examples/facebook-patterns · Mở trên StackBlitz