You’ve been writing code for hours. Everything looks clean, logical, and perfect. You click the ‘Run’ button, and in an instant, your screen floods with red text — an error. It’s hard to find a person who hasn’t experienced such a situation.

1. You Spend 50% of Your Time Debugging — and That’s Normal

If you feel like a “failed programmer” after spending hours chasing down a single bug, you need to know this: you are not alone.

Did you know?

A 2022 study by the University of Cambridge found that developers spend about 50% of their coding time debugging and fixing errors.

Debugging and fixing errors isn’t wasted effort — it’s real learning. Even experienced coders spend a huge portion of their time debugging.

Each time you fix a bug or resolve an error, you become better at writing clean code and spotting problems faster.

2. The Golden Rule of Debugging: Don’t Panic

The first and most important rule of debugging is simple: Don’t Panic.

When our code breaks, our brain has a tendency to shut down in the face of what looks like chaos.

But the reality is that almost all bugs are fixable, and most of them stem from tiny, overlooked mistakes.

You might be surprised to learn that many complex-looking problems are caused by something as simple as a “misspelled word or a missing bracket.”

3. Make the Invisible Visible

When a bug isn’t obvious from just reading the code, you need to make the execution process visible.

Simple commands like print() in Python or console.log() in JavaScript work like magic. By placing them strategically, you can check the values of variables at different points and confirm whether specific parts of your code are even being reached.

When the logic errors run deeper, it’s time to use a debugger.

A debugger is a powerful tool that lets you run your program step by step, setting “breakpoints” to pause execution and inspect everything that’s happening.

Never see bugs or errors as failures.

🔹 Read error messages carefully

🔹 Check brackets, spelling & punctuation

🔹 Use print() / console.log() to trace variables

🔹 Debug step by step with breakpoints

🔹 Copy error messages into Google or Stack Overflow. Someone’s already solved your exact problem.

4. Be Systematic, Then Step Away

Debugging is not just a technique; it’s a disciplined habit.

In a rush to find a solution, many of us make multiple changes at once. This is a critical mistake. A core principle of effective debugging is to make only one change at a time, then test. If you change too much, you’ll never know what fixed the problem — or what made it worse.

And what about when nothing seems to work? When you’ve been staring at the screen for hours and your head is spinning, the best strategy is often the most counter-intuitive: step away for five minutes. Take a short walk, sip some tea, or just look out the window. This mental break gives your tired brain a pair of “fresh eyes” that can often spot the obvious mistake you were missing before.

5. Talk It Out (Even to a Duck)

Sometimes the solution is not in the code, but in the act of explaining it.

The most surprisingly effective expert technique is known as ‘rubber duck debugging.’

The process is simple: you explain your code and the bug you’re facing, line by line, to a solid object like a rubber duck on your desk.

The act of expressing the problem out loud forces you to organize your thoughts and assumptions, making the solution become obvious.

6. AI-Powered Debugging

AI Is Here to Make Debugging Less Painful, Not to Replace You:

We are living in a new era for debugging, thanks to the rise of Artificial Intelligence. AI-powered tools can analyze your code, identify potential bugs, and suggest solutions, reducing hours of manual work to just minutes.

Tools like Snyk Code AI don’t just find errors; they also recommend ways to make your code safer and more efficient.

A common fear among developers is that these tools will eventually make their roles obsolete. The answer is a clear “No.” AI tools are designed to assist you, not replace you.

At the end:

Debugging should never be seen as a sign of defeat. It is a process of transformation.

As the computer scientist Edsger W. Dijkstra famously quipped: “If debugging is the process of removing software bugs, then programming must be the process of putting them in.”

Every red error message that appears on your screen is an invitation to learn something new and deepen your understanding of the systems you are building. It’s not wasted time; it’s an investment in your own expertise.

The next time your code breaks, will you see it as a roadblock, or as an opportunity to become a better developer?

The CSS-based animations and transitions API simplifies code writing.

Six months ago, the Software Mansion team released the beta version of React Native Reanimated 4, and last week, they finally released its stable version. The team described this release as another significant milestone in the development history of this SDK. Featuring

• Animations and Transitions now by CSS! 🔥
• Introduced new React Native Worklets SDK 🚀
• Easy migration — From 3.x to 4.x 💯

🔥️ Article written by ➜ 𝑹𝒆𝒂𝒄𝒕20𝑩𝒖𝒍𝒍𝒆𝒕𝒊𝒏 Team

Get top 20 React & React Native news like this every Tuesday — right in your inbox (1 MAIL) via 𝑹𝒆𝒂𝒄𝒕20𝑩𝒖𝒍𝒍𝒆𝒕𝒊𝒏 newsletter — SUBSCRIBE.

💌 SUBSCRIBE our Newsletter (on Substack) 🚀

What is React Native Reanimated?

React Native Reanimated is a powerful animation library for React Native apps, created and actively maintained by the Software Mansion team. It was first launched around 2019. The true benefits of this SDK include

• Runs at 60–120 FPS for ultra-smooth visuals
• Works with gestures like drag, swipe, and pinch
• Supports physics-based animations like spring and decay
• Integrates with various sensors (e.g., gyroscope, keyboard)
• Cross-platform: works on iOS, Android, and even Web

Now let’s check out what’s new in the v4 release 🚀

CSS Animations and Transitions!

In this new release of Reanimated version 4, the team introduced a CSS-based animations and transitions API. The team hopes that these CSS-based animations and transitions will make Reanimated more accessible for developers coming from the web, and also that React Native developers will be able to stay familiar with the same CSS APIs across all platforms.

Another benefit is that CSS animations are much easier to optimize, because with CSS-style animations, Reanimated knows exactly:

• Which components are being animated
• Which properties (like opacity, scale, etc.) are changing. This makes it easier for Reanimated to improve performance behind the scenes.

But in older Reanimated setups, figuring out what’s being animated required extra calculations. But from Reanimated 4 onward, these extra calculations are no longer needed. As a result, Reanimated 4 now offers:

• Less code (no need for hooks like useSharedValue)
• Runs faster
• More performance boosts in future updates

New React Native Worklets SDK

The Worklets concept was first introduced with Reanimated 2 in 2021. Worklets are short-running JavaScript functions that can run on the UI thread (the native thread that can run your code natively under the hood with high performance and without disturbing any FPS during UI rendering). Reanimated uses worklets to calculate view styles and react to events on the UI thread.

Now in Reanimated 4, the team has separated all the worklets code into a new SDK, react-native-worklets, and Reanimated now uses this SDK as an internal dependency. The team did this to better support independent progress and to open it up for other non-animation packages to utilize.

Easy migration — From 3.x to 4.x 💯

Reanimated 4.x introduces only minor renames in styling APIs, and all the animation logic you’ve written using Reanimated v2 or v3 APIs works seamlessly in 4.x. You can adopt CSS animations and transitions in your codebase incrementally, at your own pace.

The important point is that Reanimated 4.x supports only the New Architecture and no longer supports the Legacy Architecture.

Additionally, when shifting to Reanimated 4.x, you need to install the react-native-worklets package using your package manager, then change ‘react-native-reanimated/plugin’ to ‘react-native-worklets/plugin’ in your babel.config.js file, and finally rebuild your Apps.

Check out more details about migrating from Reanimated 3.x to 4.x.

🩵 Enjoyed the read?

Get top 20 React & React Native news like this every Tuesday — right in your inbox (1 MAIL) via 𝑹𝒆𝒂𝒄𝒕20𝑩𝒖𝒍𝒍𝒆𝒕𝒊𝒏 newsletter — SUBSCRIBE.

💌 SUBSCRIBE our Newsletter (on Substack) 🚀

Sentry’s Godot SDK version 1.0 Alpha now supports Godot 4.5 Beta

Last week Sentry team released Sentry’s Godot SDK 1.0, which is currently in Alpha release — supports Godot 4.5 Beta.

Let’s first understand the basics of what Godot SDK, Sentry, etc.

🔥️ Article written by ➜ 𝑹𝒆𝒂𝒄𝒕20𝑩𝒖𝒍𝒍𝒆𝒕𝒊𝒏 Team

Get 20 React & React Native updates every Tuesday — right in your inbox (MAIL) via 𝑹𝒆𝒂𝒄𝒕20𝑩𝒖𝒍𝒍𝒆𝒕𝒊𝒏 newsletter — SUBSCRIBE Now.

💌 SUBSCRIBE our Newsletter (on Substack) 🚀

What is Godot SDK?

Godot SDK (written in C++) is a toolkit designed to help game developers create games using the Godot engine, which is a popular free and open-source platform for both 2D and 3D game development.

What is Sentry?

Sentry is a tool that acts like a smart error detective for your software and games. It helps developers monitor, track, and fix problems like crashes, bugs, or unexpected behaviors in real-time — even after their product is live to their users.

What is Sentry’s Godot SDK?

Okay, now the Sentry’s Godot SDK is a custom plugin that has been made to connect Sentry’s powerful error-tracking features directly with Godot SDK for Godot-based games. It’s like giving your game the ability to talk back when something goes wrong.

Introducing Sentry’s Godot SDK — v1.0 (Alpha)

Historically, Godot has lacked some of the debugging functionality available in other game engines, but with Godot 4.5 (currently in beta), you now get built-in support for script stack traces (a step-by-step record of function calls), so when something breaks at runtime, you can see what led up to it, even outside the editor.

Building on that progress, Sentry’s new Godot SDK 1.0 (currently in alpha) has onboarded Godot 4.5 beta, which expands visibility into live crashes and runtime errors for Godot developers. With full GDScript stack traces, native crash reporting, and contextual breadcrumbs, so you can fix production issues fast, without waiting on player reports or parsing logs looking for answers.

NOTE: GDScript is a scripting language made for Godot. Godot developers use this language to write their game's logic files.

What’s new in Sentry’s Godot SDK 1.0 (Alpha)?

With the release of Godot 4.5 beta, the Sentry Godot SDK 1.0 now supports:

• Full GDScript stack traces — step-by-step record of function calls made in your GDScript code.
• The new Godot logger interface — Logs now include exact line numbers, making it easier to trace issues & many more features with the new interface.
• Better debugging — you can now attach custom logs and config files to your error reports, giving you (or your team) a clear view of what the player was doing, what settings were active, and what the game engine was processing before the crash.

No more chasing vague bug reports — Sentry delivers clear, structured insights with full error context, so you can trace the issue, test your fix, and confidently ship a patch that keeps players moving forward.

🩵 Enjoyed the read? Get 20 React & React Native updates every Tuesday — right in your inbox (MAIL) via 𝑹𝒆𝒂𝒄𝒕20𝑩𝒖𝒍𝒍𝒆𝒕𝒊𝒏 newsletter — SUBSCRIBE.

💌 SUBSCRIBE our Newsletter (on Substack) 🚀

Hello React & ReactNative devs,

Last week was a real shipping week — lots of exciting stuff landed. The major highlights

• Sentry’s Godot SDK hit 1.0,
• Shadcn/v0 launched its registry,
• React Native Reanimated 4 went stable, and
• Expo SDK 54 (coming with 0.81) announced 10x faster iOS builds.

☕️ Coffee in hand? Let’s scroll through today’s gems 😇

NOTE: 🔥 It was originally published on Substack (React20Bulletin Newsletter) — Subscribe now to get the newsletters delivered straight to your inbox every Tuesday! ➜ SUBSCRIBE (on Substack)

💌 SUBSCRIBE on Substack — 1 mail every TUESDAY

🔮 Sponsor

Hire a World-Class Dev Team for Your Next Big Idea 🚀 — Trusted by startups and enterprises across the USA, Europe, Dubai, and beyond, our senior full-stack team brings 9+ years of experience in 🔹 Mobile (React Native), 🔹 Web (React), and 🔹 Blockchain (Ethereum, Solana), we deliver high-performance solutions — from MVP to full-scale launch 🚀.

Feel free to reach out directly via: Email: anisurrahmanbup@gmail.com or X (Twitter): @anis_RNCore

⚛️ All the Hot React Updates 🚀

