Re-Render Hot Spots

## Why a log line costs frames In a browser, a stray `console.log` is mostly harmless. In a React Native release build it can show up as jank, because of where the work happens: - React Native replaces the global `console` with a **polyfill** whenever the runtime provides a native logging hook. That condition is not tied to `__DEV__`, so the polyfill runs in release builds too. - For every call, the polyfill turns the arguments into one string. A single string argument is used as is; any other argument is formatted by an **inspector** that walks objects and arrays up to **10 levels deep**. - The resulting string is passed to the native logger (the platform log), which is extra work beyond the formatting. - All of that runs **synchronously on the JS thread**, the same thread that renders components and handles touches. A single log is cheap. The trouble is logs in **hot paths**: inside a component body that renders often, in a scroll or gesture handler, in a list row, or in a store middleware that logs every action with the whole state. The React Native performance guide calls this out explicitly, including logging from debugging libraries, as a big bottleneck on the JavaScript thread in bundled apps. ## Stripping calls at build time The documented fix is a Babel plugin, **`babel-plugin-transform-remove-console`**, which removes `console.*` calls from the code during the build: 1. Install it as a dev dependency: `npm i babel-plugin-transform-remove-console --save-dev`. 2. Add it under `env.production.plugins` in `babel.config.js` (see the code example). In an Expo project, run `npx expo customize babel.config.js` first if the file does not exist; the default preset there is `babel-preset-expo`. 3. **Clear the Metro cache** so already-transformed files are rebuilt: `npx react-native start --reset-cache` or `npx expo start --clear`. The `env` key works because of how Metro calls Babel: | Bundle | Babel env name | Plugin applied? | |---|---|---| | Development (`dev=true`) | `development` | no | | Release (`dev=false`) | `BABEL_ENV` if set, otherwise `production` | yes | The docs recommend the plugin even for projects that make no console calls themselves, because third-party libraries in the bundle may. ## Trade-offs to decide deliberately - **It removes every `console.*` call**, including `console.error` and `console.warn`. If any error-reporting path in your app relies on `console.error` being called, stripping it removes that signal too. - **Arguments go with the call.** Code such as `console.log(markSeen(post))` loses the `markSeen` call in release. Never put required work inside a console call. - **A custom `BABEL_ENV`** on your release build machine changes the env name, so the `production` block would not apply. Keep release builds on the default or match the key. - **Debug builds keep their logs**, so development is unaffected. ## Beyond the plugin The plugin is a safety net, not a logging strategy. Good habits that go with it: - Keep logs out of render bodies, list rows and per-frame handlers even in development; they slow the dev loop as well. - Log identifiers and small summaries rather than whole objects; the inspector's cost grows with object size. - Gate verbose diagnostics behind `__DEV__` when you do want them during development. - Remember that removing logs fixes one cost; re-render cost itself still needs profiling. ## Common mistakes - Assuming release builds drop console output automatically. - Adding the plugin to the top-level `plugins` array, which strips logs from development too. - Forgetting the cache reset and concluding the plugin "does nothing". - Wrapping side effects in log calls, which silently vanish in release. A good interview answer names the mechanism (formatting and native logging on the JS thread in release), the fix (the plugin under `env.production`) and at least one trade-off (it also strips `console.error` and anything inside the call).