DEV Community: Ola Abaza

1 RN Thing a Day – Day 15: What is createListenerMiddleware

Ola Abaza — Sun, 07 Jun 2026 10:08:17 +0000

createListenerMiddleware is a feature from Redux Toolkit that allows you to listen for actions or state changes and run side effects.

Why was it created?
Before createListenerMiddleware, developers typically used:

useEffect
Custom middleware
Redux Thunk
Redux Saga
Redux Observable

for side effects.

Redux Toolkit introduced createListenerMiddleware as a simpler alternative for many common use cases.

There are two Ways to Listen:-

By Action

startListening({
  actionCreator: addItem,

  effect: () => {
    console.log('Item added')
  }
})

Runs only when:

dispatch(addItem())

//is dispatched.

2.By Predicate

startListening({
  predicate: (_, currentState, previousState) =>
    currentState.cart.items.length >
    previousState.cart.items.length,

  effect: () => {
    console.log('Cart grew')
  }
})

Runs whenever the cart gets bigger, regardless of which action caused it.

What does startListening() do?
It registers a listener.

listenerMiddleware.startListening({
  actionCreator: someAction,

  effect: () => {
    // side effect
  }
})

Similar to:

Listen for someAction ↓ When it happens ↓ Run effect

What can you do inside the effect?
You get access to a listenerApi.

effect: async (action, listenerApi) => {
  listenerApi.dispatch(fetchUser())

  const state = listenerApi.getState()

  await listenerApi.delay(3000)

  console.log(state)
}
// we can also Cancel Running Effects 

//listenerApi.cancelActiveListeners()

Where is it added?
In your store configuration:

export const listenerMiddleware =
  createListenerMiddleware()

export const store = configureStore({
  reducer,

  middleware: getDefaultMiddleware =>
    getDefaultMiddleware().prepend(
      listenerMiddleware.middleware
    )
})

Simple Definition
createListenerMiddleware is a Redux Toolkit middleware that lets you:

Listen for specific actions (actionCreator)
Listen for specific state transitions (predicate)
Execute side effects (effect)

without putting that logic inside React components. It helps keep application behavior separate from UI behavior.

Let's understand what happens when you dispatch an action in Redux.
Without Middleware

When you do:

dispatch(addItem(product))

Redux follows this flow:

dispatch(action) ↓ reducer ↓ new state

What is Middleware?
Middleware is code that sits between:

dispatch()
and

reducer()
Think of it as a security checkpoint at an airport.

In Redux: Action ↓ Middleware ↓ Reducer

Every dispatched action passes through middleware first.

Why Does the Predicate Have Access to Both States?
Because listener middleware watches the entire process.

Imagine it takes a snapshot:

const previousState = store.getState()

before the reducer runs.

Then after the reducer:

const currentState = store.getState()

Now it can compare:

predicate(
  action,
  currentState,
  previousState
)

//Example:

predicate: (_, current, previous) =>
  !previous.auth.isLoggedIn &&
  current.auth.isLoggedIn

we mean it participates in the dispatch pipeline and has visibility into the action and the state transition, allowing it to react after the state changes. That's what makes Predicate & Effect possible.

1 RN Thing a Day – Day 14: Predicate & Effect Patterns in React Native

Ola Abaza — Sun, 24 May 2026 10:40:01 +0000

The easiest way to think about it is:

Predicate = Watch for something

Effect = Do something when it happens

Example:

predicate: Is someone entering the building?
effect: Check their ID

Example 1: Add Item To Cart

// cartSlice.ts

import { createSlice, PayloadAction } from '@reduxjs/toolkit'

interface Product {
  id: string
  name: string
}

interface CartState {
  items: Product[]
}

const initialState: CartState = {
  items: []
}

const cartSlice = createSlice({
  name: 'cart',
  initialState,
  reducers: {
    addItem: (state, action: PayloadAction<Product>) => {
      state.items.push(action.payload)
    },

    removeItem: (state, action: PayloadAction<string>) => {
      state.items = state.items.filter(
        item => item.id !== action.payload
      )
    }
  }
})

