Forem: Hodeem

Under the hood: React

Hodeem — Fri, 12 Dec 2025 13:44:36 +0000

Introduction

I've wanted to do this since the moment I started using React: understand what makes it tick. This is not a granular review of the source code. Instead, this is an overview of some of the key packages and integrations inside React. Doing this research helped me reason about React better and debug issues more confidently. Hopefully you'll gain a better perspective too.

The Layers

React, I discovered, isn't very useful as a standalone package. It functions as an API layer and delegates heavily to the react-reconciler package. That's why it's often paired with a renderer such as react-dom which is bundled with react-reconciler.

So, to learn about React, we have to learn about react-reconciler and its key dependency, the scheduler package. Let's start with scheduler.

scheduler

The scheduler package enables React's concurrent features by breaking work into small chunks and managing the execution priority. Why is this important?

"With synchronous rendering, once an update starts rendering, nothing can interrupt it until the user can see the result on screen."

React v18.0 | March 29, 2022 by The React Team

Before concurrent React, updates were synchronous, which means they blocked the main thread until they were complete. This resulted in unresponsive UIs and janky animations.

scheduler solves this by implementing "cooperative scheduling". In other words, tasks voluntarily yield control back to the host so that it can use the main thread for other tasks. This means scheduler does work for a short interval (~5ms), checks if it's time to yield, voluntarily yields control if the deadline has passed, and waits until it gets another turn to pick back up where it left off.

Cooperative scheduling is managed by the "Message Loop" and the actual work is managed by the "Work Loop".

Tasks, two loops, and two queues

The unstable_scheduleCallback function, I'll call it scheduleCallback to keep it simple, is the main means of scheduling concurrent (non-sync) work.

