DEV Community: Tanvir Azad

React Native Architecture: Busting the "Compile to Native" Myth

Tanvir Azad — Tue, 10 Feb 2026 12:59:25 +0000

If you’ve ever stared at a React Native build log and wondered what exactly is happening behind the scenes, you aren't alone. The build process is often treated as a "black box," leading to some widespread myths about how our JavaScript actually powers a mobile app.

Does your code turn into Swift? Is the Metro Bundler just a fancy file watcher?

Let’s open up the hood and debunk the two biggest misconceptions about how React Native actually works under the surface.

🤯 Misconception #1: "React Native compiles my JavaScript into Swift/Objective-C."

This is perhaps the most common myth. It’s easy to assume that when you run react-native build, a magic transpiler converts your <View> and useEffect hooks into native Swift or Objective-C code.

The Reality: It doesn't. Your JavaScript stays JavaScript.

React Native operates on a "Two Worlds" model. Unlike frameworks that compile down to native code, React Native keeps the two environments separate and lets them "talk" to each other.

The Two Parallel Stages

The Native World: This is where the actual iOS buttons, scrolls, and cameras live. This part is written in Swift/Objective-C and compiled by Xcode into machine code.
The JavaScript World: This is where your React logic lives.

If there is no translation, how does it work?

Instead of converting code, React Native uses a Bridge (or the newer JSI - JavaScript Interface).

When you write <Text>Hello</Text> in JS, React Native doesn't rewrite that as Objective-C. Instead, it sends a serialized message across the bridge:

"Hey iOS side, please create a UITextView and set its text property to 'Hello'."

Your final app actually contains a small "engine" (like Hermes or JavaScriptCore) that boots up when the user opens the app, reads your JavaScript, and starts executing the logic in real-time.

🏗️ Misconception #2: "The Metro Bundler is just a local dev server."

We all know Metro as the thing running in the terminal that lets us "hot reload" our changes. But many developers think Metro's job ends when you stop the development server.

The Reality: Metro is the backbone of your production build.

When you are ready to ship, Metro transitions from a live-reloading companion to a high-speed production factory. Its primary role is to take thousands of individual JavaScript files and flatten them into a single, optimized file that the iOS app can execute.

The Journey from Code to `.ipa`

Here is the step-by-step breakdown of how Metro turns your source code into the core of your app:

Resolution & Transformation: Metro scans your entry point (usually index.js) and builds a massive "dependency graph" of every library you use. It then uses Babel to transform modern JavaScript (ES6+, JSX, TypeScript) into a version the mobile environment understands.
Minification: For production, it strips out whitespace, removes comments, and renames variables to single letters (e.g., calculateTotal() becomes a()) to reduce file size.
Creating the "Bundle": It generates a static file usually named main.jsbundle. This file is the "brain" of your app. Without it, the native iOS shell is just an empty container.
Asset Packaging: Metro also identifies your images (handling @2x and @3x resolutions automatically) and copies them into the iOS asset folder so they load offline.

🧩 The Final Product: A Hybrid App

Because of these two realities—that JS isn't compiled to Swift, and that Metro bundles JS into a static file—your final .ipa file is essentially a hybrid:

The Binary: Compiled Swift/Objective-C code (the native shell).
The Bundle: A single, massive JavaScript file (main.jsbundle) tucked inside the app's resources.

Why does this matter?

Understanding this architecture changes how you debug.

Performance: You know that your JS bundle has to be loaded and parsed by an engine (Hermes) at startup, which explains why keeping that bundle size small is critical.
Native Modules: You realize that when you install a library with "native code," you are adding code to that first parallel world (the Native World), which is why you have to rebuild the binary (pod install) for the two worlds to connect properly.

Next time you hit "Archive" in Xcode, remember: You aren't just compiling code; you are packaging a bridge between two very different worlds.

Happy Coding! 🚀

SOLID in React (Do’s & Don’ts)

Tanvir Azad — Tue, 26 Aug 2025 13:42:05 +0000

Writing React without principles is like cooking spaghetti without a pot — messy, unpredictable, and probably going to end up on the floor. The SOLID principles swoop in like React’s secret superhero squad: tiny, focused, and reusable. They keep your components slim, your hooks useful, and your future self from angrily asking “who wrote this monster component?” (spoiler: it was you).

The following table shows the Do’s ✅ and Don’ts ❌ of applying SOLID principles in React:

Principle	✅ Do	❌ Don’t
SRP (Single Responsibility Principle)	Split large components into smaller ones; put logic in hooks, UI in components.	Cram state, API calls, and rendering into one component.
OCP (Open/Closed Principle)	Design hooks/components to be extendable via props or composition.	Edit old, working code whenever requirements change.
LSP (Liskov Substitution Principle)	Keep similar components interchangeable by sharing the same props (e.g., `<Link>` vs `<IconLink>`).	Create inconsistent APIs that break when swapping components.
ISP (Interface Segregation Principle)	Pass only the props a component actually needs.	Use “mega props” objects with lots of unused properties.
DIP (Dependency Inversion Principle)	Use context, hooks, or HOCs to decouple dependencies when appropriate.	Overengineer with contexts/HOCs when a simple prop would suffice.

Follow SOLID in React and your codebase becomes less of a haunted house and more of a well-organized IKEA catalogue — everything modular, extendable, and (mostly) frustration-free. By dodging mega-components, mystery props, and over-engineered contexts, you’ll build apps that don’t collapse under their own weight. Think of SOLID as the friendly nag reminding you:

Keep it simple, don’t break what works, and stop making your test files 1000 lines long!

Reference:

Dennis Persson

Jun 2 '24

Write SOLID React Hooks

#react #architecture #webdev #designpatterns

324

Comments 17

15 min read

JS Evolution: 15 Years in 15 Minutes

Tanvir Azad — Tue, 08 Jul 2025 13:49:26 +0000

JavaScript has come a long way since its humble beginnings. From the basic scripting language of 1995 to the powerful, feature-rich language we use today, JavaScript continues to evolve rapidly. This comprehensive comparison will explore the journey from ES5 (2009) through ES6/ES2015 to the latest ES2024 features.