🔸 Introducing Sentry’s Godot SDK 1.0 🚀

Sentry’s Godot SDK helps Godot developers fix game issues faster by catching errors, Screenshots, Tags, Breadcrumbs, and helpful contexts. With version 1.0 Alpha, it now supports Godot 4.5 Beta, adding full GDScript stack traces (step-by-step record of function calls), a new Godot logger interface, and better error tracking features.

🔸 Introducing shadcn/v0 Registry 🔥

Vercel introduced v0.dev back in October 2024 as an AI-powered UI builder that lets you generate customized UI components simply by saying things like “Modify Navbar to Red!” However, they’ve now taken it a step further — last week, they launched the shadcn/v0 registry, which lets you publish those customized components in JSON files with a public URL, install them easily using the Shadcn CLI in your project (React, Vite & many more), and edit them anytime via v0.dev.

🔸 More React News Inside 👇

• Alem Tuzlak made an up-to-date implementation of auth in his Forge 42 base-stack (a basic setup for projects to start with React Router v7).
• New docs on Automatic Code Splitting in TanStack Router are live!
• Next.js Conf returns to San Francisco this October — Submit your talk ideas if you’d like to speak.
• Exciting new JSON viewer (a component that can log JSON data in a tree structure) shipped in Ark UI (component library for React & others)
• More React news in today’s draft — check out our Quick Links.

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE on Substack — 1 mail every TUESDAY

🩵 Today’s — Dev of the Week 🎖️

Meet Favaz — Senior React Native Dev & Team Lead with 5+ years of experience building scalable, user-friendly apps for fintech, logistics, and real-time comms. Expert in Socket.IO, Stripe, modular code, and cross-platform architecture.

💬 Need help with Mobile Solutions? Reach out to Favaz (or Hire) for expert guidance.

Thanks to Favaz for his shoutout on LinkedIn about React20Bulletin 💞

💌 SUBSCRIBE on Substack — 1 mail every TUESDAY

⚛️ All the Hot React Native Updates

🔹 React Native Reanimated 4 — Stable 🔥

After six months of development, the Software Mansion team has finally released Reanimated 4 (Stable). Key updates include:

• The CSS-based animations and transitions API simplifies code writing.
• React Native worklets (small functions that can run on Native/UI thread) now handle multithreading with more care, letting you offload heavy logic — even when your app is busy.

Additional Updates: Worklets code is now in a separate package — reducing bundle size and fully supporting the New Architecture, with no migration changes required.

🔹 10x Faster iOS Builds — RN 0.81 🚀

In React Native 0.81 and Expo SDK 54, Expo — together with Meta — is introducing Precompiled React Native builds for iOS — reducing compile times in apps by up to 10x. That means no more building the same code day in and day out. However, precompilation was already introduced on Android by the Hermes team a couple of years ago.

🔹 More React Native News Inside 👇

• Incremental React Native Adoption in Native Apps — a book by Callstack.
• Marc Rousavy made Nitrogen (TypeScript-to-native code generator) 4x faster 🚀
• Introducing Tool Calling in react-native-ai/apple: LLMs can now access apps like Calendar or Weather for fast & accurate answers.
• Callstack drops react-native-fast-shimmer for quick loading visuals. (GitHub)
• Three blogs published on speeding up cross-platform apps & their native components.
• More React Native news in today’s draft — check out our Quick Links.

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE on Substack — 1 mail every TUESDAY

🎬 New Dev Content — Live?

• React Native Authentication with Expo Router v5 — by Simon Grimm.
• How to Use Claude Code with React Native (Step-by-Step) — by Beto.

💼 React Jobs — Now Hiring 🔥

• Passionate about AI tooling — in Getsentry — Apply Here.
• React — Remote-first — Berlin-based — Apply Here.
• Design engineer for Shopify — Apply Here.
• React Native, React, full-stack, Swift — Apply Here.

Got a React or React Native job opening? Send it to me only if it’s legit — I share authentic roles from trusted companies. No scams.

🤖 AI Updates — You’ll Love

• OpenAI is developing 4.5 gigawatts of additional Stargate data center capacity with Oracle in the U.S.
• What is MCP? explained by Vercel. (MCP gives AI models control to other apps to place an order, write a file & many more)

🤔 Pro Programming Tips

• Don’t start with learning. Start with doing and learn when you get stuck.
• Become a React.js Pro in No Time — Grab This Handy Cheatsheet!

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE on Substack — 1 mail every TUESDAY

🏕️ Extras You Shouldn’t Miss

• Introducing Screeny.dev — add a nice background to your images & share!
• Introducing Waves, camera glasses for creators.

💌 SUBSCRIBE on Substack — 1 mail every TUESDAY

💟 Partner with React20Bulletin

💟 Sponsor With Us → Click here

💼 Hire Our Dev Team → Click here

💯 More about Newsletter/ Author → Click here

😍 Support us on → Medium, X (Twitter), LinkedIn, and 🦋 Bluesky.

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE on Substack — 1 mail every TUESDAY

🔹 Thanks for subscribing to React20Bulletin. This post is public, so feel free to share it. ➜ Share

🔹 Help shape the next issue — we’d love your thoughts! ➜ Give your Feedback!

Turbopack builds enhancements & Performance Improvements

Last week, Vercel dropped Next.js 15.4 — packed with over 140 commits from 40 contributors. This release improves Turbopack Builds, performance, and stability. Highlights include:

• Turbopack Builds: Starting from 15.4, when you run the next build command with — turbopack, all 8,298 production tests now pass successfully. Turbopack is a super-fast bundler for Next.js, written in Rust, that combines your code, images, and assets to make builds faster and smarter — and it replaces Webpack (written in JS). With this, 15.4 is now more stable, and the team is already working on a beta for Next.js 16!
• Performance Improvements: Next.js 15.4 now handles faster page loads by prefetching data more efficiently and using better caching, along with smarter error handling.

🎉 Enjoyed the read? Don’t miss out — Subscribe to React20Bulletin (Newsletter) and get the latest dev buzz, tips, and tech updates right in your inbox (Mail) on every Tuesday.

💌 SUBSCRIBE our Newsletter (on Substack) 🚀

NOTE: 🔥 It was originally published on Substack (React20Bulletin Newsletter) — Subscribe now to get the newsletters delivered straight to your inbox every Tuesday! ➜ SUBSCRIBE (on Substack)

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

Hello React & ReactNative devs,

Welcome to the newsletter, React20Bulletin (in Substack) 🩵. Some of you already know me from my book, React Native Advanced Guide Book, which has secured over 2,300 GitHub stars. However, after a year of planning, React20Bulletin has finally started today 🔮.

NOTE: Since it’s our first issue and July is nearly over, today’s newsletter covers all the major news from the start of the month 🚀.

💌 Intro To React20Bulletin 💌

React20Bulletin is a top-notch, beginner-friendly newsletter — bringing you the 20 best React and React Native updates every Tuesday, delivered straight to your inbox (email). It covers 🔻

• ⚛️ Top 10 React news of the week
• ⚛️ Top 10 React Native news of the week
• 🤖 Top AI highlights of the week
• 💼 Open React (Native) JOB opportunities
• 🔥 Dev of the Week spotlight ➙ ❝You in Next News❞? 👇

Dev of the week is a chance to make your Profile, SDK, Product, or Work go viral in front of thousands of developers through the React20Bulletin newsletter at 100% free of cost 💟.

Do you want to be featured as ❝Dev of the Week❞ in next News? ➙ Click here to get started

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

🔮 Sponsor

Hire a World-Class Dev Team for Your Next Big Idea 🚀 We’re a seasoned team of full-stack developers with over 9 years of experience delivering scalable solutions across mobile, web, and blockchain.

🔹 Mobile Development — iOS & Android apps powered by React Native 🔹 Web Development — Fast, responsive interfaces with React 🔹 Blockchain Expertise — Smart contracts & dApps on Ethereum, Solana, and beyond.

We’ve successfully partnered with clients across the USA, Dubai, Europe, North America, and more — delivering tailored, high-performance products with global impact.

Whether you need a prototype, MVP, or full-scale launch, we’re ready to bring your vision to life.

Feel free to reach out directly via: Email: anisurrahmanbup@gmail.com or X (Twitter): @anis_RNCore

⚛️ All the Hot React Updates 🚀

🔸 Next.js 15.4 released 🚀

Last week, Vercel dropped Next.js 15.4 — packed with over 140 commits from 40 contributors. This release improves Turbopack Builds, performance, and stability. Highlights include:

• Turbopack Builds: Starting from 15.4, when you run the next build command with — turbopack, all 8,298 production tests now pass successfully. Turbopack is a super-fast bundler for Next.js, written in Rust, that combines your code, images, and assets to make builds faster and smarter — and it replaces Webpack (written in JS). With this, 15.4 is now more stable, and the team is already working on a beta for Next.js 16!
• Performance Improvements: Next.js 15.4 now handles faster page loads by prefetching data more efficiently and using better caching, along with smarter error handling.

🔸 NuxtLabs is joining Vercel 💥

Big news shaking up the frontend world: NuxtLabs is now part of Vercel!

🔹 Nuxt is a popular framework for building fast and SEO-friendly web apps with Vue.js. 🔹 Vercel is a cloud platform that helps developers deploy fast, modern websites — and it’s the team behind Next.js, Turborepo, Svelte, shadcn, and more.

The Nuxt team will continue to improve Nuxt and Nitro (Nuxt’s backend engine) with the same care, while exploring ways to integrate AI into the developer experience.

🔸 React Router now supports RSC 🔥

Another great piece of news is that React Router v7.7.0 now supports React Server Component (RSC).

Before RSC, React Router (also known as Framework Mode) required additional plugins to work with bundlers like Vite or Webpack. For example, the plugin @react-router/fs-routes was needed to automatically split code for each route, and @react-router/dev/routes was used to read the routes.ts file.

But now with RSC (also known as Data Mode), you don’t need these plugins anymore for basic routing, UI streaming from server to client, or splitting code for each route. All of these handle most of it natively. This reduces a lot of complexity.

Another cool thing is that, without RSC, every component needs to be bundled and sent to the browser, making users wait until all the data arrives. Now with RSC, only the rendered client components are loaded on the server and sent immediately to the browser 🚀.

🔸 More React News Inside 👇

• TanStack Start (a full-stack React framework powered by TanStack Router) now supports Selective SSR — allowing you to choose which routes use server-side rendering and which routes skip it for browser-only dependencies like localStorage.
• The new React Compiler docs have officially landed — now with their very own category and a dedicated reference page! Huge thanks to Lauren 💯.
• Untitled UI React is finally live 🚀. It’s the world’s largest collection of open-source React components — built with Tailwind CSS and React Aria (UI accessibility toolkit). Just copy, paste, and build. Check out the components.
• Material UI (React UI tools) v7.2 is out 💯! This release introduces Multiple Cascade Layers (CSS layer rules), letting you organize style priority into separate levels to simplify theming and ensure your sx prop (inline styling) overrides work reliably.
• Ant Design (a React-based UI component library) has released version 5.26.6, featuring smoother inputs with the correct border color and a more flexible Flex layout — no need to always pass children.
• Mantine (React Component Library) v8.2 is out! The release includes smarter layouts for <Container/> (You can now pass the strategy=”grid” attribute to the container, which lets certain sections stretch full screen, like banners or big headers), a handy new selection hook (makes it easy to track which items are selected in a list or table), and full HTML mode in the Rich Text Editor (you can switch to raw code view and edit the HTML directly).

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

<iframe src=”https://anisrncore.substack.com/embed" width=”480" height=”320" style=”border:1px solid #EEE; background:white;” frameborder=”0" scrolling=”no”></iframe>

🩵 Today’s — Dev of the Week 🎖️

Ruhul Amin, a curious-minded developer with 7 years of programming experience — 5 in React and 2 in blockchain — is now diving deeper into a PhD, focused on blockchain.

He has developed and audited numerous smart contracts and decentralized applications (dApps), built a smart contract library, is writing a book on smart contract security, and has led a government-backed project to verify certificates using blockchain.

