DEV Community: Amit Kumar

JavaScript Type Coercion — Output-Based Questions ([] + [], NaN === NaN & Friends)

Amit Kumar — Sun, 26 Jul 2026 06:25:24 +0000

After hoisting, interviewers love dropping one-liners like:

console.log([] + []);
console.log([] + {});
console.log({} + []);
console.log(NaN === NaN);

…and watching whether you guess, freeze, or calmly walk the coercion rules.

This post is only output-based type coercion / equality questions.

Try each snippet yourself first. Answers are hidden — click Show answer when you’re ready.

TL;DR — what interviewers are testing

Concept	Trap
`+` with objects/arrays	Often becomes string concat, not math
`[]` / `{}` stringification	`[]` → `""`, `{}` → `"[object Object]"`
Bare `{} + []`	Parser may treat `{}` as a block, not an object
`NaN === NaN`	Always `false` — use `Number.isNaN` / `Object.is`
`==` vs `===`	`==` coerces; `===` does not
Falsy vs “empty-looking”	`[]` and `{}` are truthy
`typeof null`	Infamous `"object"` lie

One-line mental model

+ asks both sides to become primitives.

If either side is a string (after that), you get concatenation.

Otherwise you get number math — and weird values become NaN.

Warm-up: how `+` really decides

When JS hits a + b, it roughly does:

1) Convert both sides to primitives (ToPrimitive)
2) If either result is a string → String(a) + String(b)   // concat
3) Else → Number(a) + Number(b)                         // math

For plain objects / arrays, ToPrimitive usually ends up calling .toString():

Value	`String(value)`	`Number(value)`
`[]`	`""`	`0`
`[1, 2]`	`"1,2"`	`NaN`
`{}`	`"[object Object]"`	`NaN`
`null`	`"null"`	`0`
`undefined`	`"undefined"`	`NaN`
`true`	`"true"`	`1`
`false`	`"false"`	`0`

That’s enough to solve most [] + {} style questions.

How to use this post

Read the snippet
Say the output out loud (or write it down)
Only then open Show answer
Read the step-by-step — don’t only memorize the final print

Q1 — Classic `[] + []`

console.log([] + []);

Show answer
Output

""

(empty string — looks like a blank line)

Step by step

+ wants primitives from both arrays.
String([]) → "" (empty array joins to empty string).
"" + "" → "".

Interview tip: People often say 0 or []. Wrong. Empty array stringifies to "", so you get string concat of nothing.

Q2 — `[] + {}`

console.log([] + {});

Show answer
Output

[object Object]

Step by step

Left: String([]) → ""
Right: String({}) → "[object Object]"
One side is a string → concat → "" + "[object Object]" → "[object Object]"

Why not math? Because after ToPrimitive, you already have a string on the left (""), so + stays in string mode.

Q3 — `({} + [])` with parentheses

console.log({} + []);
console.log(({} + []));

Show answer
Output

[object Object]
[object Object]

Step by step

Inside console.log(...) / parentheses, {} is an object literal.
String({}) → "[object Object]"
String([]) → ""
Concat → "[object Object]" + "" → "[object Object]"

Same printable result as [] + {}, different operand order — both sides still stringify.

Q4 — The famous bare `{} + []` trap

eval('{} + []');
eval('({} + [])');

Show answer
Output

0
[object Object]

Step by step

Bare {} + [] at statement start: JS can parse {} as an empty block, not an object.
What’s left is unary +[].
+[] → Number([]) → 0.
Wrap it: ({} + []) forces an expression → object + array → "[object Object]".

Interview tip: Always ask: “Is this a statement or an expression?” Parentheses (or console.log) change the parse.

Q5 — Arrays with values still concat

console.log([1, 2] + [3, 4]);

Show answer
Output

1,23,4

Step by step

String([1, 2]) → "1,2"
String([3, 4]) → "3,4"
"1,2" + "3,4" → "1,23,4"

No spaces. No nested array. Just two strings glued together.

Q6 — `NaN === NaN`

console.log(NaN === NaN);
console.log(NaN == NaN);

Show answer
Output

false
false

Step by step

IEEE-754 rule: NaN is never equal to anything, including itself.
So both === and == return false.

Correct checks

Number.isNaN(NaN);     // true  ← prefer this
Object.is(NaN, NaN);   // true
isNaN('hello');        // true  ← coerces first (sloppy)
Number.isNaN('hello'); // false ← no coercion

Interview tip: Saying “use isNaN” is incomplete. Prefer Number.isNaN or Object.is.

Q7 — How `NaN` is born (and stays sticky)

console.log(Number('abc'));
console.log('abc' - 1);
console.log(undefined + 1);
console.log(NaN + 5);
console.log(typeof NaN);

Show answer
Output

NaN
NaN
NaN
NaN
number

Step by step

Failed number conversion → NaN.
Any math with NaN → NaN (it “poisons” the expression).
typeof NaN is still "number" — weird but true.

One-liner: NaN means “invalid number,” not “not a number type.”

Q8 — `Object.is` vs `===` (NaN + `-0`)

console.log(Object.is(NaN, NaN));
console.log(Object.is(+0, -0));
console.log(+0 === -0);

Show answer
Output

true
false
true

Step by step

Object.is treats NaN as equal to NaN.
Object.is treats +0 and -0 as different.
=== does the opposite on zeros: +0 === -0 is true.

Use this when they ask “when is Object.is not the same as ===?”

Q9 — `+` vs `-` with strings

console.log('5' + 2);
console.log('5' - 2);
console.log('5' * '2');
console.log('5' + '2');

Show answer
Output

Step by step

+ with a string → concat → "52".
- / * always do numeric conversion → 3, 10.
'5' + '2' is pure string concat → "52".

Rule of thumb: Only + is overloaded for strings. -, *, /, % are always math.

Q10 — Booleans in math

console.log(true + true);
console.log(true + false);
console.log(true + '1');
console.log(false - true);

Show answer
Output

2
1
true1
-1

Step by step

true → 1, false → 0 in numeric context.
true + true → 1 + 1 → 2.
true + '1' hits a string → "true" + "1" → "true1".
false - true → 0 - 1 → -1.

Q11 — Unary plus / Number on `[]` and `{}`

console.log(+[]);
console.log(+{});
console.log(Number([]));
console.log(Number({}));

Show answer
Output

0
NaN
0
NaN

Step by step

+[] → Number([]) → Number("") → 0.
+{} → Number("[object Object]") → NaN.

This is why bare {} + [] can print 0 (unary plus on []).

Q12 — `null` / `undefined` with `+`

console.log(null + 1);
console.log(undefined + 1);
console.log([] + null);
console.log(null + []);

Show answer
Output

1
NaN
null
null

Step by step

Numeric: null → 0, so null + 1 → 1.
Numeric: undefined → NaN, so undefined + 1 → NaN.
With arrays, + becomes string concat: "" + "null" → "null".

Same characters printed for the last two — both are the string "null".

Q13 — `null == undefined` (and friends)

console.log(null == undefined);
console.log(null === undefined);
console.log(null == 0);
console.log(undefined == 0);
console.log(null == false);

Show answer
Output

true
false
false
false
false

Step by step

Spec special case: null == undefined is true.
=== checks type too → false.
null / undefined do not loosely equal 0 or false.

Memorize this trio: null == undefined is the exception people forget.

Q14 — Empty array vs empty string vs `0`

console.log([] == 0);
console.log([] == '');
console.log('' == 0);
console.log([] == false);
console.log(false == '');

Show answer
Output

true
true
true
true
true

Step by step (high level)

== keeps coercing until it can compare primitives.
[] becomes "", then often 0.
false becomes 0.
So these “different-looking” values all meet in the middle as 0 / "".

Interview tip: This is why seniors say never use == unless you mean it. Prefer ===.

Q15 — The viral `[] == ![]`

console.log(![]);
console.log([] == ![]);

Show answer
Output

false
true

Step by step

[] is truthy, so ![] → false.
Expression becomes [] == false.
false → 0, [] → "" → 0.
0 == 0 → true.

Looks impossible. Totally consistent with coercion rules.

Q16 — Truthy / falsy surprises

console.log(Boolean([]));
console.log(Boolean({}));
console.log(Boolean(''));
console.log(Boolean(0));
console.log(Boolean(NaN));
console.log(Boolean(null));
console.log(!!'0');

Show answer
Output

true
true
false
false
false
false
true

Falsy list (memorize — only these):

false, 0, -0, 0n, '', null, undefined, NaN

Everything else is truthy — including [], {}, and '0'.

Q17 — Reference equality for objects/arrays

console.log([] === []);
console.log({} === {});
console.log([] == []);
console.log({} == {});

const a = [];
console.log(a === a);

Show answer
Output

false
false
false
false
true

Step by step

Objects/arrays compare by reference, not contents.
Each {} / [] literal creates a new value in memory.
Same variable refers to the same reference → true.

== does not deep-compare objects either.

Q18 — `typeof null` classic

console.log(typeof null);
console.log(typeof []);
console.log(typeof {});
console.log(typeof NaN);
console.log(Array.isArray([]));

Show answer
Output

object
object
object
number
true

Step by step

typeof null === "object" is a decades-old language bug/legacy quirk.
Arrays are objects → "object"; detect with Array.isArray.
NaN is a number.

Safe null check: value === null (not typeof).

Q19 — Floating point equality

console.log(0.1 + 0.2);
console.log(0.1 + 0.2 === 0.3);

Show answer
Output

0.30000000000000004
false

Why: Binary floating point can’t represent 0.1 / 0.2 exactly.

Not a coercion bug — a precision bug. Mention Number.EPSILON or decimal libraries if they push deeper.

Q20 — Mixed bag rapid fire

console.log([] + {});
console.log({} + []);
console.log([] + [] + 'ok');
console.log('' + 1 + 0);
console.log('' - 1 + 0);
console.log(true + true + true);
console.log(!![]);
console.log(Number.isNaN(NaN) && !(NaN === NaN));

Show answer
Output

[object Object]
[object Object]
ok
10
-1
3
true
true

Quick why

First two: stringified object (inside console.log, {} is an expression).
"" + "" + "ok" → "ok".
"" + 1 + 0 → "10" (left-to-right concat).
"" - 1 becomes numeric -1, then -1 + 0 → -1.
true thrice → 3.
[] truthy → true.
Best NaN check + === self-inequality both hold → true.

Practice round (no spoilers)

Predict each line, then check in a REPL.

P1

console.log([] + []);
console.log([] + 1);
console.log([1] + [2]);

Show answer


1
12

"", then "1", then "1"+"2".

P2

console.log(NaN === NaN);
console.log(Object.is(NaN, NaN));
console.log(Number.isNaN('NaN'));

Show answer

false
true
false

Number.isNaN does not coerce strings.

P3

console.log([] == ![]);
console.log({} == !{});

Show answer

true
false

!{} → false → {} == false → NaN == 0 path fails → false.

P4

console.log(null + null);
console.log(undefined + undefined);
console.log(null == undefined);

Show answer

0
NaN
true

null → 0; undefined → NaN; loose equal special case.

P5

console.log('10' - 5 + '5');
console.log('10' + 5 - '5');

Show answer

55
100

Left: (10-5)+"5" → "55". Right: "105" - "5" → 100.

Cheat sheet — say this in the interview

1. + with a string involved → concatenation
2. [] → "" → 0   |   {} → "[object Object]" → NaN
3. Bare {} at statement start may be a block
4. NaN === NaN → false; use Number.isNaN / Object.is
5. Prefer ===; == is a coercion maze
6. Only these are falsy: false, 0, -0, 0n, '', null, undefined, NaN
7. typeof null → "object" (legacy)

Wrap-up

Coercion questions in JS interviews are almost always output prediction, not definitions.

Master these four:

How + chooses concat vs math
What [] / {} become as string/number
Why NaN === NaN is false
Why == makes [] == ![] “true”

Everything else is a remix of those rules.

If useful, I can do a follow-up in the same format for this binding, closures, or optional chaining / nullish coalescing output traps.

React Native Local Notifications with Notifee — Foreground, Background, Killed + Progress & Images

Amit Kumar — Sat, 25 Jul 2026 16:24:02 +0000

React Native Local Notifications with Notifee — Foreground, Background, Killed + Progress & Images

You schedule a reminder.

You start a download.

You kill the app.

Users still expect:

the notification to show
a tap to open the right screen
a progress bar / image to look native

@notifee/react-native is the library that makes local notifications feel like first-class Android / iOS work — not a JS toy.

This is the practical write-up for RN 0.86: channels, permissions, all three app states, progress indicators, images, and how this pairs with background tasks.

TL;DR

Job	Notifee API	Survives kill?
Show now	`displayNotification`	N/A (app must be alive to call it)
Fire at a time	`createTriggerNotification` + AlarmManager	✅ Android
Handle press while app open	`onForegroundEvent`	—
Handle press while background / killed	`onBackgroundEvent` in `index.js`	✅
Progress bar (download / sync)	`android.progress`	Update same `id`
Big image	`android.largeIcon` / `bigPicture` / `ios.attachments`	✅
Periodic sync → then notify	BackgroundFetch + `displayNotification`	✅ Android headless

iOS reality check: force-quit kills background fetch. Trigger notifications and tap-to-open still work; silent “do work then notify” after kill needs push.

Mental model: three app states

FOREGROUND  — app visible, JS running
  → notifee.onForegroundEvent(...)
  → you decide: show in-app banner, or suppress OS tray noise

BACKGROUND  — app in Recents, process may still be warm
  → OS shows the notification
  → tap → onBackgroundEvent (or cold start + getInitialNotification)

KILLED      — process gone
  → trigger / AlarmManager can still display
  → tap relaunches JS → onBackgroundEvent / getInitialNotification
  → Headless JS can displayNotification after sync (Android)

Rule of thumb:

Display is OS-owned once scheduled or posted.
Press handling is your job in both foreground and background listeners.
Never put navigation-only logic only in a screen useEffect — killed taps won’t see it.

Install

yarn add @notifee/react-native

# if you also sync in the background:
yarn add react-native-background-fetch @react-native-async-storage/async-storage

cd ios && pod install

Autolinking covers native wiring on modern RN. You still own permissions and channels.

Android permissions that actually matter

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<uses-permission android:name="android.permission.VIBRATE" />
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.WAKE_LOCK" />

Permission	Why you care
`POST_NOTIFICATIONS`	Android 13+ — without it, silence
`SCHEDULE_EXACT_ALARM`	Reminders that fire when the app is dead
`RECEIVE_BOOT_COMPLETED`	Reschedule / BackgroundFetch after reboot
`WAKE_LOCK`	Headless sync work

Channels first (Android)

No channel → your “HIGH importance” notification is a shrug.

import notifee, { AndroidImportance } from '@notifee/react-native';
import { Platform } from 'react-native';

const CHANNELS = {
  reminders: 'reminders',
  downloads: 'downloads',
  sync: 'sync',
};

async function ensureChannels() {
  if (Platform.OS !== 'android') return;

  await notifee.createChannel({
    id: CHANNELS.reminders,
    name: 'Reminders',
    importance: AndroidImportance.HIGH,
    vibration: true,
  });

  await notifee.createChannel({
    id: CHANNELS.downloads,
    name: 'Downloads',
    importance: AndroidImportance.LOW, // progress updates shouldn't scream
    vibration: false,
  });

  await notifee.createChannel({
    id: CHANNELS.sync,
    name: 'Background sync',
    importance: AndroidImportance.DEFAULT,
  });
}

Split channels by user expectation, not by screen. Progress ≠ alarm.

Permissions (iOS + Android 13+)

import notifee, {
  AuthorizationStatus,
  AndroidNotificationSetting,
} from '@notifee/react-native';

export async function requestNotificationPermission() {
  const settings = await notifee.requestPermission();
  return (
    settings.authorizationStatus === AuthorizationStatus.AUTHORIZED ||
    settings.authorizationStatus === AuthorizationStatus.PROVISIONAL
  );
}

export async function ensureExactAlarms() {
  if (Platform.OS !== 'android') return true;
  const settings = await notifee.getNotificationSettings();
  if (settings.android.alarm === AndroidNotificationSetting.ENABLED) {
    return true;
  }
  await notifee.openAlarmPermissionSettings();
  return false;
}

Exact alarms are a product permission, same tier as camera. If disabled, triggers often wait until the user opens the app — looks like a bug.

1) Instant local notification

await ensureChannels();

await notifee.displayNotification({
  id: 'welcome-1',
  title: 'Welcome',
  body: 'Local notification from Notifee',
  data: { screen: 'Home', itemId: '42' },
  android: {
    channelId: CHANNELS.reminders,
    pressAction: { id: 'default' }, // required for tap to open app
    smallIcon: 'ic_launcher', // or your drawable name
  },
  ios: {
    sound: 'default',
  },
});

pressAction: { id: 'default' } is the difference between “pretty banner” and “tappable deep link”.

2) Scheduled reminder (survives kill on Android)

import { TriggerType, AndroidImportance } from '@notifee/react-native';

await notifee.createTriggerNotification(
  {
    id: 'demo-reminder-1min',
    title: 'Reminder',
    body: 'Still fired after you killed the app.',
    data: { screen: 'Details', itemId: 'reminder-1' },
    android: {
      channelId: CHANNELS.reminders,
      pressAction: { id: 'default' },
      importance: AndroidImportance.HIGH,
    },
    ios: { sound: 'default' },
  },
  {
    type: TriggerType.TIMESTAMP,
    timestamp: Date.now() + 60_000,
    alarmManager: { allowWhileIdle: true },
  },
);

Without alarmManager.allowWhileIdle, Doze will eat your “1 minute” demo for lunch.

Cancel:

await notifee.cancelNotification('demo-reminder-1min');
await notifee.cancelAllNotifications();

3) Handle foreground / background / killed

This is the part most tutorials under-explain.

Foreground (app open)

import notifee, { EventType } from '@notifee/react-native';
import { useEffect } from 'react';
import { NavigationService } from './src/services';

useEffect(() => {
  const unsubscribe = notifee.onForegroundEvent(({ type, detail }) => {
    switch (type) {
      case EventType.DELIVERED:
        // optional: in-app toast instead of tray spam
        break;
      case EventType.PRESS:
        handleNotificationPress(detail.notification);
        break;
      case EventType.ACTION_PRESS:
        // custom buttons (Mark done, Reply, …)
        break;
      case EventType.DISMISSED:
        break;
    }
  });

  return unsubscribe;
}, []);

function handleNotificationPress(notification) {
  const data = notification?.data ?? {};
  if (data.screen) {
    NavigationService.navigate(data.screen, { id: data.itemId });
  }
}

Background + killed (must live outside React)

Put this in index.js before AppRegistry — same rule as Headless JS:

import 'react-native-gesture-handler';
import { AppRegistry } from 'react-native';
import notifee, { EventType } from '@notifee/react-native';
import BackgroundFetch from 'react-native-background-fetch';
import App from './App';
import { name as appName } from './app.json';
import { backgroundHeadlessTask } from './src/services/backgroundHeadlessTask';

notifee.onBackgroundEvent(async ({ type, detail }) => {
  const { notification, pressAction } = detail;

  if (type === EventType.PRESS) {
    // Persist intent — NavigationContainer may not be ready yet
    // e.g. AsyncStorage.setItem('@pending_notification', JSON.stringify(notification?.data))
    console.log('[Notifee] background press', notification?.id, pressAction?.id);
  }

  if (type === EventType.ACTION_PRESS && pressAction?.id === 'mark-done') {
    // lightweight work only — no heavy UI
  }
});

BackgroundFetch.registerHeadlessTask(backgroundHeadlessTask);
AppRegistry.registerComponent(appName, () => App);

Cold start from a tap (killed → launch)

When the process was dead, also check what opened the app:

// App.js or root navigator — after NavigationContainer is ready
useEffect(() => {
  (async () => {
    const initial = await notifee.getInitialNotification();
    if (initial?.notification) {
      handleNotificationPress(initial.notification);
    }
  })();
}, []);

Pattern that ships:

onBackgroundEvent  → stash route in AsyncStorage / memory
NavigationContainer onReady → read stash + getInitialNotification → navigate
onForegroundEvent  → navigate immediately

Don’t navigate from onBackgroundEvent into a tree that doesn’t exist yet.

4) Progress indicator (downloads / long work)

Reuse the same notification id. Android replaces the tray entry in place.

const DOWNLOAD_ID = 'download-video-1';

async function startDownloadNotification() {
  await ensureChannels();

  await notifee.displayNotification({
    id: DOWNLOAD_ID,
    title: 'Downloading…',
    body: '0%',
    android: {
      channelId: CHANNELS.downloads,
      onlyAlertOnce: true, // don't buzz on every %
      progress: {
        max: 100,
        current: 0,
        indeterminate: false,
      },
      pressAction: { id: 'default' },
      ongoing: true, // user can't swipe away mid-download (optional)
    },
  });
}

async function updateDownloadProgress(percent) {
  await notifee.displayNotification({
    id: DOWNLOAD_ID,
    title: 'Downloading…',
    body: `${percent}%`,
    android: {
      channelId: CHANNELS.downloads,
      onlyAlertOnce: true,
      progress: {
        max: 100,
        current: percent,
        indeterminate: false,
      },
      pressAction: { id: 'default' },
      ongoing: true,
    },
  });
}

async function finishDownloadNotification() {
  await notifee.displayNotification({
    id: DOWNLOAD_ID,
    title: 'Download complete',
    body: 'Tap to open',
    android: {
      channelId: CHANNELS.downloads,
      progress: undefined, // clear progress bar
      ongoing: false,
      pressAction: { id: 'default' },
    },
  });
}

Indeterminate spinner while you don’t know size yet:

progress: { indeterminate: true }

Throttle updates (e.g. every 250–500 ms or every 1%). Flooding the notification manager from a tight loop is how you invent jank.

5) Images on notifications

Large icon (small circle / square beside text)

android: {
  channelId: CHANNELS.reminders,
  largeIcon: 'https://picsum.photos/256', // remote URL
  // or require / local file URI depending on your asset pipeline
  pressAction: { id: 'default' },
}

Big picture style (expanded image)

import { AndroidStyle } from '@notifee/react-native';