Feature	ES2024	ES6 / ES2015	ES5 (2009)
Variable Declaration	`'let' & 'const'`	`'let' & 'const'`	`'var' only`
Arrow Functions	`(a, b) => a + b`	`(a, b) => a + b`	❌
Object Destructuring	`const { age } = user`	`const { age } = user`	`var user = {age: 25}; var age = user.age`
Spread Operator	`const obj2 = { ...obj1 }`	`const obj2 = { ...obj1 }`	❌
String Interpolation	`Hello ${userName}!`	`Hello ${userName}!`	`"Hello" + userName + "!";`
Modules (Export/Import)	`import obj from '...'`	`import obj from '...'`	`var obj = require('...')`
Classes	`class Person {...}`	`class Person {...}`	❌
Promises	`new Promise(...)`	`new Promise(...)`	❌
Top-Level `await`	`const data = await fetch(...);`	❌	❌
Private Class Fields	`class A { #x = 42 }`	❌	❌
BigInt	`123456789012345678901234567890n;`	❌	❌
Array `.at()` Method	`const last = arr.at(-1);`	❌	❌
Object.hasOwn()	`Object.hasOwn(obj, 'prop');`	❌	❌
Hashbang Grammar	`#!/usr/bin/env node`	❌	❌
Set Union	`a.union(b);`	❌	❌
Set Intersection	`a.intersection(b);`	❌	❌
Set Difference	`a.difference(b);`	❌	❌
Set Disjoint Check	`a.isDisjointFrom(b);`	❌	❌
Set Symmetric Difference	`a.symmetricDifference(b);`	❌	❌
Set Subset/Superset	`a.isSubsetOf(b);` `a.isSupersetOf(b);`	❌	❌

ES2024 Features - In-Depth Examples

Let's dive into the newest JavaScript features that ES2024 brings to the table, complete with practical examples you can use in your projects today.

1. Top-Level `await`

One of the most requested features finally arrived with ES2022 and continues to be refined in ES2024. You can now use await at the top level of modules without wrapping it in an async function.

// Before (ES5/ES6) - Required wrapping in async function
(async () => {
  const response = await fetch('/api/config');
  const config = await response.json();
})();

// ES2024 - Clean and simple
const response = await fetch('/api/config');
const config = await response.json();

2. Private Class Fields

Encapsulation is finally first-class in JavaScript with private fields using the # syntax.

class Account {
  #balance = 0; // private field

  constructor(amount) {
    this.#balance = amount;
  }

  deposit(amount) {
    this.#balance += amount;
  }

  #format() {
    return `$${this.#balance}`;
  }

  getBalance() {
    return this.#format();
  }
}

const acc = new Account(100);
acc.deposit(50);
console.log(acc.getBalance()); // $150