export const { addItem, removeItem } = cartSlice.actions

export default cartSlice.reducer

// listenerMiddleware.ts

import { createListenerMiddleware } from '@reduxjs/toolkit'
import Toast from 'react-native-toast-message'

export const listenerMiddleware =
  createListenerMiddleware()

// cartListeners.ts

import { listenerMiddleware } from './listenerMiddleware'

listenerMiddleware.startListening({
  predicate: (_, currentState, previousState) => {
    return (
      currentState.cart.items.length >
      previousState.cart.items.length
    )
  },

  effect: async () => {
    Toast.show({
      type: 'success',
      text1: 'Item added to cart'
    })
  }
})

Why use a predicate instead of listening to addItem directly?
You could do:

listenerMiddleware.startListening({
  actionCreator: addItem,
  effect: () => {
    Toast.show({
      type: 'success',
      text1: 'Item added to cart'
    })
  }
})

But the predicate version is more powerful because it reacts to state changes, not specific actions.

The predicate doesn't know or care which action happened. It only cares about the resulting state.

For example, if items are added by:

dispatch(addItem(product))
dispatch(syncCartFromServer())
dispatch(restoreSavedCart())

the same predicate still works:

currentState.cart.items.length >
previousState.cart.items.length

because it only cares that the cart grew, regardless of which action caused it. That's the main strength of the Predicate & Effect pattern.

Why Compare Current State and Previous State?
Because many actions happen in the app.

For example: User adds item to cart

Without comparing states, your effect might run every time.

Instead, the predicate asks:

Did the specific thing I care about change?

Only then does it execute the effect.

When should I use actionCreator?
Use it when your business rule is: "When this action happens, do something."

Examples:


Track Login Event
startListening({
  actionCreator: loginSuccess,
  effect: () => {
    Analytics.track('Login')
  }
})

You specifically want to react to the login action.

When should I use predicate?
Use it when your business rule is:"When the state becomes this, do something."

Examples:

User Became Logged In
predicate: (_, current, previous) =>
  !previous.app.isLoggedIn &&
  current.app.isLoggedIn

Maybe several actions can lead to a logged-in state:

loginSuccess()
restoreSession()
refreshTokenSuccess()

You don't want to listen to all of them.

You just care that: isLoggedIn changed from false to true

Why not just use useEffect?

For small apps, useEffect is often enough. Predicate & Effect becomes valuable when you want to move business logic outside the UI layer.

The Problem With useEffect
Imagine this: When a user logs in, you need to:

Fetch profile
Load permissions
Connect websocket
Start analytics session

Many developers write:

function HomeScreen() {
  const isLoggedIn = useSelector(selectIsLoggedIn)

  useEffect(() => {
    if (isLoggedIn) {
      dispatch(fetchProfile())
      dispatch(loadPermissions())
      connectWebSocket()
      startAnalytics()
    }
  }, [isLoggedIn])
}

Now ask yourself:

Why is HomeScreen responsible for login behavior?

It isn't really a UI concern.

It's application behavior.

The app should perform these actions whenever a user becomes logged in, regardless of which screen is mounted.

This is where Predicate & Effect shines.

Simple Rule

Use useEffect when:

The effect belongs to the component.

Examples:

Focus input
Start animation
Listen to keyboard
Set navigation title
Fetch data only for this screen

Use Predicate & Effect when:
The effect belongs to the application.

Examples:

User logged in
User logged out
Network restored
Language changed
Permissions updated
Token expired
Cart became non-empty
Analytics tracking
Background synchronization

1 RN Thing a Day – Day 13: Redux Thunk

Ola Abaza — Fri, 15 May 2026 20:15:52 +0000

What Is Redux Thunk?
Redux Thunk is a middleware for Redux that allows you to write action creators that return a function instead of a plain action object.

Normally, Redux actions look like this:

{
  type: "SET_USER",
  payload: user
}

async code doesn't work directly: Redux would throw an error because it expects an object.

dispatch(async () => { 
  const data = await api.getUser()
})

But with thunk, you can return a function:

const fetchUser = () => {// Return an async function that receives dispatch as parameter
  return async (dispatch) => {
    const response = await api.getUser()

    dispatch({
      type: "SET_USER",
      payload: response.data
    })
  }
}

Thunk acts as the bridge between async operations and Redux state updates.

The Problem Without Thunk
Imagine handling login directly inside a screen:

const handleLogin = async () => {
  setLoading(true)

  try {
    const response = await api.login(email, password)

    dispatch({
      type: "LOGIN_SUCCESS",
      payload: response.data
    })
  } catch (error) {
    setError(error.message)
  }

  setLoading(false)
}

This approach causes problems:

Components become bloated
Logic is duplicated
Reusability decreases
Testing becomes harder
UI and business logic become tightly coupled

The Same Logic Using Thunk:

export const loginUser = (email, password) => {
  return async (dispatch) => {
    dispatch(setLoading(true))

    try {
      const response = await api.login(email, password)

      dispatch(loginSuccess(response.data))
    } catch (error) {
      dispatch(loginError(error.message))
    } finally {
      dispatch(setLoading(false))
    }
  }
}

Then inside the component:

dispatch(loginUser(email, password))

Now the component becomes clean and focused only on UI.

Redux Toolkit createAsyncThunk

Modern Redux apps should prefer Redux Toolkit. Instead of manually writing thunk boilerplate.

The Structure Usually:

Service Layer: Handles API only.

// services/userService.js

export const getProducts = async () => {
  const response = await fetch(API_URL)

  return response.json()
}

Thunk Layer: Handles async Redux logic.

// store/thunks/userThunk.js

export const fetchProducts = createAsyncThunk(
  "products/fetchProducts", // action type prefix. // sliceName/actionName

  async () => {
    return await getProducts()
  }
)

"products/fetchProducts" It is simply:a unique Redux action identifier prefix used to generate async action types automatically.

Slice Layer: Handles state updates.

import { createSlice } from "@reduxjs/toolkit"
import { fetchProducts } from "./productThunk"

const productSlice = createSlice({
  name: "products",

  initialState: {
    products: [],
    loading: false,
    error: null
  },

  reducers: {},

  extraReducers: (builder) => {
    builder
      .addCase(fetchProducts.pending, (state) => { /
        state.loading = true
      })

      .addCase(fetchProducts.fulfilled, (state, action) => {
//internally matches:products/fetchProducts/fulfilled
        state.loading = false
        state.products = action.payload
      })

      .addCase(fetchProducts.rejected, (state, action) => {
        state.loading = false
        state.error = action.error.message
      })
  }
})

export default productSlice.reducer

Benefits:

Cleaner syntax
Built-in pending/fulfilled/rejected states
Less boilerplate
Better TypeScript support

Important Concept
createAsyncThunk is NOT mainly about API calls.
It is about:
Managing async operations that affect global state. API calls are just the most common example.

Better understanding:
Thunk = async business logic connected to Redux state

That business logic may include:

API calls
caching
conditional fetching
retries
authentication
reading current state
dispatching multiple actions

1 RN Thing a Day – Day 12: useEffect vs useFocusEffect

Ola Abaza — Tue, 21 Apr 2026 09:06:31 +0000

useEffect

React to data changes only

useEffect(() => {
  // logic
}, [dep])

✅ Runs when:

The component mounts
The dependency (dep) changes

❌ Does NOT run when:

The screen is revisited (focused again)
Navigation happens without changing the dependency

useFocusEffect

useFocusEffect(
  useCallback(() => {
    // logic
  }, [dep])
)

✅ Runs when:

The screen becomes focused (opened or revisited)
The dependency changes while the screen is focused

Even if dep did NOT change → it still runs on screen focus

🚨 Common Pitfall

Using useFocusEffect without resetting state or params:

if (isError) {
  // will trigger EVERY time screen is focused
}

👉 This can cause repeated side effects or bugs

✅ Best Practice

When using navigation params:

useFocusEffect(
  useCallback(() => {
    if (!isError) return

    handleSideEffect()

    // reset param to avoid repeated triggers
    NavigationFunctions.setParams({ isError: false })
  }, [isError])
)