await notifee.displayNotification({
  id: 'promo-1',
  title: 'New drop',
  body: 'Expand to see the cover',
  android: {
    channelId: CHANNELS.reminders,
    pressAction: { id: 'default' },
    largeIcon: 'https://picsum.photos/256',
    style: {
      type: AndroidStyle.BIGPICTURE,
      picture: 'https://picsum.photos/800/400',
    },
  },
  ios: {
    attachments: [
      {
        // local file path or bundled asset URL iOS can read
        url: 'https://picsum.photos/800/400',
        thumbnailHidden: false,
      },
    ],
  },
});

Notes that save hours:

Android can often fetch HTTPS images for largeIcon / bigPicture.
iOS attachments are pickier — prefer local files you already downloaded.
Always provide a smallIcon drawable on Android (white silhouette on transparent). Colored PNGs look broken in the status bar.
Remote images can fail offline — fall back to text-only notification.

Local file example (after you cached an image)

android: {
  channelId: CHANNELS.reminders,
  largeIcon: filePath, // e.g. from RNFS / CacheDir
  style: {
    type: AndroidStyle.BIGPICTURE,
    picture: filePath,
  },
  pressAction: { id: 'default' },
}

6) Action buttons

await notifee.displayNotification({
  id: 'task-1',
  title: 'Stand up',
  body: 'Meeting in 5 minutes',
  android: {
    channelId: CHANNELS.reminders,
    pressAction: { id: 'default' },
    actions: [
      { title: 'Snooze', pressAction: { id: 'snooze' } },
      { title: 'Done', pressAction: { id: 'mark-done' } },
    ],
  },
  ios: {
    categoryId: 'reminder', // register categories via notifee.setNotificationCategories
  },
});

Handle EventType.ACTION_PRESS in both foreground and background listeners. Background handler should stay light (persist flag, cancel notification, schedule snooze) — not mount React.

7) Pair with background tasks

Local notifications + BackgroundFetch is the combo:

Flow	Who wakes you	What you show
Reminder at 3:00 PM	Notifee trigger / AlarmManager	Pre-built notification
Sync every ~15 min	BackgroundFetch / Headless JS	Optional `displayNotification` after work
Download while app open	Your JS loop	Progress notification updates

Keep sync work pure (no navigation imports) so Headless can call it:

// syncJob.js — safe for Headless JS
export async function runSyncJob() {
  const res = await fetch('https://jsonplaceholder.typicode.com/todos/1');
  const payload = await res.json();
  await AsyncStorage.setItem(KEY, JSON.stringify({ at: Date.now(), payload }));
  return payload;
}

Headless → notify (Android, after kill):

// backgroundHeadlessTask.js
import notifee, { AndroidImportance } from '@notifee/react-native';
import BackgroundFetch from 'react-native-background-fetch';
import { runSyncJob } from './syncJob';

export async function backgroundHeadlessTask({ taskId, timeout }) {
  if (timeout) {
    BackgroundFetch.finish(taskId);
    return;
  }

  try {
    const payload = await runSyncJob();

    await notifee.displayNotification({
      id: `sync-${Date.now()}`,
      title: 'Sync complete',
      body: payload?.title ?? 'Background sync finished',
      android: {
        channelId: 'sync',
        pressAction: { id: 'default' },
        importance: AndroidImportance.DEFAULT,
      },
    });
  } finally {
    BackgroundFetch.finish(taskId); // never skip
  }
}

Configure BackgroundFetch with stopOnTerminate: false + enableHeadless: true if you want this after swipe-away. Details: same pattern as our background sync guide.

Wire it on launch

// App.js
useEffect(() => {
  let cancelled = false;

  (async () => {
    await ensureChannels();
    await requestNotificationPermission();
    // BackgroundSyncService.init() if you use fetch
  })();

  const unsub = notifee.onForegroundEvent(({ type, detail }) => {
    if (type === EventType.PRESS) {
      handleNotificationPress(detail.notification);
    }
  });

  return () => {
    cancelled = true;
    unsub();
  };
}, []);

index.js owns onBackgroundEvent + headless registration.

App.js owns channels, permission, foreground events, cold-start getInitialNotification.

Settings lab (demo in 90 seconds)

Ship a Settings screen that can:

request notification permission
open exact-alarm settings
Notify now (plain)
Notify with image
Start fake download (0 → 100% progress)
Schedule reminder in 1 min
Cancel all
show last background sync time

Verification matrix:

Test	Steps	Pass
Foreground press	App open → notify now → tap	Navigates / logs PRESS
Background press	Notify → Home button → tap tray	Opens app + handles data
Killed reminder	Schedule 1 min → swipe away → wait	Notification appears
Killed tap	Tap that notification	Lands on intended screen
Progress	Start download demo	Bar updates, then completes
Image	Notify with big picture	Expanded image shows
Headless notify	Kill app → wait for fetch (or force)	Sync notification appears (Android)

File map

index.js                      # onBackgroundEvent + registerHeadlessTask
App.js                        # channels, permission, onForegroundEvent
src/services/
  NotificationService.js      # schedule / cancel / permission helpers
  BackgroundSyncService.js    # BackgroundFetch configure
  backgroundHeadlessTask.js   # killed-state sync (+ optional notify)
  syncJob.js                  # pure work
  NavigationService.js        # navigate from notification data
AndroidManifest.xml           # POST_NOTIFICATIONS, SCHEDULE_EXACT_ALARM, …

Common footguns

No pressAction → tap does nothing useful on Android.
Background handler only inside a screen → killed taps miss it.
Navigate before NavigationContainer is ready → use a pending-intent stash.
Wrong / missing channel → importance ignored.
Exact alarm denied → “scheduled” means “whenever”.
Progress without onlyAlertOnce → notification sound spam.
Heavy work in onBackgroundEvent → ANRs / truncated execution. Persist + finish.
iOS force-quit + BackgroundFetch → won’t run. Don’t promise it.
Colored smallIcon → looks like a white blob; use a silhouette.
Forgetting BackgroundFetch.finish(taskId) → OS throttles you into invisibility.

Takeaways

Notifee owns local display + triggers — channels and exact alarms are half the product.
Three states, two listeners — onForegroundEvent + onBackgroundEvent, plus getInitialNotification for cold start.
Same id = in-place progress updates — throttle and onlyAlertOnce.
Images — largeIcon / BIGPICTURE on Android; prefer local attachments on iOS.
Background work ≠ reminder scheduling — Fetch/Headless for sync; AlarmManager for “at 3 PM”.
Headless code stays boring — fetch, storage, displayNotification, finish. No React tree.

What’s next (prod)

Deep link map: data.screen → typed routes
Notification categories / reply actions on iOS
Group notifications (android.groupId) for chat-style apps
FCM / APNs for server push; keep Notifee for local display + rich UI
Don’t update progress every byte — batch it

If this helped, drop a ❤️ and tell me what you’re notifying on (downloads, habits, chat, sync). Happy to do a follow-up on Notifee + FCM (remote message → local rich notification) or OEM battery hell.

React Native List Performance — ScrollView, FlatList, SectionList, FlashList

Amit Kumar — Sat, 25 Jul 2026 14:03:14 +0000

Your feed scrolls fine with 20 items.

Ship 2,000 and the UI starts hitching, memory climbs, and “just wrap it in a ScrollView” becomes the bug report.

Lists are where most React Native apps feel slow. Not because RN is slow — because the wrong list API (or the right one, misconfigured) forces the JS thread and the UI thread to do work they shouldn’t.

This is the practical guide: which component to pick, how recycling actually works, and the knobs that matter in production.

TL;DR

Component	Best for	Virtualizes?	Recycles views?	Scale
`ScrollView`	Short, fixed content	❌ mounts all	❌	~tens of items
`FlatList`	Long homogeneous lists	✅	✅ (limited)	hundreds–low thousands
`SectionList`	Grouped lists (A–Z, dates)	✅	✅ (limited)	hundreds–low thousands
`FlashList` (`@shopify/flash-list`)	Long lists that must feel native	✅	✅ (aggressive)	thousands+

Rule of thumb

If every child mounts at once → not a list for large data. Use virtualization.

Prefer FlashList for feeds, catalogs, chats, search results.

Use FlatList / SectionList when you want zero extra deps or need sticky section headers with RN primitives.

Use ScrollView only when the content is small and known.

Mental model: what makes a list “slow”

A scrollable screen can be slow for three different reasons. Optimize the right one.

1) Mount cost
   Too many React trees created up front
   → blank screen, high JS heap, slow first paint

2) Frame cost (scroll jank)
   Too much work per frame while scrolling
   → dropped frames, sticky fingers

3) Memory cost
   Too many native views / images retained
   → OOM, background kills, iOS jetsam

Virtualization attacks (1) and (3).

Recycling + lighter rows attack (2).

Image strategy and memoization finish the job.

ScrollView
  [ item ][ item ][ item ] ... [ item ]   ← all mounted

FlatList / SectionList / FlashList
  viewport + overscan window
  ┌─────────────────────────┐
  │  recycled row cells     │  ← only these exist in native UI
  └─────────────────────────┘
         ↕ bind new data as you scroll

1. ScrollView — when it’s correct (and when it’s a footgun)

ScrollView renders every child immediately. No windowing. No recycling.

Use it when

Settings screens, forms, onboarding steps
Content height is roughly one or two screens
You need nested layout that isn’t a data-driven list
Item count is small and stable (say under 20–30 simple rows)

Don’t use it when

data.map(...) over API results of unknown length
Chat history, product grids, notification feeds
Anything that grows with user data

Anti-pattern

// ❌ Looks fine in demos. Dies in production.
<ScrollView>
  {products.map(item => (
    <ProductCard key={item.id} item={item} />
  ))}
</ScrollView>

Why it hurts:

All ProductCard components mount on open
All images may start loading
Native view hierarchy is huge
Scroll is smooth until it isn’t — then memory and JS GC thrash

Nested ScrollView + list = pain

Avoid:

<ScrollView>
  <Header />
  <FlatList data={items} ... />  {/* nested VirtualizedList warning / broken windowing */}
</ScrollView>

Prefer:

One list with ListHeaderComponent / ListFooterComponent
Or FlashList’s similar header/footer APIs
Or a single scroll surface (don’t nest vertical scrollers)

⚠️ Warning: Nesting a vertical FlatList inside a vertical ScrollView breaks windowing. You’ll often get the “VirtualizedLists should never be nested…” warning — and real jank.

2. FlatList — the default virtualized list

FlatList is a convenience wrapper over VirtualizedList. It only mounts items near the viewport (plus a render window), and reuses some native cells as you scroll.

Minimal solid setup

import { FlatList, Pressable, Text } from 'react-native';
import { memo, useCallback } from 'react';

const Row = memo(function Row({ item, onPress }) {
  return (
    <Pressable onPress={() => onPress(item.id)} style={styles.row}>
      <Text>{item.title}</Text>
    </Pressable>
  );
});

function ProductList({ products, onOpen }) {
  const renderItem = useCallback(
    ({ item }) => <Row item={item} onPress={onOpen} />,
    [onOpen],
  );

  const keyExtractor = useCallback(item => item.id, []);

  return (
    <FlatList
      data={products}
      renderItem={renderItem}
      keyExtractor={keyExtractor}
      initialNumToRender={10}
      maxToRenderPerBatch={10}
      windowSize={5}
      removeClippedSubviews
    />
  );
}

Props that actually matter

Prop	What it does	Guidance
`keyExtractor`	Stable identity for recycling	Use a real id, never `index` alone for mutable lists
`getItemLayout`	Skip measuring if rows are fixed height	Big win when every row is the same height
`initialNumToRender`	First paint batch	Keep close to what’s on screen (~8–12)
`maxToRenderPerBatch`	How many items per JS batch while scrolling	Lower = less JS spike, higher = fewer blanks
`windowSize`	Viewport multiples kept mounted	Default `21` is heavy; try `5`–`10`
`updateCellsBatchingPeriod`	Delay between batches (ms)	Raise slightly if scroll feels choppy from JS
`removeClippedSubviews`	Detach offscreen native views	Often helps Android; verify no missing views
`ListEmptyComponent`	Empty state	Avoid conditional whole-list unmount flicker

Fixed-height turbo: `getItemLayout`

If every row is 72 px tall:

const ITEM_HEIGHT = 72;

const getItemLayout = useCallback(
  (_data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  }),
  [],
);

<FlatList getItemLayout={getItemLayout} /* ... */ />

You skip async layout measurement. Jump-to-index and scroll restoration get cheaper and more accurate.

Variable-height rows? Skip this, or maintain your own offset cache carefully.

The `extraData` trap

FlatList does a shallow compare on data. Selection state living outside data won’t re-render rows unless you tell it:

<FlatList
  data={items}
  extraData={selectedId} // force rows to update when selection changes
  renderItem={({ item }) => (
    <Row item={item} selected={item.id === selectedId} />
  )}
/>

Inline functions and anonymous rows

These recreate every parent render and defeat memo:

// ❌ new function + new component type every render
<FlatList
  renderItem={({ item }) => <Row item={item} onPress={() => go(item.id)} />}
/>

Prefer stable renderItem, memoized row, and stable handlers (pass id, handle in row, or use a context/ref for callbacks).

Images in FlatList rows

Size images explicitly (width / height)
Use a caching library (react-native-fast-image or Expo Image)
Don’t decode huge assets into tiny thumbnails without resizing
Use recycling-aware placeholders so recycled cells don’t flash the wrong image (cancel / version tokens)

3. SectionList — grouped data without fighting FlatList

SectionList is FlatList’s cousin for sectioned data:

[
  { title: 'A', data: [/* contacts */] },
  { title: 'B', data: [/* ... */] },
]

Solid pattern

import { SectionList, Text, View } from 'react-native';
import { memo, useCallback } from 'react';

const ContactRow = memo(function ContactRow({ item }) {
  return (
    <View style={styles.row}>
      <Text>{item.name}</Text>
    </View>
  );
});

function ContactsScreen({ sections }) {
  const renderItem = useCallback(
    ({ item }) => <ContactRow item={item} />,
    [],
  );

  const renderSectionHeader = useCallback(
    ({ section: { title } }) => (
      <View style={styles.header}>
        <Text style={styles.headerText}>{title}</Text>
      </View>
    ),
    [],
  );

  return (
    <SectionList
      sections={sections}
      keyExtractor={item => item.id}
      renderItem={renderItem}
      renderSectionHeader={renderSectionHeader}
      stickySectionHeadersEnabled
      initialNumToRender={12}
      windowSize={7}
      removeClippedSubviews
    />
  );
}

SectionList gotchas

Same optimization rules as FlatList — memo rows, stable keys, tune window props.
Sticky headers have platform quirks — test Android carefully.
Don’t rebuild sections every render with a fresh array/object graph if data didn’t change — that invalidates list reconciliation.
Mixed item types (header-like rows inside data) make recycling harder — keep headers as real section headers.
For very large sectioned datasets (e.g. 10k contacts), consider FlashList + manual sticky headers or a specialized contacts UI.

When SectionList is the wrong tool

Fake sections by stuffing headers into a flat array and branching in renderItem — works, but you lose sticky header semantics and complicate getItemLayout
Nested SectionLists
Tiny static grouped content — a ScrollView with plain Views is simpler

4. FlashList — when FlatList’s recycling isn’t enough

@shopify/flash-list is built for blank-free, high-FPS lists. It recycles views more aggressively and asks you to help with item type and size estimates.

Install

yarn add @shopify/flash-list

# iOS
cd ios && pod install

Baseline migration from FlatList

import { FlashList } from '@shopify/flash-list';
import { memo, useCallback } from 'react';
import { Text, View } from 'react-native';

const Row = memo(function Row({ item }) {
  return (
    <View style={styles.row}>
      <Text>{item.title}</Text>
    </View>
  );
});

function Feed({ items }) {
  const renderItem = useCallback(({ item }) => <Row item={item} />, []);

  return (
    <FlashList
      data={items}
      renderItem={renderItem}
      keyExtractor={item => item.id}
      estimatedItemSize={72} // critical in v1; confirm for your version
    />
  );
}

💡 Version note: FlashList API evolved (v1 → v2). Always confirm current required props (estimatedItemSize vs newer sizing APIs) for the version you install. The ideas stay the same: estimate sizes, separate item types, keep rows pure.

Why FlashList feels faster

FlatList	FlashList
Conservative recycling	Cell recycling tuned like native `RecyclerView` / `UICollectionView`
More blank cells under fast fling	Fewer blanks when configured well
Measurement churn on variable heights	Size estimates + recycling reduce thrash
Easy defaults, easier to misuse	Slightly more setup, better ceiling

Item types — don’t skip this

If row layouts differ (text-only vs image vs ad), tell FlashList so it recycles like-with-like:

<FlashList
  data={items}
  renderItem={renderItem}
  estimatedItemSize={80}
  getItemType={item => item.kind} // 'text' | 'media' | 'ad'
/>

Without this, a tall media cell may be reused for a short text row → layout jumps / wasted work.

Headers, footers, empty states

<FlashList
  data={items}
  ListHeaderComponent={Header}
  ListFooterComponent={isLoading ? FooterSpinner : null}
  ListEmptyComponent={Empty}
  renderItem={renderItem}
  estimatedItemSize={72}
/>

Grid with FlashList

<FlashList
  data={products}
  numColumns={2}
  renderItem={renderItem}
  estimatedItemSize={220}
/>

Keep column cell heights predictable. Wildly different cell heights in a grid are where you earn your performance scars.

FlashList as a SectionList alternative

FlashList doesn’t replace SectionList 1:1. Common approach:

Flatten sections into one array with { type: 'header' | 'row', ... }
getItemType returns 'header' vs 'row'
Implement sticky headers via FlashList sticky props / a custom overlay if you need them

More work than SectionList, but worth it at large scale.

Optimization checklist (all virtualized lists)

Copy/paste PR checklist

Data & identity

[ ] Stable keyExtractor / keys from server ids
[ ] Avoid using array index as key when items reorder/insert
[ ] Don’t clone data / sections every render
[ ] Paginate on the server (limit / cursor) — UI virtualization ≠ fetching the world

Row components

[ ] memo row components
[ ] Cheap rows: no heavy hooks work per row on every parent render
[ ] Avoid anonymous renderItem that closes over changing values unnecessarily
[ ] Move press handlers carefully (stable callback or row-local)
[ ] Don’t put the entire screen state into every row via props

Layout

[ ] Prefer fixed heights + getItemLayout (FlatList / SectionList)
[ ] Provide accurate size estimates (FlashList)
[ ] Separate heterogeneous layouts with item types (FlashList)
[ ] No nested VirtualizedLists in the same orientation
[ ] Use ListHeaderComponent instead of ScrollView wrapping a list

JS thread hygiene

[ ] Keep renderItem pure and fast
[ ] Debounce filtering/sorting; do heavy work off the critical path
[ ] Prefer InteractionManager.runAfterInteractions for non-urgent work after push
[ ] Profile with React DevTools + RN Perf monitor before “optimizing” randomly

Images & media

[ ] Explicit dimensions
[ ] Cache and prioritize visible URLs
[ ] Blurhash / LQIP placeholders beat layout jumps
[ ] Recycle-safe binding (don’t show previous item’s avatar)

Tuning knobs (FlatList / SectionList)

Start conservative, measure, then adjust:

initialNumToRender={8}
maxToRenderPerBatch={8}
windowSize={5}
updateCellsBatchingPeriod={50}
removeClippedSubviews

See blank areas while flinging → increase windowSize / batch size
See JS thread spikes → decrease them and lighten rows

Choosing the right tool — decision flow

Is the content short and fixed?
  YES → ScrollView (or plain View)
  NO  ↓

Do you need sticky section headers with minimal setup?
  YES → SectionList (or FlashList + sticky strategy if huge)
  NO  ↓

Is the list long / fling-heavy / heterogeneous / business-critical FPS?
  YES → FlashList
  NO  → FlatList is fine

Practical defaults for common screens

Screen	Recommendation
Settings	`ScrollView`
Inbox / notifications	`FlashList` (or tuned `FlatList`)
Chat messages	`FlashList` inverted / maintain visible content
Product catalog grid	`FlashList` + `numColumns`
Contacts A–Z	`SectionList` until scale hurts, then flatten + FlashList
Horizontal carousels	`FlatList` / `FlashList` horizontal; don’t nest badly with parent vertical list
Search results	Virtualized list + pagination + cancel in-flight requests

Nested lists without shooting yourself

Horizontal list inside vertical list is common (Netflix-style rows).

function ShelfRow({ shelf }) {
  return (
    <View>
      <Text>{shelf.title}</Text>
      <FlatList
        horizontal
        data={shelf.items}
        keyExtractor={item => item.id}
        renderItem={renderShelfItem}
        showsHorizontalScrollIndicator={false}
        initialNumToRender={4}
        windowSize={3}
      />
    </View>
  );
}

function Home({ shelves }) {
  return (
    <FlashList
      data={shelves}
      keyExtractor={s => s.id}
      renderItem={({ item }) => <ShelfRow shelf={item} />}
      estimatedItemSize={220}
    />
  );
}

Rules:

Different orientations → OK
Same orientation nested virtualization → almost always wrong
Memoize ShelfRow
Don’t give every horizontal list a huge windowSize

Profiling: prove the win

Guessing is how you ship React.memo theater.

Enable perf monitor in the dev menu — watch JS / UI FPS while flinging
Why did you render? / React DevTools — catch rows re-rendering for no reason
FlashList recycling warnings — fix estimated sizes / item types
Xcode Instruments / Android Studio Profiler — native memory & overdraw
Compare:
- time to first contentful list paint
- FPS during fast fling
- memory after scrolling to end and back

A real win looks like: same features, higher floor FPS, lower memory, fewer blank cells.

Production patterns that pay rent

Pagination + list

const onEndReached = useCallback(() => {
  if (hasMore && !loadingMore) {
    fetchNextPage();
  }
}, [hasMore, loadingMore, fetchNextPage]);

<FlashList
  data={items}
  onEndReached={onEndReached}
  onEndReachedThreshold={0.5}
  ListFooterComponent={loadingMore ? <Spinner /> : null}
  estimatedItemSize={72}
  renderItem={renderItem}
/>

💡 Tip: Guard onEndReached — it can fire more than you think.

Optimistic updates & sparse changes

Update by id with a stable array strategy (e.g. React Query / normalized store)
Avoid re-creating every row object if nothing changed
For selection, store selectedId once; derive UI in the row; use extraData on FlatList

