skip to content

In React Native DevTools, which requests does the Network panel capture, and what are its current gaps?

level: middleimportance: should knowfreq 30%

answer

  1. new in 0.83
  2. fetch, XMLHttpRequest, <Image>
  3. no WebSocket frames yet
  4. no mocking, no throttling
  5. 100 MB preview buffer

basics

~20 s

Since 0.83 the Network panel records fetch(), XMLHttpRequest and <Image> requests while DevTools is connected, with headers, timings, previews and an Initiator stack. It does not yet show WebSocket events, mock responses or throttle, and misses custom stacks such as Expo Fetch.

solid answer

~40 s

The Network panel arrived in React Native 0.83. While DevTools is connected it records every request made through `fetch()`, `XMLHttpRequest` (so libraries built on it too) and `<Image>`, showing headers, timings, response previews and an **Initiator** tab with the call stack that sent the request. Previews live in an on-device buffer capped at 100 MB, so the oldest bodies can be evicted while their metadata stays. As of the 0.87 docs it does not show WebSocket events, has no response mocking and no network throttling, and it doesn't capture custom networking stacks such as Expo Fetch. Expo apps therefore still get Expo's own **Expo Network** panel, which covers those sources but has no initiator and no Performance integration.

go deeper

for a junior

Remember that DevTools has a Network panel since 0.83 and that it shows fetch, XMLHttpRequest and image requests with headers and response previews.

for a middle

Explain what is and isn't captured, the Initiator tab, the 100 MB preview buffer, and why Expo apps show a separate Expo Network panel.

for a senior

Work around the gaps on real bugs: reproduce start-up requests with DevTools open, inspect WebSocket traffic another way, and use device-level network conditions when throttling is needed.

for a principal

Decide what the team standardises on for network debugging across bare and Expo apps, knowing the core panel and Expo's panel cover different request sources today.

## What the Network panel is The **Network panel** in React Native DevTools, added in **React Native 0.83**, lists the HTTP requests your app makes, much as the Network panel of a browser's developer tools does for a web page. Requests are recorded automatically **while DevTools is connected** to the app, so the habit to build is: open DevTools first, then reproduce the problem. It is built on the Chrome DevTools Protocol's Network domain, reported by React Native itself. It replaced older routes that are now gone or going: Flipper's network plugin (unsupported since 0.74), the Network tab of the in-app Element Inspector (removed in 0.84), and the `XHRInterceptor` / `WebSocketInterceptor` APIs that tools hooked into (deprecated in 0.84 in favour of CDP). ## What gets recorded As of the 0.87 docs, React Native records every request made through: - **`fetch()`**; - **`XMLHttpRequest`**, which also covers networking libraries built on it; - **`<Image>`**, so remote image loads show up next to your API calls. Custom networking stacks outside those three are not recorded yet. The docs name **Expo Fetch** as the example, with support planned for later releases. ## What you see for each request - **Headers**, sent and received, and the status. - **Timings** for the request. - **Response previews** of the body. - An **Initiator** tab with the JavaScript call stack that started the request, so you can jump from a failing request straight to the line that sent it. Response previews are held in an **on-device buffer capped at 100 MB**. When a session collects more than that, previews are evicted **oldest first**, while each request's metadata stays in the list. A long session with large JSON payloads can therefore show an old request whose body is no longer available. Network events also appear as a track in the Performance panel's timeline; performance tracing itself is a separate topic. ## The gaps | Capability | Chrome DevTools on a web page | React Native DevTools (0.87 docs) | |---|---|---| | `fetch` / XHR requests | Yes | Yes | | Image loads | Yes | Yes, via `<Image>` | | WebSocket frames | Yes | Not yet | | Response mocking | Yes | Not yet | | Network throttling | Yes | Not yet | | Initiator call stack | Yes | Yes | The practical consequences: 1. A chat or live-score feature built on WebSockets cannot be inspected message by message here; log the messages yourself or use another tool. 2. A slow-network bug cannot be reproduced by throttling in DevTools; you need to slow the network another way, for example on the emulator or device. 3. An error state that depends on a particular server response cannot be forced by mocking in the panel; stub it in code or on a test server. ## Expo projects Expo apps continue to see the **Expo Network** panel, Expo's own implementation. It covers Expo-specific network events such as Expo Fetch, but has fewer features: **no request initiator** and **no Performance panel integration**. The React Native and Expo teams have said they are working to bring Expo Fetch and third-party libraries into the core pipeline. In an interview, it is enough to say that the two panels exist, that the core one covers `fetch`, XHR and `<Image>`, and that Expo's covers its own sources. ## Using it on a real bug The Network panel answers four questions quickly, and each points to a different next step: - **Did the request leave at all?** If it is missing, the failure happened before sending, or the request went through a stack the panel does not record. - **What did it carry?** The request headers and body show a wrong base URL, a missing auth header or a malformed payload. - **What came back?** The status and response preview separate a server rejection from a client-side handling bug. - **Which code sent it?** The Initiator stack takes you to the call site, which matters when several screens call the same endpoint. It does not answer *why the UI then did something wrong*. For that you move to breakpoints in the Sources panel or to component state in the Components panel. Keep in mind that everything here needs a debug build: React Native DevTools, including this panel, is disabled in release builds, so a problem that appears only in production traffic needs logging in the app rather than the inspector.

  • A request fired during app start is missing from the Network panel. What is the likely reason?
    Requests are recorded while DevTools is connected, so anything sent before you opened it may not be in the list. Open DevTools, then reload the app from the Dev Menu or with r in the dev server terminal to reproduce the start-up sequence with recording on. Also check that the request goes through fetch, XMLHttpRequest or <Image>, since other networking stacks aren't captured.
  • Your app talks to its backend over a WebSocket. How do you debug the messages in React Native 0.87?
    The Network panel does not show WebSocket events yet, so you can't read frames there. Log the sent and received messages to the Console, or set a logpoint in the socket's message handler in the Sources panel so you can inspect each payload without editing code.

saying these in an interview costs you the question

  • The Network panel shows WebSocket frames like a browser does.
  • You can throttle the connection from the Network panel.
  • Every request since app launch is always listed.
  • Expo apps get no network inspection at all.
  • Response bodies are kept for the whole session no matter their size.