1 RN Thing a Day – Day 11: When Is await Unnecessary?

Ola Abaza — Tue, 10 Feb 2026 14:57:54 +0000

The Basic Rule
Inside an async function:

👉 If you are just returning a Promise, you do NOT need await.

Simple Example
Look at these two functions:

Version 1

async function getData() {
  return await fetchData()
}

Version 2

async function getData() {
  return fetchData()
}

Both functions do exactly the same thing.

They return a Promise
They resolve to the same value
No behavior difference

So in Version 1, the await is unnecessary.

Why This Works
An async function automatically wraps its return value in a Promise.

So when you write:

return fetchData()

JavaScript already knows it’s a Promise and returns it correctly.

Adding await just waits for the Promise and then returns the same result—without any benefit.

When await IS Needed
You need await only when you actually want to use the result.

async function getUserName() {
  const user = await fetchUser()
  return user.name
}

Here await is required because you need to access user.name.

Easy Rule to Remember

Use await when:

You need the resolved value
You want to do logic with the result
You have multiple async steps

Skip await when:

You are only returning a Promise
No extra logic is needed

TL;DR
Inside an async function:
👉 If you are only returning a Promise, don’t use await.

1 RN Thing a Day – Day 10: Memoization in React Native

Ola Abaza — Sat, 30 Aug 2025 13:03:13 +0000

It is an optimization technique used to improve performance by caching the results of expensive function calls or avoiding unnecessary re-renders of components.

How to use memoization effectively in React Native:

Memoizing Components with React.memo React.memo is used to prevent unnecessary re-renders of functional components when their props do not change.

import React from 'react';

const ExpensiveComponent = React.memo(({ data }) => {
  console.log('Rendering ExpensiveComponent');
  return <Text>{data}</Text>;
});

// Parent component
const App = () => {
  const [count, setCount] = React.useState(0);
  return (
    <>
      <ExpensiveComponent data="This won't re-render" />
      <Button title="Increment" onPress={() => setCount(count + 1)} />
    </>
  );
};

In this example, ExpensiveComponent only re-renders if its data prop changes.

2.Memoizing Values with useMemo
useMemo caches the result of an expensive computation so that it does not need to be recalculated unless its dependencies change.

import React, { useMemo } from 'react';

const App = () => {
  const [count, setCount] = React.useState(0);

  const expensiveCalculation = useMemo(() => {
    console.log('Performing expensive calculation');
    return count * 2;
  }, [count]);

  return (
    <>
      <Text>Result: {expensiveCalculation}</Text>
      <Button title="Increment" onPress={() => setCount(count + 1)} />
    </>
  );
};

3.Memoizing Functions with useCallback
useCallback memoizes a function to avoid re-creating it on every render, especially when passing it as a prop to child components.

import React, { useState, useCallback } from 'react';

const Button = React.memo(({ onPress }) => {
  console.log('Rendering Button');
  return <TouchableOpacity onPress={onPress}><Text>Press Me</Text></TouchableOpacity>;
});

const App = () => {
  const [count, setCount] = useState(0);

 // without useCallback the onPress prop changed (new function reference), so I need to re-render <Button />

  const increment = useCallback(() => {
    setCount(prev => prev + 1);
  }, []);

  return (
    <>
      <Text>Count: {count}</Text>
      <Button onPress={increment} />
    </>
  );
};

Without useCallback, the increment function would be re-created on every render, causing the Button component to re-render unnecessarily.

The problem without useCallback

In React, functions are objects.
Every time your component re-renders, any inline function you create gets a new reference in memory even if the logic is identical.

Avoid Overusing Memoization

Avoid memoizing components or values that are inexpensive to compute.
Use profiling tools (e.g., React DevTools Profiler) to identify performance bottlenecks before applying memoization.

Memoization Libraries

In some cases, you might want to use libraries like memoize-one or lodash.memoize for custom memoization needs:

import memoize from 'lodash.memoize';

const memoizedFunction = memoize(expensiveFunction);

function expensiveFunction(arg) {
  console.log('Calculating...');
  return arg * 2;
}