Avoid layout thrash in rows

// ❌ measuring & setting state in every row on mount
useEffect(() => {
  rowRef.current?.measureInWindow(/* ... */);
}, []);

Measure once at list level, or use fixed layout. Per-row measurement is how “beautiful” lists become jank machines.

Don’t animate everything

Enter animations on every recycled row re-bind look cool once and expensive forever. Animate mounts sparingly; prefer list-level transitions.

Quick “stop doing this” list

ScrollView + .map for feeds
Index keys on dynamic data
Anonymous renderItem + inline arrow props breaking memo
Nested vertical FlatList inside ScrollView
Fetching 10,000 rows “because FlatList virtualizes” (network + JS memory still pay)
Heavy Context values changing every keystroke while a list is mounted
Ignoring estimatedItemSize / item types in FlashList
Complex chart/video in every offscreen row with a huge window

Cheat sheet

ScrollView     → small, static, non-virtualized content
FlatList       → default virtualized list, tune window props
SectionList    → virtualized + sticky sections, same tuning mindset
FlashList      → best FPS / recycling for real feeds at scale

Always
  - stable keys
  - memoized rows
  - light renderItem
  - pagination
  - no nested same-orientation VirtualizedLists

Measure
  - blank cells → increase window / fix sizes / use FlashList
  - JS stutters → shrink batches, lighten rows, memoize
  - memory → smaller window, recycle images, fewer heavy subtrees

Closing

Virtualization is not a silver bullet — it’s a contract.

You promise: stable identity, predictable row layout, cheap renders.

The list promises: only a window of items exists at a time.

Break the contract with ScrollView for unbounded data, unstable keys, or bloated rows, and no windowSize tweak will save you.

Start with the simplest component that fits the screen. When the list becomes a product surface people fling through all day — graduate to FlashList, measure FPS, and keep rows boring.

Boring rows scroll fast.

React Native Background Sync That Survives App Kill (Plus Local Reminders)

Amit Kumar — Sat, 25 Jul 2026 13:55:51 +0000

React Native Background Sync That Survives App Kill (Plus Local Reminders)

You swipe the app away.

Five minutes later you still expect:

data to sync in the background
that reminder to fire on time

React Native doesn’t give you one magic API for that. The OS does — and Android / iOS play by different rules.

We shipped both in a RN 0.86 (New Arch) app. This is the practical write-up: what we used, how we wired it, and how to prove it works after the app is dead.

TL;DR

Job	Library	Survives kill on Android?
Sync every ~15+ min	`react-native-background-fetch`	✅ Headless JS
Fire a reminder at a time	`@notifee/react-native`	✅ AlarmManager
Remember last sync	AsyncStorage	✅

iOS reality check: force-quit = background fetch stops. No workaround without silent push. We went Android-first.

Two problems, two tools

People mash these together. Don’t.

Background sync → “wake me when you can, do short work” → JobScheduler / BGAppRefresh → react-native-background-fetch
Reminders → “wake me at 3:00 PM sharp” → AlarmManager → Notifee timestamp triggers

If you try to schedule a 1‑minute reminder with Background Fetch… you’ll have a bad day.

Mental model

App open
  → init Notifee (channel + permissions)
  → configure BackgroundFetch

App killed (Android)
  → OS starts Headless JS
  → runSyncJob() → AsyncStorage
  → BackgroundFetch.finish(taskId)   ← never skip this

Reminder
  → Notifee TIMESTAMP + alarmManager.allowWhileIdle
  → notification shows even if app process is gone

Rule of thumb: headless code must be boring. No navigation. No React tree. No “just import the store that mounts the app”.

Install

yarn add react-native-background-fetch \
  @notifee/react-native \
  @react-native-async-storage/async-storage

cd ios && pod install

Android permissions that actually matter

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="android.permission.VIBRATE" />
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />

Quick why:

RECEIVE_BOOT_COMPLETED → startOnBoot: true isn’t cosplay
POST_NOTIFICATIONS → Android 13+ will ghost you without it
SCHEDULE_EXACT_ALARM → reminders that fire when the app is dead

Autolinking handles the rest. We didn’t touch MainApplication.

iOS (minimal, honest)

Info.plist:

UIBackgroundModes: fetch, processing
BGTaskSchedulerPermittedIdentifiers: com.transistorsoft.fetch

AppDelegate.swift:

import TSBackgroundFetch

TSBackgroundFetch.sharedInstance().didFinishLaunching()

That’s enough for backgrounded iOS.

Force-quit? You’re done. Apple said so.

Keep the sync job pure

This is the whole trick.

// syncJob.js — safe for Headless JS
export async function runSyncJob() {
  const startedAt = new Date().toISOString();
  try {
    const res = await fetch('https://jsonplaceholder.typicode.com/todos/1');
    const payload = await res.json();
    const result = { lastSyncAt: startedAt, lastPayload: payload, lastError: null, ok: true };
    await AsyncStorage.setItem(KEY, JSON.stringify(result));
    return result;
  } catch (e) {
    const result = { lastSyncAt: startedAt, lastPayload: null, lastError: e.message, ok: false };
    await AsyncStorage.setItem(KEY, JSON.stringify(result));
    return result;
  }
}

Same function for:

“Sync now” button
BackgroundFetch while app is alive
Headless wake after kill

One job. Three doors.

Configure BackgroundFetch for “app is dead”

await BackgroundFetch.configure(
  {
    minimumFetchInterval: 15,
    stopOnTerminate: false, // Android: keep going after kill
    startOnBoot: true,
    enableHeadless: true,   // Android Headless JS
    requiredNetworkType: BackgroundFetch.NETWORK_TYPE_ANY,
  },
  async (taskId) => {
    try {
      await runSyncJob();
    } finally {
      BackgroundFetch.finish(taskId);
    }
  },
  async (taskId) => {
    // timeout — still finish
    BackgroundFetch.finish(taskId);
  },
);

If you forget finish(), Android will quietly throttle you into oblivion.

Register Headless in `index.js` (order matters)

import BackgroundFetch from 'react-native-background-fetch';
import { backgroundHeadlessTask } from './src/services/backgroundHeadlessTask';

BackgroundFetch.registerHeadlessTask(backgroundHeadlessTask);
AppRegistry.registerComponent(appName, () => App);

Headless handler:

export async function backgroundHeadlessTask({ taskId, timeout }) {
  if (timeout) {
    BackgroundFetch.finish(taskId);
    return;
  }
  try {
    await runSyncJob();
  } finally {
    BackgroundFetch.finish(taskId);
  }
}

Reminders: Notifee + AlarmManager

await notifee.createTriggerNotification(
  {
    id: 'demo-reminder-1min',
    title: 'Reminder',
    body: 'Still fired after you killed the app.',
    android: {
      channelId: 'reminders',
      pressAction: { id: 'default' },
      importance: AndroidImportance.HIGH,
    },
  },
  {
    type: TriggerType.TIMESTAMP,
    timestamp: Date.now() + 60_000,
    alarmManager: { allowWhileIdle: true },
  },
);

Also check exact-alarm permission on Android 12+:

const settings = await notifee.getNotificationSettings();
if (settings.android.alarm === AndroidNotificationSetting.DISABLED) {
  await notifee.openAlarmPermissionSettings();
}

No AlarmManager → notification often waits until the user opens the app. Super confusing. Super common.

Wire it on launch

useEffect(() => {
  (async () => {
    await NotificationService.init();
    await BackgroundSyncService.init();
  })();
}, []);

Give yourself a Settings lab

Don’t wait 15 minutes staring at Logcat.

We put this in Settings:

fetch status
last sync timestamp / error
exact-alarm allowed?
Run sync now
Schedule reminder in 1 min
Cancel reminders
open exact-alarm settings

If you can’t demo the feature in 90 seconds, you can’t ship it.

How to verify on a real Android device

1. Sync while alive

Settings → Run sync now → last sync updates.

2. Reminder after kill

Schedule 1‑min reminder → swipe app from Recents → wait → notification shows.

3. Headless sync

Kill app → wait for OS wake (15+ min; OEMs vary) → reopen → lastSyncAt moved without a tap.

OEM drama: Xiaomi / Oppo / some Samsung builds love murdering background work. Battery optimization + autostart settings are part of the product story, not “user error”.

File map

index.js                 # registerHeadlessTask
App.js                   # init services
src/services/
  syncJob.js
  BackgroundSyncService.js
  NotificationService.js
  backgroundHeadlessTask.js
src/screens/Settings/    # verification UI
AndroidManifest.xml
Info.plist + AppDelegate.swift

Takeaways

Sync ≠ reminders — different native systems.
Headless code stays pure — no UI imports.
Always finish(taskId) — including timeouts.
Persist results — otherwise you can’t prove headless ran.
Exact alarms are a permission — treat them like camera access.
Don’t lie about iOS — force-quit ends the story without push.

What’s next (if you go to prod)

Real API + auth + retry/backoff
Offline queue
Silent push for iOS kill survival
Don’t promise exact 15‑minute sync — the OS owns the clock

If this helped, drop a ❤️ and tell me what you’re syncing in the background (chat? habits? crypto prices you definitely shouldn’t sync every 15 minutes?). Happy to dig into OEM battery hell in a follow-up.

Types of Functions in JavaScript — Differences Explained with Examples

Amit Kumar — Fri, 24 Jul 2026 17:17:13 +0000

Types of Functions in JavaScript — Differences Explained

JavaScript has several ways to define functions. They look similar, but they differ in hoisting, this, arguments, and whether they can be used with new.

If you’ve ever wondered why fn() works before its line for one function but throws for another — or why an arrow “method” prints undefined — this guide is for you.

Table of contents

Function Declaration
Function Expression
Arrow Function
Object Method
Constructor Function & Class
Generator Function
Async Function
IIFE (Immediately Invoked Function Expression)
Quick Comparison Table
Key Differences
When to Use What
Interview Gotchas

1. Function Declaration

function greet(name) {
  return `Hello, ${name}`;
}

greet("Amit"); // "Hello, Amit"

Key traits

Fully hoisted — you can call it before its definition
Has its own this (depends on how it’s called)
Has arguments
Can be used with new, but prefer class / dedicated constructors — don’t treat that as the normal pattern
Best for named, reusable top-level functions

sayHi(); // works — hoisted

function sayHi() {
  console.log("Hi");
}

2. Function Expression

const greet = function (name) {
  return `Hello, ${name}`;
};

Named function expression (useful for stack traces / recursion):

const factorial = function fact(n) {
  if (n <= 1) return 1;
  return n * fact(n - 1);
};

Key traits

The variable may be hoisted (var), but the function value is not available until the assignment runs
With const / let, accessing before the line is a TDZ ReferenceError
With var, calling before assignment is usually a TypeError (undefined is not a function)
Same this / arguments behavior as a declaration
Can be anonymous or named
Common when assigning functions to variables or passing as callbacks

// var → TypeError
sayHiVar(); // TypeError: sayHiVar is not a function
var sayHiVar = function () {
  console.log("Hi");
};

// const / let → ReferenceError (TDZ)
sayHiConst(); // ReferenceError: Cannot access 'sayHiConst' before initialization
const sayHiConst = function () {
  console.log("Hi");
};

3. Arrow Function

const greet = (name) => `Hello, ${name}`;

const add = (a, b) => {
  return a + b;
};

Key traits

Not hoisted
No own this — uses lexical this from the surrounding scope
No arguments object (use rest params: (...args) => {})
Cannot be used as a constructor (new throws)
No prototype
Perfect for callbacks, map / filter / reduce, and preserving outer this

Lexical `this` example

const user = {
  name: "Amit",
  regular() {
    setTimeout(function () {
      console.log(this.name); // undefined (or global) — lost this
    }, 0);
  },
  arrow() {
    setTimeout(() => {
      console.log(this.name); // "Amit" — lexical this
    }, 0);
  },
};

user.regular();
user.arrow();

Rest instead of `arguments`

const sum = (...nums) => nums.reduce((a, b) => a + b, 0);
sum(1, 2, 3); // 6

Guess the output?

const user = {
  name: "Amit",
  greet: () => this.name,
};
console.log(user.greet());

Answer: undefined in a typical module / strict runtime — the arrow does not take this from user.

4. Object Method

const user = {
  name: "Amit",
  greet() {
    return `Hello, ${this.name}`;
  },
};

user.greet(); // "Hello, Amit"

Key traits

this is usually the object that owns the method (when called as obj.method())
Shorthand method syntax is preferred over greet: function () {}
Avoid arrow functions as object methods if you need this to be the object

const user = {
  name: "Amit",
  greet: () => `Hello, ${this.name}`, // wrong — lexical this
};

user.greet(); // "Hello, undefined" (in modules / strict mode)

5. Constructor Function & Class

Constructor function

function Person(name) {
  this.name = name;
}

Person.prototype.greet = function () {
  return `Hello, ${this.name}`;
};

const p = new Person("Amit");
p.greet(); // "Hello, Amit"

Class (modern syntax)

class Person {
  constructor(name) {
    this.name = name;
  }

  greet() {
    return `Hello, ${this.name}`;
  }
}

const p = new Person("Amit");

Key traits

Meant to be called with new
Creates instance objects
Methods usually live on the prototype (shared across instances)
Prefer class in modern code; behavior is still prototype-based under the hood
Classes are hoisted into the TDZ — you cannot use them before the class line (ReferenceError)

const user = new User(); // ReferenceError
class User {}

React / class-fields note

class Button {
  label = "Save";

  // Per-instance arrow — lexical this (handy for callbacks)
  onPress = () => this.label;

  // Prototype method — this depends on call site
  handle() {
    return this.label;
  }
}

6. Generator Function

function* idGenerator() {
  let id = 1;
  while (true) {
    yield id++;
  }
}

const gen = idGenerator();
gen.next().value; // 1
gen.next().value; // 2
gen.next().value; // 3

Key traits

Defined with function*
Can pause and resume with yield
Returns an iterator
Useful for lazy sequences, custom iteration, infinite lists

Also works as a generator method:

const obj = {
  *range(n) {
    for (let i = 1; i <= n; i++) yield i;
  },
};

[...obj.range(3)]; // [1, 2, 3]

There are also async generators (async function*) used with for await...of — same pause/resume idea for async streams.

7. Async Function

async function loadUser() {
  const res = await fetch("/api/user");
  return res.json();
}

// async arrow
const loadUserArrow = async () => {
  const res = await fetch("/api/user");
  return res.json();
};

Key traits

Always returns a Promise
Lets you write async code with await in a sync-looking style
Thrown errors become rejected promises (use try/catch or .catch())
await on a non-Promise still works — the value is wrapped

async function example() {
  return 42;
}

example(); // Promise that resolves to 42

8. IIFE (Immediately Invoked Function Expression)

Also called a self-calling or self-invoking function.

An IIFE is defined and executed in the same step — you don’t call it later by name.

(function () {
  console.log("I run immediately");
})();

// Arrow version
(() => {
  console.log("I also run immediately");
})();

Why wrap in parentheses?

Without wrapping, JS treats function as a declaration, and declarations can’t be invoked that way as a statement.

// Valid — force an expression, then invoke
(function () {
  console.log("works");
})();

Other (less common) IIFE forms

(function () {
  console.log("form 1");
})();

(function () {
  console.log("form 2");
}());

!function () {
  console.log("form 3");
}();

Prefer the (function () { ... })() or (() => { ... })() style in real code.

Pass arguments

(function (name) {
  console.log(`Hello, ${name}`);
})("Amit");

Create private scope

(function () {
  const secret = "hidden";
  // secret is not accessible outside
})();

// console.log(secret); // ReferenceError

Return a value / module-like API

const counter = (function () {
  let count = 0;

  return {
    increment() {
      count++;
      return count;
    },
    getCount() {
      return count;
    },
  };
})();

counter.increment(); // 1
counter.getCount(); // 1
// count itself is private

Async IIFE

Useful for top-level async setup when you can’t use top-level await:

(async function () {
  const res = await fetch("/api/user");
  console.log(await res.json());
})();

Key traits

Defined and executed immediately
Creates a private scope
Can take parameters and return values
Common before ES modules; still used in bundles, polyfills, one-off setup, and interviews

Guess the output?

const result = (function () {
  var x = 10;
  return x;
})();

console.log(result);
// console.log(x);

Answer: result is 10. Logging x throws ReferenceError — x stayed private inside the IIFE.

9. Quick Comparison Table

Feature	Declaration	Expression	Arrow	Method	Constructor / Class	Generator	Async
Hoisting	Yes (full)	No (assignment); `var`/`const` differ	No	No	Function ctor: yes · Class: TDZ	Like its form	Like its form
Own `this`	Yes	Yes	No (lexical)	Yes (usually)	Yes (instance)	Yes	Yes (unless arrow)
`arguments`	Yes	Yes	No	Yes	Yes	Yes	Yes (unless arrow)
Can use `new`	Possible*	Possible*	No	Not intended	Yes	Avoid	No
Returns	Any	Any	Any	Any	Instance	Iterator	Promise
Best for	Named utils	Assigned fns	Callbacks	Object behavior	OOP / instances	Lazy iteration	Async / await

* Technically allowed for classic functions, but prefer class for constructors.

10. Key Differences

Declaration vs Expression

Point	Function Declaration	Function Expression
Syntax	`function fn() {}`	`const fn = function () {}`
Before definition	Callable	`var` → `TypeError` · `const`/`let` → `ReferenceError`
Name required	Yes	Optional
Use case	Top-level helpers	Assign to vars, pass as values

hello(); // works
function hello() {
  console.log("declaration");
}

bye(); // ReferenceError with const
const bye = function () {
  console.log("expression");
};

Arrow Function vs Normal Function

“Normal function” = declaration or classic expression.

Feature	Normal Function	Arrow Function
Own `this`	Yes — depends on how it’s called	No — lexical
`arguments`	Yes	No — use `...args`
Can use `new`	Yes	No (`TypeError`)
`prototype`	Yes	No
Implicit return	No	Yes — `() => value`
Best for	Methods, constructors, own `this`	Callbacks, keep outer `this`

`this` binding

const user = {
  name: "Amit",
  normal: function () {
    console.log(this.name); // "Amit"
  },
  arrow: () => {
    console.log(this.name); // undefined (not the object)
  },
};

user.normal();
user.arrow();

Constructor usage

function Person(name) {
  this.name = name;
}
new Person("Amit"); // OK

const PersonArrow = (name) => {
  this.name = name;
};
new PersonArrow("Amit"); // TypeError

When to use which

Normal function → object methods, constructors, handlers where you need call-site this
Arrow function → callbacks (map, filter, setTimeout) where you want the parent’s this

Method vs Arrow as Method

Point	Method `greet() {}`	Arrow property `greet: () => {}`
`this`	Owning object (usual call)	Outer / lexical `this`
Recommended for objects?	Yes	Usually no

const user = {
  name: "Amit",
  method() {
    return this.name; // "Amit"
  },
  arrow: () => this.name, // wrong for object method
};

Constructor Function vs Class

Point	Constructor Function	Class
Syntax	`function Person() {}`	`class Person {}`
Style	Older / prototype style	Modern syntactic sugar
Before definition	Function is hoisted	TDZ — `ReferenceError`
Internals	Prototype model	Same prototype model

function PersonFn(name) {
  this.name = name;
}

class PersonClass {
  constructor(name) {
    this.name = name;
  }
}

Function Expression vs IIFE

Point	Function Expression	IIFE
When it runs	When you call it later	Immediately
Stored in variable?	Usually yes	Often not needed
Purpose	Reuse later	One-time run + private scope

const greet = function (name) {
  console.log(name);
};
greet("Amit");

(function (name) {
  console.log(name);
})("Amit");

An IIFE can be an arrow:

(() => {
  console.log("arrow IIFE");
})();

Normal vs Async vs Generator (quick)

Point	Normal	Async	Generator
Keyword	`function`	`async function`	`function*`
Returns	Any value	Always a Promise	An iterator
Special	—	`await`	`yield` / `.next()`

function syncFn() {
  return 10; // number
}

async function asyncFn() {
  return 10; // Promise → 10
}

function* gen() {
  yield 1;
  yield 2;
}

11. When to Use What

Need	Prefer
Named reusable helper	Function declaration
Pass / assign a function	Function expression or arrow
Callback / array method / keep outer `this`	Arrow function
Behavior on an object	Object method / class method
Create many similar objects	`class`
Pause / resume / lazy values	Generator
Fetch / timers / promises	Async function
Run once + private variables	IIFE (or an ES module)

12. Interview Gotchas

1. Hoisting: declaration vs expression

fnDecl(); // works

function fnDecl() {}

fnVar(); // TypeError
var fnVar = function () {};

fnConst(); // ReferenceError (TDZ)
const fnConst = function () {};

2. Arrow functions don’t bind their own `this`

const button = {
  id: "save",
  bindRegular() {
    setTimeout(function () {
      console.log(this.id); // undefined — lost this
    }, 0);
  },
  bindArrow() {
    setTimeout(() => {
      console.log(this.id); // "save" — lexical this
    }, 0);
  },
};

In the browser, a regular addEventListener callback gets the element as this; an arrow does not.

3. Losing `this` when extracting a method

const user = {
  name: "Amit",
  greet() {
    return this.name;
  },
};

const fn = user.greet;
fn(); // undefined (this is lost)

fn.call(user); // "Amit"

4. Async always returns a Promise

async function getValue() {
  return 10;
}

getValue().then(console.log); // 10

5. Don’t use arrow functions as constructors

const Person = (name) => {
  this.name = name;
};

new Person("Amit"); // TypeError

6. IIFE creates private scope

(function () {
  var x = 10;
})();

// console.log(x); // ReferenceError

Practical Rule of Thumb

Declaration → top-level named functions
Arrow → callbacks and short logic where lexical this helps
Method / class → object behavior and OOP
Async → anything that waits on promises
Generator → when you need yield or custom iterators
IIFE → run once immediately with private scope (or just use a module)

Master these differences and you can explain not just how to write a function, but why one form is better than another — in interviews and in real projects.

If this helped, leave a ❤️ and comment which function type still confuses you the most.

Can You Guess These 50 JavaScript Outputs? (React Native Interview Edition)

Amit Kumar — Fri, 24 Jul 2026 17:15:34 +0000

Can You Guess These 50 JavaScript Outputs? (React Native Interview Edition)