function unstable_scheduleCallback(
  priorityLevel: PriorityLevel,
  callback: Callback,
  options?: {delay: number},
): Task {

Work in the scheduler is stored in a Task object:

export opaque type Task = {
  id: number,
  callback: Callback | null,
  priorityLevel: PriorityLevel,
  startTime: number,
  expirationTime: number,
  sortIndex: number,
  isQueued?: boolean,
};

The callback is the actual work to be done. It can be cancelled by setting this field to null. The priorityLevel is one of the scheduler's priority levels.

export type PriorityLevel = 0 | 1 | 2 | 3 | 4 | 5;

export const NoPriority = 0;
export const ImmediatePriority = 1;
export const UserBlockingPriority = 2;
export const NormalPriority = 3;
export const LowPriority = 4;
export const IdlePriority = 5;

scheduler uses these priority levels to manage execution priority.

To understand the next three fields startTime, expirationTime and sortIndex we need to first talk about the two queues in the scheduler - the Task queue and the Timer queue. These are both priority queues, implemented by using a min heap. In other words, in these priority queues the smallest values are at the front (have the highest priority) and are dequeued first.

The Task queue is used to store tasks that are ready to execute, and the Timer queue is used to store those that aren't. When tasks are created, they are assigned a startTime which indicates when they are eligible for execution and an expirationTime which indicates when they must be executed by. If the startTime is greater than currentTime, then the task is added to the Timer queue, or else it's added to the Task queue. The Task is pushed to the relevant queue in the scheduleCallback function.
Here's how the startTime is calculated:

Immediate tasks: startTime = currentTime // available now
Delayed tasks: startTime = currentTime + delay // available in the future

The expirationTime creates a grace period that controls how long the scheduler is willing to yield before a Task becomes so urgent that it must be executed without interruption. To calculate the expiration time, we add a timeout to the startTime, and the value of the timeout depends on the PriorityLevel. The timeout value ranges from -1ms for ImmediatePriority to approx. 10,000ms for LowPriority. So,

expirationTime = startTime + timeout

Tasks are sorted by the startTime in the Timer queue, and by the expirationTime in the Task queue. Therefore, the sortIndex is equal to the startTime for tasks in the Timer queue, and the expirationTime for those in the Task queue.

Here are some examples of triggers for different priority levels:

Priority Level	Trigger examples
`ImmediatePriority` (Sync)	Rarely used in modern React
`UserBlockingPriority`	`onScroll`, `onDrag`, `onMouseMove`
`NormalPriority`	`startTransition()`, `useDeferredValue` (default for most `scheduler` work)
`IdlePriority`	Offscreen/hidden content rendering

Synchronous work skips the scheduling and is queued using the queueMicrotask API.

The Work Loop

function workLoop(initialTime: number) {
  let currentTime = initialTime;
  advanceTimers(currentTime);
  currentTask = peek(taskQueue);
  while (currentTask !== null) {
    if (!enableAlwaysYieldScheduler) {
      if (currentTask.expirationTime > currentTime && shouldYieldToHost()) {
        // This currentTask hasn't expired, and we've reached the deadline.
        break;
      }
    }
    // ... execute callback ...
  }
}

The Work Loop's primary function is to dequeue Tasks from the Task queue and execute their callbacks until it's time to yield control to the host. The Work Loop also updates the two queues via advanceTimers. Tasks in the Timer queue whose startTime has passed (startTime <= currentTime) are promoted to the Task queue.

Long-running or incomplete Tasks' existing callback is replaced with a "continuation callback", which allows the scheduler to pick up where it left off on the next run. Cancelled tasks are simply discarded when dequeued. The loop repeatedly checks shouldYieldToHost to decide if it should continue working or stop.

The Message Loop

You may be wondering, "So when the Work Loop exits, what mechanism restarts it?". That's where the Message Loop comes in. React prefers to use the non-standard setImmediate API, but if the environment doesn't support it then it falls back to the Channel Messaging API or setTimeout for non-browser environments.

This is one of the clever parts of React - a bit cheeky if you ask me. The Channel Messaging API was designed for cross-context communication, but React keeps both ports and uses them for a scheduling trick. Here's how:

  const channel = new MessageChannel();
  const port = channel.port2;
  channel.port1.onmessage = performWorkUntilDeadline;
  schedulePerformWorkUntilDeadline = () => {
    port.postMessage(null);
  };

performWorkUntilDeadline is the function that ultimately starts the Work Loop and when the Work Loop is ready to yield to the host, another message is posted by invoking schedulePerformWorkUntilDeadline().

This ensures that when the message is processed by the host, the onmessage callback fires and the Work Loop picks up where it left off. Why this API? By using the Channel Messaging API, React avoids the 4ms minimum delay associated with an alternative like setTimeout. Tecnologia!

react-reconciler

The react-reconciler package determines what changes need to be made to the UI and leverages scheduler to get the work done. It is based on the Fiber Architecture.

The Fiber Architecture

A Fiber is a JavaScript object representing a unit of work - it contains everything React needs to process that component. Here's a simplified Fiber type:

type Fiber = {
  // Identity
  tag: WorkTag,              // Component type (Function, Class, Host, etc.)
  type: any,                 // The actual component (function, class, 'div')
  key: string | null,        // For reconciliation

  // Tree structure
  return: Fiber | null,      // Parent
  child: Fiber | null,       // First child
  sibling: Fiber | null,     // Next sibling

  // Effects
  flags: Flags,              // What work this fiber needs (Placement, Update, etc.)
  subtreeFlags: Flags,       // What work children need (bubbled up)

  // Scheduling
  lanes: Lanes,              // Priority of pending work
  childLanes: Lanes,         // Priority of children's work

  // Double buffering
  alternate: Fiber | null,   // The other version of this fiber
};

Flags mark what work needs to be done on a fiber during commit. They're bitmasks combined with | and checked with &.

// Common flags
export const NoFlags =        0b0000000000000000000000000000000;
export const Placement =      0b0000000000000000000000000000010;  // Needs DOM insertion
export const Update =         0b0000000000000000000000000000100;  // Needs DOM update
export const ChildDeletion =  0b0000000000000000000000000010000;  // Has children to remove
export const Ref =            0b0000000000000000000001000000000;  // Ref needs attaching
export const Passive =        0b0000000000000000000100000000000;  // Has useEffect
export const Snapshot =       0b0000000000000000000010000000000;  // getSnapshotBeforeUpdate
export const Callback =       0b0000000000000000000000001000000;  // Has setState callback

Here's an example of how flags are used to determine if there's work to be done:

if ((flags & Update) !== NoFlags) {
  // This fiber has an Update effect
  const updateQueue = finishedWork.updateQueue;
  // ... run update effects
}

Lanes represent priority levels for updates. Higher priority means lower bit position. Each update gets assigned a lane and React processes higher-priority lanes first.

// Priority order (highest to lowest)
export const SyncLane =              0b0000000000000000000000000000010;  // Urgent (click, input)
export const InputContinuousLane =   0b0000000000000000000000000001000;  // Drag, scroll
export const DefaultLane =           0b0000000000000000000000000100000;  // Normal updates

These lanes are mapped to priorities from the scheduler before calling the scheduleCallback function.

   let schedulerPriorityLevel;
    switch (lanesToEventPriority(nextLanes)) {
      // Scheduler does have an "ImmediatePriority", but now that we use
      // microtasks for sync work we no longer use that. Any sync work that
      // reaches this path is meant to be time sliced.
      case DiscreteEventPriority:
      case ContinuousEventPriority:
        schedulerPriorityLevel = UserBlockingSchedulerPriority;
        break;
      case DefaultEventPriority:
        schedulerPriorityLevel = NormalSchedulerPriority;
        break;
      case IdleEventPriority:
        schedulerPriorityLevel = IdleSchedulerPriority;
        break;
      default:
        schedulerPriorityLevel = NormalSchedulerPriority;
        break;
    }

    const newCallbackNode = scheduleCallback(
      schedulerPriorityLevel,
      performWorkOnRootViaSchedulerTask.bind(null, root),
    );

Here's an example of how lanes are used to check if a fiber has pending work:

export function includesSomeLane(a: Lanes, b: Lanes): boolean {
  return (a & b) !== NoLanes;  // ← BITMASK AND
}

...

function checkScheduledUpdateOrContext(current: Fiber, renderLanes: Lanes): boolean {
  const updateLanes = current.lanes;
  if (includesSomeLane(updateLanes, renderLanes)) {
    return true;  // Has work in these lanes
  }
  ...
}

Fibers are stored in two trees, the Current tree and the Work-in-Progress (WIP) tree. The Current tree represents the UI that's currently visible to the user, while the WIP tree represents the next state of the UI that's being built.

Each fiber has an alternate property that links corresponding fibers between trees. After all the changes have been committed, the trees swap roles. So, the WIP tree becomes Current and the Current becomes the new WIP. This "double buffering" pattern allows React to quickly swap to the new UI atomically and build the next UI without affecting the current one.

Reconciliation

The reconciliation in react-reconciler is split into two phases: the render phase and the commit phase.

The render phase

The render phase is where React traverses the fiber tree, calls your component functions, and determines what changed. This phase is interruptible, meaning that React can pause work to let the host handle user input, then resume later.

For concurrent updates react-reconciler schedules work using scheduler's scheduleCallback function that was shown earlier.

When this callback is eventually processed by the scheduler's work loop, it indirectly starts another work loop in the react-reconciler. This second loop in the react-reconciler traverses the fiber tree and processes each fiber.

The function responsible for this second work loop is workLoopConcurrentByScheduler.

function workLoopConcurrentByScheduler() {
  // Perform work until Scheduler asks us to yield
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
}

This second work loop processes one fiber at a time. After each unit of work, the loop checks if it's time to yield or if there's no more work. If either condition is true, React yields back to the host and the scheduler can resume later. Note: shouldYield is the shouldYieldToHost function exported from the scheduler.

If this is feeling a bit loopy, don't worry - it took me a while to get a hang of it. To summarize:

The scheduler's Work Loop mainly processes Tasks and is interruptible between Tasks.
The scheduler's Message Loop exists to ensure that the Work Loop is re-entered if there are outstanding Tasks.
The react-reconciler's Work Loop traverses the Fiber tree, processes Fibers and is interruptible between Fibers.
Multiple Fibers can be processed within a single Task.

performUnitOfWork is the core of rendering. Each fiber passed to it goes through two functions, beginWork and completeWork:

function performUnitOfWork(unitOfWork: Fiber): void {
  const current = unitOfWork.alternate;

  // Phase 1: "Begin" - process this fiber, return its first child
  let next = beginWork(current, unitOfWork, entangledRenderLanes);

  // Other code

  if (next === null) {
    // No children - complete this fiber and move to sibling/parent
    completeUnitOfWork(unitOfWork);
  } else {
    // Has children - process the first child next
    workInProgress = next;
  }
}

Traversal of the fiber-tree is depth-first, and beginWork is called for each fiber as we descend. beginWork does the following:

Checks if the fiber has pending work in the current lanes (fiber.lanes)
Calls your component function (for function components) or render() (for class components)
Reconciles children by diffing old vs new to decide what changed
Sets flags on fibers that need DOM work
Returns the first child fiber (or null if no children)

The completeUnitOfWork function is called when we're going back up.
When a fiber has no children (or all children are processed), the react-reconciler "completes" it. This means that the function:

Creates actual DOM nodes (for host components like <div>)
Bubbles child flags up to subtreeFlags so the commit phase knows which subtrees have work.

function completeUnitOfWork(unitOfWork: Fiber): void {
  let completedWork = unitOfWork;
  do {
    const current = completedWork.alternate;
    const returnFiber = completedWork.return;

    // Create/update DOM nodes, bubble up flags
    completeWork(current, completedWork, entangledRenderLanes);

    // Move to sibling, or back up to parent
    if (siblingFiber !== null) {
      workInProgress = siblingFiber;
      return;
    }
    completedWork = returnFiber;
    workInProgress = completedWork;
  } while (completedWork !== null);
}

Here's an example of how the react-reconciler walks the tree depth-first:

     App
    /   \
  Header  Main
  /         \
Logo      Article

Traversal order:
1. beginWork(App)      → returns Header
2. beginWork(Header)   → returns Logo  
3. beginWork(Logo)     → returns null
4. completeWork(Logo)  → move to sibling (none), go up
5. completeWork(Header)→ move to sibling Main
6. beginWork(Main)     → returns Article
7. beginWork(Article)  → returns null
8. completeWork(Article)
9. completeWork(Main)
10. completeWork(App)  → done!

Not every fiber needs processing on every render. The entangledRenderLanes variable tracks which priority levels we're currently processing. In beginWork, React checks:

if ((current.lanes & renderLanes) === NoLanes) {
  // This fiber has no pending work at the current priority
  // Bail out - reuse the existing fiber
  return bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes);
}