console.log(memoizedFunction(2)); // "Calculating..." -> 4
console.log(memoizedFunction(2)); // Cached result -> 4

lodash.memoize keeps a cache of results for each unique input key you pass in.

useMemo (React) doesn’t store results for every input ever passed.
It only remembers the last computation tied to its dependency array.

What memoization does under the hood

When you use React.memo, useMemo, or useCallback, React has to:
Store the previous value (or component render).
Compare the current props/values with the previous ones (a shallow comparison).
Decide whether to re-render or return the cached result.

This bookkeeping work itself takes CPU time and memory.

If the component or calculation is very cheap (e.g., rendering a single or calculating a + b), then:
Re-rendering or recalculating is often faster than doing all the memoization checks.
Adding memoization in such cases can slow things down instead of speeding them up

Always measure (with React DevTools Profiler) before and after, to confirm the performance gain.

1 RN Thing a Day – Day 9: Animated API

Ola Abaza — Mon, 18 Aug 2025 20:09:55 +0000

In React Native, the Animated API is used because it gives you a performant and flexible way to create animations in your app.

🔑 Reasons to Use the Animated API

Performance
If you animate with setState, every frame causes a full React render, which is slow.The Animated API runs animations on the native UI thread (especially with useNativeDriver: true), so animations stay smooth (60fps)(frames per second) even if JavaScript is busy.
Declarative Animations
You describe what should happen (e.g., "move this box from X=0 to X=200 over 500ms"), and React Native handles the how. Makes animations easier to reason about.
Reusability
The same Animated.Value can drive multiple properties (opacity, scale, rotation, etc.). Easier than manually tracking multiple states.
Gestures + Physics
Supports spring animations, decay (momentum), and interactions with touch gestures. Perfect for natural-feeling UI like swipes, drags, and bounces.
Cross-Platform Consistency
Works on both iOS and Android with the same API, without you needing to use native code for animations.
Interpolation
You can map one animated value into different ranges. Example:

const progress = useRef(new Animated.Value(0)).current;

// Slide horizontally
const translateX = progress.interpolate({
  inputRange: [0, 1],
  outputRange: [0, 200],
});

// Fade out
const opacity = progress.interpolate({
  inputRange: [0, 0.5, 1],
  outputRange: [1, 0.5, 0],  // custom curve
});

// Rotate
const rotate = progress.interpolate({
  inputRange: [0, 1],
  outputRange: ["0deg", "360deg"],
});

All are derived from the same progress value.
→ This allows chaining multiple visual effects from one value.

🔹 Step by step (useRef(new Animated.Value(0)).current;)
1- new Animated.Value(0)
Creates an Animated.Value object starting at 0.
This is the special type React Native uses to drive animations (instead of a normal number).

2- useRef(...)
Ensures the value is persistent across re-renders.
Without useRef, every re-render would create a new Animated.Value, resetting the animation back to 0.
With useRef, React will keep the same object during the component’s lifecycle.

3- .current
useRef returns an object like { current: }.
.current gives you the actual Animated.Value stored inside.

Example

import React, { useRef, useEffect } from "react";
import { Animated, View } from "react-native";

export default function Box() {
  const fadeAnim = useRef(new Animated.Value(0)).current; // start opacity at 0

  useEffect(() => {
    Animated.timing(fadeAnim, {
      toValue: 1,
      duration: 2000,
      useNativeDriver: true, // run on UI thread
    }).start();
  }, []);

  return (
    <Animated.View
      style={{
        opacity: fadeAnim,
        width: 100,
        height: 100,
        backgroundColor: "blue",
      }}
    />
  );
}

👉 Without Animated, you'd have to manually update opacity on every frame — very inefficient.

✅ In short:
We need the Animated API in React Native because it makes animations smooth, efficient, declarative, and easy to combine with gestures and physics.

🔹 What happens with setState?

When you call setState, React re-renders in the JS thread.
That means every frame of the animation depends on the JS thread being free and fast.
If the JS thread is busy (fetching API, parsing JSON, rendering a heavy component), the animation drops frames → stutters.
That’s why animations with setState often run at 30fps or less, instead of smooth 60fps.