He & his team are currently building a Hybrid-Backed USD-Pegged Stablecoin Ecosystem that allows swapping between different types of tokens (like fiat-backed and crypto-backed), especially designed for banks looking to onboard their customers into crypto.

💬 Need help with crypto or blockchain solutions? Reach out to Ruhul for expert guidance.

Ruhul subscribed to React20Bulletin and mentioned us on LinkedIn — now he’s featured 🤝. Follow the same steps to get into the newsletter!

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

⚛️ All the Hot React Native Updates

🔹 React Native Screens Overhaul 🚀

Software Mansion has released React Native Screens v4.13, which introduces Native Bottom Tabs for both iOS and Android. These tabs work with both the New and Legacy Architecture, making them flexible for all kinds of projects. The feature is currently in Alpha, so it’s still experimental — but ready for early adopters to test and give feedback. A release that’s winning hearts 😍. Kudos to Kafara, maciekstosio, Krzysztof & the whole team.

Evan from the Expo team confirmed that Native Bottom Tabs are coming to Expo Router soon for both platforms (Android & iOS).

🔹 Announcing Stable Unistyles 3.0 💥

Jacek has announced the first stable release of Unistyles 3.0, featuring C++-powered StyleSheets and styling via react-native-nitro-modules, giving it native-like performance. More importantly, Unistyles 3.0’s core highlight is Selective Updates, which check & update only the affected styles (e.g., from theme changes or screen rotation) — so your app updates without any full re-renders.

Unistyles 3.0 is designed for the New Architecture only, and is compatible with React 19, React Native 0.75, and Expo SDK 52. 📅 Support for Unistyles 2.0 ends on December 31, 2025, with no patches released after that date.

🔹 Announcing Ignite 11 — Bison 🔥

The Infinite Red team started the month by releasing Ignite 11, called “Bison.” This version now works only with the New Architecture, includes Expo SDK 53, and supports Android 15’s edge-to-edge enforcement by Google — meaning app content now uses the full screen, including areas under the status bar. Also, you can now Bring Your Own State Management tool, replacing the default MobX setup.

📝 Note: Ignite is a React Native / Expo boilerplate (starter kit) that’s been actively maintained since 2016, with over 18K GitHub stars.

🔹 More React Native News Inside 👇

• Heads up, everyone: 10 days left until React Universe Conf tickets get pricier. Late Birds batch drops Aug 1.
• Mike, Callstack’s CTO, shared that Apple’s on-device AI is now in React Native 🚀. They’ve released a preview of @react-native-ai/apple, a package that brings Apple Intelligence models — including a ~3B parameter model — right to users’ devices. It supports text generation, streaming, and more — all running locally.
• Kraen Hansen, along with the Callstack team, announced a new SDK, react-native-node-api, to support Node-API in React Native. Starting today, any of your favorite Node.js packages can run in your React Native project using this SDK.
• Software Mansion introduced react-native-wallet, built in collaboration with Expensify. It provides a React Native way to add payment cards to Apple Wallet and Google Wallet, allowing users to complete payments without manually entering card details — just tap a button. It works on both iOS and Android, and supports a wide array of card providers like Visa, MasterCard, Amex, and Discover.
• Software Mansion launched Private Mind, a React Native app built with React Native ExecuTorch, which brings Meta’s on-device AI framework that can run PyTorch machine-learning models 100% locally on your device. The source code is open, so you can easily add it to your project.
• Kiryl from the Mergelo team released react-native-keyboard-controller v1.18.0, which now lets you bring your custom views inside the keyboard — meaning you can place custom UI (like a “Scan QR” button) directly above the keys.

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

🎬 New Dev Content — Live?

• Deploy TanStack Start in Less Than A Minute — Jack Herrington breaks it down quickly. Don’t miss this!
• Build a Full Stack mobile app in just 8 Hours (React Native, Expo, Clerk, Supabase) — by notJust․dev. Be sure to catch this!
• Tanstack Start — A deep dive into THE React Framework — blog published by Pedro Martins.

💼 React Jobs — Now Hiring 🔥

• Frontend Engineer — React Native — Austin — Apply Here
• React Native Mobile Developer​/Remote — Dubai — Apply Here
• Senior JavaScript Engineer (React/TypeScript) — Remote — Apply Here
• Senior Full Stack Developer (TypeScript) — Remote — Apply Here

Got a React or React Native job opening? Send it to me only if it’s legit — I share authentic roles from trusted companies. No scams.

🤖 AI Updates — You’ll Love

• Announcing Grok CLI — an open-source AI agent that brings the power of Grok (an AI assistant developed by xAI) directly into your terminal.
• Grok 4 is available in Cursor (an AI Code Editor)!
• Cursor can now make to-do lists, search PRs, queue messages, and much more.
• Introducing Zero AI — an AI CLI that allows you to use Grok4, Claude, Gemini, and a lot more — crafted by Oskar from CallstackIO.

🤔 Pro Programming Tips

• When you need to optimize something, you should be able to go DOWN a layer of abstraction.
• If you’re starting a new Expo project, consider these 12 tips.

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

🏕️ Extras You Shouldn’t Miss

• Nuxt 4.0 released — A smoother dev experience with smarter data fetching and better TypeScript support. Read the official blog.
• Supabase Drops 7 New Components — Fresh tools for faster builds and better UI. Explore the update.
• OpenCut Alpha Is LIVE! — Import videos, edit timelines, and more — all in your browser. No watermarks, full privacy. Try it now.

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

💟 Partner with React20Bulletin

💟 Sponsor With Us → Click here

💼 Hire Our Dev Team → Click here

💯 More about Newsletter/ Author → Click here

😍 Support us on → Medium, X (Twitter), LinkedIn, and 🦋 Bluesky.

SUBSCRIBE to the Newsletter on Substack to get the issues directly to your MAIL — Every Tuesday.

💌 SUBSCRIBE this Newsletter (on Substack) 🚀

🔹 Thanks for subscribing to React20Bulletin. This post is public, so feel free to share it. ➜ Share

🔹 Help shape the next issue — we’d love your thoughts! ➜ Give your Feedback!

🚀 A top-notch newsletter bringing you the 20 best React and React Native updates every Tuesday — delivered straight to your inbox (email)

Hey React & React Native folks!

It’s official! After months of planning, React20Bulletin launches Tuesday, July 22 🎉. 20 React & React Native news, delivered to your inbox (email) every Tuesday. Subscribe now (on Substack) to get it FREE!

💌 Intro to React20Bulletin 🎉

React20Bulletin is a top-notch, beginner-friendly newsletter — the first of its kind — bringing you the 20 best React and React Native updates every Tuesday, delivered straight to your inbox (email). It covers 🔻

• Top 10 News on React including Next.js, React Router, Vercel SDKs, shadcn/ui, Remix, Remotion, TanStack Router & many more updates and
• Top 10 News on React Native including Expo, OneJS, Software Mansion (Reanimated, Gesture Handler), CallstackIO (VisionOS, RNTL), MergeloIO (Vision Camera, Nitro Module) SDK updates, Skia & many more.

🩵 Join thousands of devs staying connected ➙ SUBSCRIBE and stay updated.

🔥 Why Subscribe? 🔥

Subscribing to React20Bulletin is worthwhile because you’ll receive all of the following goodies every Tuesday, straight to your inbox (mail):

• ⚛️ Top 10 React news of the week
• ⚛️ Top 10 React Native news of the week
• 🤖 Top AI highlights of the week
• 💼 Open React job opportunities
• 🔥 Dev of the Week spotlight ➙ ❝You in Next News❞ 👇

Dev of the week is a chance to make your Profile, SDK, Product, or Work go viral in front of thousands of developers through the React20Bulletin newsletter at 100% free of cost 💟 (Details on next section 🔻🔻🔻)

🩵 Why wait? Subscribe now and be part of the momentum 🚀.

🚀 How to be a → Dev Of The Week? 🎖️

How can you be in the next news for 100% free?

If you’d like to be featured as Dev of the Week in the React20Bulletin next newsletter, follow these steps:

• Subscribe to the React20Bulletin newsletter 🤝.
• Read the most recent newsletters.
• Mention React20Bulletin and author Anis on X (Twitter), and share how the newsletter helped expand your knowledge.

What will you get in return?

• Each week, we’ll select one lucky developer from our subscriber list who posts their journey with React20Bulletin on Twitter (X). We’ll then spotlight that developer’s latest SDK or product in the React20Bulletin newsletter — shared with thousands of developers across the community 🚀

🩵 Interesting? SUBSCRIBE React20Bulletin: anisrncore.substack.com

🔥 We’ll make you — or your work — go viral. Just subscribe on Substack.

💟 Sponsor With Us → Click here

💼 Hire Our Dev Team → Click here

💯 More about React20Bulletin Newsletter/ Author → Click here

Hi React Native Developers,

Exciting news in the world of React Native is that V0.74 was released just a couple of days ago with over 1600 commits. The highlights are:

• Yoga 3.0
• New Architecture: Bridgeless by Default
• New Architecture: Batched onLayout Updates
• Yarn 3 for New Projects

Let’s dive into each of the new highlights.

Yoga 3.0

Let's understand first what yoga is in React Native.

Yoga — the layout engine

Yoga is an open-source layout engine developed by Meta. The engine which refers to how UI elements (such as buttons, text, images, etc.) are arranged and positioned within a user interface.

Yoga calculates these four for each UI element.

1. Positioning
2. Sizing
3. Alignment
4. Spacing

With Yoga, you can create responsive layouts that adapt to different screen sizes and orientations. It also implements a widely used concept called CSS Flexbox in React Native. So you already feel that yoga is the heart (♥︎) of React Native flexible UI.

Yoga 3.0 — what’s new?

In all previous versions of React Native, there were some incorrect layout behaviors. Yoga 3 solved all of them. One of the most common issues was that the ‘row-reverse’ style was not functioning properly.

Let’s look at the image below where the left one is from V0.73 and the right one is from V0.74.

In the above image, we have a <Container/>, then inside it a <Parent/> component, then inside two <Child/> components.

We then applied this style in the <Parent/> component.

// Style for <Parent/> component
style={{
      flexDirection: 'row-reverse',
      backgroundColor: 'dodgerblue',
      flex: 1,
      marginLeft: 100,
      marginRight: 20,
      marginVertical: 20,
      alignItems: 'center'
}}

Did you notice, that we added a marginLeft of 100 pixels for <Parent/>? Yeah, but see the output in React Native V0.73 (the left one) from the above image. It shows a 100 pixels margin on the right (not on the left) !! Okay, now let’s see the output of React Native V0.74 (the right one). Great, in V0.74 we see a perfect 100-pixel margin at left, and also two <Child/> components got reversed 🚀

So, in Yoga-2, if you apply a ‘row-reverse’ flex-direction with “margin” or “padding” or “border” in a component then the edges of that component also get flipped. But in Yoga-3 it has been solved perfectly 💯

Yoga-3 has brought some other important styling components that were missing in Yoga-2.

• 'space-evenly' property for alignContent style
• 'static' property for position style

New Architecture: Bridgeless by Default

Old Architecture

React Native previously used a bridge to communicate between JavaScript and native modules. The Modules are written in C++, Objective C, Java, or kotlin to access native features like cameras, sensors, etc. Unfortunately, the Bridge has some limitations.

One main limitation is that each time one layer communicates with another, it involves serializing (converting JS Object to JSON String) and deserializing (converting JSON String back to JS Object) data. Since the conversion takes time, this process adds a performance issue to the communication flow.

New Architecture — performance booster

The good news is that the React Native team was able to replace the bridge with an interface called JSI (JavaScript Interface). It was written in C++ and it opens up all the native features available to your JS code, which means that you can call native methods without any data serialization or deserialization, making the app super fast.

Remove OLD architecture dependencies

JSI is the core part of New Architecture. To enable JSI (New Architecture) with its full power in our app, we need to first remove the app dependency from OLD bridge architecture. To do that, the React Native Team has introduced three pillars of New Architecture, which allow us to remove full dependency on the bridge.