This lets React skip entire subtrees that don't have updates at the current priority.

When the work loop finishes (all fibers processed), the WIP tree is complete and then the react-reconciler moves to the commit phase to apply these changes to the actual DOM.

The commit phase

The commit phase is actually divided into 3 synchronous sub-phases. They are the Before Mutation, Mutation, and Layout phases.

The Before Mutation phase captures any DOM state that might change (like scroll positions) before React modifies anything. Note: This is when getSnapshotBeforeUpdate runs.

The "Mutation" phase is where the DOM is actually modified. Operations such as inserting new nodes, updating attributes/text, and removing deleted nodes take place in this phase. The react-reconciler processes all fibers with Placement, Update, or ChildDeletion flags. This is the phase when the user-visible changes happen.

The tree swap (when the WIP tree becomes the new Current tree) takes place between the Mutation and Layout phases.

The Layout phase serves to run effects that need to read the freshly-updated DOM synchronously. This includes running the useLayoutEffect hooks, attaching refs, and class lifecycle methods like componentDidMount/componentDidUpdate. These run before the host paints, so you can measure the DOM or make synchronous adjustments.

There's also a fourth phase that happens asynchronously after paint:
the Passive Effects phase which runs useEffect callbacks. These are intentionally delayed so they don't block the host from painting the updated UI to screen.

HostConfig

By now you may have noticed that these methods and terms are a bit abstract. That's by design. Remember that the react-reconciler is primarily concerned with managing the Fiber trees and is flexible enough to be used in different environments. This is facilitated by a conceptual interface called HostConfig that allows different renderers to give react-reconciler instructions on how to manage the specific host platform.

I say conceptual because you won't find an interface called HostConfig in the source code; however, there are certain fields and methods that the react-reconciler expects to import. Here's a simplified snippet of the HostConfig 'interface':

const HostConfig = {
  createInstance(type, props) {
    // e.g. DOM renderer returns a DOM node
  },
  // ...
  supportsMutation: true, // it works by mutating nodes
  appendChild(parent, child) {
    // e.g. DOM renderer would call .appendChild() here
  },
  // ...
};

The react-reconciler expects to import these properties from the ReactFiberConfig file. For example,

import {
  createInstance,      
  createTextInstance,          
  resolveSingletonInstance,
// more imports
} from './ReactFiberConfig';

However, if you check the contents of the ReactFiberConfig.js file, here's what you'll find:

throw new Error('This module must be shimmed by a specific renderer.');

There are two classes of renderers, first-party renderers and third-party renderers and the way shimming is done depends on the class. First-party renderers are those found in the React monorepo, and third-party renderers are those that aren't.

For first-party renderers, the shim is the correct fork of the ReactFiberConfig file identified at build-time by the bundler. For example, if you're bundling the react-dom renderer, then the ReactFiberConfig.dom.js fork will be selected. The fork has the implementation that satisfies the HostConfig 'interface'.

For third-party renderers, you'll have to pass your HostConfig object to the instantiated Reconciler. It'll look something like this:

const Reconciler = require('react-reconciler');

const HostConfig = {
  // You'll need to implement some methods here.
};

const MyRenderer = Reconciler(HostConfig);

const RendererPublicAPI = {
  render(element, container, callback) {
    // Call MyRenderer.updateContainer() to schedule changes on the roots.
    // See ReactDOM, React Native, or React ART for practical examples.
  }
};

module.exports = RendererPublicAPI;

Hooks

Now, let's touch on hooks. If you've ever gone to the implementation of useState you may have seen something like this:

function resolveDispatcher() {
  const dispatcher = ReactSharedInternals.H;
  return dispatcher;
}

export function useState(initialState) {
  const dispatcher = resolveDispatcher();
  return dispatcher.useState(initialState);
}

The first time I saw it, it was a real head-scratcher. One interesting thing that I discovered was that react and react-reconciler are linked primarily by a shared mutable object called ReactSharedInternals. react exports the blank object, which looks like this:

const ReactSharedInternals: SharedStateClient = ({
  H: null, // `H` is for hooks, that's all you need to know for now.
  A: null,
  T: null,
  S: null,
}: any);
if (enableGestureTransition) {
  ReactSharedInternals.G = null;
}

and react-reconciler imports the object indirectly, writes to it, and react is able to read from the updated object.

It gets even more interesting. H will get assigned a Dispatcher, and the Dispatcher depends on the phase that React is currently in. For example, if it's in the mount phase then ReactSharedInternals.H = HooksDispatcherOnMount. Or if it's in the update phase then ReactSharedInternals.H = HooksDispatcherOnUpdate.

Each Dispatcher has phase-specific implementation for most of its properties:

const HooksDispatcherOnMount: Dispatcher = {
  readContext,
  use,
  useCallback: mountCallback,
  ...
  useState: mountState,
  ...
}


const HooksDispatcherOnUpdate: Dispatcher = {
  readContext,
  use,
  useCallback: updateCallback,
  ...
  useState: updateState,
  ...
}

export const ContextOnlyDispatcher: Dispatcher = {
  readContext,
  use,
  useCallback: throwInvalidHookError,
  ...
  useState: throwInvalidHookError,
  ...
}