⚖️ Quick Comparison between Animated(built-in) and react-native-reanimated

Performance --> Good, but JS can block --> Excellent (runs on UI thread)
Complexity handling --> Basic animations only --> Handles very complex flows
Gesture support --> Limited --> designed to work seamlessly with react-native-gesture-handler.
Ease of use --> Simple API --> Steeper learning curve
Dependencies --> Built-in (no install) --> Requires installation & setup
Recommended for production --> Small/simple apps --> Medium/large apps with rich UI

1 RN Thing a Day – Day 8: Trivyignore

Ola Abaza — Sun, 17 Aug 2025 22:58:44 +0000

.trivyignore is a configuration file used by Trivy, an open-source vulnerability scanner for containers, Kubernetes, and other dependencies.

🔹 Containers
A container is a lightweight, standalone package that includes:
The application code (e.g., your React Native backend service, or a Node.js API)

Its dependencies (libraries, runtimes like Node.js, Python, Java, etc.)
The OS-level binaries needed to run

👉 Think of it like a zip file that has everything your app needs so it runs the same way on any machine.

🔹 Kubernetes (K8s)3
Kubernetes is a system that helps you run and manage containers across multiple machines.

With Kubernetes:

You describe what you want (e.g., "I need 5 containers of my RN backend always running").
Kubernetes automatically deploys, scales, heals, and load-balances containers.

👉 Think of it like a container orchestrator or a "manager for containers."

📌 Example:

You write a YAML file (deployment.yaml) that says:
Run 5 replicas of my RN backend container.
Expose them via a service on port 3000.
Kubernetes ensures those 5 are always running. If one dies → it restarts it.

Container = a package of your app + everything it needs to run.
Kubernetes = a system that runs and manages lots of containers reliably.

What is Trivy?
Trivy is a security scanning tool developed by Aqua Security that detects:

OS package vulnerabilities (e.g., in Alpine, Debian, Ubuntu)
Application dependencies vulnerabilities (e.g., npm, pip, Maven)
Container image vulnerabilities
Infrastructure as Code (IaC) misconfigurations

What is .trivyignore?
.trivyignore is a file that allows you to ignore specific vulnerabilities found by Trivy. This is useful when you:

Acknowledge a vulnerability but determine it doesn’t affect your project.
Are waiting for an upstream fix and want to suppress noise.
Need to whitelist known issues for compliance reasons.

How to use .trivyignore?

Create a .trivyignore file in your project root.
Add the vulnerability IDs you want to ignore.

CVE-2022-1234
CVE-2021-5678

Trivy will skip reporting these vulnerabilities in scans.

1 RN Thing a Day – Day 7: KeyboardAwareScrollView

Ola Abaza — Mon, 11 Aug 2025 21:58:09 +0000

KeyboardAwareScrollView is a component from the react-native-keyboard-aware-scroll-view library that helps handle keyboard interactions in React Native. It ensures that input fields remain visible when the keyboard appears, preventing them from being covered.

Usage:
Here's a simple example of how to use KeyboardAwareScrollView:

import React from 'react';
import { TextInput, View, Text } from 'react-native';
import { KeyboardAwareScrollView } from 'react-native-keyboard-aware-scroll-view';

const MyScreen = () => {
  return (
    <KeyboardAwareScrollView
      style={{ flex: 1, padding: 16 }}
      contentContainerStyle={{ flexGrow: 1 }}
      enableOnAndroid={false} //  true by default
      extraScrollHeight={0} // Adjusts scrolling space when the keyboard  is open , 75 by default
      keyboardShouldPersistTaps="handled" //"never" by default
      showsVerticalScrollIndicator: false
      bounces: false
    >
      <View>
        <Text>Enter your details:</Text>
        <TextInput
          placeholder="Type here..."
          style={{
            height: 50,
            borderWidth: 1,
            borderColor: '#ccc',
            marginVertical: 10,
            paddingHorizontal: 10,
          }}
        />
      </View>
    </KeyboardAwareScrollView>
  );
};

export default MyScreen;