console.log(acc.#balance); 
// ❌ SyntaxError: Private field '#balance' must be declared in an enclosing class

3. BigInt for Large Numbers

JavaScript's number limitations are addressed with BigInt, allowing you to work with arbitrarily large integers.

// Traditional number limitations
const maxSafeInteger = Number.MAX_SAFE_INTEGER; // 9007199254740991
const problematic = maxSafeInteger + 1; // 9007199254740992
const moreProblem = maxSafeInteger + 2; // 9007199254740992 (same as above!)

// BigInt solution
const bigNumber = 123456789012345678901234567890n;
const anotherBig = BigInt('987654321098765432109876543210');

// Arithmetic operations
const sum = bigNumber + anotherBig;
const product = bigNumber * 2n;

4. Array `.at()` Method

Access array elements with support for negative indices, making it easier to get elements from the end.

const fruits = ['apple', 'banana', 'orange', 'grape'];

// Traditional approach
const lastFruit = fruits[fruits.length - 1]; // 'grape'
const secondLast = fruits[fruits.length - 2]; // 'orange'

// ES2024 .at() method
const lastFruit2 = fruits.at(-1); // 'grape'
const secondLast2 = fruits.at(-2); // 'orange'
const firstFruit = fruits.at(0); // 'apple'

// Particularly useful in function chains
const processedItems = getData()
  .filter(item => item.active)
  .map(item => item.name)
  .at(-1); // Get the last processed item

5. Object.hasOwn()

A safer alternative to Object.prototype.hasOwnProperty.call() for checking object properties.

const user = {
  name: 'John',
  age: 30,
  email: 'john@example.com'
};

// Old approach (potentially unsafe)
if (user.hasOwnProperty('name')) {
  console.log('Has name property');
}

// Safer but verbose approach
if (Object.prototype.hasOwnProperty.call(user, 'name')) {
  console.log('Has name property');
}

// ES2024 clean approach
if (Object.hasOwn(user, 'name')) {
  console.log('Has name property');
}

6. Hashbang Grammar

Support for shebang (#!) syntax in JavaScript files, making them executable on Unix-like systems.

#!/usr/bin/env node

// This is now valid JavaScript syntax
console.log('Hello from a directly executable JS file!');

// Make the file executable and run it directly:
// chmod +x script.js
// ./script.js

7. Set Operations

ES2024 introduces powerful set operations that make working with collections much more intuitive.

const developers = new Set(['Alice', 'Bob', 'Charlie']);
const designers = new Set(['Bob', 'David', 'Eve']);
const managers = new Set(['Alice', 'Frank']);

// Union - combine all unique values
const allEmployees = developers.union(designers).union(managers);
console.log(allEmployees); // Set(6) {'Alice', 'Bob', 'Charlie', 'David', 'Eve', 'Frank'}

// Intersection - find common elements
const versatileEmployees = developers.intersection(designers);
console.log(versatileEmployees); // Set(1) {'Bob'}

// Difference - elements in first set but not in second
const onlyDevelopers = developers.difference(designers);
console.log(onlyDevelopers); // Set(2) {'Alice', 'Charlie'}

// Symmetric difference - elements in either set but not both
const specializedEmployees = developers.symmetricDifference(designers);
console.log(specializedEmployees); // Set(4) {'Alice', 'Charlie', 'David', 'Eve'}

// Check relationships between sets
console.log(developers.isDisjointFrom(new Set(['Xavier', 'Yuki']))); // true
console.log(new Set(['Alice']).isSubsetOf(developers)); // true
console.log(developers.isSupersetOf(new Set(['Alice', 'Bob']))); // true

Conclusion

ES2024 brings powerful new features that make JavaScript more expressive, safer, and more convenient to use. From better error handling with cause chains to efficient set operations, these features help write cleaner, more maintainable code.

The evolution from ES5 to ES2024 shows JavaScript's commitment to addressing real-world developer needs while maintaining backward compatibility. Whether you're building modern web applications or Node.js services, these features will help you write better code.

Start experimenting with these features in your projects today, and watch how they improve your development experience!

Have you tried any of these ES2024 features in your projects? Share your experiences in the comments below!

Oreo's Top K Treats (Bucket Sort)

Tanvir Azad — Wed, 25 Jun 2025 11:49:09 +0000

My name is Oreo, and I'm a data-driven persian with a serious treat addiction. My human keeps giving me different snacks throughout the day, but I got curious - which treats am I getting the most? Time to put my programming paws to work!

The Great Treat Mystery 🤔

So there I was, lying in my favorite sunny spot, when I started wondering: "What are my TOP treats?" I mean, I get shrimp 🍤, chicken 🍗, cookies 🍪, and fish 🐟 regularly, but which ones appear most frequently in my daily feast?

Being the sophisticated feline I am, I decided to solve this programmatically. This is a classic "Top K Frequent Elements" problem, and I'm going to solve it in O(treats) time and O(treats) space using bucket sort. Purr-fect!

My Treat Data 📊

Here's what my human gave me recently:

const treats = ["🍤", "🍗", "🍪", "🐟", "🍤", "🍪", "🍗", "🐟", "🍪", "🍤"]
const k = 2  // I want my top 2 treats

Hmm, looks like cookies and shrimp are showing up a lot... but let me verify this scientifically!

Step 1: Counting My Treats 🧮

First, I need to count how many times each treat appears. I'll use a Map for this:

const map = new Map()

for (const treat of treats) {
    map.set(treat, (map.get(treat) || 0) + 1)
}

This is like keeping a mental tally every time my human gives me a treat. "Oh, another shrimp! That's number 3..." you know how it goes.

After this loop, my map looks like:

🍤 (shrimp): 3 times
🍗 (chicken): 2 times
🍪 (cookies): 3 times
🐟 (fish): 2 times

Step 2: The Bucket Sort Magic ✨

Here's where it gets interesting! Instead of sorting (which would be O(n log n)), I'm using bucket sort. I create buckets where the index represents the frequency:

const buckets = Array(treats.length + 1).fill(null).map(() => [])

for (const [treat, freq] of map) {
    buckets[freq].push(treat)
}

Think of this as organizing my treats into frequency boxes. Box 1 has treats that appeared once, box 2 has treats that appeared twice, etc.

My buckets now look like:

buckets[0]: [] (empty - no treats appeared 0 times)
buckets[1]: [] (empty - all treats appeared more than once)
buckets[2]: [🍗, 🐟] (chicken and fish appeared 2 times each)
buckets[3]: [🍤, 🍪] (shrimp and cookies appeared 3 times each)
buckets[4] through buckets[10]: [] (empty)

Step 3: Finding My Top K Treats 🏆

Now I traverse the buckets from highest frequency to lowest, collecting treats until I have my top K:

const result = []

outer: for (let i = buckets.length - 1; i > 0; i--) {
    const currentBucket = buckets[i];
    if (currentBucket.length === 0) continue;

    for (const item of currentBucket) {
        result.push(item);
        if (result.length === k) break outer;
    }
}

I start from the highest frequency bucket and work my way down.

The Moment of Truth! 🎉

console.log(topKFrequent(treats, k))
// Output: ["🍤", "🍪"]

Aha! My top 2 treats are shrimp 🍤 and cookies 🍪, each appearing 3 times. My sophisticated palate was right all along!

Why This Approach is Purr-fect 🐾

Time Complexity: O(n) - I go through my treats once to count, once to put in buckets, and once to collect results. Linear time, just like how I eat treats in a straight line!

Space Complexity: O(n) - I use a map to store treat counts and buckets to organize by frequency. The space grows linearly with the number of treats.

This bucket sort approach is much more efficient than traditional sorting methods for this specific problem.

The Complete Solution 💻

var topKFrequent = function (treats, k) {
    const map = new Map()
    const buckets = Array(treats.length + 1).fill(null).map(() => [])
    const result = []

    // Count treat frequencies
    for (const treat of treats) {
        map.set(treat, (map.get(treat) || 0) + 1)
    }

    // Place treats in frequency buckets
    for (const [treat, freq] of map) {
        buckets[freq].push(treat)
    }

    // Collect top K treats from highest frequency buckets
    outer: for (let i = buckets.length - 1; i > 0; i--) {
        const currentBucket = buckets[i];
        if (currentBucket.length === 0) continue;

        for (const item of currentBucket) {
            result.push(item);
            if (result.length === k) break outer;
        }
    }

    return result
};

Final Thoughts 💭

Well, now I know scientifically that shrimp and cookies are my favorites! Time to demand more of these from my human. This bucket sort approach is elegant because it leverages the constraint that frequencies can't exceed the array length, making it perfect for this type of problem.

Now if you'll excuse me, I have some high-frequency treats to go demand... 🍤🍪

Promise.all(): The Case of the Missing Tuna

Tanvir Azad — Fri, 16 May 2025 22:09:05 +0000

Scene: Catland Central Police Station

Detective Oreo is sipping catnip tea when suddenly—an emergency call comes in:

“THE TUNA IS MISSING FROM THE FRIDGE!”

Oreo slams down his tea. “Not on my watch.”

To solve the case, he must gather three critical clues from different sources:

Pawprint Analysis
Scent Trail Report
Surveillance Footage

Each report takes time, and they are all asynchronous.

Oreo the Async Detective (Enter: `Promise.all`)

Here’s how it looks in code:

// Simulated async clue fetchers
function getPawprintAnalysis() {
  return new Promise(resolve =>
    setTimeout(() => resolve("Pawprints match: Garfield"), 1000)
  );
}

function getScentTrailReport() {
  return new Promise(resolve =>
    setTimeout(() => resolve("Scent trail leads to the litter box"), 2000)
  );
}

function getSurveillanceFootage() {
  return new Promise(resolve =>
    setTimeout(() => resolve("Garfield spotted at 2AM near fridge"), 1500)
  );
}

Oreo doesn’t want to wait one by one for each clue. So, he does the smart thing:

Promise.all([
  getPawprintAnalysis(),
  getScentTrailReport(),
  getSurveillanceFootage()
]).then(([pawprints, scent, footage]) => {
  console.log("Case Clues:");
  console.log(pawprints);
  console.log(scent);
  console.log(footage);
  console.log("Oreo concludes: It was Garfield! Case closed.");
});

What `Promise.all()` Does

Runs all clue fetches in parallel
Waits for ALL to finish
Returns an array of results
If any one fails, the whole thing fails (Oreo yells: “Abort!”)

What If One Clue Fails?

Let’s say the surveillance camera was unplugged by a raccoon:

function getSurveillanceFootage() {
  return new Promise((_, reject) =>
    setTimeout(() => reject("Camera offline! Raccoon sabotage suspected."), 1500)
  );
}

Promise.all([
  getPawprintAnalysis(),
  getScentTrailReport(),
  getSurveillanceFootage()
]).then(clues => {
  console.log(clues);
}).catch(error => {
  console.error("Investigation failed:", error);
  console.log("Oreo: ‘Back to square one... but I’ll get that tuna thief.’");
});

Summary Table: `Promise.all()`

Feature	Description
Purpose	Run multiple promises in parallel
Result	Resolves with array of all results
Failure	If one fails, the entire `Promise.all()` fails
Ideal for	When all results are required to proceed

Detective Oreo Says:

“If you're solving a crime and need all the clues before pouncing, use Promise.all()—the purr-fect tool for the job.”

Understanding JavaScript's call, bind, and apply: From Oreo's Perspective

Tanvir Azad — Fri, 16 May 2025 22:00:00 +0000

Hello there! I'm Oreo, the black and white cat who spends most of his days lounging on my human's keyboard while they code. I've picked up quite a bit about JavaScript just by watching. Today, I want to explain those confusing call, bind, and apply methods that even my human struggles with sometimes.

Let Me Introduce Myself (and My Friends)

// That's me
const oreo = {
  name: "Oreo",
  color: "black and white",
  favoriteSpot: "keyboard",
  meow: function(loudness, times) {
    for (let i = 0; i < times; i++) {
      console.log(`${this.name} says ${"m" + "e".repeat(loudness) + "ow"}!`);
    }
  }
};

// My neighborhood cat friends
const luna = {
  name: "Luna",
  color: "gray",
  favoriteSpot: "windowsill"
};

const whiskers = {
  name: "Whiskers",
  color: "orange tabby",
  favoriteSpot: "couch"
};

The Call Method: Lending My Abilities

I've noticed that in JavaScript, sometimes you want to let another object use your method. It's like when Luna comes over and wants to meow like me. She doesn't have her own meow method, but she can borrow mine using call.

// Luna borrowing my meow method
oreo.meow.call(luna, 3, 2);
// Output:
// Luna says meeeow!
// Luna says meeeow!

What's happening here? I'm lending my meow method to Luna through call. The first argument to call is who gets to be this inside the function (Luna), and the rest of the arguments are passed to the function as normal (loudness 3, times 2).

From what I observe, call works like this:

It lets you execute a function while explicitly setting what this refers to inside that function. It runs immediately and takes its arguments one by one after the first this argument.

The Apply Method: My Function, Your Array of Arguments

Whiskers likes to be more organized. When he visits, he brings his meow specifications in a neat array. This is where apply comes in handy.

// Whiskers has his parameters organized in an array
const whiskersWants = [5, 1]; // loudness of 5, 1 time

// Using apply with an array of arguments
oreo.meow.apply(whiskers, whiskersWants);
// Output:
// Whiskers says meeeeeeow!

The difference between call and apply is simple from my perspective:

apply does the same thing as call, but it takes its arguments as an array. The first argument is still who gets to be this, but the second argument is an array containing all the parameters. It also executes immediately.

The Bind Method: Creating a Personalized Function

Sometimes Luna stops by when I'm napping. She wanted a way to meow without having to bother me every time. That's where bind comes in - it lets her create her own personalized meow function based on mine.

// Creating a specialized meow function for Luna
const lunaMeow = oreo.meow.bind(luna, 2);

// She can use it whenever she wants
lunaMeow(3);
// Output:
// Luna says meeow!
// Luna says meeow!
// Luna says meeow!

// The first argument (loudness = 2) is preset, but she can change the times
lunaMeow(1);
// Output:
// Luna says meeow!

What makes bind different is:

It doesn't execute the function right away. Instead, it creates a new function with this permanently set to whatever you specified. You can also pre-set some arguments if you want, while leaving others to be filled in later when the function is actually called.

How I Remember the Differences

From my feline perspective, here's how I keep these methods straight:

call - "C" for "Comma-separated arguments" - I call the function now with a specific this and list out all the arguments.
apply - "A" for "Array of arguments" - I call the function now with a specific this and provide an array of arguments.
bind - "B" for "Bookmark for later" - I create a new function with a fixed this that I can call later, and I can optionally preset some arguments.

I've watched my human struggle with these concepts for too long, so I hope my explanation helps you understand them better. Now if you'll excuse me, I need to get back to my nap on the keyboard.

Purrs contentedly

Understanding JavaScript Mixins with My Cat Oreo

Tanvir Azad — Fri, 16 May 2025 21:32:31 +0000

Oreo is a magnificent creature with an identity crisis. One minute he's a fearsome predator stalking invisible prey, the next he's a professional napper who can sleep 18 hours straight. In the JavaScript world, he'd need multiple inheritance to truly capture his essence - but as we know, JavaScript only supports single inheritance.

Enter mixins - the perfect solution for when your objects need to be as multi-talented as my cat!

What Are Mixins?

In JavaScript, mixins are a pattern that allows us to add methods and properties from one object to another without inheritance. Think of them as behavior packages that you can "mix in" to any object or class.

It's like how Oreo can be both a "Cat" (base class) but also mix in behaviors like "NapMaster", and "ZoomiesPractitioner" without needing to inherit from multiple parent classes.

Basic Mixin Example: The Oreo Approach

Let's start by creating a basic Cat class for Oreo:

class Cat {
  constructor(name, color) {
    this.name = name;
    this.color = color;
  }

  meow() {
    return `${this.name} says meow!`;
  }
}

const oreo = new Cat('Oreo', 'black and white');
console.log(oreo.meow()); // Oreo says meow!

But Oreo is more than just a basic cat. He has specialized behaviors that not every cat has. Let's create some mixins:

// Mixin 1: Napping skills
const NapMaster = {
  nap(hours) {
    return `${this.name} is taking a ${hours}-hour nap on your ${this.currentLocation}`;
  },
  findComfySpot(location) {
    this.currentLocation = location;
    return `${this.name} has claimed your ${location}`;
  }
};

// Mixin 2: Zooming around like a maniac
const ZoomiesPractitioner = {
  zoomies() {
    return `${this.name} is running at MAXIMUM VELOCITY in random directions!`;
  },
  knockThingsOver(item) {
    return `${this.name} has strategically knocked over your ${item}. It's art.`;
  }
};

Now let's apply these mixins to the Cat class:

Object.assign(Cat.prototype, NapMaster, ZoomiesPractitioner);

Now Oreo can do all sorts of things!

console.log(oreo.nap(3)); // Oreo is taking a 3-hour nap on your keyboard
console.log(oreo.findComfySpot('keyboard')); // Oreo has claimed your keyboard
console.log(oreo.zoomies()); // Oreo is running at MAXIMUM VELOCITY in random directions!
console.log(oreo.knockThingsOver('cup')); // Oreo has strategically knocked over your cup. It's art.

Real-World Applications

Mixins aren't just for modeling cat behavior (shocking, I know). Here are some practical applications:

UI Components: Add behaviors like "Draggable", "Resizable", or "Collapsible" to various components.
API Clients: Mix in authentication, caching, or logging behaviors to API clients.
Game Development: Add abilities like "CanFly", "CanSwim", or "CanCastSpells" to game characters.

Conclusion

JavaScript mixins offer a flexible way to share behavior between objects without the limitations of single inheritance. Whether you're modeling a complex cat like Oreo or building a sophisticated application, mixins can help you compose behavior in clean, reusable chunks.

Remember Oreo's approach: be adaptable, combine behaviors when needed, and always take a nap when the code gets too complex.

Happy coding, and may your objects be as versatile as my cat!

Do you use mixins in your JavaScript projects? Let me know in the comments how you apply them, or share stories about your own pets who have inspired coding patterns!

JavaScript Static vs Private: Explained by My Cat Oreo

Tanvir Azad — Fri, 16 May 2025 20:57:45 +0000

Oreo is a black and white male cat who spends his days judging my code from the comfort of my desk chair (which he has claimed as his throne). Like most cats, he believes he owns everything - a perfect metaphor for understanding JavaScript's various scoping mechanisms!

Regular Variables and Methods: The Cat Features

Let's start with regular class variables and methods. Oreo's name and color are regular properties - anyone can access them.

class Cat {
  constructor(name, color) {
    this.name = name;
    this.color = color;
  }

  meow() {
    console.log(`${this.name} says: Meow!`);
  }
}

const oreo = new Cat("Oreo", "Black & White");
oreo.meow(); // Oreo says: Meow!
console.log(oreo.color); // Black & White - We can access and modify this property

Static Variables and Methods: The Community Cat

Static variables and methods belong to the class itself, not instances of the class. This is not specific to Oreo but to all cats in the neighbourhood, like catCount and whatAreCats().

class Cat {
  static catCount = 0;

  constructor(name) {
    this.name = name;
    Cat.catCount++; // Incrementing the static variable
  }

  static whatAreCats() {
    return "Cats are liquid that sometimes behaves like a solid";
  }
}

const oreo = new Cat("Oreo");
const mittens = new Cat("Mittens");

console.log(Cat.catCount); // 2
console.log(Cat.whatAreCats()); // "Cats are liquid that sometimes behaves like a solid"

// console.log(oreo.catCount); // undefined
// oreo.whatAreCats(); // TypeError

Private Variables and Methods: Oreo's Energy Level Management System

Private variables and methods (denoted with #) are only accessible within the class itself. Instances won't be able to use them. Oreo's energy level management system? Private.

class Cat {
  #energyLevel = 100;
  #recoverEnergy() {
    this.#energyLevel = 100;
    console.log(`${this.name} has recharged!`);
  }

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

  play() {
    console.log(`${this.name} is playing!`);
    this.#energyLevel -= 30;

    if (this.#energyLevel < 50) {
      this.#recoverEnergy();
    }
  }
}

const oreo = new Cat("Oreo");
oreo.play(); // Oreo is playing!
oreo.play(); // Oreo is playing!
oreo.play(); // Oreo is playing! Oreo has recharged!

// console.log(oreo.#energyLevel); // SyntaxError
// oreo.#recoverEnergy(); // SyntaxError

Private Static Variables and Methods: The Secret Cat Society

Finally, we have private static variables and methods. Only the Cat class can keep track of all the naps. Individual cats like Oreo can take naps, but they can't directly access the total nap count.

class Cat {
  static #totalCatNaps = 0;

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

  // Instance method accessing private static method
  takeNap() {
    Cat.#incrementNapCount();
    console.log(`${this.name} is napping`);
  }

  // Private static method, can't be called by Cat.#incrementNapCount()
  static #incrementNapCount() {
    Cat.#totalCatNaps++;
  }

  // Public static method, Cat.getTotalNaps() is used to access this
  static getTotalNaps() {
    return `Cats have taken ${Cat.#totalCatNaps} naps so far.`;
  }
}

const oreo = new Cat("Oreo");
oreo.takeNap(); // Oreo is napping
oreo.takeNap(); // Oreo is napping

const mittens = new Cat("Mittens");
mittens.takeNap(); // Mittens is napping

console.log(Cat.getTotalNaps()); // Cats have taken 3 naps so far.

// console.log(Cat.#totalCatNaps); // SyntaxError
// Cat.#incrementNapCount(); // SyntaxError

Summary: What Oreo Taught Us

Regular Variables/Methods: Oreo's name and color are accessible to everyone.
Static Variables/Methods: Oreo does not know about the totalCatCount or whatAreCats() as they are both static, so it is only known by the Cat class.
Private Variables/Methods: Oreo's energy level and recoverEnergy() are hidden (private) and can only be accessed using a public method, play().
Private Static Variables/Methods: Despite being static, the Cat class can't access the #totalCatNaps or #incrementNapCount(), since they are private static. takeNap() is to be accessed by Oreo and getTotalNaps() is to be accessed by the Cat class.

Practical Applications

Understanding these concepts is crucial when designing class hierarchies:

Use regular variables/methods when each instance needs its own unique data that should be accessible from outside
Use static variables/methods for functionality or data that applies to all instances collectively
Use private variables/methods to hide implementation details within instances
Use private static variables/methods to hide implementation details at the class level

Conclusion

Whether it’s Oreo’s public meow, his hidden energy levels, or the secret nap-tracking society only the Cat class knows about, each example helps draw a clear line between who owns what and who gets to know what. So the next time you're designing classes, think like Oreo: Some things are meant to be shared, others are best kept secret… even from the humans.

Disclaimer: No cats were consulted in the writing of this article.

Factory vs Constructor Functions: When Prototypes Don't Behave as Expected

Tanvir Azad — Fri, 16 May 2025 19:10:21 +0000

Have you ever found yourself scratching your head while debugging JavaScript prototype behavior? I recently encountered a fascinating quirk that highlights an important distinction between factory functions and constructor functions. Let's explore why the following code behaves the way it does:

function purr() {
    console.log(`${this.name} is purring`)
}

// FACTORY FUNCTION
function createCat(name, breed) {
    return {
        name,
        breed,
        greet() {
            console.log(`Hello, my name is ${this.name}`)
        }
    };
}
createCat.prototype.purr = purr
const oreo = createCat("Oreo", "Persian")
oreo.greet() // Hello, my name is Oreo
// oreo.purr() // TypeError: oreo.purr is not a function

//CONSTRUCTOR FUNCTION
function Cat(name, breed){
    this.name = name
    this.breed = breed
    this.greet = function(){
        console.log(`Hello, my name is ${this.name}`)
    }
}
Cat.prototype.purr = purr
const frosty = new Cat("Frosty", "Tabby")
frosty.greet() // Hello, my name is Frosty
frosty.purr() // Frosty is purring

The Mystery: Why Can't Oreo Purr?

Oreo and Frosty are both cats who can greet us, but only Frosty can purr! When we try to make Oreo purr, JavaScript throws a TypeError. What's going on here?

Understanding the Root Cause

The difference comes down to how prototypal inheritance works for objects created using different patterns:

Factory Functions: Plain Objects with No Prototype Connection

When we use a factory function like createCat(), it simply returns a plain object literal. This object's prototype is linked to Object.prototype, not to createCat.prototype.

In our example:

We added purr() to createCat.prototype
But oreo doesn't inherit from createCat.prototype at all!
The prototype chain for oreo looks like: oreo → Object.prototype → null

Constructor Functions: The Magic of `new`

When we use the new keyword with a constructor function like Cat(), something special happens:

A new object is created
This object's prototype is set to Cat.prototype
The constructor function is executed with this bound to the new object
The new object is returned (unless the constructor returns another object)

So for frosty:

We added purr() to Cat.prototype
frosty inherits from Cat.prototype
The prototype chain looks like: frosty → Cat.prototype → Object.prototype → null

How to Fix Oreo's Inability to Purr

If we want objects created by factory functions to share methods, we have a few options:

Option 1: Include the method directly in each object

function createCat(name, breed) {
    return {
        name,
        breed,
        greet() {
            console.log(`Hello, my name is ${this.name}`)
        },
        purr // Add purr method to each object
    };
}

Option 2: Use Object.create for proper prototype inheritance

const catMethods = {
    greet() {
        console.log(`Hello, my name is ${this.name}`)
    },
    purr() {
        console.log(`${this.name} is purring`)
    }
};

function createCat(name, breed) {
    const cat = Object.create(catMethods);
    cat.name = name;
    cat.breed = breed;
    return cat;
}

Option 3: Use classes (which are syntactic sugar for constructor functions)

class Cat {
    constructor(name, breed) {
        this.name = name;
        this.breed = breed;
    }

    greet() {
        console.log(`Hello, my name is ${this.name}`)
    }

    purr() {
        console.log(`${this.name} is purring`)
    }
}

Memory Efficiency Considerations

One advantage of the prototype approach is memory efficiency. When we add methods to prototypes rather than directly to each object:

With constructor functions, methods like purr() exist once in memory (on the prototype)
With our original factory function, greet() is recreated for each object, wasting memory

The Big Takeaways

Factory functions create objects from scratch with no inherent prototype linking
Constructor functions with new automatically link the created object to the constructor's prototype
If you're using factory functions and want shared methods, you need to:
- Include them in each object (memory inefficient)
- Use Object.create() to establish proper inheritance
- Or switch to classes/constructors

Which Should You Use?

Both patterns have their place in modern JavaScript:

Factory functions are great for creating objects with private data using closures
Constructor functions and classes provide a cleaner inheritance model for shared behavior

The key is understanding how JavaScript's prototype system works under the hood, so you don't get caught by surprising behaviors like our poor Oreo who couldn't purr!

What's your preferred way of creating objects in JavaScript? Have you encountered other prototype quirks? Share in the comments below!

Follow me for more JavaScript insights and explanations of those weird behaviors that make you go "wait, what?!"

Prototype Methods vs. Instance Methods in JavaScript

Tanvir Azad — Fri, 16 May 2025 18:46:41 +0000

Let's explore two ways to create methods in JavaScript using Oreo the cat as our example. These approaches affect how your code performs and uses memory.

Two Ways to Create Cat Methods

// Method 1: Instance Methods (using this)
function Cat(name) {
  this.name = name;

  // Method attached directly to each cat
  this.meow = function() {
    console.log(`${this.name} says meow!`);
  };
}

// Method 2: Prototype Methods
function BetterCat(name) {
  this.name = name;
}

// Method attached to the cat blueprint (prototype)
BetterCat.prototype.meow = function() {
  console.log(`${this.name} says meow!`);
};

What's the Difference?

Let's create some cats:

// Create two cats using instance methods
const oreo1 = new Cat("Oreo");
const felix1 = new Cat("Felix");

// Create two cats using prototype methods
const oreo2 = new BetterCat("Oreo");
const felix2 = new BetterCat("Felix");

// Are their methods the same?
console.log(oreo1.meow === felix1.meow); // false - each cat has its own copy
console.log(oreo2.meow === felix2.meow); // true - both cats share one method

Memory: The Big Difference

Instance Methods

Each cat gets its own copy of every method:

oreo1: { name: "Oreo", meow: function() {...} }
felix1: { name: "Felix", meow: function() {...} }
whiskers1: { name: "Whiskers", meow: function() {...} }

Prototype Methods

All cats share the same methods:

oreo2: { name: "Oreo" } ─────────────┐
felix2: { name: "Felix" } ───────────┼─→ BetterCat.prototype.meow
whiskers2: { name: "Whiskers" } ─────┘

Why This Matters

If you have many cats (like a cat shelter app with thousands of cats), prototype methods use much less memory:

// Creating 10,000 cats
function createManyCats(count) {
  // Instance method cats - each has its own methods
  const instanceCats = [];
  for (let i = 0; i < count; i++) {
    instanceCats.push(new Cat(`Cat${i}`));
  }

  // Prototype method cats - all share methods
  const protoCats = [];
  for (let i = 0; i < count; i++) {
    protoCats.push(new BetterCat(`Cat${i}`));
  }
}

createManyCats(10000);
// The prototype version uses much less memory!

When To Use Each

Use Instance Methods When:

Each cat needs its own unique version of a method
You need to remember information from when the cat was created

function SpecialCat(name, favoriteToy) {
  this.name = name;

  this.play = function() {
    console.log(`${this.name} plays with ${favoriteToy}`);
  };
}

const oreo = new SpecialCat("Oreo", "feather wand");
oreo.play(); // "Oreo plays with feather wand"

Use Prototype Methods When:

All cats do the same thing in the same way
You're creating lots of cats
You want faster, more efficient code

Modern JavaScript - Classes

The modern way to do this is with classes. Methods in classes automatically use prototypes:

class Cat {
  constructor(name) {
    this.name = name;

    // Instance method - each cat gets its own copy
    this.uniqueId = function() {
      return Math.random().toString(36).slice(2, 7);
    };
  }

  // Prototype method - all cats share this
  meow() {
    console.log(`${this.name} says meow!`);
  }
}

const oreo = new Cat("Oreo");
const felix = new Cat("Felix");

// Both cats share the same meow method
console.log(oreo.meow === felix.meow); // true

// But each has its own uniqueId method
console.log(oreo.uniqueId === felix.uniqueId); // false

Bottom Line

Prototype methods (like BetterCat.prototype.meow) are more efficient
Instance methods (like this.meow) are good for custom behavior
Class methods are prototype methods by default - the best option!

By understanding the difference, you can write better JavaScript code that runs faster and uses less memory, whether you're building a simple cat app or something much bigger!

Why Passing Entire Objects as Props in React is a Bad Practice

Tanvir Azad — Fri, 16 May 2025 16:41:31 +0000

When building React applications, you'll frequently need to pass data from parent components to children. Many developers, especially those new to React, often take the seemingly convenient approach of passing entire objects as props. However, this practice can lead to significant problems with performance, maintainability, and code quality.

Let's examine why passing entire objects is problematic through the lens of React's reconciliation process and SOLID principles, using a practical scenario.

The Scenario: A User Profile Management System

Imagine we're building a user profile dashboard with various components that display and edit different aspects of a user's information:

Profile header showing name and avatar
Contact information section
Account settings section
Subscription details

The Problematic Approach: Passing the Entire User Object

// Parent component
function UserDashboard() {
  const [user, setUser] = useState({
    id: "user_123",
    name: "Jane Smith",
    email: "jane@example.com",
    avatar: "/avatars/jane.png",
    role: "Administrator",
    department: "Engineering",
    lastLogin: "2025-05-10T10:30:00",
    preferences: {
      theme: "dark",
      notifications: true,
      language: "en-US"
    },
    subscription: {
      plan: "premium",
      renewalDate: "2025-06-15",
      paymentMethod: "credit_card"
    }
  });

  const updateUser = (updatedFields) => {
    setUser({...user, ...updatedFields});
  };

  return (
    <div className="dashboard">
      <ProfileHeader user={user} />
      <ContactInfo user={user} updateUser={updateUser} />
      <AccountSettings user={user} updateUser={updateUser} />
      <SubscriptionDetails user={user} updateUser={updateUser} />
    </div>
  );
}

// One of the child components
function ProfileHeader({ user }) {
  // Only uses name and avatar
  return (
    <header>
      <img src={user.avatar} alt={user.name} />
      <h1>{user.name}</h1>
    </header>
  );
}

The Problems with This Approach

1. React Reconciliation Inefficiency

React's reconciliation process determines when components need to re-render. When passing an entire object as props, any change to that object (even to properties the component doesn't use) creates a new object reference, triggering unnecessary re-renders.

