It was a typical Friday night, unfolding as planned. The latest version of our React Native app has just been pushed to production via the Play Console, with a controlled rollout targeting 30% of users. However, our sense of routine was abruptly shattered when a critical alert appeared in the Google Analytics dashboard: the crash-free user rate had plummeted from 99% to 92%. This alarming drop triggered a code-red situation.
Thanks to my incredibly diligent team, we immediately convened on a call, even in the middle of the night. Leveraging the Google Crash Analytics tool, we analyzed the stack trace and tracked user behavior across screens. Despite these insights, we couldn’t pinpoint a consistent pattern to reproduce the crash. The only plausible theory was that an accidental early return statement in the code might be responsible.
Finding the Bug
With no discernible pattern in user behavior, we turned to the version diff in our codebase. Meticulously, we reviewed every line of code and combed through over 150+ Git diffs, searching for anomalies. Yet, the elusive early return statement remained undetected. Still, we implemented a series of optimizations and pushed an update to production. While the crash reoccurred 12 hours later, its frequency had significantly dropped.
The breakthrough came unexpectedly. While working on a separate feature, my internet connection briefly went offline, and I happened to have the app open. To my surprise, the fatal error surfaced right before my eyes.
The mistake
const {isConnected} = netState();
if (!isConnected){
return;
}
const calculateMyView = useCallback(() => {
// ...some code
},[]);
After extensive debugging, we traced the issue to an early return statement buried deep within one of our components. This subtle bug introduced a crash under specific circumstances: when a user reconnected to a stable internet connection, causing the component to attempt a re-render.
What Happens Internally?
Initial Render
During the initial render, React registers each hook (e.g., useCallback) in the exact order they are called. Hooks are stored in an internal list, indexed by their position in the component tree.
Subsequent Renders
On re-renders, React expects hooks to be called in the same order and at the same positions. If this order changes — for example, due to an early return statement that skips the execution of a hook — the internal list becomes misaligned. React then tries to access a hook (e.g., at position 1) that wasn’t executed, resulting in an error.
The crash, identified as a com.facebook.react.common.JavascriptException, occurred because React was rendering fewer hooks than expected—a classic symptom of skipping stateful logic due to a misplaced early return. This behavior violated React's rules of hooks, which require the order of hooks execution to remain consistent across renders. As a result, any user with this screen on their stack would encounter a crash if the internet connection dropped.
The Fix
const {isConnected} = netState();
const calculateMyView = useCallback(() => {
// ...some code
},[]);
if (!isConnected){
return;
}
To resolve the issue, we reordered the logic to ensure the return statement no longer interrupted the execution flow of hooks. By making this adjustment, we adhered to React’s declarative principles, stabilized the re-render process, and eliminated the crash.
This experience was a powerful reminder of the importance of following React’s rules of hooks and avoiding conditional returns within render logic. These principles are critical for maintaining the integrity and stability of React applications.
Top comments (1)
Informative...