Key Props:

enableOnAndroid={false}: Disables keyboard awareness on Android. If you need input fields to move up when the keyboard appears, you might want this set to true.
extraScrollHeight={0}: No additional space is added when the keyboard appears. If inputs get covered, consider increasing this value (e.g., extraScrollHeight: 20).
keyboardShouldPersistTaps=" handled": Allows taps on the screen to dismiss the keyboard.
showsVerticalScrollIndicator: "false": Hides the vertical scrollbar, which might be good for a cleaner
contentContainerStyle={{ flexGrow: 1 }}: Ensures content is scrollable when necessary.
bounces: "false": Prevents the slight bounce effect when reaching the top or bottom of the scrollable content.

List of other common KeyboardAwareScrollView props:

enableAutomaticScroll – true (will scroll automatically to focused input).
extraHeight – 0 (no extra height unless set).
keyboardOpeningTime – 250 (ms delay before scrolling).
viewIsInsideTabBar – false (no adjustment unless inside tab bar).
enableResetScrollToCoords – true (scroll resets when keyboard hides).
contentContainerStyle – undefined (no default styles).
showsVerticalScrollIndicator – true (scroll bar visible).
bounces – true (scroll view bounces at edges).
horizontal – false (scrolls vertically by default).
onScroll – undefined (no default scroll handler).
pagingEnabled – false (no page snapping).
onKeyboardWillShow – undefined (no default event handler).
onKeyboardDidShow – undefined (no default event handler).
onKeyboardWillHide – undefined (no default event handler).

If you don’t use KeyboardAwareScrollView:

Input fields near the bottom may get covered by the keyboard.
You’ll need to manually handle keyboard show/hide events.
Scrolling to bring inputs into view won’t happen automatically.
Different behavior on iOS vs Android may cause inconsistent UX.
User may need to manually scroll to see what they’re typing.
Small-screen devices will have worse usability.

1 RN Thing a Day – Day 6: Shallow Copy vs. Deep Copy

Ola Abaza — Sat, 09 Aug 2025 18:27:36 +0000

Example: Shallow Copy vs. Deep Copy

import cloneDeep from 'lodash/cloneDeep';

const original = [
  { id: 1, info: { status: "active" } },
  { id: 2, info: { status: "inactive" } }
];

// Shallow copy
const shallowCopy = original.slice();
shallowCopy[0].info.status = "changed";
console.log(original[0].info.status); // "changed" (still linked)

// Deep copy
const deepCopy = cloneDeep(original);
deepCopy[0].info.status = "changed again";
console.log(original[0].info.status); // "changed" (original unaffected)
console.log(deepCopy[0].info.status); // "changed again"

cloneDeep from Lodash recursively walks through the structure of your object or array and:

Creates new objects/arrays instead of reusing existing ones.
Copies primitive values (string, number, boolean) directly.
Handles special types (Date, Map, Set, RegExp, Buffer, TypedArrays).
Supports circular references (won’t get stuck in infinite recursion).
Preserves property descriptors, prototype chains, and symbols.

The Core Problem It Solves
In JavaScript, objects and arrays are reference types.

const a = { name: "Ola" };
const b = a; // just a reference, not a copy

b.name = "Changed";

console.log(a.name); // Changed 😱

Here, a and b are pointing to the same object in memory.

If you try to "copy" an array of objects using things like .slice() or .filter(), you only copy the outer array, not the inner objects.
So you still have shared references to the nested objects.

When You Should Use cloneDeep:

Transformations: You’re modifying data but want the original untouched.
Redux state: Avoid accidental mutation of state objects.
Test data: Copy fixtures so each test gets a fresh, isolated version.
Breaking shared references: When two lists should contain separate but identical-looking objects.

When You Should Use a Shallow Copy:

The data does not contain nested objects/arrays that we care about mutating independently.
Or when we only need to change the outer layer of the structure.
Arrays of primitives

const nums = [1, 2, 3];
const copy = nums.slice(); // shallow copy

copy[0] = 99;

console.log(nums); // [1, 2, 3] ✅ unaffected