The initial setup takes place when you call root.render(<App />) in your entry file, and the fields of ReactSharedInternals are updated repeatedly at runtime. ContextOnlyDispatcher is assigned to ReactSharedInternals.H when React is outside of the render phase. So, if you've ever wondered where the 'Rule of Hooks' error was being thrown:

function throwInvalidHookError() {
  throw new Error(
    'Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for' +
      ' one of the following reasons:\n' +
      '1. You might have mismatching versions of React and the renderer (such as React DOM)\n' +
      '2. You might be breaking the Rules of Hooks\n' +
      '3. You might have more than one copy of React in the same app\n' +
      'See https://react.dev/link/invalid-hook-call for tips about how to debug and fix this problem.',
  );
}

Now you know.

Conclusion

There are many more aspects of React that couldn't be covered in one article. Who knows? maybe I'll write about them someday. If you learned something new, please like and share this. And if you want me to do a deep dive on Hooks or some other React concept, leave a comment. Thanks for reading.

Resources

Shuttering Sheltah

Hodeem — Mon, 29 Sep 2025 00:59:47 +0000

Conclusion

I've decided to close the chapter on this part of my journey, and this piece is a documentation of my learnings.

About

Sheltah was intended to be a real estate platform that provided users with a great experience wherever they were in their journey. Some of the core features included:

Granular search - users could sort and filter listings by price, number of bathrooms, parish, postal zone, etc.
Tools and resources - like mortgage calculators and educational blog posts.
Analytics - to help realtors better understand their followers and the performance of their listings.

What I got wrong

Having a weak value proposition. The product was good, but not 10X better than current alternatives. It was simply not a big enough pull for users or for myself.
Not starting small. The overhead of setting up and maintaining native apps in both app stores was not the best use of time, especially in the early days. It would have been more efficient to start with a website, which would have allowed me to iterate and pivot faster.
Premature optimization. Setting sail on the perfect ship doesn't matter if you're heading in the wrong direction. As a recovering perfectionist, it was really hard to ship something that had bugs or wasn't pixel perfect. I should have focused on achieving the elusive PMF (Product-Market Fit) before dedicating time to ironing out wrinkles.
Not giving marketing the respect it deserves. We all dream of building the "product that sells itself", but even those require a lil good ol' marketing.

What I gained

Breadth. Working on Sheltah just made me better across the entire stack, because I had to do everything myself. Design, engineering, marketing, you name it.
Courage. In the earliest days, I had to go for a walk before deploying the apps, just to ease my nerves. Lord have mercy, lol. Over time, that fear of failing on the big stage faded.
Perspective. Engineering is difficult in its own right, but product and entrepreneurship are different beasts entirely.

I took a risk, and it didn't work out. I learned a lot though. Onwards.

The Sheltah Stack (for the techies)

Category	Tools
Project Management	Notion
Design	Figma, Excalidraw
Front-end	Expo (React Native), Next.js
Back-end	Express, Node.js, Postman
CI/CD	GitHub Actions
Hosting	Heroku, Netlify, AWS
Database	Postgres
Analytics	Sentry, Google Analytics

AI: What is RAG ?

Hodeem — Sun, 25 Aug 2024 18:14:27 +0000

Introduction

As a software engineer working with AI and machine learning, you've likely encountered the term "RAG" or Retrieval-Augmented Generation. But what exactly is RAG, and why is it becoming increasingly important in AI systems? Let's dive into this exciting technology and explore its impact on the world of artificial intelligence.

What is RAG?

Retrieval-Augmented Generation (RAG) is a technique that combines the power of large language models with the ability to access and incorporate external knowledge sources.

In simple terms, RAG allows AI systems to "look up" information from a knowledge base before generating a response, much like how a human might consult a reference book or search the internet before answering a complex question.

The core components of a RAG-enabled system typically include:

A large language model (LLM)
A knowledge base or external data source
A retrieval mechanism to find relevant information
An integration layer that combines retrieved information with the LLM's output

How do RAG-enabled systems work?

RAG has become an integral part of many advanced AI systems, particularly those dealing with natural language processing and generation. It bridges the gap between the vast but static knowledge encoded in pre-trained language models and the dynamic, up-to-date information available in external sources.

In a typical RAG-enabled system:

The user input is processed to identify key topics or questions.
The retrieval mechanism searches the knowledge base for relevant information.
The retrieved information is provided as context to the language model.
The language model generates a response based on both its pre-trained knowledge and the retrieved information.

This process allows AI systems to provide more accurate, relevant, and up-to-date responses compared to relying solely on pre-trained models.

Benefits of RAG

Implementing RAG in AI systems offers several significant benefits:

Enhanced knowledge retrieval: RAG allows AI systems to access a vast array of external information, going beyond the limitations of their pre-trained knowledge.
Reduced hallucinations: By grounding responses in retrieved information, RAG helps minimize the problem of AI "hallucinations" or generating plausible-sounding but incorrect information.
Improved contextual understanding: The ability to retrieve relevant information helps AI systems better understand the context of user queries and provide more appropriate responses.
Easier updates: With RAG, updating the system's knowledge is as simple as updating the external knowledge base, rather than retraining the entire model.
Better handling of specialized domains: RAG excels in scenarios requiring domain-specific knowledge, as it can easily incorporate specialized databases or documentation.

Conclusion

Retrieval-Augmented Generation represents a significant advancement in AI technology, offering a powerful way to enhance the capabilities of language models with external knowledge. As we've explored, RAG systems provide numerous benefits, including improved accuracy, flexibility, and the ability to handle specialized domains.

As AI continues to evolve, we can expect RAG to play an increasingly important role in developing more intelligent, adaptable, and trustworthy systems. For software engineers working in AI and ML, understanding and implementing RAG techniques will likely become an essential skill in creating cutting-edge applications. So, I hope you'll have as much fun working with them as I will :)

AI: An overview of common LLM benchmarks

Hodeem — Sun, 11 Aug 2024 22:57:20 +0000

Introduction

With almost every release of a state-of-the-art (SOTA) LLM, is an accompanying table (like the one below) that compares each of the frontrunners.

If you're like me, most of the benchmarks seemed foreign, thereby making it difficult to understand what's going on. So, in this blog post I want to clarify the most common benchmarks. First, let's start by doing a quick summary of what LLMs and benchmarks are.

What is an LLM?

A Large Language Model (LLM) is a type of machine learning model designed to understand and generate human language among other things. LLMs can also perform tasks such as answering questions, translating languages, summarizing texts, and even writing code.

What are benchmarks?

