DEV Community: Trường Trịnh Đức

Tích hợp Hot Update vào dự án để tối ưu thời gian cho internal testing

Trường Trịnh Đức — Fri, 20 Mar 2026 09:01:49 +0000

Giới thiệu

const x = "dừng tay, chuyển nhánh, pull code, build app"

Nếu anh em đã từng làm React Native một thời gian, chắc chắn không ít lần nghe câu quen thuộc từ QA: "Em ơi build lại cho chị cái task này với." Rồi phải x đợi 20–30 phút, gửi file, rồi lại ngồi chờ phản hồi. Cứ lặp đi lặp lại như vậy mỗi ngày.

Vấn đề x có thể giải quyết bằng việc tích hợp CI/CD để tự động hóa quá trình này. Nhưng vẫn không tránh khỏi việc mất thời gian, QA vẫn phải đợi pipeline build xong mới có app để test. Chưa kể có các task cần khách UAT trên TestFlight thì vẫn không tránh khỏi việc dev cần tự mình build lại app để đẩy lên cho khách UAT.

Đây không phải vấn đề của một người — đây là vấn đề của cả team. Và nó hoàn toàn có thể giải quyết được.

Tài liệu này mô tả hệ thống Dynamic Hot Update Channel — một giải pháp OTA (Over-The-Air) update được thiết lập trong project, cho phép dev deploy thay đổi JavaScript trực tiếp lên thiết bị của QA trong vài giây, không cần build lại native app, không cần qua TestFlight, không cần chờ đợi.

1. Vấn Đề Cần Giải Quyết

Trước khi đi vào giải pháp, hãy nhìn thẳng vào những điểm bất cập hiện tại:

🐢 QA Cycle quá chậm

Mỗi lần có thay đổi JavaScript — dù chỉ là sửa một dòng text hay điều chỉnh màu button — team vẫn phải trải qua toàn bộ quy trình: CI/CD build ra file .ipa hoặc .apk, đợi 15–20 phút, rồi QA mới có app để test -> Lãng phí thời gian không cần thiết.

🐢 🐢 Khách UAT các task riêng lẻ

Flow CI/CD hiện tại chỉ support internal test cho case app IOS. Nên việc khách UAT task thì vẫn cần dev phải tự build app rồi đẩy lên TestFlight để khách có thể test. Case này là gây mất thời gian nhất vì dev phải thực hiện đúng một vòng x để có app cho khách UAT.

2. Giải Pháp: OTA Update + Switch Channel

OTA Update là gì?

Hãy tưởng tượng một ứng dụng React Native như một rạp chiếu phim. Phần native (iOS/Android shell) chính là toàn bộ cơ sở hạ tầng của rạp — tòa nhà, màn hình, hệ thống âm thanh, ghế ngồi. Phần JavaScript bundle chính là bộ phim đang chiếu - nội dung thực sự mà khán giả đến để xem.

Khi muốn chiếu phim mới, bạn không cần phá rạp đi xây lại. Bạn chỉ cần thay cuộn phim. Đó chính xác là cách OTA update hoạt động: thay vì build lại toàn bộ app, chúng ta chỉ đẩy một JavaScript bundle mới lên server. App tự kiểm tra, tải về và chạy — người dùng thấy version mới mà không cần làm gì cả.

Nhưng nếu muốn nâng cấp hệ thống âm thanh Dolby hay lắp thêm máy chiếu 4K — lúc đó mới cần đụng đến phần xây dựng vật lý. Tương tự, khi app cần thêm native module, thay đổi cấu hình iOS/Android, hay cập nhật dependency có native code — bạn vẫn phải build lại native app như bình thường.

Giới hạn quan trọng: OTA update chỉ áp dụng được cho thay đổi ở tầng JavaScript và Assets (hình ảnh, font). Nếu thêm native module mới, thay đổi cấu hình iOS/Android, hay cập nhật dependency có native code — vẫn phải build lại native app như bình thường.

Switch Channel là gì?

Thay vì có một staging environment duy nhất cho tất cả, mình sẽ tạo ra các channel riêng biệt — mỗi channel là một "làn đường" độc lập chứa JavaScript bundle của một task cụ thể.

Ví dụ thực tế:

Channel stg → chứa code của nhánh develop- nhánh ổn định nhất và sẽ là nhánh được chọn để build Native App.
Channel V567APP-199 → chứa code JS của task V567APP-199 rẽ từ develop, QA muốn test task này thì chỉ cần switch sang "làn đường" - Channel V567APP-199 là có code mới nhất của task để test.