1. TurboModules: It removed the app dependency on native calls from the bridge (released on V0.68)
2. Fabric Renderer: It removed the app dependency on component rendering from the bridge (released on V0.68)
3. Bridgeless Mode: It removed the app dependency on everything else (i.e: the rest of the React Native runtime: error handling, global event emitters, timers, and more) from the bridge (released on V0.73)

What is new in V0.74?

From V0.74, once you enable the New Architecture, you will see that ‘Bridgeless Mode’ has been enabled automatically. However, the New Architecture itself is still not yet enabled by default.

When you enable New Architecture in your React Native app with V0.74, you will see these two lines like the below in your Metro Log:

That’s it 🚀. From React Native V0.74, you don’t need to enable Bridgeless mode manually after enabling New Architecture 💯

New Architecture: Batched onLayout Updates

Another great news is that the React Native team not only made the New Architecture Bridgeless Mode the default, but they also improved this architecture to handle batched onLayout updates (executing multiple updates in a single rendering). This optimization enhances performance by minimizing layout-related computations during rendering.

The “onLayout” props

The onLayout prop in React Native is used to handle layout (position) changes for a component. When the layout of a component changes (due to mounting, resizing, rotation, or other factors), the onLayout callback function is triggered.

You can use this prop like below to perform actions based on the updated layout information.

function App(){
  return (
      <View
         onLayout={() => {
          console.log('Component has been invoked 🚀')
         }}
      />
   )
}

How “onLayout" batch update works?

Assume the component <App/> is as shown below, where each View triggers an onLayout callback function when mounted.

function App() {
 const [state1, setState1] = useState(false)
 const [state2, setState2] = useState(false)
 const [state3, setState3] = useState(false)

 console.log('✅ COMPONENT RE-RENDERED .....')

 return (
  <View>
   <View
    onLayout={() => {
     console.log('FIRST View invoked')
     setState1(true) // Update state1 when the View mounts
    }}></View>

   <View
    onLayout={() => {
     console.log('SECOND View invoked')
     setState2(true) // Update state2 when the View mounts
    }}></View>

   <View
    onLayout={() => {
     console.log('THIRD View invoked')
     setState3(true) // Update state3 when the View mounts
    }}></View>
  </View>
 )
}

Now, in React Native V0.73, you will see an output like below 👇

Did you notice that, on each execution of the “onLayout” callback, it re-renders the whole component? Yeah, it is not expected.

Now, let’s see the output in React Native V0.74 with enabling New Architecture 👇

Amazing performance 🔥. The component got re-rendered only once for all 3 “onLayout” callback execution.

A good summary in the below image on “onLayout” batch update 👇

Yarn 3 for New Projects

Yarn 3 is now the default JavaScript package manager for new projects initialized with React Native Community CLI. This replaces Yarn Classic (1.x), which was deprecated and previously used as the default.

Yarn 3 speeds up the process of installing and updating dependencies and optimizes how dependencies are stored.

That’s it 🙌

React Native version 0.74 introduced significant improvements in component layout, and architecture, batched onLayout updates, and integration with Yarn 3.

All Latest React Native News 🚀

I’m writing on all the latest React Native news on my Twitter account. You can follow me there & keep yourself updated with this highly evolving space. (My Twitter account: Anis).

I’m also publishing my deep R&D on React Native's latest releases of different SDKs. (LINK: https://github.com/anisurrahman072/React-Native-SDK-Research)

I’m thrilled to share some exciting news from Software Mansion! 🚀 In the ever-evolving world of React Native, they’ve made remarkable strides. Last month, they unveiled react-native-screens version 3.30, and it comes with a groundbreaking feature: “Custom Screen Transitions Based on Gesture.”

In today’s newsletter, we’ll dive into the code and explore how we can harness this powerful feature in our React Native apps.

Before we delve further, let’s explore the essential groundwork of React Native Screens.

The React-Native-Screens library

When building React Native applications, effective navigation is essential. React Native Screens, developed by Software Mansion, provides native navigation primitives specifically tailored for React Native apps. These primitives correspond to native components offered by your phone’s operating system. By leveraging these components, React-native-screens enhances performance and ensures that your app operates seamlessly.

However, it’s important to note that React Native Screens isn’t intended to be used as a standalone library for handling navigation independently. Instead, it serves as a dependency for full-featured navigation libraries.

Some of the most popular full-featured navigation libraries are:

• react-navigation (Most popular for bare React Native apps)
• react-native-navigation (Created by Wix)

We will use react-navigation for this newsletter. Let’s get cooking with it! 🍟.

Custom screen transitions based on Gesture

From now on, in React Native apps, developers can apply a screen transition effect based on users’ gestures (like swipe up, swipe left, etc) while going back to the previous screen. To make this feature ready, three open-source teams from Software Mansion came to the table.

1. react-native-reanimated
2. react-native-screens
3. react-native-gesture-handler

All the teams have published their dependencies for this feature in their latest release. Just “react-native-reanimated ” team's latest release is in pre-release V3.9.0-rc.0.

In the next section, we will explore the necessary additions or upgrades to our app, enabling the implementation of this feature.

Install with React-Navigation

To enable Custom screen transitions with gesture let’s install the following packages.

• First, install React Navigation:

npm install @react-navigation/native

• Then install React Native Gesture Handler, React Native Screens (Latest version is important) & its dependencies:

npm install react-native-gesture-handler react-native-screens react-native-safe-area-context

• Finally, install the pre-release version (V3.9.0-rc.0) of “React Native Reanimated”. Or if you already installed it before then upgrade it to “3.9.0-rc.0”.

npm install react-native-reanimated@3.9.0-rc.0

You can check the reanimated release note from here (Change Log of reanimated 3.9.0-rc.0).

Code Example

To enable custom screen transitions based on gestures, we need to modify our navigation file (the file that declares the names of each screen to navigate). We will use “App.js” as our navigation file in this example.

1. We have to import “createNativeStackNavigator” from “react-native-screens/native-stack” instead of “@react-navigation/native-stack”. They both provide the same functionalities on navigation but “react-native-screens/native-stack” provides an extra functionality for handling Custom screen transitions.
2. We need to wrap the <NavigationContainer /> component by using <GestureDetectorProvider /> from “react-native-screens/gesture-handler”. The GestureDetectorProvider enables you to recognize and handle various gestures (like swipes, pinches, rotations, etc.) in your React Native app.
3. Finally, wrap your whole app by using <GestureHandlerRootView /> from “react-native-gesture-handler” as it allows your app to catch all touch events.

The imports should look like below in “App.js”:

// Imports in "App.js"
import { NavigationContainer } from '@react-navigation/native'
import { GestureHandlerRootView } from 'react-native-gesture-handler'
import { createNativeStackNavigator } from 'react-native-screens/native-stack'
import { GestureDetectorProvider } from 'react-native-screens/gesture-handler'
import { ScreenTransition } from 'react-native-reanimated'

As we have imported all dependencies, now let’s do all the wrapping with these imported components:

// Imports...

// Build the stack for screens
const Stack = createNativeStackNavigator()

// Build App function
function App() {
  return (
    <GestureHandlerRootView style={styles.container}>
      <GestureDetectorProvider>
        <NavigationContainer>
          <Stack.Navigator>
            <Stack.Screen name="Home" component={Home} />
            <Stack.Screen name="ScreenA" component={ScreenA} />
            <Stack.Screen name="ScreenB" component={ScreenB} />
          </Stack.Navigator>
        </NavigationContainer>
      </GestureDetectorProvider>
    </GestureHandlerRootView>
  );
}

Let’s recap what we did in the above navigation file. The top component is now <GestureHandlerRootView />, which detects all touch events in your app. The next component is <GestureDetectorProvider />, responsible for identifying whether the touch corresponds to a gesture (such as swipes, pinches, rotations, etc.). After that, we have our <NavigationContainer /> component.

That’s it! You’ve enabled gesture action handling power in your React Native app. Now it’s time to apply some “go back” transitions to each screen, as shown below:

// Imports...

// Build the stack for screens...

// Build App function
function App() {
  return (
    <GestureHandlerRootView style={styles.container}>
      ......
        <Stack.Screen name="Home" component={Home} />
        <Stack.Screen name="ScreenA" component={ScreenA} options={{
            goBackGesture: 'twoDimensionalSwipe'
          }}
        />
        <Stack.Screen name="ScreenB" component={ScreenB} options={{
            goBackGesture: 'swipeDown'
          }}
        />
      ......
    </GestureHandlerRootView>
  );
}

We used the “twoDimensionalSwipe” gesture for “ScreenA” & “swipeDown” gesture for “ScreenB”. You are all set 🚀.

For your information, below are all the available gestures from React Native Screens:

• swipeRight
• swipeLeft
• swipeUp
• swipeDown
• verticalSwipe
• horizontalSwipe
• twoDimensionalSwipe

Now let’s create the “Home” screen (component) to navigate to “ScreenA” & “ScreenB”. The “Home” screen will be like the below:

// Imports ...

// Build "Home" screen (component) 
export default function Home({ navigation: { navigate } }) {
  return (
    <View>
      {/* GO TO SCREEN A */}
      <TouchableOpacity onPress={() => navigate("ScreenA")}>
        <Text> ScreenA </Text>
      </TouchableOpacity>

      {/* GO TO SCREEN B*/}
      <TouchableOpacity onPress={() => navigate("ScreenB")}>
        <Text> ScreenB </Text>
      </TouchableOpacity>
    </View>
  );
}

Design your screens (components) ScreenA and ScreenB. Reload your app, navigate from the Home screen to “ScreenA”, and then swipe in any direction as we’ve set up “twoDimensionalSwipe” for ScreenA. For “ScreenB”, perform a swipe down, as we’ve configured “swipeDown” for it. You’ll observe an effect like the one shown below: 👇

That’s it 🙌

In the latest React Native screens V3.30, a notable feature has been introduced: screen transition animations for “go back” gestures. This enhancement allows smoother and more visually appealing transitions when navigating between screens.

All Latest React Native News 🚀

I’m writing on all the latest React Native news on my Twitter account. You can follow me there & keep yourself updated with this highly evolving space. (My Twitter account: Anis for React Native)