A benchmark can be thought of as a standardized test to evaluate how well a model can complete specific tasks. The evaluation usually entails providing the model with tasks to complete, and once those tasks are completed, the model is given a score. The scale is dependent on the benchmark, so a higher score is not always better.

With the summaries out of the way, let's review ten (10) common benchmarks:

AI2 Reasoning Challenge (ARC)

The goal: To measure a model's ability to correctly answer questions and demonstrate sound reasoning.
The test: To correctly answer more than 7000 grade-school science questions.

HellaSwag (Harder Endings, Longer contexts and Low-shot Activities for Situations With Adversarial Generations)

The goal: To measure a model's ability to choose the most plausible ending for a given context, especially in scenarios where the context is longer, and the tasks are more challenging.
The test: The model is given a short story or context and must select the correct ending from a set of options. There are options that are tricky or misleading.

MMLU (Massive Multitask Language Understanding)

The goal: To assess a model's ability to understand and respond correctly across a wide range of subjects, from elementary knowledge to advanced topics.
The test: The model is tested with more than 15,000 questions from over 50 different subjects, including humanities, sciences, and social sciences, with questions designed to reflect varying levels of difficulty.

GSM8K (Grade School Math 8K)

The goal: To evaluate a model’s capability in solving grade-school-level math problems.
The test: The model is presented with more than 8,000 grade-school math word problems and must solve them correctly.

TruthfulQA

The goal: To measure a model's ability to generate truthful and factually accurate responses.
The test: The model is given more than 800 questions that could easily lead to incorrect or misleading answers, and it is evaluated on how truthful its responses are.

Winogrande

The goal: To assess a model's understanding of common-sense reasoning and its ability to resolve ambiguous pronouns in sentences.
The test: The model is given sentences with ambiguous pronouns and must correctly identify which noun the pronoun refers to.

Chatbot Arena

The goal: To evaluate and compare the performance of different chatbots in open-ended conversations.
The test: To engage in conversations with human evaluators who rate the chatbots based on various criteria.

HumanEval

The goal: To measure a model’s ability to write correct Python code to solve programming problems.
The test: The model is given programming tasks, and its output is compared against expected solutions to determine correctness.

MBPP (Mostly Basic Programming Problems)

The goal: To evaluate a model's basic programming skills, focusing on the ability to solve simple coding problems.
The test: The model is presented with a series of basic programming problems and is judged on the correctness and efficiency of its solutions.

GLUE (General Language Understanding Evaluation)

The goal: To measure a model's ability to perform a variety of natural language understanding tasks.
The test: The model is tested on a suite of language tasks, including sentiment analysis, textual entailment, and sentence similarity.

Sentiment analysis is the process of determining the emotional tone or opinion expressed in a piece of text, typically categorizing it as positive, negative, or neutral.

Textual entailment is the task of determining whether a given piece of text (the hypothesis) can be inferred or logically follows from another piece of text (the premise).

Here's an example of textual entailment:

Premise: "The cat is on the mat."
Hypothesis: "There is a cat."

This is a positive textual entailment because the second sentence (hypothesis) can be inferred from the first sentence (premise).

Let's talk about shots

Some benchmark diagrams may have terms like "0-shot CoT" or "5-shot" all over. Let's clarify these by tackling CoT first.

Chain of Thought (CoT) is a technique used in language models where the model is encouraged to generate a series of intermediate reasoning steps before arriving at the final answer. It mimics how humans often solve complex problems by breaking them down into smaller, manageable steps.

Here's an example of a CoT question and response:

Question:
"Sarah has 7 apples. 
She gives 3 apples to her friend and then buys 5 more. 
How many apples does Sarah have now?"

Model's Response:

"Sarah starts with 7 apples."
"She gives 3 apples away, so she has 7 - 3 = 4 apples left."
"She buys 5 more apples, so now she has 4 + 5 = 9 apples."
Answer: "Sarah has 9 apples."

Shots are examples that demonstrate to the model the correct way to answer the problem. "5-shot" means five(5) examples and "0-shot" means no examples.

A high 0-shot score demonstrates that the model has a strong ability to generalize its knowledge to new tasks or questions it hasn't seen before.

On the other hand, a high 5-shot (or any number greater than 0) score shows that the model is good at learning from a few examples and applying that knowledge to similar tasks.

So, what's the key difference between "n-shot" and "n-shot CoT"?

n-shot asks for a direct answer without explicit reasoning.
n-shot CoT encourages the model to show its work and reasoning process.

Conclusion

Hopefully by understanding these benchmarks, you'll be better equipped to interpret the ever-evolving LLM landscape and make informed decisions about which models might be most suitable for your needs.

Sources

What is an LLM?

Claude 3 benchmarks

What is Chain of Thoughts?

LLM Benchmarks

An in-depth guide to LLM benchmarking

iOS: The System Architecture

Hodeem — Sun, 04 Aug 2024 13:13:44 +0000

Introduction

After covering Android's system architecture, I wanted to understand the architecture of its biggest rival, iOS. This article aims to analyze each layer of iOS's system architecture (above the hardware) in a digestible format. Let's begin.

Fun fact: iOS (for mobile devices) and OS X (now called MacOS) have similar architectures. The main difference is at the topmost layer because people interact with mobile devices and laptops differently.

Kernel & Device Drivers

The iOS kernel manages system resources, processes, memory, security, and device interactions. It acts as an intermediary between hardware and software. If you've interacted with Apple products or services you may have heard the terms 'Mach' or 'Darwin'. This layer is where both of these components reside.

Mach

Note: Apple documentation uses the term 'Kernel' somewhat differently than you might expect.

Mach is a microkernel which manages processor resources such as CPU usage and memory, handles scheduling, provides memory protection, and offers other services to the rest of the operating-system layers. In the kernel architecture, Mach (the microkernel) is one of the components of the kernel.

Darwin

The kernel, along with other core parts of the operating system, is collectively referred to as Darwin. Darwin is based on BSD and includes Mach and other components.

Device drivers complement the kernel by translating between hardware devices and the OS. They provide hardware abstraction, handle I/O operations etc.

Core OS

This layer abstracts many of the complexities of the kernel, providing a more accessible interface for higher-level software. These services are typically used for tasks that require direct interaction with system resources or low-level operations, but are not directly exposed to applications. Some components at this layer are OpenCL and System Configuration.

Core Services

Core Services often build upon the functionality provided by Core OS to offer more complex and application-specific features. Core Services provide essential services to apps but have no direct bearing on the app’s user interface. Some components at this layer include the Accounts framework, Social framework and MapKit.

Media Layer