React Native interviews rarely ask you to recite API docs.

They drop a short snippet and ask:

Guess the output?

Same language. Same traps. Whether the code runs in a browser, Metro, or Hermes — JavaScript rules don’t change.

These 50 challenges cover what interviewers actually probe:

hoisting · scope · closures · this · coercion · references · prototypes · Promises · async/await · event loop

How to play (same as the Instagram / LinkedIn challenges)

Read the snippet.
Pick A / B / C / D before you scroll.
Open 👀 Reveal answer only after you commit.
Say why out loud — interviewers care about the explanation as much as the letter.

Challenge rule: Do not run the code until you have made your prediction.

React Native note: Timers, Promises, closures, and shared object references show up as real bugs — stale state, double renders, wrong list keys, race conditions. The UI layer does not rewrite the language.

🔥 Warm-up: coercion, scope, and hoisting

⚡ Challenge 1 — Guess the output?

console.log(1 + "2" + 3 - 4);

A. 119

B. 1234

C. 1199

D. NaN

👀 Reveal answer
A. 119

1 + "2" + 3 → "123" (string concat).

"123" - 4 coerces to number → 119.

⚡ Challenge 2 — Guess the output?

console.log(score);
var score = 10;

A. 10

B. undefined

C. ReferenceError

D. null

👀 Reveal answer
B. undefined

var is hoisted and initialized as undefined. Only the assignment stays in place.

⚡ Challenge 3 — Guess the output?

console.log(score);
let score = 10;

A. 10

B. undefined

C. ReferenceError

D. null

👀 Reveal answer
C. ReferenceError

let is in the Temporal Dead Zone until its line runs. Classic RN interview follow-up after Challenge 2.

⚡ Challenge 4 — Guess the output?

console.log(add(2, 3));
function add(a, b) {
  return a + b;
}

A. 5

B. undefined

C. TypeError

D. ReferenceError

👀 Reveal answer
A. 5

Function declarations are hoisted with their full body.

⚡ Challenge 5 — Guess the output?

console.log(add(2, 3));
var add = function (a, b) {
  return a + b;
};

A. 5

B. undefined

C. TypeError

D. ReferenceError

👀 Reveal answer
C. TypeError

add is hoisted as undefined, then you call undefined(...).

⚡ Challenge 6 — Guess the output?

console.log(name);
const name = "Amit";

A. "Amit"

B. undefined

C. ReferenceError

D. TypeError

👀 Reveal answer
C. ReferenceError

Same TDZ rules as let.

⚡ Challenge 7 — Guess the output?

var a = 1;
if (true) {
  var a = 2;
  let b = 3;
}
console.log(a, typeof b);

A. 1 "undefined"

B. 2 "undefined"

C. 2 "number"

D. Error

👀 Reveal answer
B. 2 "undefined"

var is function-scoped (rewrites outer a).

b is block-scoped; typeof safely returns "undefined" for an undeclared identifier.

🔁 Closures & loops (stale-timer territory)

⚡ Challenge 8 — Guess the output?

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}

A. 0 1 2

B. 3 3 3

C. 0 0 0

D. Error

👀 Reveal answer
B. 3 3 3

One shared var i. Loop finishes (i === 3) before timers fire.

Same class of bug as firing three API calls from a loop with the wrong index.

⚡ Challenge 9 — Guess the output?

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}

A. 0 1 2

B. 3 3 3

C. 0 0 0

D. Error

👀 Reveal answer
A. 0 1 2

let creates a new binding per iteration.

⚡ Challenge 10 — Guess the output?

function makeCounter() {
  let count = 0;
  return () => ++count;
}
const counter = makeCounter();
console.log(counter(), counter());

A. 1 1

B. 0 1

C. 1 2

D. Error

👀 Reveal answer
C. 1 2

The returned function closes over the same count. Think custom hooks / factory helpers.

⚡ Challenge 11 — Guess the output?

function createCounter() {
  let count = 0;
  return () => ++count;
}
const a = createCounter();
const b = createCounter();
console.log(a(), a(), b());

A. 1 2 1

B. 1 2 3

C. 1 1 1

D. 0 1 0

👀 Reveal answer
A. 1 2 1

Each factory call gets its own lexical environment.

⚡ Challenge 12 — Guess the output?

let x = 5;
console.log(x++);
console.log(++x);
console.log(x);

A. 5, 6, 6

B. 5, 7, 7

C. 6, 6, 7

D. 6, 7, 7

👀 Reveal answer
B. 5, 7, 7

x++ returns then increments (5, now 6).

++x increments then returns (7).

Final x is 7.

🎯 `this` binding (methods, bind, arrows)

⚡ Challenge 13 — Guess the output?

const user = {
  name: "Amit",
  getName() {
    return this.name;
  },
};
console.log(user.getName());

A. "Amit"

B. undefined

C. window.name

D. Error

👀 Reveal answer
A. "Amit"

Call site is user.getName() → this is user.

⚡ Challenge 14 — Guess the output?

"use strict";
const user = {
  name: "Amit",
  getName() {
    return this.name;
  },
};
const getName = user.getName;
console.log(getName());

A. "Amit"

B. undefined

C. TypeError

D. ReferenceError

👀 Reveal answer
C. TypeError

Detached method → this === undefined in strict mode → reading .name throws.

Same pitfall as passing obj.method into a callback without binding.

⚡ Challenge 15 — Guess the output?

const user = {
  name: "Amit",
  getName: () => this.name,
};
console.log(user.getName());

A. "Amit"

B. undefined

C. TypeError

D. Always "global"

👀 Reveal answer
B. undefined (typical module / RN runtime)

Arrows do not take this from the object. They capture outer this.

⚡ Challenge 16 — Guess the output?

const user = { name: "Amit" };
function greet() {
  return `Hi ${this.name}`;
}
const boundGreet = greet.bind(user);
console.log(boundGreet());

A. "Hi Amit"

B. "Hi undefined"

C. Error

D. undefined

👀 Reveal answer
A. "Hi Amit"

bind locks this permanently.

🧪 Equality, types, and weird JS

⚡ Challenge 17 — Guess the output?

console.log([] == false, [] === false);

A. true true

B. true false

C. false true

D. false false

👀 Reveal answer
B. true false

== coerces both sides toward numbers (0 == 0).

=== also checks type → false.

⚡ Challenge 18 — Guess the output?

console.log(null == undefined, null === undefined);

A. true true

B. true false

C. false true

D. false false

👀 Reveal answer
B. true false

Special == rule: null and undefined are loosely equal.

⚡ Challenge 19 — Guess the output?

console.log(NaN === NaN, Object.is(NaN, NaN));

A. true true

B. true false

C. false true

D. false false

👀 Reveal answer
C. false true

NaN !== NaN with ===.

Object.is treats two NaNs as equal — useful when validating parsed numbers from APIs.

⚡ Challenge 20 — Guess the output?

console.log(typeof null, typeof []);

A. "null" "array"

B. "object" "object"

C. "undefined" "object"

D. "null" "object"

👀 Reveal answer
B. "object" "object"

Historic quirk. Use Array.isArray() for arrays.

📦 References (React state landmines)

⚡ Challenge 21 — Guess the output?

console.log([] === [], [] == []);

A. true true

B. true false

C. false true

D. false false

👀 Reveal answer
D. false false

Each [] is a new object. References never match.

⚡ Challenge 22 — Guess the output?

const a = [1, 2];
const b = a;
b.push(3);
console.log(a);

A. [1, 2]

B. [1, 2, 3]

C. [3]

D. Error

👀 Reveal answer
B. [1, 2, 3]

a and b point to the same array. Mutating “copy” mutates state if you shared the reference.

⚡ Challenge 23 — Guess the output?

const a = { profile: { city: "Delhi" } };
const b = { ...a };
b.profile.city = "Pune";
console.log(a.profile.city);

A. "Delhi"

B. "Pune"

C. undefined

D. Error

👀 Reveal answer
B. "Pune"

Spread is shallow. Nested profile is still shared — classic “I updated state but nested object mutated” interview moment.

⚡ Challenge 24 — Guess the output?

const obj = {};
const a = {};
const b = {};
obj[a] = "first";
obj[b] = "second";
console.log(obj[a]);

A. "first"

B. "second"

C. undefined

D. Error

👀 Reveal answer
B. "second"

Object keys become strings → both are "[object Object]". Use Map for object identity keys.

📚 Arrays & helpers interviewers love

⚡ Challenge 25 — Guess the output?

console.log([1, 30, 4, 21].sort());

A. [1, 4, 21, 30]

B. [1, 21, 30, 4]

C. [30, 21, 4, 1]

D. Error

👀 Reveal answer
B. [1, 21, 30, 4]

Default sort compares as strings. Use (a, b) => a - b for numbers.

⚡ Challenge 26 — Guess the output?

console.log(["1", "2", "3"].map(parseInt));

A. [1, 2, 3]

B. [1, NaN, NaN]

C. [1, 1, 1]

D. Error

👀 Reveal answer
B. [1, NaN, NaN]

map passes (value, index).

parseInt("2", 1) → NaN (bad radix). Prefer .map(Number) or .map((x) => parseInt(x, 10)).

⚡ Challenge 27 — Guess the output?

const items = [1, , 3];
console.log(items.map((x) => x * 2), items.length);

A. [2, 0, 6] 3

B. [2, undefined, 6] 3

C. [2, empty, 6] 3

D. Error

👀 Reveal answer
C. [2, empty, 6] 3

map skips holes and keeps the hole in the result. Length stays 3.

⚡ Challenge 28 — Guess the output?

console.log([0, 1, false, 2, "", 3, null].filter(Boolean));

A. [0, 1, 2, 3]

B. [1, 2, 3]

C. [false, null]

D. Error

👀 Reveal answer
B. [1, 2, 3]

filter(Boolean) drops all falsy values — including legitimate 0 (e.g. quantity / score).

⚡ Challenge 29 — Guess the output?

const values = [1, 2, 3];
const removed = values.splice(1, 1);
console.log(values, removed);

A. [1,2,3] [2]

B. [1,3] [2]

C. [1,3] [1,2]

D. Error

👀 Reveal answer
B. [1,3] [2]

splice mutates and returns removed items. Prefer immutable updates in React state.

⚡ Challenge 30 — Guess the output?

const [a = 1, b = 2] = [undefined, null];
console.log(a, b);

A. 1 2

B. undefined null

C. 1 null

D. null 2

👀 Reveal answer
C. 1 null

Defaults apply only for undefined, not null — important when APIs return null.

🧩 Parameters, prototypes, classes

⚡ Challenge 31 — Guess the output?

function greet(name = "Guest") {
  return name;
}
console.log(greet(), greet(undefined), greet(null));

A. Guest Guest Guest

B. Guest Guest null

C. undefined undefined null

D. Error

👀 Reveal answer
B. Guest Guest null

Defaults fire for missing args / undefined, not for null.

⚡ Challenge 32 — Guess the output?

function total(...nums) {
  return nums.reduce((sum, n) => sum + n, 0);
}
console.log(total(1, 2, 3));

A. 6

B. [1,2,3]

C. 123

D. Error

👀 Reveal answer
A. 6

Rest params → real array → reduce.

⚡ Challenge 33 — Guess the output?

function login(email, password = "secret", remember) {}
console.log(login.length);

A. 3

B. 2

C. 1

D. 0

👀 Reveal answer
C. 1

function.length counts parameters before the first defaulted one.

⚡ Challenge 34 — Guess the output?

const parent = { role: "admin" };
const user = Object.create(parent);
user.name = "Amit";
console.log(user.role, user.hasOwnProperty("role"));

A. "admin" true

B. "admin" false

C. undefined false

D. Error

👀 Reveal answer
B. "admin" false

role comes from the prototype chain, not an own property.

⚡ Challenge 35 — Guess the output?

const parent = { theme: "dark" };
const settings = Object.create(parent);
settings.theme = "light";
delete settings.theme;
console.log(settings.theme);

A. "light"

B. "dark"

C. undefined

D. Error

👀 Reveal answer
B. "dark"

Deleting the own property reveals the inherited one again.

⚡ Challenge 36 — Guess the output?

const config = Object.freeze({
  api: { timeout: 1000 },
});
config.api.timeout = 2000;
console.log(config.api.timeout);

A. 1000

B. 2000

C. TypeError

D. undefined

👀 Reveal answer
B. 2000

Object.freeze is shallow. Nested objects stay mutable.

⚡ Challenge 37 — Guess the output?

const user = new User();
class User {}

A. A User instance

B. undefined

C. ReferenceError

D. TypeError

👀 Reveal answer
C. ReferenceError

Classes are hoisted into the TDZ — not usable before the declaration line.

⏱️ Promises, async/await & the event loop

⚡ Challenge 38 — Guess the output?

console.log("start");
Promise.resolve().then(() => console.log("promise"));
console.log("end");

A. start promise end

B. promise start end

C. start end promise

D. Error

👀 Reveal answer
C. start end promise

Sync first → then microtasks.

⚡ Challenge 39 — Guess the output?

console.log("start");
setTimeout(() => console.log("timer"), 0);
Promise.resolve().then(() => console.log("promise"));
console.log("end");

A. start end promise timer

B. start promise end timer

C. start end timer promise

D. timer promise start end

👀 Reveal answer
A. start end promise timer

All microtasks before the next macrotask — even setTimeout(..., 0).

Core RN interview question for loading indicators + API race timing.

⚡ Challenge 40 — Guess the output?

Promise.resolve().then(() => {
  console.log(1);
  Promise.resolve().then(() => console.log(2));
});
Promise.resolve().then(() => console.log(3));

A. 1 2 3

B. 1 3 2

C. 3 1 2

D. 1 3

👀 Reveal answer
B. 1 3 2

First wave queues 1 and 3. Nested 2 is appended after 1 runs.

⚡ Challenge 41 — Guess the output?

async function getValue() {
  return 42;
}
console.log(getValue());

A. 42

B. Promise { 42 }

C. undefined

D. Error

👀 Reveal answer
B. Promise { 42 }

Formatting varies by engine, but an async function always returns a Promise.

⚡ Challenge 42 — Guess the output?

async function run() {
  console.log("inside");
  await 0;
  console.log("after await");
}
console.log("before");
run();
console.log("after");

A. before inside after await after

B. before inside after after await

C. before after inside after await

D. Error

👀 Reveal answer
B. before inside after after await

await yields; the continuation runs as a microtask after sync work finishes.

⚡ Challenge 43 — Guess the output?

const slow = new Promise((resolve) => setTimeout(() => resolve("slow"), 10));
const fast = Promise.resolve("fast");
Promise.all([slow, fast]).then(console.log);

A. ["fast", "slow"]

B. ["slow", "fast"]

C. "slowfast"

D. Rejection

👀 Reveal answer
B. ["slow", "fast"]

Promise.all keeps input order, not finish order — useful when joining multiple RN API calls.

⚡ Challenge 44 — Guess the output?

Promise.all([
  Promise.resolve("ok"),
  Promise.reject("failed"),
]).then(console.log).catch(console.log);

A. ["ok", "failed"]

B. "failed"

C. "ok"

D. Nothing

👀 Reveal answer
B. "failed"

One rejection fails the whole Promise.all. Prefer Promise.allSettled when you need every result.

⚡ Challenge 45 — Guess the output?

Promise.resolve("data")
  .finally(() => "cleanup")
  .then(console.log);

A. "cleanup"

B. "data"

C. undefined

D. Rejection

👀 Reveal answer
B. "data"

A normal return from finally does not replace the resolved value (throwing would).

⚡ Challenge 46 — Guess the output?

async function run() {
  [1, 2].forEach(async (n) => {
    await Promise.resolve();
    console.log(n);
  });
  console.log("done");
}
run();

A. 1 2 done

B. done 1 2

C. done 2 1

D. Nothing

👀 Reveal answer
B. done 1 2

forEach does not await async callbacks. Use for...of + await for sequential RN work (uploads, chained requests).

🗺️ Sets, Maps, modern operators

⚡ Challenge 47 — Guess the output?

const first = { id: 1 };
const second = { id: 1 };
console.log(new Set([first, second]).size);

A. 1

B. 2

C. 0

D. Error

👀 Reveal answer
B. 2

Objects compared by reference, not deep equality — same idea as deduping list items incorrectly.

⚡ Challenge 48 — Guess the output?

const map = new Map();
map.set({}, "value");
console.log(map.get({}));

A. "value"

B. undefined

C. null

D. Error

👀 Reveal answer
B. undefined

get({}) uses a new object key, not the stored one.

⚡ Challenge 49 — Guess the output?

const user = {};
console.log(user.profile?.address?.city);

A. null

B. undefined

C. ReferenceError

D. TypeError

👀 Reveal answer
B. undefined

Optional chaining stops safely — great for messy API payloads in RN.

⚡ Challenge 50 — Guess the output?

console.log(0 || 10, 0 ?? 10, "" || "guest", "" ?? "guest");

A. 10 0 "guest" ""

B. 0 0 "" ""

C. 10 10 "guest" "guest"

D. Error

👀 Reveal answer
A. 10 0 "guest" ""

|| falls back on any falsy value.

?? falls back only on null / undefined.

Use ?? when 0 or "" are valid (counts, empty search text).

Fast React Native interview revision

Topic	Remember
Hoisting	Declarations hoist; `var` → `undefined`; `let` / `const` / `class` → TDZ
Closures	Timers/callbacks keep the variables they closed over
`this`	Call site for regular functions; lexical for arrows
Equality	Prefer `===`; know `null == undefined` and `NaN`
References	Arrays/objects share identity; spread is shallow
Event loop	Sync → all microtasks → one macrotask
Async	`async` returns a Promise; `forEach` won’t await

Comment challenge

Drop your score in the comments:

X / 50 — and the one question that still feels unfair 👇

If this helped your next React Native / JavaScript interview, bookmark it and practice explaining each answer out loud — that’s what interviewers actually hire for.

Happy coding 🚀

Signing API Requests with HMAC (React Native)

Amit Kumar — Fri, 24 Jul 2026 17:13:24 +0000

HMAC request signing proves two things to your backend: the caller knows a shared secret, and the request was not altered after it was signed.

It is not encryption — the body stays readable — but it is a strong, lightweight integrity and authenticity check for mobile APIs.

Note: This walkthrough uses a React Native client and react-native-quick-crypto. The same ideas apply to web or any HTTP client.

Table of contents

See it in action
What is HMAC?
Generate a strong secret
The canonical string
Reference implementation
How to call signOutgoingRequest
Sort the body before hashing
Challenges I faced
Best practice: mirror the backend
Checklist
Mental model

See it in action

Before the code — here’s the whole story visually.

Interactive animation

Valid signature — request accepted

Invalid signature — hacker tampering rejected

What is HMAC?

HMAC (Hash-based Message Authentication Code) mixes a hash function (usually SHA-256) with a secret key.

You pass in:

A message string
A secret both client and server share

You get back a fixed-length signature (typically hex).

Property	Meaning
Integrity	Change one character of the message → signature changes
Authenticity	Only holders of the secret can produce a valid signature
Not encryption	Payload remains readable; HMAC proves who signed it

API flow:

Client → build canonical string → HMAC-SHA256 → send signature header
Server → rebuild same canonical string → HMAC-SHA256 → compare (constant-time)

Same canonical string + same secret = match. Anything else fails.

Generate a strong secret

openssl rand -hex 32

That yields 32 random bytes as 64 hex characters — a 256-bit key that fits HMAC-SHA256 well.

Why bother?

Weak choice	Problem
`"mySecret123"` / app-name keys	Easy to guess or brute-force
Short / human-picked secrets	Low entropy
Secrets in git or logs	Instant leak

Tip: Use a CSPRNG (openssl rand), store the value in a secrets manager, and never commit or log it.

The canonical string

HMAC does not understand HTTP. You pick the fields that matter, join them in a fixed order, then sign that string.

METHOD
PATH
TIMESTAMP
CLIENT_PLATFORM
SECRET_ID
SIGNED_HEADERS
BODY_HASH

Example:

POST
/api/v1/orders
1710000000000
ios
mobile-app-v1
accept:application/json;x-api-version:1
a3f2c9...   ← sha256 hex of the body

More fields → stronger binding. Each line ties the signature to another part of the request:

Field	Guards against
Method + path	Replaying a body on a different endpoint
Timestamp	Stale / replayed requests
Client platform	Cross-client misuse of the same secret
Secret id	Ambiguity during key rotation
Signed headers	Spoofing headers you care about
Body hash (`bodyHex`)	Tampering with the payload

Warning: Signing only method + path is weak. Bind method, path, time, identity, headers, and body hash — and keep that list identical on client and server.

Reference implementation

Uses react-native-quick-crypto. Names are illustrative — align them with your backend contract.

import Crypto from "react-native-quick-crypto";
import { resolvePath, sortBodyKeys } from "./signingHelpers";

/** HMAC-SHA256 → hex digest */
export const createHmacDigest = (message, sharedSecret) => {
  if (!sharedSecret) {
    throw new Error("Shared signing secret is required");
  }
  const hmac = Crypto.createHmac("sha256", sharedSecret);
  hmac.update(message);
  return hmac.digest("hex");
};

const sha256Hex = (data) =>
  Crypto.createHash("sha256").update(data).digest("hex");

/** Build canonical string and sign it */
export const buildRequestSignature = ({
  method,
  url,
  issuedAt,
  body,
  sharedSecret,
  secretId,
  signedHeaderBlock,
  clientRuntime, // e.g. "ios" | "android" | "web"
}) => {
  let bodyStr = "";
  if (body != null) {
    bodyStr = typeof body === "string" ? body : JSON.stringify(body);
  }
  const bodyHex = sha256Hex(bodyStr);
  const path = resolvePath(url);

  // Order must match the backend exactly.
  // More lines = signature covers more of the request.
  const canonical = [
    method.toUpperCase(),
    path,
    issuedAt,
    clientRuntime,
    secretId,
    signedHeaderBlock,
    bodyHex,
  ].join("\n");

  return createHmacDigest(canonical, sharedSecret);
};