Reconciliation Comparison Table

Scenario	Passing Entire Object	Passing Individual Properties
User changes name	All components re-render (new object reference)	Only components using `name` re-render
User changes theme preference	All components re-render (new object reference)	Only components using `preferences` re-render
Component shallow comparison check	`prevProps.user !== nextProps.user` (always true with new reference)	Only changed properties fail equality check
Memoization effectiveness	Poor (entire object changes frequently)	Good (individual properties change only when needed)
Re-render trigger granularity	Coarse (any field change triggers all components)	Fine (only affected components re-render)
Performance impact on large apps	Significant render cascades	Minimal, targeted re-renders

In our example:

function ContactInfo({ user, updateUser }) {
  // Only uses email and department
  return (
    <div>
      <input 
        value={user.email}
        onChange={(e) => updateUser({ email: e.target.value })} 
      />
      <select 
        value={user.department}
        onChange={(e) => updateUser({ department: e.target.value })}
      >
        {/* Department options */}
      </select>
    </div>
  );
}

If a user changes their theme preference:

The updateUser function is called with { preferences: {...user.preferences, theme: "light" }}
The entire user object gets a new reference
All four components re-render, even though only AccountSettings actually needs to reflect this change

This creates a needless performance bottleneck, especially as the application grows.

2. Violations of SOLID Principles