QA có thể switch qua lại giữa các channel ngay trên một app đã cài sẵn, không cần cài lại, không cần bản build mới.

3. Kiến Trúc & Infrastructure

Hệ thống được xây dựng trên hot-updater với Cloudflare làm backend, được chọn vì chi phí thấp, tốc độ cao phù hợp với mục đích phục vụ cho internal test hiện tại.

┌─────────────────────────────────────────────────────────┐
│                    Cloudflare Infrastructure            │
│                                                         │
│  ┌──────────────────┐      ┌──────────────────────────┐ │
│  │  Cloudflare R2   │      │     Cloudflare D1        │ │
│  │  (Object Storage)│      │     (SQLite Database)    │ │
│  │                  │      │                          │ │
│  │  • bundle.js     │      │  channel | version | ... │ │
│  │  • assets/       │      │  stg     | 4.0.0   | ... │ │
│  │  • fonts/        │      │  V567-99 | 4.0.0   | ... │ │
│  └──────────────────┘      └──────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
         ▲                              ▲
         │ deploy                       │ query metadata
         │                              │
┌────────┴──────────┐        ┌──────────┴──────────────┐
│   Developer CLI   │        │    React Native App     │
│  yarn hot:task:   │        │  (on QA's device)       │
│  ios V567APP-199  │        │  → checks channel,      │
└───────────────────┘        │  → downloads bundle     │
                             │  → reloads JS engine    │
                             └─────────────────────────┘

Các thành phần chính:

Thành phần	Vai trò
Cloudflare R2	Lưu trữ JavaScript bundle và static assets
Cloudflare D1	Database theo dõi metadata: channel nào đang chạy bundle nào, version nào
`hot-updater` CLI	Tool deploy bundle từ máy developer lên Cloudflare
`DevChannelSwitcher`	UI trong app để QA switch channel

Các channel được định nghĩa:

stg — Channel mặc định, luôn phản ánh code của nhánh staging chính (develop). Logic hiện tại khi build native app với config staging sẽ auto set default channel là stg
[Task-Name] — Ephemeral channel (tồn tại tạm thời) cho từng Jira ticket, ví dụ V567APP-199

4. Tích hợp

A. Infrastructure Configuration

Việc set-up, cấu hình anh em có thể check trực tiếp trên docs của Hot Updater nhé 🫡: https://hot-updater.dev/docs/get-started/introduction

B. Deployment Scripts

Các script được định nghĩa trong package.json, sử dụng biến môi trường từ .env.stg:

"hot:console":       "npx hot-updater console",
"hot:stg:ios":       "ENVFILE=.env.stg npx hot-updater deploy -p ios -t \"4.0.0\" --channel stg",
"hot:stg:android":   "ENVFILE=.env.stg npx hot-updater deploy -p android -t \"4.0.0\" --channel stg",
"hot:stg":           "yarn hot:stg:ios && yarn hot:stg:android",
"hot:task:ios":      "ENVFILE=.env.stg npx hot-updater deploy -p ios -t \"4.0.0\" --channel",
"hot:task:android":  "ENVFILE=.env.stg npx hot-updater deploy -p android -t \"4.0.0\" --channel"

Mổ xẻ từng phần của một lệnh deploy điển hình:

ENVFILE=.env.stg  npx hot-updater deploy  -p ios  -t "4.0.0"  --channel stg
│                 │                        │        │              │
│                 │                        │        │              └─ Tên channel sẽ nhận bundle này
│                 │                        │        └─ Version targeting: chỉ apply cho app 4.0.0
│                 │                        └─ Platform: ios hoặc android
│                 └─ Lệnh deploy của hot-updater CLI
└─ Inject .env.stg làm môi trường build (API keys, app config, v.v.)

Tại sao cần ENVFILE=.env.stg?

Khi JavaScript bundle được tạo ra, nó sẽ bake-in các giá trị từ file .env vào trong bundle — bao gồm API endpoint, feature flags, v.v. Chỉ định .env.stg đảm bảo bundle được build với đúng config của môi trường staging, không phải production.

DEVELOPMENT_MODE=true để check điều kiện chỉ implement với các bản build app ở staging không gây rủi do đến các bản build của production.

const isDevelopmentMode = Boolean(Config.DEVELOPMENT_MODE === "true")

export default isDevelopmentMode
  ? HotUpdater.wrap({
      baseURL: "[https://hot-update.staging.workers.dev/api/check-update](https://hot-update.staging.workers.dev/api/check-update)",
      updateStrategy: "appVersion",
      updateMode: "auto",
    })(App)
  : App

Tại sao cần -t "4.0.0"?

hot-updater.config.ts đang dùng updateStrategy: "appVersion" — nghĩa là Cloudflare D1 sẽ lưu thêm thông tin version targeting cho mỗi bundle. Khi app khởi động và check update, nó gửi kèm app version hiện tại. Cloudflare D1 chỉ trả về bundle nếu version của thiết bị thỏa điều kiện 4.0.0 ( Version chung của các bản build staging )

Sự khác biệt giữa hot:stg và hot:task:

hot:stg deploy lên channel cố định stg — channel này luôn tồn tại và là nơi toàn bộ team nhận update sau mỗi lần merge.

hot:task:ios và hot:task:android không có --channel cố định — dev phải tự append tên channel khi gọi:

yarn hot:task:ios V567APP-199
# tương đương với:
# ENVFILE=.env.stg npx hot-updater deploy -p ios -t "4.0.0" --channel V567APP-199

C. In-App Dev Channel Switcher

DevChannelSwitcher.tsx — Một FAB (Floating Action Button) được inject vào root của app, chỉ hiển thị khi DEVELOPMENT_MODE=true (tức là chỉ có trên bản staging, không bao giờ xuất hiện trên production).

UI này cung cấp một modal với 3 chức năng:

Hiển thị channel đang active hiện tại
Input để nhập tên channel mới và switch sang bundle tương ứng
Nút Reset để quay về channel stg mặc định

NOTE: Do logic của hot update, bắt buộc cần phải chuyển về default channel rồi sau đó mới có thể chuyển đến các Ephemeral channel khác. Ví dụ từ default channel stg chuyển sang channel V567APP-199 để test. Test xong, muốn sang task V567APP-200 thì cần Reset về stg sau đó chuyển sang task V567APP-200 không được chuyển trực tiếp từ V567APP-199 qua V567APP-200.


1. App ở default channel	2. App ở Ephemeral channel

5. Quy Trình Làm Việc Hàng Ngày

👨‍💻 Dev— Deploy một task lên channel riêng

Khi hoàn thành task V567APP-199 và muốn QA bắt đầu test:

Bước 1: Đảm bảo code đã sẵn sàng trên branch local.

Bước 2: Chạy lệnh deploy lên channel riêng của task:

yarn hot:task:ios V567APP-199
yarn hot:task:android V567APP-199

Lệnh này sẽ bundle JavaScript hiện tại ở local và push lên Cloudflare dưới channel V567APP-199. Toàn bộ quá trình mất khoảng 1–2 phút, thay vì 20 phút build native.

Bước 3: Ping QA trên Jira/Mattermost: "Task V567APP-199 Không có phần update native code và đã được deploy lên rồi"

Lưu ý: Mỗi lần chạy lại lệnh deploy cho cùng một channel, bundle cũ sẽ bị ghi đè. QA nếu đang ở channel đó rồi thì chỉ cần đợi app tải về bundle vừa được deploy lên là có code mới nhất vừa được dev update để test, không cần làm gì thêm. 😳

🕵️‍♂️ QA — Switch sang channel của task cần test

Bước 1: Mở Staging App trên thiết bị.

Bước 2: Tap vào icon 🔥 ở góc dưới bên phải màn hình để mở Task Switcher.

Bước 3: Nhập tên task vào ô input: V567APP-199

Bước 4: Tap "🚀 Switch task".

App sẽ tự động tải JavaScript bundle của task đó từ Cloudflare và reload. Sau khi reload xong, app sẽ chạy đúng code của V567APP-199.

Bước 5 (khi test xong): Mở lại Task Switcher → tap "🔄 Reset" để quay về channel stg mặc định.

NOTE: Có thể switch qua lại giữa nhiều task trong cùng một buổi test mà không cần cài lại app hay làm gì phức tạp. Chỉ cần nhập đúng tên channel và tap Switch.

🚀 Release Management — Merge vào Staging chính

Khi PR của V567APP-199 đã được approve và merge vào nhánh staging chính, cần cập nhật channel stg để toàn bộ team nhận được code mới:

Bước 1: Pull code staging mới nhất về máy.

Bước 2: Deploy lên channel stg:

yarn hot:stg

Script này sẽ deploy song song cho cả iOS và Android. Từ lần mở app tiếp theo, mọi thiết bị đang dùng channel stg sẽ tự động fetch và apply bundle mới.

Quan trọng: Chỉ chạy yarn hot:stg sau khi PR đã được merge và code trên nhánh staging đã ổn định. Tránh deploy code đang dở dang lên channel stg vì nó sẽ ảnh hưởng đến toàn bộ team.

🎛️ Dashboard — Quản lý và Rollback

Để xem toàn bộ lịch sử deployment, kiểm tra bundle nào đang active trên channel nào, hoặc thực hiện rollback khi cần:

yarn hot:console

Lệnh này mở một local web interface kết nối trực tiếp với Cloudflare D1 và R2, cho phé:

Xem danh sách tất cả channels và bundle đang active
Force rollback về một bundle cũ hơn chỉ bằng vài click

6. Tóm Tắt So Sánh

	Quy trình cũ	Với Hot Update Channel
Thời gian deploy cho QA	10–15 phút đợi tool (build native), 20-30 phút cho đẩy TestFlight UAT	1–2 phút
Khi update code ở task	Cần build lại app	Không cần làm gì, app tự tải code mới nhất về
Test song song nhiều task	Cần nhiều bản build riêng	Switch channel ngay trên một app
Rollback khi có bug	Build lại từ commit cũ	Rollback qua dashboard, tức thì
Áp dụng cho	Mọi thay đổi	Chỉ JS/Assets, không áp dụng cho native changes

7. Những Điều Cần Lưu Ý

Không dùng cho native changes: Nếu task của dev có thay đổi native code (thêm pod, sửa AndroidManifest, cập nhật native module), dev vẫn phải build native app bình thường. Hot update chỉ dành cho JS/Assets.
Version targeting: Bundle chỉ apply cho app 4.0.0 (default version của staging). Thiết bị đang chạy app version khác sẽ không nhận update.
.env.hotupdater là file nhạy cảm: Không commit file này lên git. Nếu cần onboard thành viên mới, chia sẻ qua kênh bảo mật riêng.

Deep Dive React Native #4: The Architect Inside — Understanding Reconciliation

Trường Trịnh Đức — Wed, 03 Dec 2025 15:43:33 +0000

If you ask a React Native developer: "Does React Native use a Virtual DOM?", the answer is usually a hesitant "Yes... sort of."

Technically, the "DOM" (Document Object Model) is a Web concept. There are no <div> or <span> tags in your phone. However, the mechanism—the core brain that makes React Native performant—is exactly the same. We call it the Virtual Tree (or React Element Tree).

In this article, we will explore Reconciliation: The algorithm that decides when to repaint a wall and when to tear down the entire house.

1. The Expensive Truth: Native Views

Why do we need a "Virtual" tree in the first place?

Imagine you are building a house (User Interface):

Virtual Tree: This is a blueprint on paper. You can erase a wall, redraw a window, or crumble the paper up in milliseconds. It is cheap.
Native Views (UIView on iOS, android.view.View on Android): These are the actual bricks and mortar. Creating a new native view requires memory allocation, GPU rendering, and layout calculation. It is expensive.

If React Native destroyed and recreated the actual Native Views every time your state changed, your app would run at 1 FPS and burn the user's battery instantly.

Reconciliation is the strategic process of comparing the new Blueprint with the old Blueprint to minimize the work required by the Builders (Native UI Thread).

2. The Diffing Algorithm: O(n) Heuristics

In computer science, comparing two trees to find the minimum number of operations is typically an O(n³) complexity problem. For an app with 1,000 elements, that would mean one billion calculations. Too slow.

React uses a "heuristic" (smart guessing) algorithm to bring this down to O(n). To achieve this, it relies on two major assumptions that every Good Developer must know:

Rule #1: Different Types = Total Destruction
If the root element type changes, React tears down the old tree and builds a new one from scratch.

Old: <View><Text>Hi</Text></View>
New: <ScrollView><Text>Hi</Text></ScrollView>

Even though the inside is the same, React sees that View changed to ScrollView. Action:

Unmount the old View (Native View destroyed, state lost).
Mount the new ScrollView (New Native View created).

Pitfall: Never define a component inside another component.

const Parent = () => {
  // ❌ BAD: This creates a new 'Child' type on every render
  const Child = () => <View />;
  return <Child />;
}

This forces React to hit Rule #1 continuously, causing flickering and focus loss.

Rule #2: Same Type = Update Props Only

If the element type remains the same, React keeps the underlying Native View instance.

Old: <View style={{ width: 100 }} />
New: <View style={{ width: 200 }} />

Action: React sees the type is still View. It calculates the difference (diff) in props and sends a specific command to the Native side: "Update property 'width' to 200". The heavy Native View is preserved.

3. The List Problem: Why key is Critical

This is the most common performance bottleneck in React Native lists (FlatList, ScrollView).

Imagine a list: A -> B. You want to insert C at the top: C -> A -> B.

Without Keys:

React compares index 0: A vs C. Different? Mutate A to C.
React compares index 1: B vs A. Different? Mutate B to A.
React appends B at the end. Result: Every single row is re-rendered.

**With Keys (key="a", key="b"): React looks at the unique ID, not the index.

It sees A and B still exist.
It realizes C is the only new item. Result: It re-uses the native views for A and B, and only creates C.

4. The Native Twist: The Shadow Tree

This is where React Native differs from the Web.

On the Web, React talks to the Browser DOM. In React Native, after Reconciliation is done in the JavaScript Thread, the result is not HTML. It is a set of serialized commands (UIManager operations).

JS Thread: Calculates the diff (Reconciliation).
The Bridge (Old Arch) / JSI (New Arch): Transports these changes.
Shadow Tree (C++): A dedicated tree structure used to calculate Layout (Yoga Engine).
UI Thread: The actual pixels are drawn on the screen.

In the New Architecture (Fabric), the Reconciliation step can create the Shadow Tree directly in C++, reducing the overhead significantly and allowing for synchronous updates.

5. Performance Takeaways

Understanding Reconciliation changes how you write code:

Stability is King: Keep your component structure stable. Avoid dynamic component types.
React.memo is your shield: If a parent re-renders, the child re-renders by default (even if props didn't change). Use memo to tell Reconciliation: "Stop here, nothing changed."
Keys Matter: Use unique IDs (from your database) for list keys. Never use the array index (key={index}) if the list can be reordered or filtered.

Final Thoughts

Reconciliation is the "Architect" that bridges the gap between the flexibility of JavaScript and the performance of Native UI. It allows us to write declarative code ("I want a blue button") without worrying about the imperative manual labor ("Create view, set background, set frame...").

Mastering this concept is the first step in moving from "My app works" to "My app flies."

𝐃𝐞𝐞𝐩 𝐃𝐢𝐯𝐞 𝐑𝐞𝐚𝐜𝐭 𝐍𝐚𝐭𝐢𝐯𝐞 #3: 𝐁𝐚𝐛𝐞𝐥 #2— The Real-World Battlefield

Trường Trịnh Đức — Sun, 30 Nov 2025 10:04:56 +0000

In the previous part, we established that Babel is the "Translator." Now, let's see how this translator handles difficult situations in a real project.

1. Absolute Path & Alias — "The Triangle of Synchronization"

Many developers configure Aliases, run the app, and it works perfectly, but VS Code is covered in red errors. Or vice versa: VS Code is happy, but the app crashes. Why?

Because this is the "Triangle of Synchronization." For an Alias (e.g., @components/Button) to work smoothly, three giant systems must shake hands:

Babel: So the code runs (Runtime).
TypeScript (tsconfig.json): So VS Code understands and provides autocomplete (Dev Experience).
Metro: (Sometimes) To resolve overlapping imports.

The Standard Configuration
First, install the plugin: yarn add -D babel-plugin-module-resolver

In babel.config.js:

module.exports = {
  presets: ['module:@react-native/babel-preset'],
  plugins: [
    [
      'module-resolver',
      {
        root: ['./src'], // The root directory to start searching
        extensions: ['.ios.js', '.android.js', '.js', '.ts', '.tsx', '.json'],
        alias: {
          '@components': './src/components',
          '@utils': './src/utils',
          '@assets': './src/assets',
        },
      },
    ],
  ],
};

The Trap
Many people forget the extensions array. If you don't declare .ts or .tsx here, Babel sometimes won't know to apply the Alias to your TypeScript files, leading to random "Module not found" errors.

Sync with tsconfig.json (Mandatory)
Babel modifies the code underneath, but VS Code doesn't know that. You must "declare" it again to TypeScript:

{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@components/*": ["components/*"],
      "@utils/*": ["utils/*"]
    }
  }
}

2. Cleaning Up for Production (Removing Console Logs)

A good developer is always obsessed with performance. console.log is incredibly useful during development, but it is poison in a release build.

It slows down the JS Bridge (because strings must be serialized and sent between JS and Native).
It exposes sensitive information if a user connects the device to a computer to view logs.

We don't delete logs manually line by line. We tell Babel to do it.

Smart Configuration (Dynamic Configuration)
The Babel config is essentially a JS function, so we can write if/else logic inside it.

module.exports = function(api) {
  // api.cache(true) helps Babel cache this config forever until restart
  // Significantly speeds up build time
  api.cache(true);

  const presets = ['module:@react-native/babel-preset'];
  const plugins = [];

  // Logic: Only remove logs when building for Production
  if (process.env.NODE_ENV === 'production') {
    plugins.push('transform-remove-console');
  }

  return {
    presets,
    plugins,
  };
};

Developer Insight: Using api.cache(true) or api.cache.using(() => process.env.NODE_ENV) is a build time optimization technique that few notice. Without it, Babel might recalculate the config for every single file, slowing down your build process.

3. Environment Variables & Caching Hell

When using react-native-dotenv to manage API Keys, Babel directly replaces those variables into your code as strings.

Example Code: console.log(process.env.API_URL)
Babel Translates to: console.log("https://api.example.com")

The Deadly Trap:
You change API_URL in your .env file from "dev" to "prod". You reload the app. The app still points to "dev". You pull your hair out?

The Reason:
Babel (via Metro) has CACHED the old translation. It sees your JS code hasn't changed (it's still the same process.env... line), so it doesn't re-translate it. It doesn't know that the .env file outside has changed.

The Expert Solution

Always run npx react-native start --reset-cache when changing environment variables.
Or configure Babel to cache based on the .env file (more complex, but automated).

Summary

When working with babel.config.js, remember these 3 Golden Rules:

The Triangle: If Babel changes a path, TSConfig must know about it.
The Environment: Configs for Dev and Prod can be different (clean up logs in Prod).
Reset Cache: The magic spell that fixes almost everything when editing Babel configs.

console.log("Thanks for reading!")

Deep Dive React Native #2: Babel — The Versatile "Translator"

Trường Trịnh Đức — Thu, 27 Nov 2025 17:11:31 +0000

In our previous post, we explored Metro, the "Logistics Hub" that gathers and packages your code. But before Metro packs the boxes, something crucial must happen to the product inside.

In your project file, babel.config.js often looks very brief, even sketchy. But don't let that appearance fool you. Without it, your application would crash on the very first line of code.

Why? Because you are writing code in a language your phone does not understand.

1. The Mental Model: The "Diplomat"

Imagine you (The Developer) are a diplomat speaking French (Modern JS, JSX, TypeScript). However, the listener (The JavaScript Engine on the phone — Hermes or JSC) only understands broken English (old Standard JavaScript).

If you say: "Je t'aime" (Fancy Code: const App = () => <View />), the listener will be confused.

Babel is the interpreter standing in between. He takes your French text, translates it into broken English: "I love you" (Old Code: var App = function() { return React.createElement(View)... }), and then hands it to the phone to execute.

In short: Babel turns your "modern, beautiful" code into "ugly, basic" code that any machine can run.

2. Under the Hood: How Babel Works

To become a Good Developer, you need to know Babel isn't just simple "find & replace" text. It operates through 3 sophisticated surgical steps:

1. Parsing (Reading): Babel reads your code and draws a tree diagram called the AST (Abstract Syntax Tree). It understands the logical structure of the code, not just the characters.

2. Transformation (Editing): This is where the Plugins jump in. They climb that AST tree, cut this branch, and graft that branch.

It sees a "JSX" branch → cuts it → replaces it with a React.createElement branch.
It sees a "TypeScript Type" branch → chops it off completely (since JS doesn't need types).

3. Code Generation (Writing): From the modified tree, Babel writes out the new code file (output) that Metro will eventually bundle.

3. Dissecting `babel.config.js`

This configuration file is essentially where you command the "Translator" on what to translate. It has two core components: Presets and Plugins.

module.exports = {
  presets: ['module:@react-native/babel-preset'],
  plugins: [
    'react-native-reanimated/plugin',
  ],
};

A. Presets (The Combo Menu)
Instead of telling Babel to translate bit by bit (translate arrows =>, translate class, translate const...), we use Presets. module:@react-native/babel-preset is a giant combo package containing hundreds of translation rules (plugins) essential for React Native. It tells Babel: "Translate everything that React Native folks usually use (Flow, TS, JSX) into standard JS for me."

B. Plugins (Side Dishes / Special Agents)
Sometimes the Combo menu isn't enough. You need special tools for specific tasks.

Classic Example 1: Alias (The Shortcut)
For Babel to actually understand and change the code paths, we need a plugin. When Babel sees @components, it silently fixes it to ./src/components in the final code.

Classic Example 2: Reanimated (The Magic)
Why does react-native-reanimated require a mandatory plugin?

Because this library runs code on a separate thread (UI Thread). Its Babel plugin secretly turns your function into a "worklet" — a small piece of code that can be detached from the main JS thread and sent to the UI thread. Without this plugin, the App crashes immediately because the UI thread receives no code.

4. Why You - A React Native Developer Need to Care?

You might ask: "It works out of the box, why touch it?"

Order Matters (Life or Death) 💀: This is a basic but headache-inducing error. Babel runs Plugins from top to bottom. Some libraries (like react-native-reanimated) require their plugin to be last in the list. Wrong placement → Crash with unknown cause.
Cache War 💾: Metro caches Babel's results very tightly. When you edit babel.config.js (e.g., adding a new alias), but the App doesn't update? That's because Metro says: "I already translated this file, I'll grab the old version." Whenever you touch config, always run: npx react-native start --reset-cache.
Debugging and Source Maps 🐞: When the App errors, the log points to index.bundle (the file Babel has mashed up). How do you know where the error is in the original file? That’s thanks to Source Maps — a map linking "ugly" code back to "beautiful" code. A wrong Babel config can break this map.

Final Thoughts

babel.config.js is not just a soulless configuration file. It is the blueprint for your code's "transformation" process.

Metro: The Transporter (Logistics).
Babel: The Processor (Translator) working for Metro.

Understanding Babel helps you confidently integrate the "pickiest" libraries (like Reanimated, Skia) and structure projects professionally.

console.log("Thanks for reading!")

Deep Dive React Native #1: The Most Overlooked File in Your Project: Do You Truly Understand metro.config.js

Trường Trịnh Đức — Tue, 25 Nov 2025 16:58:09 +0000

When you initialize a new React Native project, you will find a file quietly sitting in your root directory: metro.config.js Most developers tend to ignore it until something breaks, or they need to install a specific library like react-native-svg

But have you ever asked yourself:

Why doesn't React Native use Webpack or Vite?
How does the app update so instantly when I change a single line of code (Fast Refresh)?

The answer lies in Metro.

In this article, we won't just learn how to "configure" it. We are going to tear it open to understand what it actually does. Understanding Metro is the difference between a coder who just copies solutions and a developer who understands the first principles of their tools.

1. The Mental Model: The "Logistics Hub"

Imagine your React Native application is a fully assembled car, running inside a factory (the user's device). However, your raw materials (Source Code) are scattered everywhere:

Logic code lives in ts and js files.
UI components are in tsx
Images are stored in an assets folder.
Third-party parts are buried in the massive warehouse known as node_modules

If the device had to go and fetch every single component individually at runtime, the app would be incredibly slow.

Metro acts as a giant Logistics Hub. Its mission is to:

Gather: Locate every file your app needs.
Process: Translate "foreign" languages (TypeScript, JSX) into something the machine understands (Standard JavaScript).
Package: Stuff everything into a single container (the index.bundle file) and ship it to the device.

2. Under the Hood: The 3 Stages of Metro

To truly understand metro.config.js, you need to visualize the lifecycle of the bundling process. It consists of three sequential stages:

Stage 1: Resolution (Finding the files) 🔍
This is where Metro answers the question: "When you write import A from './A', where exactly is file A?"

Unlike the Web, React Native has a unique mechanism called Platform-specific extensions. When you write import Button, Metro is smart enough to look for:

Button.ios.js (if running on iOS)
Button.android.js (if running on Android)
Button.native.js (fallback)

This is why React Native needs its own custom resolver instead of using Webpack. Metro is heavily optimized to search through thousands of modules within node_modules in milliseconds.

Stage 2: Transformation (Translation) 🔄
React Native (specifically the Hermes Engine or JSC) doesn't understand TypeScript, JSX, or the newest ESNext syntax. Metro pushes your code through a "translator" (usually Babel).

It turns <View> into React.createElement(View)
It strips types: const name: string becomes var name. This is the most CPU-intensive stage. Metro optimizes this using Caching and Parallel Processing.

Stage 3: Serialization (Packaging) 📦
Once thousands of individual files have been translated, Metro will:

Combine them into a single (or few) JavaScript bundle files.
Assign numeric IDs to modules so the runtime knows which file to load first.

3. Dissecting `metro.config.js`

Essentially, this config file allows you to intercept and modify the 3 stages mentioned above.
There are two main objects you will interact with most often:

1. The Transformer (Intercepting Stage 2)
You use this when you want Metro to understand a file type that it doesn't support by default (e.g., SVGs). You need to tell Metro: "Hey, don't treat .svg as text. Use react-native-svg-transformer to turn it into a component."

2. The Resolver (Intercepting Stage 1)
You use this to guide Metro on where to look, or what not to look at.

sourceExts: List of extensions treated as source code (js, ts, tsx...).
assetExts: List of static resources (png, jpg...).
blockList: Used to forbid Metro from indexing specific folders to avoid conflicts.

4. Real World Example

Here is the standard code snippet that a developer would write to handle SVGs, using mergeConfig (the modern approach for React Native > 0.72):

const {getDefaultConfig, mergeConfig} = require('@react-native/metro-config');

/**
 * Get the default config so we don't break standard RN settings
 */
const defaultConfig = getDefaultConfig(__dirname);
const {assetExts, sourceExts} = defaultConfig.resolver;

/**
 * Custom Config
 */
const config = {
  transformer: {
    // Use a specific transformer for SVGs
    babelTransformerPath: require.resolve('react-native-svg-transformer'),
  },
  resolver: {
    // Remove 'svg' from assetExts (so it's not copied as a raw file)
    assetExts: assetExts.filter((ext) => ext !== 'svg'),

    // Add 'svg' to sourceExts (so it's processed as source code)
    sourceExts: [...sourceExts, 'svg'],
  },
};

// Merge default config with custom config
module.exports = mergeConfig(defaultConfig, config);

5. Why You - A React Native Developer Need to Care?

You might ask: "As long as it runs, why should I care about this file?"

Debugging "Haunted" Errors: Someday, you will encounter an error like "Unable to resolve module X" even though the module is there. Understanding the Resolver and Cache(--reset-cache) is the key to exorcising these ghost errors.
Performance & Build Speed: Knowing how to use blockList to exclude unnecessary folders can significantly speed up your development cycle.
Monorepos & Symlinks: In professional environments (Monorepo), Metro does not handle Symlinks well by default. You will eventually need to configure watchFolders manually to make Metro "see" code outside the project root.

Final Thoughts

metro.config.js isn't scary. It is simply the map that guides the factory on how to build your code. The next time you see this file, remember: It decides what goes into your app and how it gets processed.

console.log(Thanks for reading!)

DEV Community: Trường Trịnh Đức

Tích hợp Hot Update vào dự án để tối ưu thời gian cho internal testing

Giới thiệu

1. Vấn Đề Cần Giải Quyết

🐢 QA Cycle quá chậm

🐢 🐢 Khách UAT các task riêng lẻ

2. Giải Pháp: OTA Update + Switch Channel

OTA Update là gì?

Switch Channel là gì?

3. Kiến Trúc & Infrastructure

4. Tích hợp

A. Infrastructure Configuration

B. Deployment Scripts

C. In-App Dev Channel Switcher

5. Quy Trình Làm Việc Hàng Ngày

👨‍💻 Dev— Deploy một task lên channel riêng

🕵️‍♂️ QA — Switch sang channel của task cần test

🚀 Release Management — Merge vào Staging chính

🎛️ Dashboard — Quản lý và Rollback

6. Tóm Tắt So Sánh

7. Những Điều Cần Lưu Ý

Deep Dive React Native #4: The Architect Inside — Understanding Reconciliation

1. The Expensive Truth: Native Views

2. The Diffing Algorithm: O(n) Heuristics

Rule #2: Same Type = Update Props Only

3. The List Problem: Why key is Critical

4. The Native Twist: The Shadow Tree

5. Performance Takeaways

Final Thoughts

𝐃𝐞𝐞𝐩 𝐃𝐢𝐯𝐞 𝐑𝐞𝐚𝐜𝐭 𝐍𝐚𝐭𝐢𝐯𝐞 #3: 𝐁𝐚𝐛𝐞𝐥 #2— The Real-World Battlefield

1. Absolute Path & Alias — "The Triangle of Synchronization"

2. Cleaning Up for Production (Removing Console Logs)

3. Environment Variables & Caching Hell

Summary

Deep Dive React Native #2: Babel — The Versatile "Translator"

1. The Mental Model: The "Diplomat"

2. Under the Hood: How Babel Works

3. Dissecting babel.config.js

4. Why You - A React Native Developer Need to Care?

Final Thoughts

Deep Dive React Native #1: The Most Overlooked File in Your Project: Do You Truly Understand metro.config.js

1. The Mental Model: The "Logistics Hub"

2. Under the Hood: The 3 Stages of Metro

3. Dissecting metro.config.js

4. Real World Example

5. Why You - A React Native Developer Need to Care?

Final Thoughts

3. Dissecting `babel.config.js`

3. Dissecting `metro.config.js`