/** Attach time + signature headers to an outgoing request */
export const signOutgoingRequest = (request, sharedSecret) => {
  if (!sharedSecret) {
    return request;
  }

  try {
    const issuedAt = String(Date.now());

    // Sort body keys so client/server stringify & hash the same JSON.
    const sortedBody = sortBodyKeys(request.data);

    if (sortedBody != null && typeof sortedBody === "object") {
      request.data = sortedBody;
    }

    const signature = buildRequestSignature({
      method: request?.method,
      url: request.url,
      issuedAt,
      body: sortedBody,
      sharedSecret,
      secretId: "mobile-app-v1",
      signedHeaderBlock: "accept:application/json;x-api-version:1",
      clientRuntime: "ios", // or detect at runtime
    });

    request.headers["x-request-time"] = issuedAt;
    request.headers["x-request-signature"] = signature;
  } catch (error) {
    console.error("[signing] Failed to sign request:", error);
  }

  return request;
};

Field	Role
`secretId`	`"mobile-app-v1"` — server looks up which secret to use (rotation)
`signedHeaderBlock`	Headers bound into the signature, same format on both sides
`bodyHex`	`sha256Hex(bodyStr)` — hash of the sorted, stringified body

How to call `signOutgoingRequest`

Hook it into your HTTP client request interceptor after headers and body are ready:

import axios from "axios";
import { signOutgoingRequest } from "./requestSigning";

const api = axios.create({
  baseURL: "https://api.example.com",
});

api.interceptors.request.use(
  (request) => {
    request.headers = request.headers ?? {};
    request.headers["Content-Type"] = "application/json";

    signOutgoingRequest(request, sharedSecret); // adds x-request-time + x-request-signature

    return request;
  },
  (error) => Promise.reject(error),
);

await api.post("/api/v1/orders", { itemId: "123", qty: 2 });

One-off:

const request = {
  method: "post",
  url: "/api/v1/orders",
  data: { itemId: "123", qty: 2 },
  headers: {},
};

signOutgoingRequest(request, sharedSecret);
await api.request(request);

Argument	Meaning
`request`	Needs `method`, `url`, `data`, `headers`
`sharedSecret`	From `openssl rand -hex 32` (or secrets store). Empty → request left unsigned

Headers set on success:

x-request-time — same value inside the canonical string
x-request-signature — hex HMAC of the canonical string

Use whatever header names your backend defines.

Sort the body before hashing

JSON key order is not guaranteed:

{"b":1,"a":2}   vs   {"a":2,"b":1}

Same meaning, different bytes → different bodyHex → signature mismatch.

Body sort fixes it: both sides run the same key-order pass (sortBodyKeys) before JSON.stringify and sha256Hex. Send that sorted body on the wire so what you transmit matches what you signed.

Challenges I faced

Canonical strings did not match

Even with the correct secret, signatures failed until both sides built the exact same string.

Common causes:

Field order differs (timestamp before path on one side)
Different newlines / separators
Method casing (post vs POST)
Path shape (/api/foo vs full URL vs trailing slash)
Empty body as "" vs "{}" vs omitted
Body hashed before sort on one side, after sort on the other

Tip: In non-prod, log the full canonical string (or its hash) on client and server and diff them.

Signature still wrong when “logic looks fine”

Usually the message encoding differs, not the crypto:

Algorithm (sha256) and digest form (hex vs base64)
Secret as UTF-8 string vs raw bytes
Timestamp as string vs number
Header block casing / trimming

Sequence is the protocol

If the backend expects:

METHOD \n PATH \n TIMESTAMP \n ...

and the client sends:

METHOD \n TIMESTAMP \n PATH \n ...

it will never verify. HMAC will not “figure out” order — you must keep the same sequence as the backend (or document a shared sort both sides apply).

Best practice: mirror the backend

Treat the canonical format as a shared protocol — not a client-only convenience.

Do	Why
Same fields, same order, same separators	HMAC is order-sensitive
Sort body keys on both sides	Avoids JSON key-order drift
Stabilize only the headers you sign	Keeps `signedHeaderBlock` identical

Caution: Do not invent a friendlier order on the client. Align with BE first; any body-sort step must run the same way on both sides.

Checklist

One written canonicalization spec for mobile, web, and API.
Bind many request dimensions (method, path, time, secret id, headers, body hash).
Strong secret via openssl rand -hex 32; rotate with secretId.
Server rejects old timestamps (e.g. ±2–5 minutes).
Hash the body (bodyHex); do not dump huge payloads raw into HMAC.
Constant-time signature compare on the server.
Never log secrets; debug canonical strings only in non-prod.
Fail closed if signing fails when the API requires HMAC.
Version the scheme if field order ever changes.
Golden-vector tests: fixed inputs → expected signature on both sides.

Mental model

openssl rand -hex 32     →  shared secret
sort body + pick fields  →  canonical string (fixed order)
HMAC-SHA256              →  x-request-signature
server repeats           →  accept or 401

HMAC itself is simple. The hard part is discipline: identical inputs, identical order, identical encoding. Get the canonical string right on both sides, and request signing becomes boring — in the best way.

If this helped, drop a comment with the gotchas you hit when wiring HMAC on your stack — especially anything platform-specific on iOS/Android.

Bridging Swift with React Native's New Architecture using TurboModules

Amit Kumar — Fri, 24 Jul 2026 17:11:25 +0000

With the release of React Native 0.79 and React 19, bridging native modules to JavaScript has become even more seamless using the TurboModules system. In this guide, we’ll walk through how to create a Swift-based TurboModule and expose native functionality to your React Native app.

Project Setup

We assume you're using the latest versions:

{
  "dependencies": {
    "react": "19.0.0",
    "react-native": "0.79.3"
  }
}

Directory Structure

Your project should resemble:

yourapp/
├── ios/
│   ├── NativeMessageModule/
│   │   ├── NativeMessageModule.swift
│   │   └── NativeMessageModule-Swift.m
├── specs/
│   └── NativeMessageModule.ts
├── App.js
├── package.json
└── ...

Define the TurboModule Interface

Create specs/NativeMessageModule.ts:

import {TurboModule} from 'react-native/Libraries/TurboModule/RCTExport';
import {TurboModuleRegistry} from 'react-native';

export interface Spec extends TurboModule {
  sendMessage(message: string): void;
  getMessage(): Promise<string>;
  sendWithCallback(callback: (response: string) => void): void;

  addListener(eventName: string): void;
  removeListeners(count: number): void;
  startSendingEvents(): void;
}

export default TurboModuleRegistry.getEnforcing<Spec>('NativeMessageModule');

✅ All native TurboModules must begin with the Native prefix and match the registered module name exactly (NativeMessageModule here).

Configure Codegen

In your package.json, add:

"codegenConfig": {
  "name": "NativeMessageModule",
  "type": "modules",
  "jsSrcsDir": "specs",
  "android": {
    "javaPackageName": "com.turbomodules" #Replace this with your packagename
  }
}

Then, inside the ios folder:

cd ios
bundle install
bundle exec pod install

Implement Native Code in Swift

1. Native Bridge Header (Objective-C)

Create ios/NativeMessageModule/NativeMessageModule-Swift.m:

#import <React/RCTBridgeModule.h>
#import <React/RCTEventEmitter.h>

@interface RCT_EXTERN_MODULE(NativeMessageModule, RCTEventEmitter)

RCT_EXTERN_METHOD(sendMessage:(NSString *)message)

RCT_EXTERN_METHOD(getMessage:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject)

RCT_EXTERN_METHOD(sendWithCallback:(RCTResponseSenderBlock)callback)

RCT_EXTERN_METHOD(startSendingEvents)

@end

2. Swift Implementation

Create ios/NativeMessageModule/NativeMessageModule.swift:


import Foundation
import React

@objc(NativeMessageModule)
class NativeMessageModule: RCTEventEmitter {

    private var hasListeners = false

    override static func requiresMainQueueSetup() -> Bool {
        return true
    }

    override func supportedEvents() -> [String]! {
        return ["onTimerTick"]
    }

    override func startObserving() {
        hasListeners = true
    }

    override func stopObserving() {
        hasListeners = false
    }

    @objc
    func sendMessage(_ message: String) {
        NSLog("[iOS TurboModule] Received from JS: %@", message)
    }

    @objc
    func getMessage(_ resolve: @escaping RCTPromiseResolveBlock,
                    reject: @escaping RCTPromiseRejectBlock) {
        let response = "Hello from iOS TurboModule"
        resolve(response)
    }

    @objc
    func sendWithCallback(_ callback: @escaping RCTResponseSenderBlock) {
        callback(["Callback response from iOS TurboModule"])
    }

    @objc
    func startSendingEvents() {
        guard hasListeners else { return }

        for i in 1...5 {
            DispatchQueue.main.asyncAfter(deadline: .now() + Double(i)) { [weak self] in
                guard let self = self, self.hasListeners else { return }
                let eventData = ["message": "iOS TurboModule Event at \(Date().timeIntervalSince1970)"]
                self.sendEvent(withName: "onTimerTick", body: eventData)
            }
        }
    }
}

Reinstall Pods After Codegen

After creating Swift files and configuring the bridging header:

cd ios
bundle install
bundle exec pod install

React Native Integration

Use the TurboModule in your App.js:


import React, {useState, useEffect} from 'react';
import {
  View,
  Button,
  Text,
  StyleSheet,
  NativeEventEmitter,
} from 'react-native';
import NativeMessageModule from './specs/NativeMessageModule';

const App = () => {
  const [receivedMessage, setReceivedMessage] = useState('');
  const [lastSentMessage, setLastSentMessage] = useState('');
  const [callbackMsg, setCallbackMsg] = useState('');
  const [eventMsg, setEventMsg] = useState('');

  useEffect(() => {
    const eventEmitter = new NativeEventEmitter(NativeMessageModule);
    const subscription = eventEmitter.addListener('onTimerTick', event => {
      setEventMsg(event.message);
    });
    return () => subscription.remove();
  }, []);

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Bridging Example</Text>

      <Button title="Send Message to Native" onPress={() => {
        const msg = 'Hello from React Native';
        NativeMessageModule.sendMessage(msg);
        setLastSentMessage(msg);
      }} />
      <Text style={styles.message}>Last sent: {lastSentMessage}</Text>

      <Button title="Get Message from Native" onPress={async () => {
        const msg = await NativeMessageModule.getMessage();
        setReceivedMessage(msg);
      }} />
      <Text style={styles.message}>Received: {receivedMessage}</Text>

      <Button title="Use Callback" onPress={() => {
        NativeMessageModule.sendWithCallback(msg => setCallbackMsg(msg));
      }} />
      <Text>Received: {callbackMsg}</Text>

      <Button title="Trigger Native Event" onPress={() => {
        NativeMessageModule.startSendingEvents();
      }} />
      <Text>Received: {eventMsg}</Text>
    </View>
  );
};

const styles = StyleSheet.create({
  container: {flex: 1, justifyContent: 'center', padding: 16},
  title: {fontSize: 24, fontWeight: 'bold', marginBottom: 32, textAlign: 'center'},
  message: {marginTop: 8, fontSize: 14, color: '#666'},
});

export default App;

📌 Summary

In this blog, we:

✅ Defined a TurboModule spec in TypeScript
✅ Created Swift native module logic compatible with the New Architecture
✅ Configured the Objective-C Bridging Header
✅ Handled Promises, Callbacks, and native event emissions
✅ Used the module in React Native with hooks and state

Automating Firebase App Distribution for Android and iOS

Amit Kumar — Fri, 24 Jul 2026 17:07:19 +0000

In this blog, we’ll walk through automating the process of distributing Android and iOS builds using Firebase App Distribution. This process ensures a seamless workflow for testing by leveraging Firebase CLI and a custom script that handles Android APK and iOS IPA distributions with ease.

Folder Setup

First, let's create the required folder structure in your project to manage Firebase App Distribution efficiently.

Navigate to your project's root directory.
Create a folder named distribution inside config/scripts/.

mkdir -p config/scripts/distribution

Inside the distribution folder, create two files:

firebase-distribution.sh: This will be the shell script that automates the distribution.
release_notes_file.txt: This file will store your release notes for each version.

touch config/scripts/distribution/firebase-distribution.sh
touch config/scripts/distribution/release_notes_file.txt

Folder structure after creation:

Firebase Distribution Script

Next, we’ll create a custom shell script that automates the distribution process. Open firebase-distribution.sh and add the following content:

#Set App Distribution Properties
##############################################
# App name on ipa file (FILE_NAME.ipa)
FILE_NAME="ipaFileName"

# Firebase App IDs
FIREBASE_APP_ID_ANDROID="1:46:android:36f84"
FIREBASE_APP_ID_IOS="1:46:ios:36f84"

# Distribution Group Ids
INTERNAL_GROUP_APP_ID="appIdOfDistributionGroup"
DEVELOPERS_GROUP_APP_ID="appIdOfDistributionGroup"

##############################################

# Firebase CLI path
FIREBASE_CLI_PATH="firebase"

# APK and IPA paths
APK_PATH="android/app/build/outputs/apk/release/app-release.apk"
IPA_PATH="src/config/scripts/distribution/release/$FILE_NAME.ipa"

# Tester group and release notes paths
TESTERS_FILE_PATH=$DEVELOPERS_GROUP_APP_ID
RELEASE_NOTES_FILE_PATH="src/config/scripts/distribution/release_notes_file.txt"

# Platform selection options
options=("Android🤖" "iOS🍎")
selected_platform=""

echo "\n\n"
echo "📲 Please select Platform:"
REPLY=1  # Set default option to Android
select choice in "${options[@]}"; do
    case $choice in
        "Android🤖")
          echo "Android selected ✅"
            selected_platform="Android"
            ;;
        "iOS🍎")
          echo "iOS selected ✅"
            selected_platform="iOS"
            ;;
        *)
            echo "Invalid option. Please try again."
            ;;
    esac
    if [ -n "$selected_platform" ]; then
        break
    fi
done

# Setting parameters based on the platform
if [ "$selected_platform" = "Android" ]; then
    FILE_PATH="$APK_PATH"
    APP_ID="$FIREBASE_APP_ID_ANDROID"
else
    FILE_PATH="$IPA_PATH"
    APP_ID="$FIREBASE_APP_ID_IOS"
fi

# Distribution group selection
share_groups_options=("Internal Testing" "Developers")
echo "\n\n"
echo "🧑 Please select Distribution Group:"
REPLY=1  # Set default option to Internal Testing
select choice in "${share_groups_options[@]}"; do
    case $choice in
        "Internal Testing")
            echo "Internal Testing group selected ✅"
            TESTERS_FILE_PATH=$INTERNAL_GROUP_APP_ID
            ;;
        "Developers")
          echo "Developers group selected ✅"
            TESTERS_FILE_PATH=$DEVELOPERS_GROUP_APP_ID
            ;;
        *)
            echo "Invalid option. Please try again."
            ;;
    esac
    if [ -n "$TESTERS_FILE_PATH" ]; then
        break
    fi
done

# Check if Firebase CLI is installed
if [ ! "$FIREBASE_CLI_PATH" ]; then
  echo "Firebase CLI is not installed. Please install it."
  exit 1
fi

# Validate file paths and release notes
if [ ! -f "$FILE_PATH" ]; then
  echo "File does not exist at the provided path."
  exit 1
fi
if [ ! -f "$RELEASE_NOTES_FILE_PATH" ]; then
  echo "Release notes file not found."
  exit 1
fi

RELEASE_NOTES=$(cat "$RELEASE_NOTES_FILE_PATH")

# Display selected options
echo "\n---------------------------------------------\n"
echo "📱 Platform: $selected_platform\n"
echo "📦 Distribution group: $TESTERS_FILE_PATH\n"
echo "📝 Release Notes: $RELEASE_NOTES"
echo "\n---------------------------------------------\n"
echo "Press Enter to continue...↩️"
read

# Distribute using Firebase CLI
"$FIREBASE_CLI_PATH" appdistribution:distribute "$FILE_PATH" \
  --app "$APP_ID" \
  --release-notes "$RELEASE_NOTES" \
  --groups "$TESTERS_FILE_PATH"

Key Details:

**Firebase App IDs:** Get your Firebase App IDs from the Firebase console. Navigate to your app’s settings, and you’ll find the App ID under the "Your apps" section.
**Distribution Group IDs:** To find or create tester groups, navigate to the App Distribution section of Firebase, click on "Testers & Groups," and note the group ID next to the group name.

Screenshot for group ID reference:

Firebase CLI Installation

You need the Firebase CLI to automate the upload process. Follow these steps to install and configure it:

Install Firebase CLI globally:

npm install -g firebase-tools

firebase login

Distributing the Build

Once the script is ready and Firebase CLI is configured, follow these steps:

1. Create Android/iOS Release Build:

Generate your APK or IPA file.
Create IOS build and put ipa file in "src/config/scripts/distribution/release" folder

3. Update Release Notes:

Add your release notes in release_notes_file.txt.

Run the Script:

Run the custom script using Yarn or npm:

yarn share

4. Platform and Group Selection:

Follow the prompts to select the platform (Android or iOS) and the distribution group (Internal or Developers).

5. Confirmation:

Press Enter to confirm and the build will be uploaded to Firebase App Distribution!

Handling Upload Errors

If you encounter issues during the upload process (e.g., Firebase CLI not installed correctly), ensure the following:

Reinstall Firebase CLI:

npm install -g firebase-tools

firebase login

With this setup, you’ve automated the tedious process of distributing Android and iOS builds, streamlining the testing workflow for your team. This script not only saves time but also reduces human error, ensuring that the latest version of your app is always available for testers. Happy coding! 🎉

Integrating AeroPay SDK in React Native: A Step-by-Step Guide

Amit Kumar — Fri, 24 Jul 2026 17:04:54 +0000

In the world of digital payments, AeroPay offers a robust solution for smart bank transfers and direct bank connections. With its easy-to-implement SDKs and APIs, AeroPay simplifies the payment experience for businesses and consumers alike. This blog will guide you through integrating the AeroPay SDK into a React Native application.

Why Choose AeroPay?

AeroPay provides:

Smart Bank Transfers: Seamless payment processing.
Direct Bank Connections: Secure and fast connections to banks.
Customizable Widgets: Tailored experiences for payment flows.

Step 1: Install the Required Dependencies

To start, install the AeroPay SDK and any additional libraries required for the project:

npm install aerosync-react-native-sdk react-native-dropdown-picker

Step 2: Implement the React Native Code

import React, { useState } from 'react';
import BankLink from 'aerosync-react-native-sdk';
import DropDownPicker from 'react-native-dropdown-picker';
import {
  StyleSheet,
  SafeAreaView,
  Text,
  View,
  TextInput,
  TouchableOpacity,
} from 'react-native';

const App = () => {
  const [token, setToken] = useState('');
  const [isSubmitted, setIsSubmitted] = useState(false);
  const [consumerId, setConsumerId] = useState('');
  const [open, setOpen] = useState(false);
  const [value, setValue] = useState('staging');
  const [items, setItems] = useState([
    { label: 'STAGING', value: 'staging' },
    { label: 'SANDBOX', value: 'sandbox' },
    { label: 'PRODUCTION', value: 'production' },
  ]);

  const onLoad = () => console.log('Widget Loaded');
  const onClose = () => {
    console.log('Widget Closed');
    setIsSubmitted(false);
  };
  const onSuccess = (event) => {
    console.log('Success:', event);
    setIsSubmitted(false);
  };
  const onError = (event) => console.log('Error:', event);
  const onEvent = (event) => console.log('Event:', event);

  if (isSubmitted) {
    return (
      <SafeAreaView>
        <BankLink
          token={token}
          environment={value}
          onError={onError}
          onClose={onClose}
          onEvent={onEvent}
          onSuccess={onSuccess}
          onLoad={onLoad}
          deeplink="https://staging.aerosync.com/"
          consumerId={consumerId}
          style={{ width: '100%', height: '100%' }}
        />
      </SafeAreaView>
    );
  }

  return (
    <SafeAreaView style={styles.container}>
      <Text style={styles.title}>AeroPay React Native Integration</Text>
      <View style={styles.dropdown}>
        <DropDownPicker
          open={open}
          value={value}
          items={items}
          setOpen={setOpen}
          setValue={setValue}
          setItems={setItems}
          placeholder="Select Environment"
        />
      </View>
      <TextInput
        style={styles.input}
        placeholder="Enter Token"
        onChangeText={setToken}
        placeholderTextColor="#555"
      />
      <TextInput
        style={styles.input}
        placeholder="Enter Consumer ID (optional)"
        onChangeText={setConsumerId}
        placeholderTextColor="#555"
      />
      <TouchableOpacity
        style={styles.button}
        onPress={() => setIsSubmitted(true)}
      >
        <Text style={styles.buttonText}>Launch AeroPay Widget</Text>
      </TouchableOpacity>
    </SafeAreaView>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#fff',
  },
  title: {
    fontSize: 22,
    fontWeight: 'bold',
    marginBottom: 20,
  },
  dropdown: {
    width: '80%',
    marginBottom: 20,
  },
  input: {
    width: '80%',
    borderColor: '#ccc',
    borderWidth: 1,
    borderRadius: 5,
    padding: 10,
    marginBottom: 20,
  },
  button: {
    backgroundColor: '#24c3d2',
    padding: 15,
    borderRadius: 5,
  },
  buttonText: {
    color: '#fff',
    fontWeight: 'bold',
    fontSize: 16,
  },
});

export default App;

React Native App Security — Threat Model, Storage, Auth, Network & Production Hardening

Amit Kumar — Wed, 22 Jul 2026 17:09:17 +0000

Introduction

Your React Native app ships a JS bundle, talks to APIs, stores a session, and maybe unlocks with Face ID. Attackers don’t need your source repo — they need a rooted phone, a proxy, or a leaked token in AsyncStorage.

What is app security in React Native?

It is the set of practices that protect secrets, user data, sessions, and API trust on a device you do not fully control — across JS, native layers, network, and store distribution.

Why it matters

Mobile clients can be reverse-engineered; “hidden in the app” is not secret
Tokens in plain storage are one backup/export away from theft
Cleartext HTTP, weak deep links, and verbose logs are common real breaches
Play Store / App Store and enterprise clients increasingly expect basic hardening

What this article covers

Threat model — what you are defending against
What to store where (Keychain vs AsyncStorage)
Auth, refresh tokens, biometrics
Network security (TLS, pinning, cleartext)
Deep links, intents, WebViews
Reverse engineering & binary hardening
Device integrity, privacy screens, logging
Dependencies, CI secrets, ship checklist