Single Responsibility Principle

Each component should have one reason to change. By passing the entire user object, we create multiple reasons for a component to change:

Changes to user data structure
Changes to component rendering logic

ProfileHeader doesn't need to know about subscription details or preferences, yet changes to those will affect it.

Interface Segregation Principle

Components should only know about the data they need. Our ProfileHeader component only needs name and avatar, but it receives the entire user object with all its properties. This violates the Interface Segregation Principle, which states that "clients should not be forced to depend upon interfaces they do not use."

Open/Closed Principle

Components that receive entire objects are less resilient to change. If we modify the user object structure (like adding a new field or renaming one), every component receiving that object is potentially affected, even if they don't use the changed field.

3. Practical Problems in Development

3.1 Reduced Type Safety

With TypeScript:

// With entire object
function ProfileHeader({ user }: { user: User }) {
  // No clarity about which properties are actually used
}

// With individual props
function ProfileHeader({ name, avatar }: { name: string, avatar: string }) {
  // Type system explicitly shows required properties
}

3.2 Testing Complications

When testing components that receive entire objects, you need to provide complete mock objects, even for properties your component doesn't use.

3.3 Debugging Challenges

When debugging render issues, it's much harder to trace which property change triggered a re-render when passing entire objects.

The Better Approach: Passing Only Required Properties