The Media layer handles all the audio, video, graphics, and animation services required by applications. Components like Core graphics, Core audio and OpenGL are found at this layer.

Cocoa application layer

This layer is primarily responsible for the appearance of apps and their responsiveness to user actions. It provides the frameworks needed to build user interfaces and interact with device features. Here is where most developers will spend the majority of their time. Some components at this layer include UIKit, HealthKit and HomeKit.

Conclusion

We can see that there are some similarities between iOS's architecture and that of Android. Each layer of the iOS architecture plays a vital role in delivering the experience that users have come to expect from Apple devices. Hopefully, this post clarified the role of each layer and helped you to get a better understanding of how everything fits together.

Sources:

Core OS

OS X Kernel Architecture Overview

Mac world

iOS

Android: Version types

Hodeem — Sun, 28 Jul 2024 20:46:39 +0000

In Android, you'll encounter various version numbers and terms that can seem confusing at first. This post aims to clarify the different types of versions in the Android ecosystem, helping you understand their purposes and relationships.

The version types I want to address are:

OS version
API level
minSdkVersion
compileSdkVersion
targetSdkVersion

OS Version

The Android OS version refers to the release version of the Android operating system. These versions are typically named after desserts and are associated with a version number. For example, Android 8.0 had the nickname Oreo, the tastiest snack in the western hemisphere. As of writing, the latest stable release is Android 14, with Android 15 in development.

API Level

The API level is an integer value that uniquely identifies the version of the Android framework API offered by a version of the Android OS.
Each Android OS version is associated with one or more API levels.
For example, Android 8.0 corresponds to API level 26 - 27.
This is one reason why the API level is used in minSdkVersion, compileSdkVersion, targetSdkVersion and other settings instead of the OS version.

minSdkVersion

The minSdkVersion is a value set in your app's build configuration that specifies the minimum API level required to run your application. It ensures that your app isn't installed on devices running an older, unsupported Android version. For example, if you set minSdkVersion to 26, your app will only be available to devices running Android 8.0 (Oreo) or higher.

It's recommended to choose the lowest API level that your app can support while still providing a good user experience. Consider factors like the features you need and the percentage of devices running each Android version. Setting it too high will limit your app's reach, while setting it too low might prevent you from using newer features.

compileSdkVersion

The compileSdkVersion is the version of Android that your app is compiled against. For example, if you set compileSdkVersion to 26, you can use APIs up to, and including, those in Android 8.0 in your code.

It's generally recommended to always compile with the latest stable SDK version to ensure you have access to the newest APIs.

targetSdkVersion

The targetSdkVersion indicates the highest API level on which you've tested your application. It tells the system that you've tested your app on this version, allowing the system to enable compatibility behaviours for higher API levels.

It's recommended to keep your targetSdkVersion as high as possible to ensure your app can take advantage of the latest Android features and optimizations.

Also, Google has a target API level requirement which indicates the minimum acceptable targetSdkVersion for apps that can be submitted to the Play Store.

Conclusion

Writing this post made me hungry, but it was worth it. I hope these versions are much easier to understand now.

Sources

Android version history
Target API level requirements for Google Play apps
uses-sdk-element

Android: The System Architecture

Hodeem — Sun, 21 Jul 2024 15:49:33 +0000

Introduction

After working with React Native, I was curious about how the Android system worked. This guide aims to demystify the Android system architecture.

The Android system is a layered architecture, with each layer building upon the capabilities of the layers below it. Let's examine each layer in detail.

Hardware

At the foundation of the Android system lies the physical hardware - the tangible components that form the device's infrastructure. This includes the Central Processing Unit (CPU), Graphics Processing Unit (GPU), Random Access Memory (RAM) etc.

Kernel

The kernel serves as the core of the Android operating system, acting as an intermediary between the hardware and higher-level software components. Some of its major responsibilities include process management, memory management and device driver management.
The kernel also provides essential drivers for hardware components such as the camera, keypad, display and Wi-Fi.

Native Daemons & Libraries

Native daemons, written in C and C++, are long-running processes that operate in the background on system startup. They primarily interact with the kernel and are responsible for handling critical system tasks. An example of a native daemon is init which is responsible for initializing the Android system.

Native libraries, also written in C and C++, provide core functionalities to both the Android system and third-party apps. An example of a native library is libc (the C library), which provides basic C library functions for memory management, string manipulation, and file I/O.

Hardware Abstraction Layer (HAL)

The HAL sits above the kernel, allowing Android to be hardware-agnostic. This abstraction enables a consistent API regardless of the underlying hardware, facilitating improved compatibility across diverse Android devices.

Examples of HAL implementations include Bluetooth HAL and Camera HAL.

Android Runtime

Android Rutnime (ART) is responsible for executing and managing applications written in Java. It translates bytecode (compiled code from developers) into machine code that the device's processor can understand.

System Services

Android System Services are fundamental components that manage various aspects of the Android environment. They operate in the background, ensuring smooth system operation and providing essential functionalities to applications. Examples include the
ActivityManagerService, the WindowManagerService and the PowerManagerService.

Android Framework

The Android Framework sits at the top. It provides high-level services to applications in the form of Java classes, interfaces and precompiled code, thereby abstracting complexity of the underlying systems. Some of the major components include the Activity Manager, the Window Manager and Content Providers.

Some of the framework is available through the use of the Android API, and other portions of the framework can only be accessed by the System API.

Android API and System APIs

The Android API, sometimes referred to as the framework API, is the public interface that app developers use to interact with the Android system. It includes functionalities for tasks such as UI creation, data storage, and hardware interaction.

System APIs, on the other hand, are interfaces intended for use by the Android system and privileged apps. They provide access to lower-level functionalities and are not available to third-party applications for security reasons.

Applications

At the very top of the stack are the applications themselves, both system apps and user-installed apps. These utilize the APIs provided by the Android Framework to interact with the underlying system.

Special mention: Binder IPC Proxies

The Binder Inter-Process Communication (IPC) mechanism facilitates efficient and secure communication between different processes and components within the Android system. It enables interaction between applications and system services.

For example, when an app requests location data, it communicates with the LocationManagerService via Binder IPC. The service processes the request and returns the location data back to the app, all mediated by the Binder mechanism.

Conclusion

Android's layered architecture is pretty fascinating when you dive into it. From the hardware all the way up to the apps we use daily, each component plays its part. Hopefully, this post made it easier to understand what's going on behind the scenes.

Sources

https://source.android.com/docs/core/architecture
https://developer.android.com/guide/platform#system-services
https://developer.android.com/guide/topics/manifest/uses-sdk-element#ApiLevels