Threat model
Security decision map
Secrets & secure storage
Authentication & sessions
Biometrics
Network security
Deep links, intents & WebViews
Code protection & reverse engineering
Device integrity & privacy
Logging, analytics & PII
Permissions & platform config
Dependencies & supply chain
CI / secrets hygiene
Scenario walkthrough
Ship checklist
Interview-style Q&A

Body

1. Threat model — think like an attacker

Threat	What they do	Your defense
Casual user	Screenshot, share device	Privacy screen, short session, biometric gate
Stolen device	Unlock later, read local data	Keychain/Keystore, biometric + short TTL tokens
Network attacker	MITM on café Wi‑Fi	HTTPS only, certificate pinning (high-risk apps)
Reverse engineer	Decompile APK / read bundle	No secrets in JS, ProGuard/R8, obfuscation limits
Malicious app	Read backups, abuse intents	`allowBackup=false`, validate deep links
Compromised dependency	Steal tokens at runtime	Lockfile, audits, minimal native modules

Golden rule

Anything shipped inside the app binary can eventually be extracted. Real secrets live on the server. The app holds capabilities (tokens) that must be short-lived, revocable, and stored as safely as the OS allows.

2. Security decision map — what to use where

You need to…	Do this	Avoid
Store access / refresh token	Keychain (iOS) / Keystore-backed storage (Android)	`AsyncStorage`, plain files, Redux Persist without encryption
Store user prefs (theme, flags)	`AsyncStorage` / MMKV (non-secret)	Putting tokens next to prefs
API keys for your backend	Backend only; app uses user session	Hardcoding in JS / `.env` baked into bundle
Third-party keys (Maps, etc.)	Restrict by bundle id / SHA-1; treat as semi-public	Assuming the key is private
Unlock returning user	Biometric + secure-stored refresh token	“Biometric only” with token in AsyncStorage
Talk to API	HTTPS + timeout + auth header	Cleartext HTTP in production
Open `myapp://…` links	Allowlist hosts/paths; auth gate	Blind `navigate(params.screen)`
Hide screen in app switcher	Privacy overlay / `FLAG_SECURE` where needed	Leaving banking screens visible in recents
Debug logs in prod	Strip / gate behind `__DEV__`	Logging tokens, passwords, PII

3. Secrets & secure storage

3.1 The storage ladder

Data	Storage	Notes
Access token	Secure storage	Short TTL (minutes)
Refresh token	Secure storage	Rotating; revoke on logout / reuse
PII cache	Encrypted DB or don’t cache	Minimize retention
Feature flags / theme	AsyncStorage / MMKV	Non-sensitive
Offline content	App documents	No secrets in filenames/logs

Popular RN libraries:

react-native-keychain
expo-secure-store (Expo)
MMKV with encryption only if you manage the key correctly (key in Keychain, not hardcoded)

3.2 Scenario: Persist session the wrong way vs right way

// BAD — readable on rooted devices / backups / forensic tools
import AsyncStorage from '@react-native-async-storage/async-storage';
await AsyncStorage.setItem('token', accessToken);

// GOOD — OS-backed secure storage
import * as Keychain from 'react-native-keychain';

await Keychain.setGenericPassword('session', accessToken, {
  accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  // Optional: require biometric to read
  accessControl: Keychain.ACCESS_CONTROL.BIOMETRY_CURRENT_SET,
});

const creds = await Keychain.getGenericPassword();
const token = creds ? creds.password : null;

On logout — always wipe

await Keychain.resetGenericPassword();
// also clear in-memory auth state / query cache

3.3 Never ship server secrets in the bundle

// BAD — visible in the JS bundle
const STRIPE_SECRET = 'sk_live_...';
const ADMIN_API_KEY = 'super-secret';

// GOOD — app calls your backend; backend holds secrets
await api.createPaymentIntent({orderId});

.env files used with bundlers still often end up in the client bundle if imported by app code. Treat client env as public configuration, not secret storage.

4. Authentication & sessions

4.1 Recommended token shape

Token	Lifetime	Where	Used for
Access token	5–30 min	Memory + optional secure storage	`Authorization` header
Refresh token	Days–weeks	Secure storage only	Get new access token
ID token (OIDC)	Short	Memory	User profile claims (validate server-side)

4.2 Scenario: Auth context that doesn’t leak tokens into logs

async function login(email, password) {
  const {accessToken, refreshToken, user} = await api.login({email, password});

  await Keychain.setGenericPassword('refresh', refreshToken, {
    accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  });

  // Keep access token in memory when possible
  setSession({accessToken, user});
}

async function refreshSession() {
  const creds = await Keychain.getGenericPassword();
  if (!creds) throw new Error('No session');

  const {accessToken, refreshToken} = await api.refresh(creds.password);
  await Keychain.setGenericPassword('refresh', refreshToken, {
    accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  });
  setSession(prev => ({...prev, accessToken}));
}

Server rules that matter more than client code

Rotate refresh tokens; detect reuse → revoke family
Bind sessions to device where product allows
Rate-limit login / OTP
Never trust client-sent userId without auth

4.3 Scenario: Attach token in API client (without printing it)

async function apiFetch(path, options = {}) {
  const token = getAccessTokenFromMemory();
  const res = await fetch(`${API_URL}${path}`, {
    ...options,
    headers: {
      'Content-Type': 'application/json',
      ...(token ? {Authorization: `Bearer ${token}`} : {}),
      ...options.headers,
    },
  });

  if (res.status === 401) {
    await refreshSession();
    return apiFetch(path, options); // careful: one retry max
  }

  return res;
}

Add a single-flight refresh (mutex) so parallel 401s don’t rotate the refresh token twice.

5. Biometrics

Biometrics protect access to a key/token on device — they are not a replacement for server auth.

Scenario: “Unlock app” with biometrics

Flow:

User logs in with password / OTP once
Refresh token stored in Keychain with biometric access control
Next launch → biometric prompt → read token → refresh session

import ReactNativeBiometrics from 'react-native-biometrics';
// or @sbaiahmed1/react-native-biometrics — same idea: prompt then use secure storage

async function unlockWithBiometrics() {
  const rnBio = new ReactNativeBiometrics();
  const {success} = await rnBio.simplePrompt({
    promptMessage: 'Unlock to continue',
  });
  if (!success) return null;

  const creds = await Keychain.getGenericPassword();
  if (!creds) return null;
  return refreshSessionWith(creds.password);
}

Platform config

iOS: NSFaceIDUsageDescription in Info.plist
Android: USE_BIOMETRIC permission; prefer BiometricPrompt APIs via a maintained library

Don’t

Store the password and “secure it” with a boolean biometricsEnabled in AsyncStorage
Skip server refresh and trust a local isAuthenticated: true flag

6. Network security

6.1 HTTPS only

Production API: HTTPS only
Android: disable cleartext unless a debug-only exception exists
iOS: App Transport Security (ATS) — don’t weaken globally for convenience

Android (concept)

<!-- Release: cleartext off -->
<application
  android:usesCleartextTraffic="false"
  android:allowBackup="false"
  ...>

Use a network security config if you need cleartext only for debug builds / emulators.

iOS — avoid blanket:

<key>NSAllowsArbitraryLoads</key>
<true/>

6.2 Certificate pinning (when it is worth it)

Pinning reduces MITM risk if a user installs a custom CA (or a CA is compromised). Cost: cert rotation must be planned.

App type	Pinning?
Banking / health / high-fraud	Strongly consider
Typical consumer MVP	HTTPS + good auth often enough
Apps with frequent cert changes	Pin carefully (backup pins)

Libraries / approaches: react-native-ssl-pinning, OkHttp CertificatePinner (Android), TrustKit (iOS), or a maintained networking stack that supports pins.

6.3 Scenario: Safer `fetch` defaults

const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 15000);

try {
  const res = await fetch(url, {
    signal: controller.signal,
    headers: {Authorization: `Bearer ${token}`},
  });
  // validate res.ok + JSON schema for critical payloads
} finally {
  clearTimeout(timeout);
}

Also:

Pin API host in config (don’t accept arbitrary base URLs from user input)
Validate deep-link-driven URLs before WebView / Linking.openURL

7. Deep links, intents & WebViews

7.1 Deep links are public entry points

// BAD — attacker opens myapp://open?screen=Admin&userId=1
navigation.navigate(params.screen, params);

// GOOD — allowlist routes; ignore unexpected params
const routes = {
  product: id => navigation.navigate('Details', {id}),
  reset: token => navigation.navigate('ResetPassword', {token}),
};

function handleUrl(url) {
  const {path, queryParams} = parse(url);
  const open = routes[path];
  if (!open) return;
  open(queryParams.id || queryParams.token);
}

Rules

Allowlist paths
Never take a raw screen name from the URL
Require auth for private screens after cold start
Use https app links / universal links with verified assetlinks / AASA where possible

7.2 Android exported components

Only export activities/services that must receive outside intents. Validate intent extras. Prefer android:exported="false" by default for non-entry components.

7.3 WebViews

Risk	Mitigation
JS bridge abuse	Expose minimal API; never raw `eval` of remote strings
Phishing	Restrict navigation to allowlisted domains
Token theft	Don’t inject tokens into arbitrary pages
File access	Disable unused file / universal access settings

<WebView
  source={{uri: httpsUrlYouTrust}}
  originWhitelist={['https://*']}
  onShouldStartLoadWithRequest={req => isAllowed(req.url)}
  // avoid mixed content; careful with injectedJavaScript
/>

8. Code protection & reverse engineering

Assume the JS bundle is readable. Your goal is raise cost, not perfect secrecy.

Layer	Action
JS	No secrets; minimize sensitive strings; Hermes bytecode helps a bit, not enough alone
Android	R8/ProGuard minify for release; shrink resources
iOS	Strip symbols in release; don’t ship debug entitlements
Integrity	Server checks + optional Play Integrity / App Attest for high-risk actions
Root detection	Optional signal — never sole auth factor

// android/app/build.gradle (release)
buildTypes {
  release {
    minifyEnabled true
    shrinkResources true
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
  }
}

Keep ProGuard rules for RN / Hermes / your native libs so release builds don’t break.

9. Device integrity & privacy

9.1 Root / jailbreak detection

Useful as a risk signal (block payments, force re-login, warn). Easy to bypass on determined devices — pair with server-side fraud checks.

9.2 Scenario: Hide sensitive screen in app switcher

Android — FLAG_SECURE (blocks screenshots + hides recents content):

// via a native module / library that sets WindowManager.LayoutParams.FLAG_SECURE
enableSecureView();  // on banking / OTP screens
disableSecureView(); // when leaving

iOS — blank the screen on background / capture notifications; avoid leaving OTP visible in app switcher.

9.3 Clipboard & screenshots

Don’t auto-copy OTPs to clipboard without UX need
Clear clipboard after paste on sensitive flows when appropriate
Warn before allowing screenshots on regulated screens (where OS allows)

9.4 Local authentication lock

import {AppState} from 'react-native';

// Pseudo-flow
// when AppState goes background → mark "needsUnlock"
// when active again after N minutes → show biometric / PIN gate

10. Logging, analytics & PII

Scenario: Accidental token leak

// BAD
console.log('login response', response);
console.log('Authorization', headers);

// GOOD
if (__DEV__) {
  console.log('login ok', {userId: user.id});
}

Checklist

Gate verbose logs with __DEV__
Redact Authorization, cookies, tokens, passwords in any network logger
In crash reporting (Sentry, etc.), scrub headers and user input fields
Don’t send full form payloads to analytics

11. Permissions & platform config

Ask only what you need

Permission	Rule
Camera / mic / location	Justify in store listing + OS purpose strings
Biometric	Purpose string on iOS; prompt only when needed
Notifications	Request after value is clear, not on first frame
Exact alarms / overlay	High scrutiny — avoid unless required

Hardening defaults (examples)

<!-- AndroidManifest -->
<application
  android:allowBackup="false"
  android:usesCleartextTraffic="false"
  ...>

<!-- Info.plist: Face ID purpose (required if you use Face ID) -->
<key>NSFaceIDUsageDescription</key>
<string>Unlock your account securely</string>

allowBackup="false" reduces accidental token exfiltration via Android backup — align with product needs (some apps want backup; then encrypt sensitive data).

12. Dependencies & supply chain

React Native apps pull a lot of native code. One shady package can read Keychain via your own privileges.

Practices

Commit yarn.lock / package-lock.json
Run npm audit / yarn npm audit in CI (triage realistically)
Prefer maintained libraries with recent releases
Minimize native modules — each is attack + maintenance surface
Review postinstall scripts on new deps
Use Dependabot / Renovate for security patches

yarn npm audit
npx react-native info   # know your native surface

13. CI / secrets hygiene

Secret	Where it belongs
Keystore passwords / signing	CI secrets / ESC encrypted store
App Store Connect / Play JSON	CI secrets
API admin keys	Server / CI only
`google-services.json` / `GoogleService-Info.plist`	Often required in app — restrict APIs in cloud console

Never commit:

*.keystore with production keys
.env with production secrets
Personal access tokens

Use different dev / staging / prod API environments and signing identities.

14. Scenario walkthrough — login to API call

Product flow: email login → secure session → biometric next launch → fetch profile.

1. User submits email/password over HTTPS
2. Server returns access + refresh tokens
3. App stores refresh token in Keychain (biometric-protected optional)
4. Access token kept in memory; Authorization on API calls
5. On 401 → single-flight refresh → retry once
6. On logout → Keychain reset + memory clear + query cache clear
7. Cold start → biometric → read refresh → new access token
8. Logs never print tokens; cleartext disabled; allowBackup false

Where bugs usually appear

Refresh token left in AsyncStorage “just for now”
Access token logged by a debug axios interceptor in prod
Deep link opens ResetPassword without validating token server-side
Staging HTTP cleartext flag left on for release builds

15. Ship checklist

Storage & auth

[ ] Tokens in Keychain/Keystore-backed storage — not AsyncStorage
[ ] Logout clears secure storage + in-memory session
[ ] Refresh rotation / revoke strategy exists on server
[ ] Biometric unlock does not replace server auth

Network

[ ] HTTPS only in release
[ ] Cleartext disabled for production Android / ATS not wide-open on iOS
[ ] Timeouts on API calls
[ ] Pinning considered for high-risk apps (+ cert rotation plan)

Platform

[ ] allowBackup decided intentionally (false for sensitive apps)
[ ] Deep links allowlisted; no dynamic navigate(params.screen)
[ ] WebView domain allowlist
[ ] Face ID / biometric usage strings present

Privacy & abuse

[ ] Sensitive screens consider FLAG_SECURE / privacy overlay
[ ] __DEV__-gated logs; crash reporter redaction
[ ] Minimal permissions; purpose strings accurate

Release engineering

[ ] R8/ProGuard (Android) enabled and tested
[ ] No production secrets in JS bundle
[ ] Lockfile committed; audit run
[ ] Signing keys only in CI / secure store

16. Interview-style Q&A

Q: Is AsyncStorage encrypted?

A: No. It is plain app storage. Fine for preferences; wrong for tokens.

Q: Does Hermes / minify make the app secure?

A: It raises the bar slightly. It does not protect API keys or tokens embedded in the client.

Q: Should every app use SSL pinning?

A: No. Use HTTPS everywhere; add pinning for higher threat models and be ready for pin updates.

Q: Is biometric login enough?

A: Biometrics gate local access to a stored secret. The server must still validate refresh/access tokens.

Q: Where do you put Firebase / Maps keys?

A: In the app if the SDK requires it — but restrict them by application id / SHA in the cloud console. Never put server admin keys in the app.

Q: What’s the first security fix you’d make on a messy RN codebase?

A: Move tokens out of AsyncStorage into Keychain, disable cleartext in release, wipe secrets from console.log, and allowlist deep links.

Conclusion

React Native security is mostly discipline: treat the client as hostile, put real secrets on the server, store session material in OS secure storage, force HTTPS, and stop leaking data through logs, backups, and sloppy deep links.

Takeaways

No secrets in the JS bundle — only short-lived, revocable capabilities
Keychain/Keystore for tokens; AsyncStorage for non-sensitive prefs
HTTPS + careful cleartext/ATS config in release
Biometrics protect local unlock, not server identity alone
Allowlist deep links and WebView URLs
Redact logs and enable release minify/hardening

Next steps

Grep your app for AsyncStorage + token / password / Bearer
Turn off cleartext + review allowBackup for release
Add logout that truly clears secure storage
Walk one deep link and one WebView through an allowlist review
Add a CI audit step and secret scanning on PRs

Call to action

What’s the biggest security gap you’ve seen in a React Native app — tokens in AsyncStorage, cleartext HTTP, or logs leaking auth headers?

Comment below with your war story (redact secrets!). If this guide helped, share it with your team before the next release.

Want a follow-up deep dive? Tell me: SSL pinning in RN, OWASP MASVS mapped to RN, or secure biometric + PIN architecture.

React Native Hooks in Depth — Examples, Scenarios & Production Patterns

Amit Kumar — Wed, 22 Jul 2026 16:57:39 +0000

React Native Hooks in Depth — Examples, Scenarios & Production Patterns

Introduction

You open a screen, fetch a list, tap a favorite, rotate the phone, go to background, come back — and suddenly you have a memory leak, a double API call, or a button that feels laggy.

In modern React Native, almost all of that logic lives in hooks.

What are hooks?

Hooks are functions that let function components use state, side effects, refs, context, and memoization — without class components. Same React hooks work in React Native; the difference is where you use them (screens, lists, native modules, AppState, dimensions, safe areas).

Why this matters in React Native

Screens mount/unmount more often than web pages (navigation stacks)
Lists re-render aggressively (FlatList)
Device events (keyboard, AppState, orientation) create real side effects
Wrong useEffect / missing cleanup = leaks, duplicate network calls, jank

What this article covers

Mental model & Rules of Hooks
What hook to use and where (decision guide + full hooks table)
Core React hooks with scenario-based examples
Concurrent & advanced hooks (useTransition, useDeferredValue, useId, …)
React Native–specific hooks
Navigation hooks
Redux hooks
Custom hooks you will actually reuse
Common pitfalls + checklist

Mental model
Rules of Hooks
What hook to use and where
useState
useEffect
useLayoutEffect
useRef
useMemo & useCallback
useReducer
useContext
useImperativeHandle
useDebugValue
useId
useTransition & useDeferredValue
useSyncExternalStore
useInsertionEffect
RN platform hooks
Navigation hooks
Redux hooks
Custom hooks
Full screen example
Pitfalls
Checklist

Body

1. Mental model: what a hook really does

Hook family	Job	RN example
State	Remember UI data across renders	Form input, modal open
Effect	Sync with outside world	API fetch, AppState, listeners
Ref	Mutable value / native node	Scroll position, TextInput focus
Context	Share data without prop drilling	Theme, auth user
Memoization	Skip expensive work / stable fns	List `renderItem`, heavy filters
Reducer	Complex / multi-step state	Checkout wizard, filters
Concurrent	Defer non-urgent UI work	Search that filters a big catalog
External store	Subscribe outside React state	Redux, AppState adapters
Navigation	Screen lifecycle & routing	Focus refetch, route params
Platform	Device / system signals	Dark mode, window size

Golden rule

Hooks run top-to-bottom on every render. Effects run after paint. Cleanup runs before next effect or on unmount.

Render vs commit (RN mental model)

Render — your function runs; hooks return current values
Commit — React applies updates to native views
useLayoutEffect — runs after commit, before the user paints
useEffect — runs after paint — safe for network, AppState, logging

2. Rules of Hooks (non-negotiable)

Only call hooks at the top level (not inside if, loops, or nested functions)
Only call hooks from React function components or custom hooks
Custom hooks must start with use
Dependency arrays must be honest — include values you read from the closure

// BAD — conditional hook (order can change between renders)
if (isLoggedIn) {
  useEffect(() => {}, []);
}

// GOOD — condition inside the effect
useEffect(() => {
  if (!isLoggedIn) return;
  // ...
}, [isLoggedIn]);

Strict Mode note (React 18+ / modern RN): In development, React may mount → unmount → remount and run effects twice to surface missing cleanups. If you see double API calls only in dev, check cleanup first — don’t “fix” it by disabling Strict Mode.

3. What hook to use and where

Use this section as a decision map. Pick the situation on the left → use the hook on the right.

3.1 Full hooks reference

Hook	Purpose
`useState`	Local state
`useEffect`	Side effects
`useContext`	Access Context
`useReducer`	Complex state
`useRef`	Mutable references
`useMemo`	Memoize computed values
`useCallback`	Memoize functions
`useLayoutEffect`	Run before paint
`useImperativeHandle`	Expose child methods
`useDebugValue`	Debug custom hooks
`useId`	Unique IDs
`useTransition`	Non-urgent updates
`useDeferredValue`	Defer expensive rendering
`useSyncExternalStore`	External store subscriptions
`useInsertionEffect`	Library-level style insertion
`useColorScheme`	Detect light/dark mode
`useWindowDimensions`	Responsive screen dimensions
`useNavigation`	Navigation actions
`useRoute`	Access route params
`useFocusEffect`	Screen focus lifecycle
`useIsFocused`	Check screen focus
`useNavigationState`	Read navigation state
`useSelector`	Read Redux state
`useDispatch`	Dispatch Redux actions
`useStore`	Access Redux store

3.2 One-glance decision table

