⚙️ Under the Hood

 If you’re a React Native developer and unit testing feels confusing, optional, or “something seniors do later” — you’re not alone. Most React Native apps work fine without tests … until one day they don’t. This blog explains unit testing from scratch , so that: Beginners can start without fear Intermediate devs can test correctly Seniors can align on best practices 🧠 What Is Unit Testing? (Simple Definition) Unit testing means testing the smallest testable part of your code , in isolation. A unit can be: A function A component A utility A hook 👉 The key idea: Test one thing at a time, without dependencies. 🤔 Why Unit Testing Is Important Unit tests help you answer questions like: Did my change break existing logic? Can I refactor safely? Will this bug come back again? Can a junior change this code confidently? Real benefits: Catches bugs early Makes refactoring safer Improves code quality Acts as documentation ...

What Was Broken, What Got Fixed, and How It Works Internally For years, React Native apps suffered from: Scroll jank Slow native communication Performance unpredictability “Works on iOS, lags on Android” These were not developer mistakes . They were architecture limitations . React Native’s New Architecture was introduced to fix these fundamental problems , not just add features. Let’s understand this step by step , without jargon. 🧱 The Old Architecture (What Was the Problem?) The old React Native architecture was built around latest around 2015–2016 , when: JSON serialization was common Async communication was preferred Mobile hardware was slower It had three core pillars : 1️⃣ The Bridge JS and Native talked via an async bridge Messages were serialized to JSON Everything crossed the bridge asynchronously 2️⃣ UI Manager JS described the UI Native decided when to actually render 3️⃣ Native Modules JS called native code R...

  Why It’s Faster Than FlatList (And When You Should Use It) If you’ve ever replaced FlatList with FlashList and thought: “Why does this feel magically smoother?” The answer is not magic . It’s architecture, predictability, and aggressive recycling . Let’s open the hood and see what actually happens. 🧠 The Core Problem FlashList Solves FlatList tries to answer this question on every scroll : “Which items should I render now?” But it often doesn’t know : Exact item size Layout cost in advance How expensive rendering is So FlatList plays safe: Renders extra items Keeps more views alive Asks JS thread more often FlashList flips this model. 🧩 The FlashList Mental Model (Very Important) FlashList is a recycler first, renderer second Instead of: Creating views → destroying views → recreating views FlashList: Creates a small pool of views Recycles them aggressively Rebinds data instead of re-rendering trees This is the same...

  This guide explains  step by step  how to set up a  monorepo  containing: 📱 A React Native mobile app 🌐 A React Web app (Vite) 📦 Shared packages for: Design tokens  (colors, spacing, fonts) Network layer  (Axios) It also covers  common pitfalls ,  PNPM workspace quirks , and  troubleshooting steps  discovered during setup. 📌 Why Monorepo? A monorepo allows multiple related projects to live in a  single Git repository , enabling: Shared code without publishing packages Consistent dependency versions Atomic changes (one PR for app + shared code) Easier long-term scaling 🧠 High-Level Architecture my-monorepo/ ├── apps/ │ ├── mobile/ # React Native app │ └── web/ # React Web app (Vite) │ ├── packages/ │ ├── design-tokens/ # Shared colors, spacing, fonts │ │ └── src/ │ │ ├── colors.ts │ │ ├── spacing.ts │ │ └── index.ts │ │ │ └── network/ ...