Let's refactor our example:

function UserDashboard() {
  const [user, setUser] = useState({
    // Same user object as before
  });

  const updateUser = (updatedFields) => {
    setUser({...user, ...updatedFields});
  };

  return (
    <div className="dashboard">
      <ProfileHeader 
        name={user.name} 
        avatar={user.avatar} 
      />
      <ContactInfo 
        email={user.email} 
        department={user.department} 
        onEmailChange={(email) => updateUser({ email })}
        onDepartmentChange={(department) => updateUser({ department })}
      />
      <AccountSettings 
        preferences={user.preferences}
        onPreferencesChange={(preferences) => 
          updateUser({ preferences: {...user.preferences, ...preferences} })}
      />
      <SubscriptionDetails 
        subscription={user.subscription}
        onSubscriptionChange={(subscription) => 
          updateUser({ subscription: {...user.subscription, ...subscription} })}
      />
    </div>
  );
}

Benefits of the Improved Approach

1. Efficient Reconciliation

Now, when a user changes their theme:

Only the preferences object gets a new reference
Only the AccountSettings component re-renders
Other components remain untouched, as React can see their props haven't changed

2. SOLID Principles Adherence

Single Responsibility: Each component only depends on the data it needs
Interface Segregation: Components receive exactly the interface they require
Open/Closed: Changes to one part of the user data don't affect components that use other parts