You need to…	Use	Where it usually lives
Show / change UI data (input, toggle, modal, loading flag)	`useState`	Screen, component, custom hook
Many related updates / wizard / state machine	`useReducer`	Complex screens, form flows
Run something after render (API, listener, timer)	`useEffect`	Screens, providers, custom hooks
Fix layout/scroll before user sees a flash	`useLayoutEffect`	Lists, measuring views, chat scroll
Keep a value without re-render (timer id, flag)	`useRef`	Any component / custom hook
Call imperative native API (`.focus()`, scroll)	`useRef` + `ref={}`	Inputs, `FlatList`, video players
Expose `.focus()` / `.scrollTo()` from a child via `ref`	`useImperativeHandle` + `forwardRef`	Input wrappers, list wrappers
Share auth / theme / locale across many screens	`useContext` (+ Provider)	`App.js` / root → read in screens
Cache expensive derived data	`useMemo`	Filters, sorted lists, heavy calc
Keep a stable function for list / memo child	`useCallback`	`FlatList` handlers, memoized rows
Keep typing smooth while a heavy list filters	`useDeferredValue` / `useTransition`	Search screens, big grids
Stable accessibility / form field ids	`useId`	Forms, a11y labels
Subscribe to Redux / Zustand / external store	`useSyncExternalStore` or `useSelector`	Store adapters, libraries
Label a custom hook in React DevTools	`useDebugValue`	Custom hooks only
Inject CSS-in-JS styles before layout (libs)	`useInsertionEffect`	Style libraries — not app screens
Reload when screen is focused (tabs)	`useFocusEffect`	Tab screens, stack screens that stay mounted
Boolean “is this screen focused?”	`useIsFocused`	Conditional UI / pause video
Read current route name / nav tree	`useNavigationState`	Analytics, deep-link helpers
Navigate or read route params	`useNavigation` / `useRoute`	Screens inside a navigator
Read / write Redux state	`useSelector` / `useDispatch`	Screens connected to Redux
Pad for notch / home indicator	`useSafeAreaInsets`	Custom headers, full-screen modals
React to rotate / width breakpoints	`useWindowDimensions`	Responsive layouts, grids
Follow system light/dark	`useColorScheme`	Theme tokens, screen backgrounds
Reuse the same logic in 2+ places	Custom hook (`useX`)	`src/hooks/`

3.3 Decision flow (ask in order)

Does the UI need to update when this value changes?
  YES → useState (or useReducer if transitions are complex)
  NO  → Is it a DOM/native node or “latest value” box?
          YES → useRef
          NO  → Is it shared across many screens?
                  YES → useContext (or external store)
                  NO  → Derive it: const x = ... or useMemo if expensive

Is this talking to the outside world (API, AppState, Keyboard)?
  YES → useEffect (cleanup!) 
        Need it on every focus in a tab? → useFocusEffect
        Need zero visual flash? → useLayoutEffect

Is a child / FlatList re-rendering too much because props change identity?
  YES → useCallback for functions, useMemo for objects/arrays
  NO  → don’t add memo hooks yet

Is typing / pressing blocked by a heavy re-render?
  YES → useDeferredValue (lag the heavy value) or useTransition (mark the update)
  NO  → leave concurrent hooks alone

3.4 Where each hook belongs in an RN app

Layer	Typical hooks	Avoid here
Root (`App.js`)	`useState`/`useReducer` for bootstrapping, Context Providers	Heavy fetch for every screen
Providers (Auth, Theme)	`useState`, `useMemo` (value), `useEffect` (hydrate token)	Navigation hooks (not inside nav yet)
Navigators	Rarely — keep thin	Business `useEffect` fetch
Screens	`useState`, `useEffect` / `useFocusEffect`, nav hooks, safe area, dimensions	Deep prop drilling — lift to context/hook
List rows / pure UI	Prefer props only; maybe `useState` for local press/animation	Fetching, AppState, navigation side effects
`src/hooks/`	Any composition of the above	JSX (hooks return data/fns, not UI)

3.5 Situation → hook (scenario cheat sheet)

Scenario	Hook(s)	Why
TextInput value	`useState`	UI must re-render as user types
Modal open/close	`useState` or `useToggle`	Simple boolean UI
Checkout steps + address + payment	`useReducer`	Multiple coordinated transitions
Fetch on first mount only	`useEffect([])`	One-shot sync with server
Fetch every time user opens a tab	`useFocusEffect`	Tab screen often stays mounted
Search while typing	`useState` + `useDebouncedValue` + `useEffect`	Debounce then fetch
Heavy filter that shouldn’t block keystrokes	`useDeferredValue`	Defer list re-render
Mark a filter update as non-urgent	`useTransition`	Keep presses responsive
Pause video in background	`useEffect` + `AppState` (or `useAppState`)	Subscribe/cleanup native event
Focus password field	`useRef`	Imperative `.focus()`, no re-render
Parent calls child `.focus()` via `ref`	`useImperativeHandle`	Controlled public API
“Latest props” inside a long-lived listener	`useRef` + `useEffect`	Avoid re-binding listener every render
Filter 5k products	`useMemo`	Expensive derive; don’t store duplicate state
`FlatList` `renderItem` / `onPress`	`useCallback`	Stable identity → fewer cell updates
Auth user in Profile + Home + Settings	`useContext` / `useAuth`	Avoid prop drilling through navigators
Cart count from Redux	`useSelector`	Subscribe to one slice
Dispatch `addToCart`	`useDispatch`	Fire actions from UI
Custom header under notch	`useSafeAreaInsets`	Device-correct padding
2 columns phone / 3 tablet	`useWindowDimensions`	Responds to rotation
Dark mode colors	`useColorScheme`	Follows system appearance
Hide tab bar badge only when focused	`useIsFocused`	Focus is a boolean
Log current route name	`useNavigationState`	Read nav tree safely
Prevent leave with dirty form	`useNavigation` + `useEffect` (`beforeRemove`)	Navigation lifecycle
Same fetch logic on 3 screens	`useFetch` / React Query	Share logic; Query if you need cache
Cache + retry + focus refetch	TanStack Query / SWR	Don’t hand-roll this in `useEffect`
Cancel in-flight request on leave	`AbortController` in effect cleanup	Cleaner than `isMounted` flags

3.6 What not to use (common mis-picks)

Tempting choice	Better choice	Why
`useState` for `items.length`	Derive: `items.length`	Don’t sync derived data
`useEffect` to update state from props	Compute during render	Avoid extra render loops
`useEffect` for tab refetch	`useFocusEffect`	Mount ≠ focus
`useMemo` on every variable	Use only when measured	Noise, little gain
`useCallback` on every function	Use for list/memo children	Same reason
`useRef` for something shown in UI	`useState`	Ref changes don’t re-render
Context for high-frequency values (scroll X)	`useRef` / Reanimated shared value	Context re-renders all consumers
`useInsertionEffect` in a screen	`useEffect` / StyleSheet	Reserved for style libraries
`useStore` to render UI from Redux	`useSelector`	`useStore` doesn’t subscribe
Returning whole nav `state` from `useNavigationState`	Select `route.name` (etc.)	Avoid extra re-renders
Fetch inside list row	Fetch in screen / query hook	N rows = N requests

3.7 Mini map — “I am building X”

Login screen

Fields → useState
Submit loading/error → useState
Focus next input → useRef
On success navigate → useNavigation

Feed / Explore

Data/loading → useState or useFetch
Debounced search → custom useDebouncedValue
Refetch on focus → useFocusEffect
Grid columns → useWindowDimensions
Row press → useCallback + useNavigation

Chat

Messages → useState / useReducer
Scroll to end without flash → useLayoutEffect + useRef
Socket subscribe → useEffect + cleanup
App background → useAppState

Profile / Settings

User → useAuth (useContext)
Local form draft → useState
Unsaved guard → useNavigation listener
Safe header → useSafeAreaInsets

Root app shell

Providers → Auth/Theme with useState + useMemo
Bootstrap token → useEffect once
Not: per-screen list fetching

4. `useState` — UI memory

What it is

useState stores a value that survives re-renders and triggers a re-render when updated.

const [value, setValue] = useState(initialValue);
// Lazy init — function runs once on mount (good for expensive setup)
const [value, setValue] = useState(() => expensiveCreate());

Use when: the user (or UI) must see the change.

Don’t use when: the value is derived (items.length) or only needed imperatively (useRef).

Scenario: Favorite toggle on a product card

Problem: User taps heart; icon should flip instantly and stay in sync with server.

import React, {useState} from 'react';
import {Pressable, Text} from 'react-native';

function FavoriteButton({productId, initiallyFavorite}) {
  const [isFavorite, setIsFavorite] = useState(initiallyFavorite);
  const [loading, setLoading] = useState(false);

  const onToggle = async () => {
    if (loading) return;

    const next = !isFavorite;
    setIsFavorite(next); // optimistic
    setLoading(true);

    try {
      await api.setFavorite(productId, next);
    } catch {
      setIsFavorite(!next); // rollback
    } finally {
      setLoading(false);
    }
  };

  return (
    <Pressable onPress={onToggle} disabled={loading}>
      <Text>{isFavorite ? '♥' : '♡'}</Text>
    </Pressable>
  );
}

Why this pattern

Optimistic update feels native-fast
Rollback keeps UI honest when the network fails
Functional updates avoid stale state on rapid taps

Functional updates (avoid stale state)

// BAD if multiple updates queue quickly
setCount(count + 1);

// GOOD — always based on latest queued value
setCount(prev => prev + 1);

Scenario: Counter with rapid taps

import React, {useState} from 'react';
import {Pressable, Text, View} from 'react-native';

function CartQty() {
  const [qty, setQty] = useState(1);

  return (
    <View style={{flexDirection: 'row', alignItems: 'center', gap: 12}}>
      <Pressable onPress={() => setQty(q => Math.max(1, q - 1))}>
        <Text>-</Text>
      </Pressable>
      <Text>{qty}</Text>
      <Pressable onPress={() => setQty(q => q + 1)}>
        <Text>+</Text>
      </Pressable>
    </View>
  );
}

5. `useEffect` — side effects & cleanup

What it is

useEffect runs code after render to sync with something outside React: APIs, timers, event emitters, native listeners.

Dependency patterns

Deps	When it runs
`[]`	Mount once (+ cleanup on unmount)
`[a, b]`	Mount + whenever `a` or `b` changes
omitted	Every render (almost always a bug)

Scenario: Fetch list when screen opens

import React, {useEffect, useState} from 'react';
import {ActivityIndicator, FlatList, Text} from 'react-native';

function ExploreScreen() {
  const [items, setItems] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let alive = true;

    (async () => {
      try {
        setLoading(true);
        const data = await api.getExplore();
        if (alive) setItems(data);
      } catch (e) {
        if (alive) setError(e.message);
      } finally {
        if (alive) setLoading(false);
      }
    })();

    return () => {
      alive = false; // prevent setState after unmount / navigation away
    };
  }, []);

  if (loading) return <ActivityIndicator />;
  if (error) return <Text>{error}</Text>;

  return (
    <FlatList
      data={items}
      keyExtractor={item => String(item.id)}
      renderItem={({item}) => <Text>{item.title}</Text>}
    />
  );
}

Why alive (or AbortController)?

User can leave the screen before the request finishes. Updating state after unmount wastes work and hides missing cleanups (especially under Strict Mode). Prefer aborting the request when you can:

useEffect(() => {
  const controller = new AbortController();

  (async () => {
    try {
      const data = await api.getExplore({signal: controller.signal});
      setItems(data);
    } catch (e) {
      if (e.name === 'AbortError') return;
      setError(e.message);
    }
  })();

  return () => controller.abort();
}, []);

Scenario: Pause video when app goes to background

import {useEffect} from 'react';
import {AppState} from 'react-native';

function usePauseOnBackground(videoRef) {
  useEffect(() => {
    const sub = AppState.addEventListener('change', state => {
      if (state !== 'active') {
        videoRef.current?.pause?.();
      }
    });

    return () => sub.remove();
  }, [videoRef]);
}

Cleanup is mandatory for:

AppState / Keyboard listeners
setInterval / setTimeout
WebSocket / EventEmitter subscriptions
Navigation listeners

Prefer useWindowDimensions over manual Dimensions.addEventListener for size changes.

Scenario: Debounced search

import React, {useEffect, useState} from 'react';
import {FlatList, Text, TextInput} from 'react-native';

function useDebouncedValue(value, delay = 300) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(id);
  }, [value, delay]);

  return debounced;
}

function SearchScreen() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const debounced = useDebouncedValue(query);

  useEffect(() => {
    if (!debounced.trim()) {
      setResults([]);
      return;
    }

    let alive = true;
    api.search(debounced).then(data => {
      if (alive) setResults(data);
    });

    return () => {
      alive = false;
    };
  }, [debounced]);

  return (
    <>
      <TextInput value={query} onChangeText={setQuery} placeholder="Search" />
      <FlatList
        data={results}
        keyExtractor={item => String(item.id)}
        renderItem={({item}) => <Text>{item.title}</Text>}
      />
    </>
  );
}

`useEffect` vs data libraries

Approach	Best for
`useEffect` + `useState`	Simple one-off fetch, learning, tiny screens
React Query / TanStack Query / SWR	Cache, retry, focus refetch, deduping, pagination
Custom `useFetch`	Shared loading/error shape across a few screens

Rule of thumb: If you are inventing cache keys, stale-while-revalidate, or focus refetch by hand — use a query library.

6. `useLayoutEffect` — before paint (use carefully)

Runs synchronously after DOM/native updates, before paint. In RN, use it when you must measure/layout before the user sees a flash.

Scenario: Scroll to a message without flicker

import {useLayoutEffect, useRef} from 'react';
import {FlatList} from 'react-native';

function Chat({messages}) {
  const listRef = useRef(null);

  useLayoutEffect(() => {
    if (messages.length === 0) return;
    listRef.current?.scrollToEnd({animated: false});
  }, [messages.length]);

  return <FlatList ref={listRef} data={messages} /* ... */ />;
}

Prefer useEffect for network/AppState. Prefer useLayoutEffect for measurement / scroll position that would otherwise flash.

7. `useRef` — mutable box & native handles

What it is

useRef holds a mutable .current that does not trigger re-render when changed.

Scenario A: Focus the next input

import React, {useRef} from 'react';
import {TextInput} from 'react-native';

function LoginForm() {
  const passwordRef = useRef(null);

  return (
    <>
      <TextInput
        returnKeyType="next"
        blurOnSubmit={false}
        onSubmitEditing={() => passwordRef.current?.focus()}
      />
      <TextInput ref={passwordRef} secureTextEntry />
    </>
  );
}

Scenario B: Store latest callback without re-subscribing

import {useCallback, useLayoutEffect, useRef} from 'react';

function useEvent(handler) {
  const ref = useRef(handler);
  useLayoutEffect(() => {
    ref.current = handler;
  });
  return useCallback((...args) => ref.current(...args), []);
}

Useful when an effect should always see the latest props/state but you don’t want to re-bind listeners every render. (Same idea as React’s experimental useEffectEvent.)

Scenario C: Ignore first render (skip initial effect)

import {useEffect, useRef} from 'react';

function useDidUpdate(effect, deps) {
  const mounted = useRef(false);

  useEffect(() => {
    if (!mounted.current) {
      mounted.current = true;
      return;
    }
    return effect();
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, deps);
}

Use sparingly — usually you want the first run too, or you can gate with if (!ready) return inside a normal effect.

8. `useMemo` & `useCallback` — performance tools (not defaults)

What they are

useMemo(() => value, deps) — cache an expensive computed value
useCallback(fn, deps) — cache a function identity

Do not wrap everything. Use when:

Computation is heavy, or
A child / FlatList depends on referential equality

Scenario: Filter a large list

function FavoritesScreen({products, query}) {
  const filtered = useMemo(() => {
    const q = query.trim().toLowerCase();
    return products.filter(p => p.title.toLowerCase().includes(q));
  }, [products, query]);

  return <FlatList data={filtered} /* ... */ />;
}

Scenario: Stable `renderItem` / handlers for list rows

useCallback alone is not enough if the row still receives a new inline function every time. Pair with React.memo and pass a stable handler + id.

import React, {memo, useCallback} from 'react';
import {FlatList, Pressable, Text} from 'react-native';

const ProductRow = memo(function ProductRow({item, onOpen}) {
  return (
    <Pressable onPress={() => onOpen(item.id)}>
      <Text>{item.title}</Text>
    </Pressable>
  );
});

function ProductList({products, onOpen}) {
  const renderItem = useCallback(
    ({item}) => <ProductRow item={item} onOpen={onOpen} />,
    [onOpen],
  );

  const keyExtractor = useCallback(item => String(item.id), []);

  return (
    <FlatList
      data={products}
      renderItem={renderItem}
      keyExtractor={keyExtractor}
      initialNumToRender={10}
      windowSize={7}
    />
  );
}

Interview line

useCallback does not make the function faster — it keeps the same function reference so React.memo children / list cells can skip re-renders. Without memo, useCallback often changes nothing.

9. `useReducer` — when state has multiple transitions

Scenario: Checkout / form wizard

const initial = {step: 0, address: null, payment: null, submitting: false};

function reducer(state, action) {
  switch (action.type) {
    case 'NEXT':
      return {...state, step: state.step + 1};
    case 'SET_ADDRESS':
      return {...state, address: action.payload};
    case 'SET_PAYMENT':
      return {...state, payment: action.payload};
    case 'SUBMIT_START':
      return {...state, submitting: true};
    case 'SUBMIT_DONE':
      return {...state, submitting: false};
    default:
      return state;
  }
}

function CheckoutScreen() {
  const [state, dispatch] = useReducer(reducer, initial);

  const submit = async () => {
    dispatch({type: 'SUBMIT_START'});
    try {
      await api.checkout(state);
      dispatch({type: 'SUBMIT_DONE'});
    } catch {
      dispatch({type: 'SUBMIT_DONE'});
    }
  };

  // render steps from state.step
}

When to prefer useReducer over many useStates

Next state depends on previous in complex ways
Multiple fields update together
You want named actions (easier to test/log)

10. `useContext` — share without prop drilling

Scenario: Auth across the app

Stabilize actions with useCallback, then memoize the context value so consumers don’t re-render when nothing meaningful changed.

import React, {
  createContext,
  useCallback,
  useContext,
  useMemo,
  useState,
} from 'react';
import {Pressable, Text} from 'react-native';

const AuthContext = createContext(null);

export function AuthProvider({children}) {
  const [user, setUser] = useState(null);

  const login = useCallback(async creds => {
    setUser(await api.login(creds));
  }, []);

  const logout = useCallback(() => setUser(null), []);

  const value = useMemo(
    () => ({user, login, logout}),
    [user, login, logout],
  );

  return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;
}

export function useAuth() {
  const ctx = useContext(AuthContext);
  if (!ctx) throw new Error('useAuth must be used within AuthProvider');
  return ctx;
}

function ProfileScreen() {
  const {user, logout} = useAuth();
  return (
    <Pressable onPress={logout}>
      <Text>Log out {user?.name}</Text>
    </Pressable>
  );
}

RN tips

Put providers above NavigationContainer so every screen can read them
Split contexts (Auth vs Theme) — a theme toggle shouldn’t re-render auth-heavy trees
Don’t put high-frequency values (scroll offset) in context — use refs / Reanimated

11. `useImperativeHandle` — expose child methods

What it is

useImperativeHandle customizes the instance value that a parent receives when it holds a ref to a child. Pair with forwardRef.

Scenario: Parent focuses a wrapped `TextInput`

import React, {forwardRef, useImperativeHandle, useRef} from 'react';
import {TextInput} from 'react-native';

const PasswordField = forwardRef(function PasswordField(props, ref) {
  const inputRef = useRef(null);

  useImperativeHandle(ref, () => ({
    focus: () => inputRef.current?.focus(),
    clear: () => inputRef.current?.clear(),
  }));

  return <TextInput ref={inputRef} secureTextEntry {...props} />;
});

function LoginScreen() {
  const passwordRef = useRef(null);

  return (
    <>
      <TextInput
        placeholder="Email"
        returnKeyType="next"
        onSubmitEditing={() => passwordRef.current?.focus()}
      />
      <PasswordField ref={passwordRef} placeholder="Password" />
    </>
  );
}

When to use

You own a reusable wrapper and want a small public API (.focus(), .scrollToEnd())
You want to hide internal refs from parents

When not to

Prefer props/onChange for normal data flow — don’t reach into children for state
Avoid exposing huge imperative surfaces; keep the handle tiny

12. `useDebugValue` — debug custom hooks

What it is

useDebugValue shows a label next to your custom hook in React DevTools. It has no effect on production UI.

import {useDebugValue, useEffect, useState} from 'react';
import {AppState} from 'react-native';

function useAppState() {
  const [state, setState] = useState(AppState.currentState);

  useEffect(() => {
    const sub = AppState.addEventListener('change', setState);
    return () => sub.remove();
  }, []);

  useDebugValue(state); // DevTools: useAppState: "active"
  // Or format lazily for expensive labels:
  // useDebugValue(state, s => `app=${s}`);

  return state;
}

RN tip: Use it on hooks you share across the team (useAuth, useFetch) so DevTools dumps are readable during screen debugging.

13. `useId` — unique IDs

What it is

useId returns a unique string ID that is stable across renders for that component instance. Handy for accessibility pairing when you don’t want collision-prone Math.random().

import {useId} from 'react';
import {Text, TextInput, View} from 'react-native';

function LabeledInput({label, value, onChangeText}) {
  const id = useId();

  return (
    <View>
      <Text nativeID={`${id}-label`}>{label}</Text>
      <TextInput
        accessibilityLabelledBy={[`${id}-label`]}
        value={value}
        onChangeText={onChangeText}
      />
    </View>
  );
}

Notes

IDs are for identity / a11y, not as React keys in lists
Prefer list item ids from your data for keyExtractor
On RN, a11y APIs differ slightly by platform — useId still gives you a stable unique string

14. `useTransition` & `useDeferredValue` — keep UI responsive

When a state update triggers heavy work (filtering thousands of rows), mark it non-urgent so typing / presses stay snappy.

`useTransition` — wrap the update

import {useState, useTransition} from 'react';
import {ActivityIndicator, FlatList, Pressable, Text} from 'react-native';

function CatalogScreen({allProducts}) {
  const [filter, setFilter] = useState('all');
  const [isPending, startTransition] = useTransition();

  const visible =
    filter === 'all'
      ? allProducts
      : allProducts.filter(p => p.category === filter);

  return (
    <>
      <Pressable
        onPress={() => {
          startTransition(() => {
            setFilter('sale');
          });
        }}>
        <Text>On sale</Text>
      </Pressable>
      {isPending ? <ActivityIndicator /> : null}
      <FlatList data={visible} keyExtractor={p => String(p.id)} /* ... */ />
    </>
  );
}

`useDeferredValue` — defer a derived value

import {useDeferredValue, useMemo, useState} from 'react';
import {FlatList, TextInput} from 'react-native';

function SearchScreen({products}) {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);

  const results = useMemo(() => {
    const q = deferredQuery.trim().toLowerCase();
    if (!q) return products;
    return products.filter(p => p.title.toLowerCase().includes(q));
  }, [products, deferredQuery]);

  return (
    <>
      <TextInput value={query} onChangeText={setQuery} placeholder="Search" />
      <FlatList data={results} keyExtractor={p => String(p.id)} /* ... */ />
    </>
  );
}