I’m also publishing my deep R&D on React Native’s latest releases of different SDKs. (LINK: https://github.com/anisurrahman072/React-Native-SDK-Research)

A comprehensive guide to React Native Component Testing.

Over the course of a month, I meticulously crafted this comprehensive guide on testing for React Native applications. Each code snippet included in this article was initially executed successfully on my MacBook, ensuring their reliability.

This article serves as an all-encompassing resource on TESTING, covering a wide array of topics such as component testing, mocking, provider tests, fireEvent, and waitFor asynchronous operations, among others. It is designed to equip you with a thorough understanding of testing a React Native app, from getting started and setting up configurations, to troubleshooting potential errors.

🔥 I have published an In Depth “React Native Advanced Guide Book” which secured ≈1000 GitHub STAR. (Free Book Link)

Let’s look at the topics that we will learn from this article.

1. Types of React Native Testing
2. Types of JavaScript Testing
3. Tools for React Native Testing
4. Some Testing Libraries (Confusing names)
5. When to apply Component Testing ?
6. React Native Testing Library (RNTL)
7. Setup JEST config (for RNTL)
8. Common Error in JEST config — ES6/Ts/cjs/mts
9. Command to run a test file
10. React Native Testing Library (RNTL) APIs
11. 🪵 RNTL API — render()
12. 🐠 TEST Component with Provider — by render() API
13. 🐠 “queries” option — render() API
14. 🐠 “update" option — render() API
15. 🐠 “debug" option — render() API
16. 🪵 RNTL API — userEvent()
17. 🐠 Example of FireEvent() API
18. 🪵 RNTL API — waitFor()
19. What is Mocking ?
20. 🍁 Difference between jest.fn() & jest.mock()
21. 🍁 How to Mock a Real Function (by jest.fn()) ?
22. 🍁 How to Mock a Native Module (by jest.mock())?
23. 🍁 Another example of Native Module Mocking ( jest.mock() )
24. Some Advanced Share about RNTL
25. Differentiating between host and composite elements
26. 🚀 Intro to E2E Testing

Let’s get started with RN — TESTING 🚀

Introduction to Testing in React Native

In React Native, testing is important to prevent fragile programming and ensure that your code continues to work in the future. You can use different automated ways to ensure your app works as expected, ranging from static analysis to end-to-end tests. Writing testable code is intertwined with writing clean, modular code.

Types of React Native Testing

For practical reasons, we can distinguish React Native testing into these two parts:

1. JavaScript Testing — We mainly use the Jest framework to test our JavaScript code. When we work with React Native, we can group our tests into unit and integration tests. However, these two groups are not very different, so we do not need to separate them for practical purposes. We can just remember them so that we can comprehend them clearly. In the next section, we will see how many types of testing JavaScript Testing includes.
2. End-to-End app Testing — It typically verifies the entire application from start to end to ensure the user flows work correctly, this can include testing a user can sign up, login, perform activities, navigate to different pages and log out from an application. These tests give the most confidence because they’re pretty much a robot running your app on a device. We perform E2E tests using Detox, Appium, or any other mobile testing framework that we know.

NOTE: Because most of your business code lives in JS, it makes sense to focus your efforts there.

Below, we see how the testing flow (pyramid) works. Testing starts with Static Analysis & ends with End-to-End test.

NOTE: The main focus of this article is to dive you into the second part of Pyramid (JavaScript Testing).

Types of JavaScript Testing

We can split JavaScript Testing into these parts so that we can understand each step easily.

1. Unit testing: It typically focuses on verifying the functions works correctly, such as providing inputs to a function and checking its output against expected results.
2. Component testing: It focuses on verifying an individual component renders correctly and behaves as expected based on the provided inputs to it.
3. Integration testing: It tests how multiple components interact with each other, generally involves rendering multiple components and requires external dependencies, services or APIs. It is required to mock these for tests.
4. Snapshot testing: It captures a snapshot of the rendered output of a component and compares it to previous saved snapshot to detect visual changes. It should be used with in combination with unit and component testing to ensure comprehensive coverage of an application.

Tools for React Native Testing

• Static Analysis: Flow, eslint
• JavaScript Test: Jest, Mocha, ava
• Component Testing: React Native Testing Library by CallStack
• Webdriver Test (End to end test): Detox, Appium

Some Testing Libraries (Confusing names)

I’m giving you some testing libraries and their creators or users. You may already be confused by the almost identical names of different libraries in the JS testing world.

• react-testing-library: It is used for React web react-testing-library which was created by Kent C. Dodds.
• react-test-renderer: Created by meta & they use it for testing https://www.npmjs.com/package/react-test-renderer. Also, react-native-testing-library (RNTL) has peerDependencies listing for it.
• react-native-testing-library(RNTL): Created by CallStack on top of react-test-renderer & they use it for testing React Native Components https://github.com/callstack/react-native-testing-library.
• jest-native: It is used with JEST & react-native-testing-library . Use it for additional JEST matchers https://github.com/testing-library/jest-native.

When to apply Component Testing ?

React Native Component Testing is a way of verifying the behavior and appearance of your React Native components in isolation from their dependencies. It can help you ensure that your components work as expected, follow the best practices, and are easy to maintain.

Some scenarios are below where React Native Component Testing can play a vital role.

• When you want to test the rendering and interaction of your components without mocking the native modules or using a device emulator.
• When you want to test your components across different platforms and configurations. For example, you can use Jest’s platform-specific extensions to run different tests for iOS and Android, or use its configuration options to set up different environments or presets for your tests.
• When you want to test your components with different data and props. For example, you can use Jest’s data-driven testing feature to run the same test with different inputs, or use its mock functions to simulate the props that your component receives from its parent.
• When you want to test your components with different users and roles. For example, you can use Jest’s context feature to provide different values for global variables or constants that affect your component’s behavior, or use its spy functions to monitor how your component interacts with other modules or functions.
• When you want to test your components with different themes and styles. For example, you can use Jest’s setupFiles option in JEST config to import a global style sheet or a theme provider for your tests, or use its expect.extend feature to create custom matchers for testing the appearance of your component.

Let’s get started with JS (Component) Testing

React Native Testing Library (RNTL)

The React Native Testing Library (RNTL) is a lightweight solution for testing React Native components created by CallStack. It provides light utility functions on top of react-test-renderer, in a way that encourages better testing practices. Its primary guiding principle is:

NOTE: The more your tests resemble the way your software is used, the more confidence they can give you.

Install RNTL

As from React native version 0.38, the project will have a default Jest setup with react-test-renderer included when you create the react-native project. Just make sure that your react-test-renderer version matches exactly your react version in package.json file.

To install RNTL, open a terminal in your project’s folder and run this below command.

yarn add - dev @testing-library/react-native

In order to use additional React Native-specific Jest matchers from @testing-library/jest-native package add it to your project by this below command.

yarn add - dev @testing-library/jest-native

Then add this additional Jest matcher to your jest tests by using setupFilesAfterEnv option in your Jest configuration. Jest configuration is usually located either in package.json under "jest" key like below or in a jest.config.js file in your project root directory.

{
  "preset": "react-native",
  "setupFilesAfterEnv": ["@testing-library/jest-native/extend-expect"]
}

My package.json looks like below with additional Jest matcher config.

Setup JEST config (for RNTL)

We learned how to add JEST configuration for React Native Testing Library (RNTL) in either the package.json file or the jest.config.js file. Now let’s look at all the important options of JEST that we can set optionally along with preset or setupFilesAfterEnv in JEST configuration.

🧩 “preset”

jest-expo preset is used for testing React Native projects created using Expo, otherwise it would be react-native. Example like below:

"preset": "react-native"

🧩 “setupFiles”

This option is used to specify a module that should be executed before any tests run, such as setting up the test data or mocking external components, Native Modules, dependencies, services or APIs. Example like below:

"setupFiles": [
     "./src/mock/api",
     "./src/mock/services",
  ]

🧩 “setupFilesAfterEnv”

This option is used to set up additional testing libraries such as @testing-library/jest-native. Example like below:

"setupFilesAfterEnv": ["@testing-library/jest-native/extend-expect"]

🧩 “moduleFileExtensions”

This option is used to specify the file extensions that should be looked for when running tests. For example, if you have test files with the extensions “.ts”, “.tsx”, “.js”, “.jsx”, “.json”, and “.node”, you can specify them in the “moduleFileExtensions” option like this:

"moduleFileExtensions": [
  "ts",
  "tsx",
  "js",
  "jsx",
  "json",
  "node"
]

This option is useful for React Native projects that use TypeScript or other languages that need to be transpiled before running. It also helps Jest to recognize different file types and handle them accordingly. For example, Jest will use “ts-jest” to transform TypeScript files and “jest-environment-jsdom” to provide a browser-like environment for testing.

🧩 “moduleNameMapper”

The option “moduleNameMapper” is used to tell Jest how to find the files that you import in your code. Sometimes, you may use shortcuts or aliases to import files, for example, instead of writing:

import { Button } from "../../components/Button";

You may write:

import { Button } from "components/Button";

This makes your code shorter and cleaner, but Jest may not know where to find the file “components/Button”. To fix this, you can use the option “moduleNameMapper” to map the shortcut or alias to the actual file path. For example, you can write:

"moduleNameMapper": {
  "^components/ (.*)$": "<rootDir>/src/components/$1"
}

This means that Jest will replace any import that starts with “components/” with “<rootDir>/src/components/”. For example, “components/Button” will become “<rootDir>/src/components/Button”. You can use any regular expression to match the shortcut or alias, and use “$1”, “$2”, etc. to refer to the captured groups. You can also map different shortcuts or aliases to different file paths by using more lines.

🧩 “transformIgnorePatterns”

The option “transformIgnorePatterns” is used to tell Jest which files it should not change before testing them. Sometimes, Jest needs to change some files, for example, if they use a different language or syntax than JavaScript. By default, Jest will not change any files in the “node_modules” directory, because they are usually already written in JavaScript. But sometimes, you may need to change some of them, for example, if they use TypeScript or ES6 syntax. To do that, you can use a special code to match the files that you want to change, and use a “!” sign to exclude the ones that you don’t. For example:

"transformIgnorePatterns": [
  "/node_modules/ (?! (react-native|react-native-cookies)/)"
]

This means that Jest will change any file in the “node_modules” directory that does not start with “react-native” or “react-native-cookies”. You can add more exceptions by using the “|” sign. You can also use other codes to match different parts of the file name, such as the file type or the folder name.

🧩 “transform”

Jest will not actually change the original files in the “node_modules” directory. It will only change them temporarily in memory when it runs the tests. This is called “transformation” and it is done by using some tools called “transformers”. Jest has some built-in transformers that can handle common file types, such as JavaScript, TypeScript, JSON, etc. You can also use custom transformers that you install from npm or write yourself. You can specify which transformer to use for each file type by using the option “transform” in your Jest config file. For example:

"transform": {
  "\\.[jt]sx?$": "babel-jest",
  "\\.ts$": "ts-jest"
}

This means that Jest will use “babel-jest” to transform any file that ends with “.js”, “.jsx”, “.ts” or “.tsx”, and use “ts-jest” to transform any file that ends with “.ts”. You can use any regular expression to match the file type. You can also use different transformers for different files or directories by using an array of arrays.

🧩 "testEnvironment"

This option allows you to specify the test environment that will be used for testing. By default, Jest uses jsdom, which simulates a browser-like environment. However, for React Native projects, you may want to use node instead, which is faster and more lightweight. For example:

"testEnvironment": "node"

This way, Jest will run your tests in a Node.js environment, which is more suitable for testing React Native components. You can also create your own custom test environment.

🧩 "testMatch"

The “testMatch” option is used to specify which files should be considered as test files by Jest. It is an array of glob patterns that match the file paths of your test files. For example, if you have a folder called “tests” in your project root, and you want to run all the files inside it that end with “.test.js” or “.spec.js”, you can use this option:

"testMatch": [
    "<rootDir>/__tests__/*.js",
    "<rootDir>/src/**/*.(test|spec).js"
]

The <rootDir> is a special token that Jest replaces with the path to the project root. The ** means any subdirectories, and the * means any file name. The (test|spec) means either “test” or “spec”, and the .js means the file extension. You can use other glob patterns to match different file names or extensions, such as .jsx, .ts, or .tsx.

You can also have multiple patterns in the array, and Jest will run any file that matches at least one of them. For example, if you have some test files in a folder called “tests” and some other test files in your “src” folder, you can use this option:

"testMatch": ["<rootDir>/tests/**/*.(test|spec).js"]

This will run all the files in the “tests” folder or its subfolders that end with “.test.js” or “.spec.js”.

🧩 "coverageThreshold"

The “coverageThreshold” option is used to specify the minimum percentage of code coverage that your tests must achieve. Code coverage is a measure of how much of your code is executed by your tests. It can be calculated for different aspects of your code, such as statements, branches, functions, and lines.

The “coverageThreshold” option is an object that has a “global” property and optionally a “per-file” property. The “global” property is another object that has four properties: “statements”, “branches”, “functions”, and “lines”. Each of these properties is a number between 0 and 100 that represents the percentage of code coverage required for that aspect. For example, if you want to enforce that your tests cover at least 80% of your statements, 70% of your branches, 90% of your functions, and 85% of your lines, you can use this option:

"coverageThreshold": {
      "global": {
        "statements": 80,
        "branches": 70,
        "functions": 90,
        "lines": 85
    }
}

The “per-file” property is an array of objects that have a “path” property and a “threshold” property. The “path” property is a glob pattern that matches the file paths of your code files. The “threshold” property is an object that has the same four properties as the “global” object. This way, you can specify different coverage thresholds for different files or groups of files. For example, if you want to enforce that your tests cover at least 95% of your components and hooks, and at least 75% of everything else, you can use this option:

"coverageThreshold": {
      "global": {
        "statements": 75,
        "branches": 75,
        "functions": 75,
        "lines": 75
      },
      "per-file": [
        {
          "path": "**/src/components/*.tsx",
          "threshold": {
            "statements": 95,
            "branches": 95,
            "functions": 95,
            "lines": 95
          }
        },
        {
          "path": "**/src/hooks/*.tsx",
          "threshold": {
            "statements": 95,
            "branches": 95,
            "functions": 95,
            "lines": 95
          }
        }
    ]
}

If you use the “coverageThreshold” option, Jest will fail the test run if the actual code coverage is lower than the specified thresholds. This can help you ensure that your tests are comprehensive and reliable.

Let’s understand each Code Coverage terms “statements”, “branches”, “functions”, “lines” with examples below.

🍭 Statements
A statement is a single instruction or command in your code, such as a variable declaration, an assignment, a function call, a loop, a conditional, etc. For example, in this code snippet:

let x = 10; // statement 1
let y = 20; // statement 2
if (x > y) { // statement 3
  console.log("x is greater"); // statement 4
} else {
  console.log("y is greater"); // statement 5
}

There are five statements in total. The statement coverage is the percentage of statements that are executed by your tests. For example, if your tests only run the “else” branch of the conditional, then the statement coverage is 60% (3 out of 5 statements are executed).

🍭 Branches
A branch is a possible path of execution in your code, such as an “if” or “else” block, a “case” or “default” block in a switch statement, a ternary operator, etc. For example, in this code snippet:

let x = 10; 
let y = 20; 
if (x > y) { // branch 1
  console.log("x is greater"); 
} else { // branch 2
  console.log("y is greater"); 
}

There are two branches in total. The branch coverage is the percentage of branches that are executed by your tests. For example, if your tests only run the “else” branch of the conditional, then the branch coverage is 50% (1 out of 2 branches are executed).

🍭 Functions
A function is a block of code that performs a specific task and can be invoked by other parts of your code. For example, in this code snippet:

function add(a, b) { // function 1
  return a + b; 
}

function subtract(a, b) { // function 2
  return a - b; 
}

let x = add(10, 20); // statement 3
let y = subtract(30, 15); 

There are two functions in total. The function coverage is the percentage of functions that are invoked by your tests. For example, if your tests only call the “add” function, then the function coverage is 50% (1 out of 2 functions are invoked).

🍭 Lines
A line is a single line of code in your source file. For example, in this code snippet:

let x = 10; // line 1
let y = 20; // line 2
if (x > y) { // line 3
  console.log("x is greater"); // line 4
} else {
  console.log("y is greater"); // line 5
}

There are five lines in total. The line coverage is the percentage of lines that are executed by your tests. For example, if your tests only run the “else” branch of the conditional, then the line coverage is 80% (4 out of 5 lines are executed).

🧩 "watchPlugins"

The watchPlugins option is a way to customize how Jest runs your tests in watch mode. Watch mode is a feature that lets you run only the tests that are related to the files you have changed in your code. This can save you time and make your testing process more efficient.

To use the watchPlugins option, you need to install a plugin that provides some extra functionality for your tests. For example, you can use jest-watch-typeahead, which is a plugin that lets you filter your tests by file name or test name. This can help you find and run the tests you want more easily.

To use jest-watch-typeahead, you need to do the following steps:

• Install jest-watch-typeahead as a dev dependency: yarn add --dev jest-watch-typeahead
• Add the plugin to your Jest config in package.json like below:

"watchPlugins": [
    "jest-watch-typeahead/filename",
    "jest-watch-typeahead/testname"
]

This will enable you to use the jest-watch-typeahead plugin in your watch mode. When you run yarn test --watch, you will see two new options in the menu: p for filtering by file name and t for filtering by test name.

Common Error in JEST config — ES6/Ts/cjs/mts

You may encounter the error below while running tests on your screens.

The reason for this error is that Jest failed to parse a file because it encountered an unexpected token. This can happen when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax, such as ES6 syntax or TypeScript syntax.

NOTE: To configure it properly and solve this issue, you need to keep in mind that both .babelrc and babel.config.js do the same thing. The file .babelrc was used in older configurations, but the file babel.config.js is being used by modern JS projects. So, use only babel.config.js to configure Babel properly.

SOLUTION

There are two ways to solve this error, but you need to maintain the sequence. If solution A does not work, then go for solution B.

Solution (A): By “transform” option of Jest config.

I already explained in the previous section why we need to add a config option “transform” and what it does. Basically, an error like “Cannot use import statement outside a module” is usually caused by a file or its dependencies using non-standard JavaScript syntax.

To solve this issue, add a “transform” config to your Jest configuration file, either in the package.json or jest.config.js file, like below:

// For jest.config.js
transform: {
    '^.+\\.jsx?$': 'babel-jest'
    '^.+\\.tsx?$': '<rootDir>/node_modules/ts-jest/preprocessor.js'
}

For React Native versions older than v0.61, you will have to use the code below instead of the code above.

transform: {
    '^.+\\.js$': '<rootDir>/node_modules/react-native/jest/preprocessor.js'
}

Then add a babel.config.js file to the root of your project directory and add the code below.

// babel.config.js
module.exports = {
  presets: ['module:metro-react-native-babel-preset']
};

If the above “preset” does not work for you, then add the code below.

// babel.config.js
module.exports = {
  presets: ['module:metro-react-native-babel-preset', '@babel/preset-env']
};

NOTE: When you add the code, you must install the particular library via yarn/npm in your dev dependency using the command below (replace your library with the library name from the above code of configs that you need).

yarn add --dev @babel/preset-env

Solution (B): Use the jest config option “transformIgnorePatterns”.

Note: If the previous solution (A) does not work, then do not remove the Solution (A) codes of configs as they are necessary for the future.

So, why may solution (A) not have worked? This is because those files may not have been transformed into JavaScript syntax by the Jest preprocessor for any reason. However, you can ignore the transformation by the Jest preprocessor, as Jest can still read ES6 modules and TypeScript. Ignoring the transformation of those files will be a good solution.

Suppose you get an “import” error for “react-native-elements”. In that case, add the code below to your JEST configuration file.

// jest.config.js
const config = {
  .....
  transformIgnorePatterns: [
    'node_modules/(?!(jest-)?@react-native|react-native|react-native-elements/*)'
  ],
  .....
}

You can add more libraries like “react-native-elements” to the array by using the “|” symbol.

Command to run test file

Just use this below command to run your test file in terminal.

yearn test test_file_name.test.js

If you want to run all of your TEST file (File name ended with .test.js) then run this below command.

yarn test

NOTE: Be sure “test” command was added in “scripts” section under package.json file in.

React Native Testing Library (RNTL) APIs

We will discuss now about all the essential APIs by React Native Testing Library.

🪵 RNTL API — render()

The render API is one of the methods that RNTL re-exports from DOM Testing Library. It allows you to render a React component into a container and returns an object that has a few properties, such as queries, container, baseElement, debug, re-render, unmount, asFragment, etc.

render() method deeply renders given React element and returns helpers to query the output components structure.

Let’s see an example of how to use render() method. Below is my demo.screen.js Component on which I will apply test.

Now let’s see how to use render() method in a Test for the above demo.screen.js Component. (Note: Please match red 🔴 & green 🟢underlined in above demo.screen.js Component & bellow test code).

When we will run the command: yarn test Demo.test.js then we will see an output like below.

🤚 Wait, we missed a STANDARD procedure while using render() API. The standard procedure is like below.

So basically, latest render result is kept in screen variable that was imported from @testing-library/react-native package.

Using screen instead of destructuring render result is recommended approach. The benefit of using screen is you no longer need to keep the render call destructure up-to-date as you add/remove the queries you need. You only need to type screen. and let your editor's (VS Code for me) magic autocomplete take care of the rest.

🐠 TEST Component with Provider — by render() API

So, let’s say you want to test a component, but in that component, you used any Provider like Context Provider, Redux Provider, or any Theme Provider. So when you want to test that Component by test runner JEST, then will that component can get the value of Providers anyhow? The answer is No as you are not running any app; you are just running a Component which is a simple JS file. So then how can you still test that component without changing any simple line of code written for Providers?

The solution is to create a custom render() API with the “wrapper” argument and then use that custom render() method instead of importing the render() API from RNTL.

Below an example with “wrapper” from “render()” API

At first, here is my “AuthContext” provider like below in “authContext.js” file.

Then a component “DemoScreen” which looks like below in “demo.screen.js” file. I will apply TEST on this “DemoScreen” component. You see in this component I accessed value of “auth.username” from “AuthContext” provider.

Now, below is how I implemented custom render() by using “wrapper” argument in “test-utils.js” file. In this code, I wrapped the TESTING component {children} by <AuthContext.Provider>.

Note: The TESTING component {children} means the component on which I’m going to apply TEST run. For me, it will be “DemoScreen” Component.

Finally below is my TEST code that I wrote to test “DemoScreen” Component. In the code, you see I imported my custom “render” method instead of “render” method from “RNTL”. In the last line of code, I expected a text “Anis” in “DemoScreen” component. This text “Anis” came from “AuthContext”.

Below I’m giving full code-block for “wrapper” argument of render() API to create a custom render() method.

// ✅ File - "authContext.js"
// ✅ File - "authContext.js"

import { createContext } from 'react'

const AuthContext = createContext(null)

export default AuthContext


// ✅ File - "demo.screen.js"
// ✅ File - "demo.screen.js"

import React, { useContext } from 'react'
import { Text, ImageBackground } from 'react-native'
import AuthContext from '../util/context/authContext'

export default function DemoScreen() {
 const { auth, setAuth } = useContext(AuthContext)

 return (
  <ImageBackground source={require('../assets/homeBackdrop.png')}>
   <Text testID="greeting">GREETING</Text>
   <Text testID="username">{auth.username}</Text>
  </ImageBackground>
 )
}


// ✅ File - "test-utils.js"
// ✅ File - "test-utils.js"

import React, { useState, useMemo } from 'react'
import { render } from '@testing-library/react-native'
import AuthContext from '../context/authContext'

const AllTheProviders = ({ children }) => {
 const [auth, setAuth] = useState({
  loggedIn: true,
  username: 'Anis'
 })

 const authValue = useMemo(() => ({ auth, setAuth }), [auth, setAuth])

 return (
  <AuthContext.Provider value={authValue}>{children}</AuthContext.Provider>
 )
}

const customRender = (component, options) =>
 render(component, { wrapper: AllTheProviders, ...options })

// re-export everything
export * from '@testing-library/react-native'

// override render method
export { customRender as render }


// ✅ File - "Final TEST file"
// ✅ File - "Final TEST file"

import React from 'react'
import { render, screen } from '../src/util/__test__/test-utils'
import DemoScreen from '../src/screens/demo.screen'

describe('DemoScreen', () => {
 it('should render the Demo Screen', () => {
  // Render the Demo Screen
  render(<DemoScreen />)

  // Get the element with the testID "greeting"
  const userName = screen.getByTestId('username')

  // Expect the element to contain the text "Anis"
  expect(userName).toHaveTextContent('Anis')
 })
})

🐠 “queries" option — render() API

The most important feature of render is providing a set of helpful queries that allow you to find certain elements in the view hierarchy.

Let’s see how many types of Query are there

• getBy... queries
• getAllBy... queries
• queryBy... queries
• queryAllBy... queries
• findBy... queries
• findAllBy... queries

NOTE: getBy... query methods fail (throws error) when there is no matching element (null) but queryBy... methods don’t throw an error when no element (null) is found. We don’t want to get error from the line of fetching element. We want to get the error from the last line of TEST suit that is “expect”. So use queryBy... method instead of getBy.... Ex: queryBy... means queryByTestId.

Now let’s see the Query Predicates.

• ...ByRole
• ...ByText
• ...ByPlaceholderText
• ...ByDisplayValue
• ...ByTestId
• ...ByLabelText
• ...ByHintText, ...ByA11yHint, ...ByAccessibilityHint

Query Types

Now, let’s get the explanation of each query types.

🪸 getBy. . . : getBy* queries return the first matching node for a query, and throw an error if no elements match or if more than one match is found.

🪸 getAllBy. . . : getAllBy* queries return an array of all matching nodes for a query, and throw an error if no elements match.

🪸 queryBy. . . : queryBy* queries return the first matching node for a query, and return null if no elements match. This is useful for asserting an element that is not present.

🪸 queryAllBy. . . : queryAllBy* queries return an array of all matching nodes for a query, and return an empty array ([]) when no elements match.

🪸 findBy. . . : findBy* queries return a promise which resolves when a matching element is found. The promise is rejected if no elements match or if more than one match is found after a default timeout of 1000 ms.

🪸 findAllBy. . . : findAllBy* queries return a promise which resolves to an array of matching elements. The promise is rejected if no elements match after a default timeout of 1000 ms.

NOTE: findBy* and findAllBy* queries accept optional waitForOptions object argument which can contain timeout, interval and onTimeout properties which have the same meaning as respective options for waitFor function.

Query Predicates

Now, let’s get the explanation of each query predicates.

⛰️ …ByRole: Supported methods are getByRole, getAllByRole, queryByRole, queryAllByRole, findByRole, findAllByRole

You need to set a role or accessibilityRole prop in your Component element like below.

Now the test suit is like below to access the button by role.

NOTE: You need to set accessible prop to true in <View> host elements while using *ByRole as *ByRole needs to be considered an accessibility element.

You can pass many other useful filters to methods like getByRole. Let’s see those filter options below. You can find details of each method by inspecting the method in VSCode.

⛰️ …ByText: Supported methods are getByText, getAllByText, queryByText, queryAllByText, findByText, findAllByText

This method will join <Text> siblings to find matches. This will allow for querying for strings that will be visually rendered together, but may be semantically separate React components.

⛰️ …ByPlaceholderText: Supported methods are getByPlaceholderText, getAllByPlaceholderText, queryByPlaceholderText, queryAllByPlaceholderText, findByPlaceholderText, findAllByPlaceholderText

Returns a Query Instance for a TextInput with a matching placeholder – may be a string or regular expression.

⛰️ …ByDisplayValue: Supported methods are getByDisplayValue, getAllByDisplayValue, queryByDisplayValue, queryAllByDisplayValue, findByDisplayValue, findAllByDisplayValue

Returns a Query Instance for a TextInput with a matching display value – may be a string or regular expression. In below component I have a <TextInput> with initial value “Anis”.

Now apply TEST by getByDisplayValue to catch the <TextInput> by the initial display value “Anis”.

⛰️ …ByTestId: Supported methods are getByTestId, getAllByTestId, queryByTestId, queryAllByTestId, findByTestId, findAllByTestId

Returns a Query Instance with matching testID prop like below. testID – may be a string or a regular expression.

return (
  <View testID="button">
      <Text>Anis</Text>
   </View>
 )

And below is how the TEST suit should be written

describe('Test using ByRole', () => {
 it('should render the TEST Screen', async () => {
  // Render the Screen
  render(<TestQuery_ByTestId />)

  // Get the BUTTON with the role/accessibilityRole as "button"
  const button = screen.getByTestId('button')

  // Expect the element to contain "Anis"
  expect(button).toHaveTextContent('Anis')
 })
})

NOTE: It is recommended to use this only after the other queries don’t work for your use case. Using testID attributes do not resemble how your software is used and should be avoided if possible. However, they are particularly useful for end-to-end testing on real devices, e.g. using Detox and it's an encouraged technique to use there.

⛰️ …ByLabelText: Supported methods are getByLabelText, getAllByLabelText, queryByLabelText, queryAllByLabelText, findByLabelText, findAllByLabelText

Returns a Query Instance with matching label:

• either by matching aria-label/accessibilityLabel prop
• or by matching text content of view referenced by aria-labelledby/accessibilityLabelledBy prop

Implementation code is as same as ⛰️ …ByDisplayValue.

🐠 “update" option — render() API

During testing, you might want to simulate how your component behaves when its props change dynamically. For example, if your component receives new data from an API or user interactions trigger prop updates, you can use update() to test these scenarios.

When you call update(), you’re saying, “Hey, let’s change something about this component with some modifications!”

This update() simulates a React update at the root. If the new element has the same type and key as the previous element, the tree will be updated; otherwise, it will re-mount a new tree. This is useful when testing for componentDidUpdate(runs after a component updates) behavior, by passing updated props to the component.

Tree Update vs. Re-Mount: If the type or key is different, RNTL don’t just update the existing tree. Instead, it creates a whole new tree (re-mount). Think of it like replacing a plant: sometimes you water the same plant (update), and other times you plant a new one (re-mount).

Let’s see an example. We have a component like below with a useEffect clean-up function to TEST the component Un-Mounting stuff.

Now, I wrote a TEST suit below to test the above component.

In the TEST suit, you may see that at first I used render(). Then I used update() two times. In the second update() I used a new key as “totallyNew”.

Now, when I ran the TEST file by JEST test runner with RNTL in environment, then I see below output in console.

In the output we see, the clean-up function was called 2 times. The first one was called when I called the render() API. The second one called when I called the update() API for second time with new key “totallyNew”. So, in the first call of update() without key, din’t invoke the clean-up function.

So, it has been proved that update() with new value but without changing key will not MOUNT the component again & it will just only update the existing DOM tree.

This test ensures that our component responds correctly to dynamic prop changes, and the update() option helps us to achieve that.

🐠 “debug" option — render() API

Pretty prints deeply rendered component passed to render. Below is the code of debug.

It logged the rendered component pretty deeply like below in the console.

🪵 RNTL API — userEvent()

There are 2 types of API in RNTL to handle all interactions like scrolling, press, etc. These are

1. fireEvent() API
2. userEvent() API

FireEvent is the original event simulation API. It offers ability to invoke any event handler declared on either host or composite elements. If the element does not have onEventName event handler for passed eventName event, or the element is disabled, Fire Event will traverse up the component tree, looking for event handler on both host and composite elements along the way. By default it will not pass any event data, but the user might provide it in the last argument.

In contrast, UserEvent provides realistic event simulation for main user interactions like press or type from keyboard. Each of the interactions will trigger a sequence of events corresponding to React Native runtime behavior. These events will be invoked only on host elements, and will automatically receive event data corresponding to each event.

If UserEvent supports given interaction you should always prefer it over FireEvent counterpart, as it will make your tests much more realistic and hence reliable. In other cases, e.g. when event is not supported by User Event, or when invoking event handlers on composite elements, you have to use Fire Event as the only available option.

fireEvent dispatches DOM events, whereas userEvent simulates full interactions, which may fire multiple events and do additional checks along the way.

setup() option — userEvent()

To use UserEvent(), at first you need to create an User Event object instance which can be used to trigger events. Before creating instance let’s understand some terms.

Real Timer: Real Timer is the default timer used by JavaScript. It is based on the system clock and provides accurate timing information. However, it can cause issues when testing asynchronous code because it can take a long time to complete certain operations. To apply Real Timer just use this below code.

// Setup UserEvent (with real timer)
  const user = userEvent.setup()

Fake Timer: Fake Timer is a timer that is not based on the system clock. Instead, it is controlled by the testing framework and can be advanced manually. This allows you to test asynchronous code more easily and quickly.

Advanced Timer: An advanced timer is a tool that allows you to fast-forward time by 10 seconds, 5 seconds, 20 seconds, or any other specified duration. Unlike traditional timers, it doesn’t require you to wait for the entire duration before giving you an output. Instead, it provides you with an output within 100 milliseconds that will occur within the specified duration. To achieve this, the advanced timer takes the help of FakeTimer, which creates a fake timer inside the testing environment. This allows the advanced timer to perform its operation and give you a result from the future within just 100 milliseconds.

To apply Fake Timer with conjunction of Advance Timer, just use this below code instead of above code for Real Timers.

// Activate FakeTimer
jest.useFakeTimers()

// Now, setup UserEvent (with Advance Timer)
const user = userEvent.setup({ 
    delay: null,
    advanceTimers: (delay) => {
        jest.advanceTimersByTime(5000)
        // "5000" refers to advance the clock to 5s and show result now.
        // "delay" refers a basic "130" milliseconds to update a STATE.
    }
})

NOTE: If you don’t use advanceTimers() with UserEvent() like above then you will get an warning like below.

Now, let’s see a complete example below. At first I’m giving you an example of component on which I will apply the UserEvent().

Now, let’s see the TEST suit that I created using UserEvent() instance.

Let me give you the TEST suit code in editor below.

import React from 'react'
import { render, screen, userEvent } from '@testing-library/react-native'
import UserEventTest from '../src/screens/testScreens/userEventTest.screen'

describe('Test using UserEvent', () => {
 it('should render the TEST Screen', async () => {
  // Enable fakeTimers
  jest.useFakeTimers()

  // Setup UserEvent
  const user = userEvent.setup({
   delay: null,
   advanceTimers: (delay) => jest.advanceTimersByTime(10000)
  })

  // Render the Screen
  render(<UserEventTest />)

  // Get the BUTTON with the testID "button"
  const button = screen.getByTestId('button')

  // Each time you will call a "UserEvent" method like below,
  // it will trigger this line "jest.advanceTimersByTime(10000)"
  await user.longPress(button)

  // Get the TEXT with the testID "textConditional"
  const textConditional = screen.queryByTestId('textConditional')

  // Expect the element to contain "Text Visible"
  expect(textConditional).toHaveTextContent('Text Visible')
 })
})

In the above example, you also got an idea with a real example of how to implement the UserEvent() API of RNTL for the longPress event. Like the longPress event, there are other events that UserEvent can support. These are listed below. Use them as like as I gave example above for longPress() method.

• press()
• longPress()
• type()
• clear()
• scrollTo()

🐠 Example of FireEvent() API

Let me give you an example of fireEvent with fakeTimers and advanceTimersByTime(). fireEvent works exactly the same as userEvent in the case of fakeTimers and advanceTimersByTime(). However, fireEvent is a bit different from userEvent(). Below is the test suite that I wrote for the same component as above, with a press() and a setTimeout of 5000 ms in the action of the button press. Here is the test suite with fireEvent.

Below is the code in editor for you.

import React from 'react'
import { 
  render, 
  screen, 
  fireEvent, 
  act } 
from '@testing-library/react-native'
import FireEventTest from '../src/screens/testScreens/fireEventTest.screen'

describe('Test using UserEvent', () => {
 it('should render the TEST Screen', async () => {
  // Enable fakeTimers
  jest.useFakeTimers()

  // Render the Screen
  render(<FireEventTest />)

  // Get the BUTTON with the testID "button"
  const button = screen.getByTestId('button')

  // Fire an event "Press" by mouse
  fireEvent.press(button)

  // Apply a side-effect by act() function
  // We advanced the time 10s by this side-effect function
  act(() => {
   jest.advanceTimersByTime(10000)
  })

  // Get the TEXT with the testID "textConditional"
  const textConditional = screen.queryByTestId('textConditional')

  // Expect the element to contain "Text Visible"
  expect(textConditional).toHaveTextContent('Text Visible')

  jest.useRealTimers()
 })
})

If you place jest.advanceTimersByTime(10000) before fireEvent.press(button), you will see an error because screen.queryByTestId and expect(textConditional) depend on a setTimeout state update with a delay of 5 seconds after the button press inside the component below.

Like above, you can use fireEvent() for these actions too

• press()
• changeText()
• scroll() -> ScrollView/ FlatList

🪵 RNTL API — waitFor()

waitFor is a function provided by React Native Testing Library (RNTL) that waits for a condition to be true before continuing with the test. Here’s how it works:

1. The waitFor function takes a callback function as an argument.
2. The callback function should return a truthy value when the condition is met.
3. If the callback function returns a falsy value, waitFor will wait and try again until the condition is met or the timeout is reached.

NOTE: Before React Native v0.71, there was no support for the waitFor() API. Before v0.71, waitFor was implemented using FakeTimer and continuous polling until a truthy value was returned.

Let’s implement the previous fireEvent() test suite using the waitFor() API this time.

Here, the timeout option specifies the maximum amount of time to wait for the condition to be true before timing out. The default value is 4500ms.

The interval option specifies the amount of time to wait between each check of the condition. The default value is 50ms.

The value 10,000 at the end of the above code refers to the maximum time this test will run, and every asynchronous (await) operation must be finished within this time. By default, this time is set to 5000 ms.

Again, the component is as same as before on which I applied the waitFor() test API. I’m providing the component again below.

Below is the final code of WaitFor() in editor.

import React from 'react'
import { 
    render, 
    screen, 
    fireEvent, 
    waitFor 
  } from '@testing-library/react-native'
import FireEventTest from '../src/screens/testScreens/fireEventTest.screen'

describe('Test using WaitFor', () => {
 it('should render the TEST Screen', async () => {
  // Render the Screen
  render(<FireEventTest />)

  // Get the BUTTON with the testID "button"
  const button = screen.getByTestId('button')

  // Fire an event "Press" by mouse
  fireEvent.press(button)

  await waitFor(
   () => {
    // Get the TEXT with the testID "textConditional"
    const textConditional = screen.queryByTestId('textConditional')

    // Expect the element to contain "Text Visible"
    expect(textConditional).toHaveTextContent('Text Visible')
   },
   { timeout: 6000, interval: 500 }
  )
 }, 10000)
})

NOTE: If you are using any API (network call) inside “waitFor” operation then you may have encounter this below issue of “fetch”.

SOLUTION: You have to install “cross-fetch” in your react native app by this below command.

yarn add --dev cross-fetch

Then just import the “cross-fetch” at the top of the file from where your TEST suit is fetching the Network Data by a Network Call. For my case it was Apollo GraphQL & I just only imported the “cross-fetch” & it worked.

What is Mocking ?

Mocking is a technique used to replace real functions or modules with mock implementations during testing. This is useful when you want to isolate your tests from external dependencies or simulate certain scenarios that are difficult to reproduce in real-world conditions.

RNTL provides a set of utility functions that allow you to create mock functions and mock modules. You can use these functions to replace real functions or modules in your codebase and test how your code interacts with them.

🍁 Difference between jest.fn() & jest.mock()

jest.fn() is a function that returns a new, empty mock function. You can use this mock function to replace a real function in your codebase and test how it is called and what it returns. For example, you can use jest.fn() to create a mock function that simulates a network request and test how your code handles the response.

jest.mock() is a function that allows you to replace a module with a mock implementation. This is useful when you want to test a module that has dependencies on other modules. You can use jest.mock() to replace the dependencies with mock implementations and test how your module interacts with them.

In summary, jest.fn() is used to create mock functions that replace real functions in your codebase, while jest.mock() is used to replace entire modules with mock implementations.

🍁 How to Mock a Real Function (by jest.fn()) ?

jest.fn() is a function provided by the Jest testing framework that allows you to create mock functions that replace real functions in your codebase during testing. Below, I created a test suite where I created a mock function called ‘mockFunction’ using jest.fn().

Look at the test suite where I created a mock function called ‘mockFunction’ using jest.fn() and passed it as a prop to the <TestMock> component. Finally, I checked whether the mock function ‘mockFunction’ was called or not in the last line of the test suite “expect(mockFunction).toHaveBeenCalled()”.

Below is the component where I applied the above test suite.

🍁 How to Mock a Native Module (by jest.mock())?

Some React Native components or third-party components rely on native code to be rendered. Native code is the code that runs on the device’s operating system, such as Android or iOS. For example, AsyncStorage is a native module that allows you to store and retrieve data from the device’s local storage. PermissionsAndroid is another native module that helps you request and check permissions for various features on Android devices.

However, when you run your tests with Jest, you don’t have access to the native code or the device’s environment. Jest runs your tests in a Node.js environment, which is different from the device’s environment. Therefore, you need to mock or fake the native modules that your components depend on.

“Mocking means creating a simplified or simulated version of something that behaves in a similar way as the original thing.”

By mocking the native modules, you can avoid errors or unexpected behaviors when testing your components. You can also control how the native modules behave and return values in your tests. For example, you can mock AsyncStorage to return a specific value when you call AsyncStorage.getItem(key) in your test.

To mock a native module, you can use jest.mock(moduleName, factory) function. The moduleName is the name of the native module that you want to mock, such as ‘react-native’ or ‘@react-native-community/async-storage’. The factory is a function that returns an object with the methods and properties that you want to mock for the native module.

For example, if you want to mock AsyncStorage, you can write something like this in your setup file:

jest.mock('@react-native-community/async-storage', () => ({
  getItem: jest.fn(() => Promise.resolve('some value')),
  setItem: jest.fn(() => Promise.resolve()),
}));

This will create a mock version of AsyncStorage with two methods: getItem and setItem. The getItem method will always return a promise that resolves to ‘some value’, and the setItem method will always return a promise that resolves to nothing. You can use these methods in your tests as if they were the real AsyncStorage methods.

Similarly, if you want to mock PermissionsAndroid, you can write something like this in your setup file:

jest.mock('react-native', () => ({
  ...jest.requireActual('react-native'),
  PermissionsAndroid: {
    request: jest.fn(() => Promise.resolve('granted')),
    check: jest.fn(() => Promise.resolve(true)),
  },
}));

This will create a mock version of PermissionsAndroid with two methods: request and check. The request method will always return a promise that resolves to ‘granted’, and the check method will always return a promise that resolves to true. You can use these methods in your tests as if they were the real PermissionsAndroid methods.

🍁 Another example of Native Module Mocking ( jest.mock() ) 👇

Let’s see another example of mocking a native module. Suppose you ran a test suite and rendered a component called MessageTab. Inside the MessageTab component, you used the react-native-orientation-locker native module. When you ran the test suite and called the MessageTab component, you got the error below.

The reason for the error is that you ran only a single JS file and not the entire app, and you did not run the app even in a device or simulator. Therefore, all native modules are out of scope to access. That’s why JEST can’t access the native orientation of device functions.

Here’s how I used the react-native-orientation-locker native module in my MessageTab component:

So, I added mocking for react-native-orientation-locker inside my test suite before running the test, like the code below. This solved the error of invariant violation 🚀.

Some Advanced Share about RNTL

React Native Testing Library allows you to write integration and component tests for your React Native app or library. While the JSX code used in tests closely resembles your React Native app, the things are not quite as simple as they might appear. Let’s understand some of them in this part.

React renderers​

React allows you to write declarative code using JSX, write function or class components, or use hooks like useState. In order to output the results of your components it needs to work with a renderer. Every React app uses some type of renderer: React Native is a renderer for mobile apps, web apps use React DOM, and there are other more specialised renderers that can e.g. render to console or HTML canvas.

When you run your tests in React Native Testing Library, somewhat contrary to what the name suggest, they are actually not using React Native renderer. This is because this renderer needs to be run on iOS or Android operating system, so it would need to run on device or simulator.

React Test Renderer​

Instead, RNTL uses React Test Renderer which is a specialised renderer that allows rendering to pure JavaScript objects without access to mobile OS, and that can run in a Node.js environment using Jest (or any other JavaScript test runner).

Using React Test Renderer has pros and cons.

Benefits:

• Tests can run on most CIs (linux, etc) and do not require a mobile device or emulator
• Faster test execution
• Light runtime environment

Disadvantages:

• Tests do not execute native code
• Tests are not aware of view state that would be managed by native components, e.g. focus, unmanaged text boxes, etc.
• Assertions do not operate on native view hierarchy
• Runtime behaviours are simulated, sometimes imperfectly

Element tree​

Invoking render() function results in creation of an element tree. This is done internally by invoking TestRenderer.create() method. The output tree represents your React Native component tree, each node of that tree is an “instance” of some React component.

To be more precise: Each node represents a React fiber, and only class components have instances, while function components store the hook state using fiber.

Fiber: A fiber is a unit of work that represents a Component and its STATE. It is a lightweight thread-like structure that is used to manage the component tree and its updates. The fiber is created for each component and is responsible for scheduling the work and prioritizing the updates based on their importance.

Fabric Renderer

What is the DOM view in React is now the HOST view in React Native. So, below are two same:

React DOM view — > React Native HOST view

Rendering to HOST views is made possible by the Fabric Renderer. Fabric lets React talk to each platform and manage its host view instances. The Fabric Renderer exists in JavaScript and targets interfaces made available by C++ code.

HOST View Tree (and HOST View)​

Tree representation of views in the HOST platform (e.g. Android, iOS). On Android, the host views are instances of android.view.ViewGroup, android.widget.TextView, etc. which are the building blocks of the host view tree. The size and location of each HOST view are based on LayoutMetrics calculated with Yoga, and the style and content of each HOST view are based on information from the React Shadow Tree.

HOST and Composite components

One of the most important aspects of the element tree is that it is composed of both host and composite components:

• HOST components: HOST components are components that will have direct counterparts in the native view tree. Typical examples are <View>, <Text> , <TextInput>, and <Image> from React Native. You can think of these as analogue of <div>, <span> etc on the Web. You can also create your own host views as native modules or import them from 3rd party libraries, like React Navigation or React Native Gesture Handler.
• Composite components: Composite components are React code organisation units that exist only on the JavaScript side of your app. Typical examples are components you create (both function and class components), components imported from React Native (View, Text, etc) or from 3rd party packages.

That might sound a bit confusing at first, since we put React Native’s View in both categories. There are actually two View components: composite one and host one. The relation between them is as follows:

• composite View is the type imported from react-native package. It’s a JavaScript component, which renders host View as its only child in the element tree.
• host View , which you do not render directly. React Native takes the props you pass to the composite View, does some processing on them and passes them to host View.

The part of the tree looks as follows:

Similar relation exists between other composite and host pairs: e.g. Text , TextInput and Image components:

Not all React Native components are organised this way, e.g. when you use Pressable (or TouchableOpacity) there is no HOST Pressable, but composite Pressable is rendering a HOST View with certain props being set:

You can get a simple definition of “COMPOSITE” & “HOST” component in my tweeter post 👇

Differentiating between host and composite elements

An easy way to differentiate between host and composite elements is the type prop of given Component. Let’s have a look at below code.

In above code, the given Component is <Pressable />. Inside function isHostElement(), I used element “type” property to check if the given Component <Pressable /> is a HOST component or a Composite component.

So, if typeof element.type return a “string” then given Component is a “HOST” component otherwise given Component is a “COMPOSITE” component.

For my case <Pressable /> is a “COMPOSITE” component as it gave the below “Function type” instead of type “string”.

Queries

Most of the Testing Library queries return host components, in order to encourage best practices described above.

At this stage, there are some noteworthy exceptions:

• *ByText queries returns composite Text element
• *ByDisplayValue queries returns composite TextInput element
• *ByPlaceholderText queries returns composite TextInput element

This will change in the near future, as RNTL team make efforts for all queries to return host components. Meanwhile it shouldn’t be a huge issue, as composite Text and TextInput generally pass their props down to HOST counterparts.

Additionally, UNSAFE_*ByType and UNSAFE_*ByProps queries can return both HOST and Composite components depending on used predicates. They are marked as unsafe precisely because testing composite components makes your test more fragile.

🚀 Intro to E2E Testing

If you have reached this far, then you are already an expert in Component Testing (JS testing) of React Native. Now, you need to dive into the top of the TESTING pyramid, which is E2E testing (End-to-End testing).

One of the most popular libraries for E2E testing for React Native apps is Detox. Detox is a gray box end-to-end testing and automation framework for mobile apps built with React Native. It supports both iOS and Android apps. Detox tests your mobile app while it’s running in a real device/simulator, interacting with it just like a real user.

NOTE: I will be publishing an in-depth article on the Detox Testing Library very soon. The article will cover everything you need to know about Detox, including how to get started with it, its features, and how to use it to test your React Native apps.

Thank you for reading this article. I enjoy sharing my 5 years of experience in JavaScript, React, React-native & Node.js with you every day.

If you enjoyed reading this article, I would appreciate it if you could follow me on Twitter & Medium. You can also leave your feedback and comments there. Thank you for your support and interest.