3. Developer Experience Improvements

Clear, self-documenting API for each component
Easier testing with fewer mock objects needed
Explicit dependencies make refactoring safer

Conclusion

While passing entire objects as props might seem convenient, it creates unnecessary performance overhead and violates key software design principles. By passing only the properties that components actually need:

Your app will re-render more efficiently
Your component interfaces will be clearer and more maintainable
Your codebase will be more resilient to changes

This practice becomes increasingly important as your application grows in complexity. Start with good habits now by passing only the props your components actually need, and you'll thank yourself later when debugging or optimizing your React application.

Remember: "Explicit is better than implicit" - even if it means writing a few more lines of prop definitions, the clarity and performance benefits make it worthwhile.

Debouncing beyond API Calls

Tanvir Azad — Fri, 16 May 2025 16:20:24 +0000

At its core, debouncing is a programming practice that ensures a time-consuming function doesn't get called too frequently. It works by delaying the function execution until after a certain time has passed since it was last invoked.

Think of it like an elevator: instead of immediately moving after someone presses a button, it waits a few seconds to see if anyone else wants to get on before making the trip.

Before exploring use cases, let's implement a simple yet powerful useDebounce hook that you can use throughout your React applications:

import { useState, useEffect } from 'react';

function useDebounce(value, delay) {
  // State to store the debounced value
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    // Set up a timer to update the debounced value after the specified delay
    const timer = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    // Clean up the timer if value changes or component unmounts
    return () => {
      clearTimeout(timer);
    };
  }, [value, delay]);

  return debouncedValue;
}