Primitives (numbers, strings, booleans) are copied by value,
so shared references aren’t a problem.

_"Copied by value" means_When you assign or copy a primitive, JavaScript copies the actual value, not a reference to it.
So changes to one variable do not affect the other.

Short-lived transformations If you just need a quick copy to sort, filter, or reverse the outer array but don’t care about mutating the nested items later:


const people = [{ name: "Ola" }, { name: "Ali" }];

// Just sorting names
const sorted = [...people].sort((a, b) => a.name.localeCompare(b.name));

console.log(sorted[0] === people[0]); // true (same reference inside)

Sorting changes only the array order, not the inner objects.

Replacing the top-level object

const state = { count: 0, user: { name: "Ola" } };

// Only replacing user object
const newState = { ...state, user: { name: "John" } };

console.log(state.user.name); // Ola ✅ unchanged
console.log(newState.user.name); // John

Here, we create a new outer object but explicitly replace the nested one.
No need to deep clone the whole thing.

💡Rule of Thumb:

If the structure has no nested objects/arrays that will be mutated independently,
or if you will replace nested data entirely instead of mutating it,
then a shallow copy is fine.

1 RN Thing a Day – Day 5: Usage of _partition

Ola Abaza — Fri, 08 Aug 2025 15:28:48 +0000

— partition is a function from the Lodash library.

What _.partition does
.partition(collection, predicate)

Takes an array (collection) and a predicate function (a condition).
Splits the array into two sub-arrays:
- First array → all elements where the predicate returns true
- Second array → all elements where the predicate returns false
Returns them as a 2-element array: [matches, nonMatches].

Example

const assets = [
  { name: 'iPhone', assetType: 'Device' },
  { name: 'Netflix', assetType: 'Subscription' },
  { name: 'iPad', assetType: 'Device' }
];

const [devices, subs] = _.partition(
  assets,
  asset => asset.assetType === 'Device'
);

console.log(devices);
// [{ name: 'iPhone', assetType: 'Device' }, { name: 'iPad', assetType: 'Device' }]

console.log(subs);
// [{ name: 'Netflix', assetType: 'Subscription' }]

Why it’s different from .filter()
If you used .filter() twice like this:

const truthy = arr.filter(x => condition(x));
const falsy = arr.filter(x => !condition(x));

You’d loop through the array two times.
_.partition does it in one loop more efficient.

1 RN Thing a Day – Day 4: Usage of omitBy

Ola Abaza — Fri, 08 Aug 2025 15:15:53 +0000

In Lodash, _.omitBy creates a new object by removing properties where the predicate function returns true.

_.omitBy is only for objects (key–value pairs), not for arrays of values.
If you have an object → use omitBy (removes properties based on a condition) or pickBy (Keeps properties based on a condition).
If you have an array → use filter (removes items based on a condition) or map (transforms each item).

What omitBy Does
_.omitBy(object, predicate)

Loops over each property of the given object.
Runs your predicate function for every (value, key).
If predicate returns true, that property is removed from the new object.
Returns a new object (does not modify the original).

Think of it as the opposite of _.pickBy — instead of keeping matching properties, you remove them.

Basic Example

import omitBy from 'lodash/omitBy';

const obj = {
  name: 'Ola',
  age: 0,
  active: false,
  city: null
};

const result = omitBy(obj, (value) => value == null);
// removes `null` and `undefined`

console.log(result);
// { name: 'Ola', age: 0, active: false }

How the Predicate Works
The predicate gets two arguments:

(value, key) => {
  // value → the property value
  // key   → the property key as a string
}

Example:

omitBy(obj, (value, key) => key === 'age');
// removes any property where the key is "age"

Common Uses

Remove null or undefined fields

omitBy(obj, value => value == null);

Remove all falsy values (false, 0, '', null, undefined, NaN)

omitBy(obj, value => !value);

Remove keys by name pattern

omitBy(obj, (value, key) => key.startsWith('_'));
// removes any key starting with underscore

Difference from omit

omit → remove by key names you already know:

**_.omit(obj, ['age', 'city']);*

omitBy → remove by a condition (calculated dynamically for each key).