When to use which

Need	Hook
You control the `setState` that kicks off heavy work	`useTransition`
You already have a fast-changing value (search text) and want to lag the expensive consumer	`useDeferredValue`

RN tips

Still prefer FlashList / virtualization for huge lists — these hooks don’t replace list performance work
Pair with a lightweight pending indicator (isPending) so users know the filter is catching up
For network debounce, keep useDebouncedValue — concurrent hooks don’t replace API throttling

15. `useSyncExternalStore` — external store subscriptions

What it is

The officially supported way to subscribe a component to an external store (Redux under the hood, Zustand, a native module event bus, AppState wrappers) so React stays consistent with concurrent rendering.

import {useSyncExternalStore} from 'react';
import {AppState} from 'react-native';

function subscribe(onStoreChange) {
  const sub = AppState.addEventListener('change', onStoreChange);
  return () => sub.remove();
}

function getSnapshot() {
  return AppState.currentState;
}

function useAppStateStore() {
  return useSyncExternalStore(subscribe, getSnapshot, getSnapshot);
}

function StatusBanner() {
  const state = useAppStateStore();
  return <Text>App is {state}</Text>;
}

When to use

Building a tiny store / bridging a non-React data source
Library authors wiring subscriptions correctly

When not to

App screens usually use useSelector (Redux), Context, or a library hook that already wraps this
Don’t reinvent Redux with a hand-rolled store unless you need to

Rules

getSnapshot must return a cached / immutable value if nothing changed (same reference for objects)
Provide getServerSnapshot when SSR matters (rare in RN; still good for shared packages)

16. `useInsertionEffect` — library-level style insertion

What it is

useInsertionEffect fires before layout effects. It exists so CSS-in-JS libraries can inject styles early enough that layout reads see them.

import {useInsertionEffect} from 'react';

// Pattern for style libraries — not typical app screen code
function useInjectStyle(rule) {
  useInsertionEffect(() => {
    // library injects a style rule into a stylesheet
    const remove = styleEngine.insert(rule);
    return remove;
  }, [rule]);
}

For app developers

Prefer StyleSheet.create, theme objects, or your design-system APIs
You almost never call useInsertionEffect in a screen
If you maintain a styling library for RN/web, this is the right lifecycle slot

17. React Native platform hooks

These are the hooks you won’t see in plain React DOM apps as often.

`useWindowDimensions` — responsive layout

import {useWindowDimensions, View} from 'react-native';

function Hero() {
  const {width, height} = useWindowDimensions();
  const isTablet = width >= 768;

  return (
    <View style={{height: height * 0.4, padding: isTablet ? 32 : 16}}>
      {/* ... */}
    </View>
  );
}

Scenario: Phone vs tablet padding / columns without listening to Dimensions manually.

`useColorScheme` — light / dark

import {useColorScheme} from 'react-native';

function ThemedScreen() {
  const scheme = useColorScheme(); // 'light' | 'dark' | null
  const bg = scheme === 'dark' ? '#111' : '#fff';
  return <View style={{flex: 1, backgroundColor: bg}} />;
}

`useSafeAreaInsets` — notches & home indicator

import {useSafeAreaInsets} from 'react-native-safe-area-context';

function AppHeader() {
  const insets = useSafeAreaInsets();
  return (
    <View style={{paddingTop: insets.top, height: 56 + insets.top}}>
      <Text>Home</Text>
    </View>
  );
}

Scenario: Custom header under a notch — padding with insets.top instead of hardcoding 44.

Keyboard-aware pattern (custom hook)

import {useEffect, useState} from 'react';
import {Keyboard, Platform} from 'react-native';

function useKeyboardHeight() {
  const [height, setHeight] = useState(0);

  useEffect(() => {
    const showEvt =
      Platform.OS === 'ios' ? 'keyboardWillShow' : 'keyboardDidShow';
    const hideEvt =
      Platform.OS === 'ios' ? 'keyboardWillHide' : 'keyboardDidHide';

    const showSub = Keyboard.addListener(showEvt, e => {
      setHeight(e.endCoordinates.height);
    });
    const hideSub = Keyboard.addListener(hideEvt, () => setHeight(0));

    return () => {
      showSub.remove();
      hideSub.remove();
    };
  }, []);

  return height;
}

18. Navigation hooks (React Navigation)

Hook	Purpose
`useNavigation`	Navigate, go back, set options, add listeners
`useRoute`	Read `route.params` / route name for this screen
`useFocusEffect`	Run an effect when the screen is focused (with cleanup)
`useIsFocused`	Boolean: is this screen currently focused?
`useNavigationState`	Read (a slice of) the navigation state tree

Scenario: Open details + read params

import {useNavigation, useRoute, useFocusEffect} from '@react-navigation/native';
import {useCallback, useState} from 'react';

function HomeScreen() {
  const navigation = useNavigation();

  return (
    <Pressable
      onPress={() =>
        navigation.navigate('Details', {id: 42, title: 'React Native'})
      }>
      <Text>Open details</Text>
    </Pressable>
  );
}

function DetailsScreen() {
  const route = useRoute();
  const {id, title} = route.params;

  return <Text>{title} (#{id})</Text>;
}

Scenario: Refetch every time screen gains focus

useEffect([]) runs on mount only. In a tab navigator, the screen may stay mounted — use focus.

function FavoritesScreen() {
  const [items, setItems] = useState([]);

  useFocusEffect(
    useCallback(() => {
      let alive = true;
      api.getFavorites().then(data => {
        if (alive) setItems(data);
      });
      return () => {
        alive = false;
      };
    }, []),
  );

  return <FlatList data={items} /* ... */ />;
}

Scenario: `useIsFocused` — pause work when blurred

Prefer useFocusEffect when you need subscribe/cleanup. Use useIsFocused when you only need a boolean for UI or a child.

import {useIsFocused} from '@react-navigation/native';

function VideoTab() {
  const isFocused = useIsFocused();

  return <VideoPlayer paused={!isFocused} source={clip} />;
}

Scenario: `useNavigationState` — current route name

import {useEffect} from 'react';
import {useNavigationState} from '@react-navigation/native';

function useCurrentRouteName() {
  return useNavigationState(state => {
    let route = state.routes[state.index];
    while (route.state) {
      route = route.state.routes[route.state.index];
    }
    return route.name;
  });
}

function AnalyticsScreenTracker() {
  const routeName = useCurrentRouteName();

  useEffect(() => {
    analytics.screen(routeName);
  }, [routeName]);

  return null;
}

Tip: Pass a selector into useNavigationState so you re-render only when the selected slice changes — don’t return the whole state object unless you must.

Scenario: Prevent leaving with unsaved changes

import React, {useEffect, useState} from 'react';
import {Alert, TextInput} from 'react-native';
import {useNavigation} from '@react-navigation/native';

function EditProfileScreen() {
  const navigation = useNavigation();
  const [name, setName] = useState('');
  const [dirty, setDirty] = useState(false);

  useEffect(() => {
    const unsub = navigation.addListener('beforeRemove', e => {
      if (!dirty) return;
      e.preventDefault();
      Alert.alert('Discard changes?', '', [
        {text: 'Stay', style: 'cancel'},
        {
          text: 'Discard',
          style: 'destructive',
          onPress: () => navigation.dispatch(e.data.action),
        },
      ]);
    });
    return unsub;
  }, [navigation, dirty]);

  return (
    <TextInput
      value={name}
      onChangeText={text => {
        setName(text);
        setDirty(true);
      }}
    />
  );
}

19. Redux hooks (`useSelector`, `useDispatch`, `useStore`)

Use these when the app already has a Redux (or Redux Toolkit) store. They replace the old connect() HOC.

Hook	Purpose
`useSelector`	Read a slice of state; re-render when it changes
`useDispatch`	Get `dispatch` to fire actions / thunks
`useStore`	Rare — access the store instance directly

Scenario: Cart badge + add item

import {useDispatch, useSelector} from 'react-redux';
import {Pressable, Text} from 'react-native';
import {addItem} from './cartSlice';

function CartBadge() {
  const count = useSelector(state => state.cart.items.length);
  return <Text>{count}</Text>;
}

function ProductRow({product}) {
  const dispatch = useDispatch();

  return (
    <Pressable onPress={() => dispatch(addItem(product))}>
      <Text>Add {product.title}</Text>
    </Pressable>
  );
}

`useSelector` tips

// GOOD — primitive / stable selected value
const count = useSelector(state => state.cart.items.length);

// CARE — new array/object every time → extra re-renders
const items = useSelector(state =>
  state.cart.items.filter(i => i.qty > 0),
);

// BETTER — select raw data, derive in the component (or use a memoized selector)
const items = useSelector(state => state.cart.items);
const visible = useMemo(() => items.filter(i => i.qty > 0), [items]);

For expensive derived slices, use Reselect / RTK createSelector so equality checks stay cheap.

`useStore` — escape hatch

import {useStore} from 'react-redux';

function CheckoutButton() {
  const store = useStore();

  const onPress = () => {
    // Read once outside React render — e.g. analytics / non-reactive snapshot
    const {cart} = store.getState();
    analytics.track('checkout_start', {count: cart.items.length});
  };

  return <Pressable onPress={onPress}><Text>Checkout</Text></Pressable>;
}

Prefer useSelector for anything shown in the UI — useStore does not subscribe, so the component won’t re-render when state changes.

RN tips

Put <Provider store={store}> above NavigationContainer
Keep selectors narrow (badge count ≠ whole cart) to limit screen re-renders
Side effects (API) belong in thunks / listeners / useEffect, not inside reducers

20. Custom hooks — the real power move

A custom hook = reusable stateful logic with a use name.

`useFetch` — loading / error / data

Teaching version with AbortController. For production apps with cache/retry, prefer TanStack Query.

import {useEffect, useState} from 'react';

function useFetch(url) {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    if (!url) return;

    const controller = new AbortController();
    setLoading(true);
    setError(null);

    fetch(url, {signal: controller.signal})
      .then(r => {
        if (!r.ok) throw new Error(`HTTP ${r.status}`);
        return r.json();
      })
      .then(json => setData(json))
      .catch(e => {
        if (e.name === 'AbortError') return;
        setError(e);
      })
      .finally(() => {
        if (!controller.signal.aborted) setLoading(false);
      });

    return () => controller.abort();
  }, [url]);

  return {data, error, loading};
}

`useToggle`

import {useCallback, useState} from 'react';

function useToggle(initial = false) {
  const [on, setOn] = useState(initial);
  const toggle = useCallback(() => setOn(v => !v), []);
  const setTrue = useCallback(() => setOn(true), []);
  const setFalse = useCallback(() => setOn(false), []);
  return {on, toggle, setTrue, setFalse};
}

// Modal open/close
const modal = useToggle();
// modal.on, modal.toggle(), modal.setFalse()

`useAppState`

import {useEffect, useState} from 'react';
import {AppState} from 'react-native';

function useAppState() {
  const [state, setState] = useState(AppState.currentState);

  useEffect(() => {
    const sub = AppState.addEventListener('change', setState);
    return () => sub.remove();
  }, []);

  return state; // 'active' | 'background' | 'inactive'
}

Scenario: Refresh token only while app is active

function useSessionRefresh() {
  const appState = useAppState();

  useEffect(() => {
    if (appState !== 'active') return;
    const id = setInterval(() => {
      api.refreshToken();
    }, 60_000);
    return () => clearInterval(id);
  }, [appState]);
}

Prefer abort/`alive` over `useIsMounted`

A global isMounted flag is an older pattern. Prefer:

AbortController for fetch
Local let alive = true inside the effect that owns the async work

That keeps cancellation next to the subscription — easier to reason about under Strict Mode.

21. Putting it together — screen scenario

Feature: Explore screen with search, pull-to-refresh, responsive grid, and safe area.

import React, {useCallback, useState} from 'react';
import {
  ActivityIndicator,
  FlatList,
  Text,
  TextInput,
  useWindowDimensions,
  View,
} from 'react-native';
import {useFocusEffect, useNavigation} from '@react-navigation/native';
import {useSafeAreaInsets} from 'react-native-safe-area-context';

function ExploreScreen() {
  const navigation = useNavigation();
  const insets = useSafeAreaInsets();
  const {width} = useWindowDimensions();
  const numColumns = width >= 768 ? 3 : 2;

  const [query, setQuery] = useState('');
  const debounced = useDebouncedValue(query);
  const [items, setItems] = useState([]);
  const [loading, setLoading] = useState(true);
  const [refreshing, setRefreshing] = useState(false);
  const [error, setError] = useState(null);

  const load = useCallback(async (q, {signal} = {}) => {
    const data = await api.getExplore(q, {signal});
    setItems(data);
  }, []);

  useFocusEffect(
    useCallback(() => {
      const controller = new AbortController();
      setLoading(true);
      setError(null);

      load(debounced, {signal: controller.signal})
        .catch(e => {
          if (e.name !== 'AbortError') setError(e.message);
        })
        .finally(() => {
          if (!controller.signal.aborted) setLoading(false);
        });

      return () => controller.abort();
    }, [load, debounced]),
  );

  const onRefresh = useCallback(async () => {
    setRefreshing(true);
    try {
      await load(debounced);
    } catch (e) {
      setError(e.message);
    } finally {
      setRefreshing(false);
    }
  }, [load, debounced]);

  const onOpen = useCallback(
    id => navigation.navigate('ExploreDetails', {id}),
    [navigation],
  );

  const renderItem = useCallback(
    ({item}) => <ProductCard item={item} onOpen={onOpen} />,
    [onOpen],
  );

  return (
    <View style={{flex: 1, paddingTop: insets.top}}>
      <TextInput value={query} onChangeText={setQuery} placeholder="Search" />
      {loading && !refreshing ? <ActivityIndicator /> : null}
      {error ? <Text>{error}</Text> : null}
      <FlatList
        data={items}
        numColumns={numColumns}
        key={numColumns}
        refreshing={refreshing}
        onRefresh={onRefresh}
        renderItem={renderItem}
        keyExtractor={item => String(item.id)}
      />
    </View>
  );
}

Hooks used and why

Hook	Role
`useNavigation`	Open details
`useSafeAreaInsets`	Notch padding
`useWindowDimensions`	Responsive columns
`useDebouncedValue`	Don’t hit API every keystroke
`useFocusEffect`	Reload + abort when leaving / blurring
`useCallback`	Stable `load` / `onOpen` / `renderItem`
`useState`	Query, items, loading, error, refreshing

22. Common pitfalls (RN edition)

Missing cleanup → duplicate listeners / double intervals after navigate
Fetch without abort/alive → state updates after unmount; messy Strict Mode
useEffect instead of useFocusEffect → stale data on tabs
useCallback without React.memo on rows → often zero benefit
Unstable dependency objects → effect loops (const options = {page: 1} each render)
useMemo / useCallback everywhere → noise, harder reviews, little gain
Derived data in state → sync bugs; compute inline or with useMemo
Conditional hooks → React crash / mismatched hook order
Ignoring Debug vs Release → perf conclusions from Debug are often false
Putting scroll position in Context → re-renders the tree every frame
useInsertionEffect in app screens → wrong tool; use StyleSheet / theme
Wide Redux selectors → whole-slice select re-renders everything; keep them narrow

// BAD — derived state duplication
const [items, setItems] = useState([]);
const [count, setCount] = useState(0);
useEffect(() => setCount(items.length), [items]);

// GOOD
const count = items.length;

// BAD — new object every render retriggers effect
useEffect(() => {
  load(options);
}, [{page: 1}]);

// GOOD
const page = 1;
useEffect(() => {
  load({page});
}, [page]);

23. Quick revision checklist

Before merging a screen

[ ] All hooks at top level
[ ] Picked the right hook for the job (§3)
[ ] Effects that subscribe also unsubscribe
[ ] Async work uses AbortController or an alive flag
[ ] Tab screens that need fresh data use useFocusEffect
[ ] Lists: stable keys; useCallback only with memo rows if needed
[ ] No derived data mirrored into extra useState
[ ] Safe areas for custom headers
[ ] Smoke-test rotate + background/foreground once

Hook cheat card (full table in §3.1)

Need	Hook	Where
UI value	`useState`	Screen / component
Complex transitions	`useReducer`	Wizards / multi-field flows
Sync external system	`useEffect`	Screen / custom hook
Measure / no flash	`useLayoutEffect`	Lists / chat scroll
Native node or mutable box	`useRef`	Inputs / lists / timers
Expose child methods via `ref`	`useImperativeHandle`	Wrappers / forwardRef
Shared app data	`useContext`	Root provider → screens
Expensive derive	`useMemo`	Filters / heavy calc
Stable function	`useCallback`	`FlatList` / memo children
Non-urgent / deferred UI	`useTransition` / `useDeferredValue`	Heavy search / filters
Unique a11y ids	`useId`	Forms / labels
External store subscribe	`useSyncExternalStore`	Store adapters
Style lib injection	`useInsertionEffect`	Libraries only
DevTools label	`useDebugValue`	Custom hooks
Screen focus refetch	`useFocusEffect`	Tab / stack screens
Focus boolean	`useIsFocused`	Pause UI when blurred
Nav state slice	`useNavigationState`	Analytics / route name
Navigate / params	`useNavigation` / `useRoute`	Screens
Redux read / write	`useSelector` / `useDispatch`	Connected screens
Notch / home bar	`useSafeAreaInsets`	Headers / full-screen UI
Orientation size	`useWindowDimensions`	Responsive layout
Light / dark	`useColorScheme`	Theme colors
Reused logic	Custom `useX`	`src/hooks/`

Conclusion

Hooks are how React Native screens think: state for UI, effects for the outside world, refs for imperative islands, context for shared app data, and custom hooks for reuse.

Takeaways

Start from what you need, then pick the hook (§3.1) — don’t default everything to useState + useEffect
Learn the Rules of Hooks once — they never change
Cleanup is part of the feature: listeners, timers, and abort in-flight fetch
Prefer useFocusEffect for navigation-aware data loading; useIsFocused for simple booleans
useCallback helps only when paired with React.memo / list identity needs
Use useTransition / useDeferredValue when heavy UI work blocks input — not as a substitute for list virtualization
Extract custom hooks when logic repeats; use Redux selectors / a query library when you need shared cache

Next steps

Pick one screen and map each state/effect to the §3 decision table
Add abort/alive + focus-aware fetching where missing
Extract one custom hook this week (useDebouncedValue or useAppState)
Audit one FlatList: stable keys, memoized rows, measured useCallback

Call to action

Which hook still feels confusing in React Native — useFocusEffect, dependency arrays, or knowing when not to use useMemo?

Comment below with a scenario from your app (chat, feed, auth, video). If this guide helped, share it with a teammate who still treats every bug as “wipe node_modules” — or still fetches only with a lonely useEffect([]) on tab screens.

Want a follow-up? Tell me: Reanimated hooks, TanStack Query + RN, or testing hooks with RNTL.

DEV Community: Amit Kumar

JavaScript Type Coercion — Output-Based Questions ([] + [], NaN === NaN & Friends)

TL;DR — what interviewers are testing

Warm-up: how + really decides

How to use this post

Q1 — Classic [] + []

Q2 — [] + {}

Q3 — ({} + []) with parentheses

Q4 — The famous bare {} + [] trap

Q5 — Arrays with values still concat

Q6 — NaN === NaN

Q7 — How NaN is born (and stays sticky)

Q8 — Object.is vs === (NaN + -0)

Q9 — + vs - with strings

Q10 — Booleans in math

Q11 — Unary plus / Number on [] and {}

Q12 — null / undefined with +

Q13 — null == undefined (and friends)

Q14 — Empty array vs empty string vs 0

Q15 — The viral [] == ![]

Q16 — Truthy / falsy surprises

Q17 — Reference equality for objects/arrays

Q18 — typeof null classic

Q19 — Floating point equality

Q20 — Mixed bag rapid fire

Practice round (no spoilers)

P1

P2

P3

P4

P5

Cheat sheet — say this in the interview

Wrap-up

React Native Local Notifications with Notifee — Foreground, Background, Killed + Progress & Images

React Native Local Notifications with Notifee — Foreground, Background, Killed + Progress & Images

TL;DR

Mental model: three app states

Install

Android permissions that actually matter

Channels first (Android)

Permissions (iOS + Android 13+)

1) Instant local notification

2) Scheduled reminder (survives kill on Android)

3) Handle foreground / background / killed

Foreground (app open)

Background + killed (must live outside React)

Cold start from a tap (killed → launch)

4) Progress indicator (downloads / long work)

5) Images on notifications

Large icon (small circle / square beside text)

Big picture style (expanded image)

Local file example (after you cached an image)

6) Action buttons

7) Pair with background tasks

Wire it on launch

Settings lab (demo in 90 seconds)

File map

Common footguns

Takeaways

What’s next (prod)

React Native List Performance — ScrollView, FlatList, SectionList, FlashList

TL;DR

Mental model: what makes a list “slow”

1. ScrollView — when it’s correct (and when it’s a footgun)

Use it when

Don’t use it when

Anti-pattern

Nested ScrollView + list = pain

2. FlatList — the default virtualized list

Minimal solid setup

Props that actually matter

Fixed-height turbo: getItemLayout

The extraData trap

Inline functions and anonymous rows

Images in FlatList rows

3. SectionList — grouped data without fighting FlatList

Solid pattern

SectionList gotchas

When SectionList is the wrong tool

4. FlashList — when FlatList’s recycling isn’t enough

Warm-up: how `+` really decides

Q1 — Classic `[] + []`

Q2 — `[] + {}`

Q3 — `({} + [])` with parentheses

Q4 — The famous bare `{} + []` trap

Q6 — `NaN === NaN`

Q7 — How `NaN` is born (and stays sticky)

Q8 — `Object.is` vs `===` (NaN + `-0`)

Q9 — `+` vs `-` with strings

Q11 — Unary plus / Number on `[]` and `{}`

Q12 — `null` / `undefined` with `+`

Q13 — `null == undefined` (and friends)

Q14 — Empty array vs empty string vs `0`

Q15 — The viral `[] == ![]`

Q18 — `typeof null` classic

Fixed-height turbo: `getItemLayout`

The `extraData` trap

Register Headless in `index.js` (order matters)

Lexical `this` example

Rest instead of `arguments`

`this` binding