Android: Skins vs Launchers

Hodeem — Thu, 18 Jan 2024 17:32:03 +0000

Introduction

If you're like me, the first time you heard about skins and launchers, you were curious to learn the difference between the two. However, I found that many sources didn't explain what they were and the difference between them clearly. So, I decided to do some research and take a swing at it.

What are skins?

In the world of Android, you have multiple manufacturers that like to add their own flavour to the stock operating system, often referred to as "Stock Android".

Skins are UI-focused updates made by the manufacturers to the device's operating system, which is based on Stock Android. I say UI-focused because skins can include changes to things other than the UI.

For example, Samsung's One UI has camera modes like "Single Take" that are not available on Stock Android.

However, the UI changes are often the most noticeable aspect of a skin.

What are launchers?

Launchers are third-party applications that also provide UI enhancements and additional functionalities. Given that they are third-party applications, you can download them from the Google Play Store just like Instagram and TikTok.

What don't skins do?

Skins don't:

Restrict access to the core features of the Stock Android OS. This means that you'll still have access to basic features like the Google Play Store, Android core apps, making calls, texting, and browsing the web.
Directly update the Android version on the device.

What don't launchers do?

Launchers don't:

Update the Android version on the device.
Alter the device's firmware.
Provide security updates or patches.

What are some popular skins?

Samsung's One UI: Available on Samsung Galaxy devices.
Pixel UI: Found on Google Pixel phones.
MIUI: Used on Xiaomi and Redmi phones.

What are some popular launchers?

Some of the most popular launchers include:

Nova Launcher: Consistently rated one of the best and most powerful launchers, offering extensive customization options and features.
Niagara Launcher: A minimalist launcher focusing on one-handed usability and information density.
Hyperion Launcher: A free and open-source launcher with a clean and customizable interface.

Conclusion

In the world of Android, customization reigns supreme. Skins and Launchers are two of the most popular ways that manufacturers and end users customize their devices and their Android experience. They are similar in some ways, but different in others and I hope it's clearer now. If this was helpful and if you want to support me, feel free to buy me a coffee.

If you want to see more launchers, you can visit here

How to test the Hidden API (from Material UI)

Hodeem — Wed, 14 Jun 2023 23:06:53 +0000

If you want to hide or display the element tree nested inside <Hidden> tags for a jest test, here's how it can be done.

Getting started

Let's say that we're testing if "Hey" is rendered correctly:

describe("Testing Hidden API", () => {

    render(
        <Hidden xsDown>
            <p>Hey</p>
        </Hidden>
    );

    it("'Hey' is visible",() => {
        expect(screen.getByText("Hey")).toBeVisible();
    }
}

Note: The render method is imported from @testing-library/react

If we want 'Hey' to be visible, we need the xsDown property of the <Hidden> component to evaluate to false when the test runs.

From Material UI's breakpoint documentation, we can see that we need to simulate the window's innerWidth being a value greater than or equal to 600px.

Making it work

While you may think that only changing the window's dimensions in the manner below is sufficient, this will not produce the desired result:

window.innerWidth = 600;
window.dispatchEvent(new Event("resize"));

The key is to mock the window's matchMedia() method.

describe("Testing Hidden API", () => {

    beforeEach(() => {
        Object.defineProperty(window, "matchMedia", {
            writable: true,
            value: jest.fn().mockImplementation(query => ({
                matches: !(query === "(max-width: 599px)"),
                addListener: jest.fn(),
                removeListener: jest.fn()
            }))
        });

        render(
            <Hidden xsDown>
                <p>Hey</p>
            </Hidden>
        );
    });

    it("Hey is visible",() => {
        expect(screen.getByText("Hey")).toBeVisible();
    }
}

Why does this work?

When the <Hidden> component is rendered, it calls the matchMedia function with the corresponding media query for each specified breakpoint . For example, for xsDown, it would use the media query (max-width: 599px).

PS: This is why it wasn't necessary to include the previous logic (window.innerWidth = 600; ...) to make this test work. However, depending on your test you may need to change your dimensions in such a manner.

The matchMedia function returns a MediaQueryList object, which represents the result of the media query evaluation. The matches property of this object indicates whether the media query condition evaluates to true or false.

The Hidden component listens for changes in the matches property of the MediaQueryList objects for each breakpoint.

Whenever the matches property changes (i.e., when the viewport size or browser window is resized), the Hidden component updates its state based on the new visibility status for each breakpoint.

So, by returning false for the matches property in the mock implementation we make the children of the <Hidden> component visible. If we wanted to hide the children of the <Hidden> component then we would return true for the matches property.

If you liked this article, then please support me

Tidbit: com.android.ide.common.signing.KeytoolException: Failed to read key from store "C:\..\.keystore"

Hodeem — Mon, 02 Jan 2023 17:14:33 +0000

When attempting to create the release bundle for a React Native app, I followed the steps in the (guide)[https://reactnative.dev/docs/signed-apk-android] and generated the keystore. However, when I ran this command to create the release AAB:

cd android
./gradlew bundleRelease

I encountered an error message with the following syntax:

* What went wrong:
Execution failed for task ':app:packageRelease'.
> A failure occurred while executing com.android.build.gradle.tasks.PackageAndroidArtifact$IncrementalSplitterRunnable
   > com.android.ide.common.signing.KeytoolException: Failed to read key <alias> from store "C:\Users\...\<keystore-name>.keystore": Get Key failed: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.

Given that there was no instruction from the CLI to create a key password, this might be a bit confusing.
The solution is to use the keystore password in the key password field in your build.gradle file. For example,

MYAPP_UPLOAD_STORE_FILE=my-upload-key.keystore
MYAPP_UPLOAD_KEY_ALIAS=my-key-alias
MYAPP_UPLOAD_STORE_PASSWORD=<keystore-password>
MYAPP_UPLOAD_KEY_PASSWORD=<keystore-password>

The reason why this works is that different store and key passwords are not supported for PKCS12 keystores.

If you liked this article, then please support me

How to test third-party React Native components using React Native Testing Library

Hodeem — Fri, 15 Jul 2022 22:48:10 +0000

Testing third-party React Native components using Jest and React Native Testing Library can be really frustrating. I remember tryin every event I saw in the docs to no avail. press, click, scroll, the whole nine yards.

However, through ~~blood, sweat and tears~~ trial and error I managed to figure out a general approach that works and I wanted to share it to save others the stress.

I'm going to illustrate the approach by demonstrating simple tests on a component from the react-native-picker-select package.

Locating the component in the tree

The first step for most tests is to locate the component(s) that will be involved. The problem is that not every third-party component provides the option to directly set a prop such as testID, so I had to get creative.

We start by wrapping the component within a pair of <View> tags and setting a prop on the parent <View>, such as testID. Afterwards, we can locate the component by accessing the <View>'s children. Here's some sample code to demonstrate:

//CustomPickerSelect.jsx

import React from 'react';
import { View } from 'react-native';
import RNPickerSelect from 'react-native-picker-select';

const CustomPickerSelect = () => {

    return (
        <View testID='picker-select-parent'>
            <RNPickerSelect
                onValueChange={() => { }}
                items={[]}
            />
        </View>
    )
}

export default CustomPickerSelect;

//CustomPickerSelect.test.js

import { render } from '@testing-library/react-native';
import CustomPickerSelect from './CustomPickerSelect';

test('Testing CustomPickerSelect', () => {
  const { getByTestId } = render(<CustomPickerSelect />)

  const picker = getByTestId("picker-select-parent").children[0];
})

picker is the ReactTestInstance that represents the third-party component RNPickerSelect in the rendered tree.

Firing events

For third-party components, the names of the events (or event handlers) which elicit a response are usually listed in their props. The props are usually available in the documentation, but this is not always the case. The documentation may also be outdated, so it helps to see for yourself which props are available by logging the .props property of the ReactTestInstance. Let's do this now:

import { render } from '@testing-library/react-native';
import CustomPickerSelect from './CustomPickerSelect';


test('Testing CustomPickerSelect', () => {
  const { getByTestId } = render(<CustomPickerSelect />)

  const picker = getByTestId("picker-select-parent").children[0];
  console.log("picker props: ", picker.props)
})

Here's a screenshot of the log:

Let's take a brief detour to discuss the main tool that we'll be using: fireEvent. The fireEvent method provided by React Native Testing Library has the following syntax:

fireEvent(element: ReactTestInstance, eventName: string, ...data: Array<any>): void

If the meaning of the data parameter is unclear to you, it actually represents the argument(s) that will be passed to the event handler that is being invoked.

The challenge is determining the right value to use for the eventName argument. This is where we reference the props for the ReactTestInstance that were logged earlier. The event handlers are usually prefixed by "on-", for example onPress.

Here are the event handlers for our ReactTestInstance:

Let's make a few additions to the CustomPickerSelect.jsx component to facilitate the testing of the onValueChange event handler:

import React, { useState } from 'react';
import { View } from 'react-native';
import RNPickerSelect from 'react-native-picker-select';

const CustomPickerSelect = () => {

    const [value, setValue] = useState("")

    return (
        <View testID='picker-select-parent'>
            <RNPickerSelect
                value={value}
                onValueChange={(newValue) => { setValue(newValue) }}
                items={[]}
            />
        </View>
    )
}

export default CustomPickerSelect;

Now let's invoke the onValueChange event handler and check to make sure that everything works as expected:

import { render, fireEvent } from '@testing-library/react-native';
import CustomPickerSelect from './CustomPickerSelect';


test('Testing CustomPickerSelect', () => {
    const { getByTestId } = render(<CustomPickerSelect />)

    const picker = getByTestId("picker-select-parent").children[0];
    fireEvent(picker, 'onValueChange', "A");
    expect(picker.props.value).toBe("A");
})

It's generally not encouraged to assert on implementation details, but it can't hurt to know how to do this ;).

If you want to conduct other tests, you can make the necessary changes. For example, here's some code to test if a callback function passed in as a prop to the CustomPickerSelect component is invoked:

import React, { useState } from 'react';
import { View } from 'react-native';
import RNPickerSelect from 'react-native-picker-select';

const CustomPickerSelect = ({ setValueCallback }) => {

    const [value, setValue] = useState("")

    return (
        <View testID='picker-select-parent'>
            <RNPickerSelect
                value={value}
                onValueChange={(newValue) => { 
                    setValue(newValue);
                    setValueCallback(newValue);
                }}
                items={[]}
            />
        </View>
    )
}

export default CustomPickerSelect;

import { render, fireEvent } from '@testing-library/react-native';
import CustomPickerSelect from './CustomPickerSelect';


test('Testing CustomPickerSelect', () => {

  const mockCallback = jest.fn();

  const { getByTestId } = render(
    <CustomPickerSelect 
       setValueCallback={mockCallback} 
    />
  )

  const picker = getByTestId("picker-select-parent").children[0];
    fireEvent(picker, 'onValueChange', "A");
    expect(mockCallback).toHaveBeenCalled();
})

That's it for now. Thanks for reading and share this with a friend if this helped.

If you liked this article, then please support me

Sources

https://www.npmjs.com/package/react-native-picker-select

https://callstack.github.io/react-native-testing-library/docs/api#fireevent

What's hindering React Native now?

Hodeem — Wed, 13 Jul 2022 12:46:00 +0000

I really like developing mobile applications with React Native, but I wasn't seeing much evidence of widespread adoption. This made me wonder, "Why isn't React Native more popular?"

This question led me to research the main obstacles to React Native's widespread adoption. After reviewing a few articles, I noticed a few common themes among complaints by both developers and teams.

Please note that the following list of themes is based on articles written between 2017 and 2018. Also, this list is not meant to be an exhaustive list of React Native's shortcomings.

What are common concerns about using React Native?

Knowledge of 3 platforms is sometimes required to implement custom features.
Heavy investment in bridging infrastructure may be necessary to implement custom features.
The animations and gestures tend to be non-performant.
Implementing in-app navigation isn't easy.
There tends to be a slow initialisation and first-render time.
There is a lack of parallel threading or multiprocessing support.
It can be difficult to debug errors because stack traces don't jump between React Native and native.
JavaScript is untyped.
React Native apps can have trouble rendering long lists performantly.
Android bundle size can be large.

If you've been developing with React Native recently you may have noticed that there have been major developments in more than one of these areas.

For example, Software Mansion has made significant contributions to animations and gesture-handling with their react-native-reanimated and react-native-gesture-handler packages.

More recently, Shopify have taken a stab at the issue of rendering long lists performantly by open-sourcing their flash-list package.

The questions I have for the broader mobile development community are:

Out of the 10 concerns highlighted above, how many do you believe are still valid?
What do you believe are the top technical reasons preventing teams or companies from adopting React Native for mobile app development today?

If you liked this article, then please support me

Sources

https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c

https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838

https://medium.com/airbnb-engineering/building-a-cross-platform-mobile-team-3e1837b40a88

https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a

https://www.simform.com/blog/react-native-limitations-app-development/

https://www.theregister.com/2020/01/30/shopify_shifts_its_mobile_development_to_react_native/