export default useDebounce;

This hook takes two parameters: the value you want to debounce and the delay in milliseconds. It returns the debounced value that updates only after the specified delay has passed without any new changes.

Practical Use Cases for Debouncing in React

1. Search Input Optimization

The classic example - and for good reason. Debouncing search inputs prevents unnecessary API calls as users type:

import React, { useState } from 'react';
import useDebounce from './hooks/useDebounce';

function SearchComponent() {
  const [searchTerm, setSearchTerm] = useState('');
  const debouncedSearchTerm = useDebounce(searchTerm, 500);

  // This effect will only run when debouncedSearchTerm changes
  useEffect(() => {
    if (debouncedSearchTerm) {
      fetchSearchResults(debouncedSearchTerm);
    }
  }, [debouncedSearchTerm]);

  return (
    <input
      type="text"
      value={searchTerm}
      onChange={(e) => setSearchTerm(e.target.value)}
      placeholder="Search..."
    />
  );
}

2. Form Input Validation

Improve user experience by validating form inputs only after users have paused typing:

function EmailInput() {
  const [email, setEmail] = useState('');
  const [error, setError] = useState('');
  const debouncedEmail = useDebounce(email, 600);

  useEffect(() => {
    if (debouncedEmail) {
      validateEmail(debouncedEmail)
        ? setError('')
        : setError('Please enter a valid email address');
    }
  }, [debouncedEmail]);

  return (
    <div>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="Email address"
      />
      {error && <p className="error">{error}</p>}
    </div>
  );
}

3. Auto-Save Functionality

Create a seamless auto-save experience for text editors or form inputs:

function AutosaveTextarea() {
  const [content, setContent] = useState('');
  const debouncedContent = useDebounce(content, 1000);

  useEffect(() => {
    // Only save when user has stopped typing for 1 second
    if (debouncedContent) {
      saveToLocalStorage(debouncedContent);
      // Or save to backend
      // saveToBackend(debouncedContent);
    }
  }, [debouncedContent]);

  return (
    <div>
      <textarea
        value={content}
        onChange={(e) => setContent(e.target.value)}
        placeholder="Start typing..."
      />
      <div className="status">
        {content !== debouncedContent ? 'Saving...' : 'Saved!'}
      </div>
    </div>
  );
}

Debounce vs. Throttle: Know the Difference

While debouncing delays function execution until after a certain time has passed, throttling ensures a function executes at a regular interval.

Debounce: Wait until user stops interacting before executing (good for "final value" scenarios)
Throttle: Execute periodically during interaction (good for "continuous update" scenarios)

Choose the appropriate technique based on your specific use case.

Next time you're dealing with frequent state updates or potentially expensive operations, consider whether a debounce might be the elegant solution you need. Happy Coding!

DEV Community: Tanvir Azad

React Native Architecture: Busting the "Compile to Native" Myth

🤯 Misconception #1: "React Native compiles my JavaScript into Swift/Objective-C."

The Two Parallel Stages

If there is no translation, how does it work?

🏗️ Misconception #2: "The Metro Bundler is just a local dev server."

The Journey from Code to .ipa

🧩 The Final Product: A Hybrid App

Why does this matter?

SOLID in React (Do’s & Don’ts)

Write SOLID React Hooks

JS Evolution: 15 Years in 15 Minutes

ES2024 Features - In-Depth Examples

1. Top-Level await

2. Private Class Fields

3. BigInt for Large Numbers

4. Array .at() Method

5. Object.hasOwn()

6. Hashbang Grammar

7. Set Operations

Conclusion

Oreo's Top K Treats (Bucket Sort)

The Great Treat Mystery 🤔

My Treat Data 📊

Step 1: Counting My Treats 🧮

Step 2: The Bucket Sort Magic ✨

Step 3: Finding My Top K Treats 🏆

The Moment of Truth! 🎉

Why This Approach is Purr-fect 🐾

The Complete Solution 💻

Final Thoughts 💭

Promise.all(): The Case of the Missing Tuna

Scene: Catland Central Police Station

Oreo the Async Detective (Enter: Promise.all)

What Promise.all() Does

What If One Clue Fails?

Summary Table: Promise.all()

Detective Oreo Says:

Understanding JavaScript's call, bind, and apply: From Oreo's Perspective

Let Me Introduce Myself (and My Friends)

The Call Method: Lending My Abilities

The Apply Method: My Function, Your Array of Arguments

The Bind Method: Creating a Personalized Function

How I Remember the Differences

Understanding JavaScript Mixins with My Cat Oreo

What Are Mixins?

Basic Mixin Example: The Oreo Approach

Real-World Applications

Conclusion

JavaScript Static vs Private: Explained by My Cat Oreo

Regular Variables and Methods: The Cat Features

Static Variables and Methods: The Community Cat

Private Variables and Methods: Oreo's Energy Level Management System

Private Static Variables and Methods: The Secret Cat Society

Summary: What Oreo Taught Us

Practical Applications

Conclusion

Factory vs Constructor Functions: When Prototypes Don't Behave as Expected

The Mystery: Why Can't Oreo Purr?

Understanding the Root Cause

Factory Functions: Plain Objects with No Prototype Connection

Constructor Functions: The Magic of new

How to Fix Oreo's Inability to Purr

Option 1: Include the method directly in each object

Option 2: Use Object.create for proper prototype inheritance

Option 3: Use classes (which are syntactic sugar for constructor functions)

Memory Efficiency Considerations

The Big Takeaways

Which Should You Use?

Prototype Methods vs. Instance Methods in JavaScript

Two Ways to Create Cat Methods

What's the Difference?

Memory: The Big Difference

Instance Methods

Prototype Methods

Why This Matters

When To Use Each

Use Instance Methods When:

Use Prototype Methods When:

Modern JavaScript - Classes

The Journey from Code to `.ipa`

1. Top-Level `await`

4. Array `.at()` Method

Oreo the Async Detective (Enter: `Promise.all`)

What `Promise.all()` Does

Summary Table: `Promise.all()`

Constructor Functions: The Magic of `new`