ReactJS

Setting Up React Navigation in Expo Web: A Practical Guide

Published Jun 5, 2023

Updated Mar 25, 2024

5 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Introduction

We have come a long way from the days where we had to write different code for different platforms. Today, we can write code once and run it anywhere using technologies like React Native.

React Native is a framework that allows us to write native apps for Android, iOS, and the web, using JavaScript and React. This makes it more interesting for teams that want to cut time/development cost to look into it.

We recently launched our Expo-Zustand-Styled Components showcase app here at This Dot Labs. We also showcased how we can use expo, zustand, and styled-components to build a React Native app that can run on Android, iOS, and the web all in one codebase.

In this article, we will be looking at React Navigation, how to configure Deep Linking to navigate to different screens, and handling dynamic routes paths in our app. We'll do this by looking at the challenges we had to deal with while working on our showcase app, especially when running the app on the web.

Getting started

Before we dive in, we need to install all the needed dependencies. Let's make sure we have the expo cli installed. We can do this by running the following command:

  npm i expo-cli

We can now Initialize a new Expo app. We can do this by running the following command:

    npx create-expo-app rn-web-routing

Next, we need to install the navigation package, and since we are also building this app for the web, we need to install the needed dependencies.

    npx expo install @react-navigation/native @react-navigation/native-stack react-dom react-native-web @expo/webpack-config

You can also leverage our expo-zustand-styled-component starter kit, which offers all configurations to build for IOS, Android, and the web.

Let's set up our navigation routes. We will use native-stack for our navigation. We can do this by creating a navigation folder in our src folder, and creating an index.ts file in it. This will contain our root navigator.

import { createNativeStackNavigator } from "@react-navigation/native-stack";
import React from "react";
// import screens

const Stack = createNativeStackNavigator();

const Routes = () => {
  return <Stack.Navigator>{/** screens stack */}</Stack.Navigator>;
};

export default Routes;

We can now import our Routes component in our App.tsx file and render it.

    import React from 'react';
    import Routes from './navigation';

    export default function App() {
        return (
        {/** ... other config eg provider */}
        <Routes />
        {/** ... other config eg provider  */}
        );
    }

Creating our screens

We can now create our screens. We will create a screens folder in our src folder and a Home.tsx file in it which will contain our home screen.

import React from "react";
import { View, Text } from "react-native";

const Home = () => {
  return (
    <View>
      <Text>This is Home</Text>
    </View>
  );
};

export default Home;

We can now import our Home component in our Routes component, and add it to our stack.

import { createNativeStackNavigator } from "@react-navigation/native-stack";
import React from "react";
import Home from "../screens/Home";

const Stack = createNativeStackNavigator();

const Routes = () => {
  return (
    <Stack.Navigator>
      <Stack.Screen name="Home" component={Home} options={{ title: "Home" }} />
    </Stack.Navigator>
  );
};

export default Routes;

We can now do the same for the other screens we want to add to our stack.

Deep linking

During the development of the expo showcase kit, we faced an issue on the web. When we navigate to a page, the URL in the browser still remains in the index. This is because we have not configured deep linking.

Deep Linking is a way to navigate to different screens in our app using a custom URL link. This is very useful when we want to have individual URLs for each of our pages. This is also useful when we want to share a link to a specific screen in our app, saving the user time and energy in locating a particular page themselves.

We can do this by creating a config file in our navigation folder with the following code.

import { NavigationContainer } from "@react-navigation/native";
import * as Linking from "expo-linking";

const linking = {
  prefixes: [Linking.createURL("/")], // this is the prefix for our app. Could be anything eg https://myapp.com
  config: {
    screens: {
      Home: "",
      //  ... other screens
    },
  },
};

export default linking;

And then we can import our linking config in our App.tsx file and pass it to the NavigationContainer.

    export default function App() {
        return (
        {/** ... other config eg provider */}
        <NavigationContainer linking={linking}>
            <Routes />
        </NavigationContainer>
        {/** ... other config eg provider  */}
        );
    }

We will come back to this config file later as we are going to deep dive into more complex routing, and how to handle it. Let's run our app now, and see how it works.

Running the app

Now, we can run our app. We can do this by running the following command:

    expo start

Press w to open it on a web browser, you should see something like this:

We can see we are in our index page which is the home page, we can now navigate to the eg Profile page by clicking the button on the home page. To have your preferred page url path, we need to update the linking config with the appropriate page URL. Otherwise, deep linking will use the screen name as the page URL.

Handling dynamic routes

Say you want to have a page that can be accessed by different users. You can do this by passing the user id as a parameter in the URL. This is called dynamic routing. We can do this by updating our linking config file with the following code.

import { NavigationContainer } from "@react-navigation/native";
import * as Linking from "expo-linking";

const linking = {
  prefixes: [Linking.createURL("/")],
  config: {
    screens: {
      Home: "",
      Profile: "profile/:id",
      //  ... other screens
    },
  },
};

export default linking;

This will allow us to access the Profile page by passing the user id as a parameter in the URL. We can now update our Profile page to get the user id from the URL and display it.

import React from "react";
import { View, Text } from "react-native";
import { useRoute } from "@react-navigation/native";

const Profile = () => {
  const route = useRoute();
  const { id } = route.params;
  return (
    <View>
      <Text>This is Profile</Text>
      <Text>User id: {id}</Text>
    </View>
  );
};

export default Profile;

During the development of our showcase app, we were faced with an issue. We needed to replicate a route /tree/main/a/b/c with a pattern as /tree/:branch/:path*, where the path is a/b/cjust like we have in other showcases.

import { NavigationContainer } from "@react-navigation/native";
import * as Linking from "expo-linking";

const linking = {
  prefixes: [Linking.createURL("/")],
  config: {
    screens: {
      Home: "",
      Profile: "profile/:id",
      Tree: "tree/:branch/:path*",
      //  ... other screens
    },
  },
};

export default linking;

This didn't work as expected. But on further investigation, we found out that we have to manually handle this route in the getStateFromPath of the linking configuration file, by updating the state and returning it.

import { getStateFromPath } from "react-native";
import { NavigationContainer } from "@react-navigation/native";
import * as Linking from "expo-linking";

const linking = {
  prefixes: [Linking.createURL("/")],
  config: {
    screens: {
      Home: "",
      Profile: "profile/:id",
      Tree: "tree/:branch/:path",
      //  ... other screens
    },
  },
  getStateFromPath(path, options) {
    let state = getStateFromPath(path, options);

    // If the state is undefined, it means that the path doesn't match any route in our config, and
    // we want to handle the path ourselves to the right screen, by updating the state and returning it.
    if (!state) {
      // check if route contains the main identifier of the screen we want to show
      const isTree = path.includes("tree");
      if (isTree) {
        const [, , branch, ...rest] = path.split("/");

        state = {
          routes: [
            {
              path,
              name: "Tree",
              params: {
                branch,
                path: rest.join("/"), // here, our path is the rest of the path after the branch
              },
            },
          ],
        };
      }
    }
    return state;
  },
};

export default linking;

With these configurations, we can now navigate throughout our app using the Link component from react-navigation/native.

import React from "react";
import { View, Text } from "react-native";
import { Link } from "@react-navigation/native";

const Home = () => {
  return (
    <View style={styles.container}>
      <Text>This is Home</Text>
      <View style={styles.button}>
        <Link to="profile">
          <Button title="Go to Profile" />
        </Link>
      </View>
      <View style={styles.button}>
        <Link to="tree/d1/d2/d3">
          <Button title="Go to Tree" />
        </Link>
      </View>
    </View>
  );
};

To make use of the path parameter in our Tree page:

import React from "react";
import { View, Text } from "react-native";

const Tree = ({ route }) => {
  const { branch, path } = route.params;
  return (
    <View>
      <Text>This is Tree</Text>
      <Text>Branch: {branch}</Text>
      <Text>Path: {path}</Text>
    </View>
  );
};

export default Tree;

Conclusion

In this article, we have seen how to set up our navigation in our expo app using react-navigation/native. We have also seen how to configure deep linking, which will help us to navigate through our app using the URL path. Next, we've learned how to handle dynamic routes, which will help us pass parameters in the URL path, and handle some special cases like the one we had with the Tree page.

If you have any questions or run into any trouble, feel free to join the discussions going on at starter.dev or on our Discord.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Chinedu Okpala
@allstackDev @allStackDev1

Why is My React Reducer Called Twice and What the Heck is a Pure Function?

Why is My React Reducer Called Twice and What the Heck is a Pure Function? In a recent project, we encountered an interesting issue: our React reducer was dispatching twice, producing incorrect values, such as incrementing a number in increments of two. We hopped on a pairing session and started debugging. Eventually, we got to the root of the problem and learned the importance of pure functions in functional programming. This article will explain why our reducer was being dispatched twice, what pure functions are, and how React's strict mode helped us identify a bug in our code. The Issue We noticed that our useReducer hook was causing the reducer function to be called twice for every action dispatched. Initially, we were confused about this behavior and thought it might be a bug in React. Additionally, we had one of the dispatches inside a useEffect, which caused it to be called twice due to React strict mode, effectively firing the reducer four times and further complicating our debugging process. However, we knew that React's strict mode caused useEffect to be called twice, so it didn't take very long to realize that the issue was not with React but with how we had implemented our reducer function. React Strict Mode React's strict mode is a tool for highlighting potential problems in an application. It intentionally double-invokes specific lifecycle methods and hooks (like useReducer and useEffect) to help developers identify side effects. This behavior exposed our issue, as we had reducers that were not pure functions. What is a Pure Function? A pure function is a function that: - Is deterministic: Given the same input, always returns the same output. - Does Not Have Side Effects: Does not alter any external state or have observable interactions with the outside world. In the context of a reducer, this means the function should not: - Modify its arguments - Perform any I/O operations (like network requests or logging) - Generate random numbers - Depend on any external state Pure functions are predictable and testable. They help prevent bugs and make code easier to reason about. In the context of React, pure functions are essential for reducers because they ensure that the state transitions are predictable and consistent. The Root Cause: Impure Reducers Our reducers were not pure functions. They were altering external state and had side effects, which caused inconsistent behavior when React's strict mode double-invoked them. This led to unexpected results and made debugging more difficult. The Solution: Make Reducers Pure To resolve this issue, we refactored our reducers to ensure they were pure functions. Here's an extended example of how we transformed an impure reducer into a pure one in a more complex scenario involving a task management application. Let's start with the initial state and action types: ` And here's the impure reducer similar to what we had initially: ` This reducer is impure because it directly modifies the state object, which is a side effect. To make it pure, we must create a new state object for every action and return it without modifying the original state. Here's the refactored pure reducer: ` Key Changes: - Direct State Modification: In the impure reducer, the state is directly modified (e.g., state.tasks.push(action.payload)). This causes side effects and violates the principles of pure functions. - Side Effects: The impure reducer included side effects such as logging and direct state changes. The pure reducer eliminates these side effects, ensuring consistent and predictable behavior. I've created an interactive example to demonstrate the difference between impure and pure reducers in a React application. Despite the RESET_TASKS action being implemented similarly in both reducers, you'll notice that the impure reducer does not reset the tasks correctly. This problem happens because the impure reducer directly modifies the state, leading to unexpected behavior. Check out the embedded StackBlitz example below: Conclusion Our experience with the reducer dispatching twice was a valuable lesson in the importance of pure functions in React. Thanks to React's strict mode, we identified and fixed impure reducers, leading to more predictable and maintainable code. If you encounter similar issues, ensure your reducers are pure functions and leverage React strict mode to catch potential problems early in development. By embracing functional programming principles, you can write cleaner, more reliable code that is easier to debug and maintain....

Jun 14, 2024

3 mins

React

Improving INP in React and Next.js

Improving INP in React and Next.js In one of my previous articles, I've explained what INP is, how it works, and how it may affect your website. I also promised you to follow up with more concrete advice on how to improve your INP in your favorite framework. This is the follow-up article, where I'll focus on how to improve your INP score in React and Next.js. How to prepare for INP in React and Next.js? The first thing to do is to ensure you're using the latest version of React. The React team has been working on making React more INP-friendly and has already made some improvements in the latest versions. To enhance your INP score, consider fully taking advantage of new features introduced in React 18, such as Concurrent Rendering, Automatic Batching, and Selective Hydration. However, there are also some general areas to focus on, such as SSR and SSG in Next.js, Web Workers, or optimizing your hooks and state management. Concurrent Rendering The Concurrent Mode in React uses an algorithm that breaks rendering down into so-called "fiber nodes" and schedules the renders based on their expiration and priority. This effectively allows the user to interact with the page while the rendering is still in progress. In previous React versions, all updates, such as setState calls were treated as "urgent" and once the re-render had started, there was no way to interrupt it. Concurrent Mode changes this by being able to prioritize the updates and interrupt a non-blocking state update started with startTransition. For a simple explanation of concurrency in React, you can check out Dan Abramov's explanation. As part of the Concurrent Mode, React introduced several lifecycle methods that allow you to prioritize the rendering of certain parts of your UI, such as: - useTransition hook that allows you to update the state without blocking the UI, - useDeferredValue hook that allows you to defer the rendering of certain parts of your UI, - startTransition API that, similarly to the useTransition hook lets you mark a state update as non-blocking. It lacks, however, an indication of whether it's still pending. Automatic Batching Introduced in React 18, Automatic Batching reduces the number of re-renders that happen on state changes even when they happen outside of event handlers, e.g. in a setTimeout or Promise callback. This feature comes out of the box and you don't have to do anything to enable it, and it makes a great argument for upgrading to React 18. Selective Hydration Selective Hydration allows you to take hydration off the main thread by wrapping your components in a Suspense boundary. This way, components can become interactive faster as the browser can do other work on the main thread while the hydration is happening. To fully take advantage of selective hydration, consider the following: - Prioritizing Above-the-Fold Content: Use Suspense boundaries strategically around any parts of your application that may take the server longer to deliver to ensure they don’t block critical content from becoming interactive as soon as possible. - Hydration on Interaction: Implementing hydration upon user interaction for non-critical components can drastically reduce the main thread's workload, enhancing INP. Vercel even has a small case study showing how using selective hydration improved the performance of a Next.js site. Server-Side Rendering (SSR) and Static Site Generation (SSG) in Next.js Not everything has to run client-side. Next.js excels in SSR and SSG capabilities, which can significantly impact INP by delivering content to users faster. Optimizing SSR with techniques like incremental static regeneration (ISR) or leveraging SSG for static pages ensures that users can interact with content faster, improving the perceived performance. Workers Offloading heavy computations to Web Workers can free up the main thread, enhancing the responsiveness of React and Next.js applications. This strategy is especially useful when dealing with third-party scripts. Offloading such scripts in Next.js can be easily done by specifying the "worker" strategy on your Script component. Be aware that this feature is not yet stable and does not work with the app directory, though. If you want to take things one step further, you could use Partytown, which helps you offload any resource-intensive scripts to Web Workers. It comes with a React component that you can use to wrap your third-party scripts and offload them to a Web Worker, and it's compatible with Next.js as well. Hooks and State Management State management in React applications can easily get out of hand, leading to unnecessary re-renders and effectively an increased INP. Sometimes, using a state management library like Redux or MobX can help you consolidate your state and reduce the number of re-renders. However, they are not silver bullets and can also introduce performance issues if not used properly. If you are dealing with a lot of re-renders due to prop changes, make sure you are leveraging memoization. As of now, you may need to work with useMemo and useCallback hooks to memoize your values and functions, respectively. The upcoming React 19’s Forget Compiler, however, will apparently memoize everything under the hood, making these hooks obsolete. Using memoization properly can help you reduce the number of re-renders and improve your INP. To investigate your hook dependencies and re-renders, you can leverage React Developer Tools or use this handy helper hook I found on the internet to trace your re-renders: ` Conclusion Improving INP in React and Next.js is not easy and can require much investigation and fine-tuning. Still, it's worth doing to avoid being penalized by Google in its search results and provide a better experience for your users. Adopting React 18's new features, leveraging SSR and SSG in Next.js, utilizing Web Workers, and optimizing hooks and state management can significantly boost your INP score and deliver a faster application to your users. Remember, INP is just one among many performance metrics emphasizing the need for a comprehensive approach to performance optimization...

Apr 19, 2024

5 mins

Web PerformanceReactNextJSJavaScript

Using React In Your Qwik Application

Introduction React, developed by Meta, is a JavaScript library for building user interfaces, and it is one of the most used UI JavaScript libraries in the world. React will be turning a decade old by May 2023. It has gained a lot of popularity over the years, and its latest version, React 18, was released in March 2022. Qwik is a new JavaScript framework by Misko Hevery, creator of Angular, for building frontend browser applications. The major benefit of Qwik is its performance optimization, which features resumability and lazy loading. As it stands now, there are virtually no Qwik third-party packages or libraries that currently exist, but luckily the Qwik team factored this in, making it easy for developers to easily integrate React libraries or your old React components into your Qwik project without too much difficulty. In this article, I will show you how to easily integrate React libraries or components into your Qwik project. Project Set Up To get started, we need to create a new Qwik app. We can do this by running the following command in our terminal: ` You can also get additional tools and configurations using our starter.dev kit by running the command in your terminal: ` You will be prompted to enter the name of your project (let’s call it qwik-react), choose the default option when asked to select a starter, and then install npm dependencies. Now we have our Qwik application ready to go. Let’s start the development server and see what it looks like; ` Now that our app is up and running we will see how we can integrate a React package and component into our Qwik project. Integrating React in Qwik Like most JavaScript frontend libraries or frameworks, React makes use of hydration, which has its drawbacks and might be more expensive than you think. Qwik needs no hydration on load. It’s just pure HTML. This makes Qwik qwiker to load UIs, with which users can start interacting. You should keep this in mind when considering to include React components in your Qwik applications. QwikReact is a tool that allows you to use React components in Qwik, including the whole ecosystem of component libraries such as Material UI, Threejs and React Spring. To get started, we need to run this command inside our Qwik app: ` This will install needed dependencies such as qwik-react, react, and react-dom. It will also add emotion and mui, which you can uninstall if you don’t intend to use them. If we check our project, we should now have some new folders generated. The most important is the src/integrations/react. This is where all our React components will be implemented or React packages will be used. Qwikify$ The qwikify$ function is exported from @builder.io/qwik-react, which converts React components into Qwik components that you can use across your application, and allows Qwik to implement partial hydration of React components. You cannot use React components in Qwik without converting them first to remove React’s hydration pattern, which is not supported in Qwik, using qwikify$(). Another important thing to remember is to make sure the file containing your React component has this; ` This needs to be imported at the top of the file as this serves as instructions to the compiler to use React as the JSX factory. This means you cannot mix your React components with a Qwik component. The code above is from the Qwik demo. You can see how the React components are wrapped with the qwikify$() function. If your React package requires some configuration, don’t try to pass it as a props. Instead, do every configuration right inside the file, ensuring only the dynamic data is passed through. The code above is from our Qwik GitHub showcase. Check out the full source code here. So once you are done with Qwikifying your React component, you can now import and use it just as you would normally do a Qwik component. Let’s run our application, and navigate to the React page at ` to view the default Qwik demo; ` Interactivity Qwik tries to reduce or completely remove hydrations, but React heavily depends on it. This means we have to find a way to hydrate our React Component without affecting the concept of Qwik. Qwik allows you to decide when to hydrate your components by using the client: JSX properties. This technique is commonly referred to as “partial hydration”. For more information on this checkout Adding Interactivity on Qwik Docs. Conclusion In this article, we saw how to convert React to a Qwik component. We also learned about the dos and don’ts of using React in Qwik, as well as how to handle hydration. I hope you enjoyed this article. Thank you for reading! If you have any questions or run into any trouble, feel free to join the discussions going on at starter.dev or on our Discord....

Nov 25, 2022

5 mins

Qwik

The Importance of a Scientific Mindset in Software Engineering: Part 2 (Debugging)

The Importance of a Scientific Mindset in Software Engineering: Part 2 (Debugging) In the first part of my series on the importance of a scientific mindset in software engineering, we explored how the principles of the scientific method can help us evaluate sources and make informed decisions. Now, we will focus on how these principles can help us tackle one of the most crucial and challenging tasks in software engineering: debugging. In software engineering, debugging is often viewed as an art - an intuitive skill honed through experience and trial and error. In a way, it is - the same as a GP, even a very evidence-based one, will likely diagnose most of their patients based on their experience and intuition and not research scientific literature every time; a software engineer will often rely on their experience and intuition to identify and fix common bugs. However, an internist faced with a complex case will likely not be able to rely on their intuition alone and must apply the scientific method to diagnose the patient. Similarly, a software engineer can benefit from using the scientific method to identify and fix the problem when faced with a complex bug. From that perspective, treating engineering challenges like scientific inquiries can transform the way we tackle problems. Rather than resorting to guesswork or gut feelings, we can apply the principles of the scientific method—forming hypotheses, designing controlled experiments, gathering and evaluating evidence—to identify and eliminate bugs systematically. This approach, sometimes referred to as "scientific debugging," reframes debugging from a haphazard process into a structured, disciplined practice. It encourages us to be skeptical, methodical, and transparent in our reasoning. For instance, as Andreas Zeller notes in the book _Why Programs Fail_, the key aspect of scientific debugging is its explicitness: Using the scientific method, you make your assumptions and reasoning explicit, allowing you to understand your assumptions and often reveals hidden clues that can lead to the root cause of the problem on hand. Note: If you'd like to read an excerpt from the book, you can find it on Embedded.com. Scientific Debugging At its core, scientific debugging applies the principles of the scientific method to the process of finding and fixing software defects. Rather than attempting random fixes or relying on intuition, it encourages engineers to move systematically, guided by data, hypotheses, and controlled experimentation. By adopting debugging as a rigorous inquiry, we can reduce guesswork, speed up the resolution process, and ensure that our fixes are based on solid evidence. Just as a scientist begins with a well-defined research question, a software engineer starts by identifying the specific symptom or error condition. For instance, if our users report inconsistencies in the data they see across different parts of the application, our research question could be: _"Under what conditions does the application display outdated or incorrect user data?"_ From there, we can follow a structured debugging process that mirrors the scientific method: - 1. Observe and Define the Problem: First, we need to clearly state the bug's symptoms and the environment in which it occurs. We should isolate whether the issue is deterministic or intermittent and identify any known triggers if possible. Such a structured definition serves as the groundwork for further investigation. - 2. Formulate a Hypothesis: A hypothesis in debugging is a testable explanation for the observed behavior. For instance, you might hypothesize: _"The data inconsistency occurs because a caching layer is serving stale data when certain user profiles are updated."_ The key is that this explanation must be falsifiable; if experiments don't support the hypothesis, it must be refined or discarded. - 3. Collect Evidence and Data: Evidence often includes logs, system metrics, error messages, and runtime traces. Similar to reviewing primary sources in academic research, treat your raw debugging data as crucial evidence. Evaluating these data points can reveal patterns. In our example, such patterns could be whether the bug correlates with specific caching mechanisms, increased memory usage, or database query latency. During this step, it's essential to approach data critically, just as you would analyze the quality and credibility of sources in a research literature review. Don't forget that even logs can be misleading, incomplete, or even incorrect, so cross-referencing multiple sources is key. - 4. Design and Run Experiments: Design minimal, controlled tests to confirm or refute your hypothesis. In our example, you may try disabling or shortening the cache's time-to-live (TTL) to see if more recent data is displayed correctly. By manipulating one variable at a time - such as cache invalidation intervals - you gain clearer insights into causation. Tools such as profilers, debuggers, or specialized test harnesses can help isolate factors and gather precise measurements. - 5. Analyze Results and Refine Hypotheses: If the experiment's outcome doesn't align with your hypothesis, treat it as a stepping stone, not a dead end. Adjust your explanation, form a new hypothesis, or consider additional variables (for example, whether certain API calls bypass caching). Each iteration should bring you closer to a better understanding of the bug's root cause. Remember, the goal is not to prove an initial guess right but to arrive at a verifiable explanation. - 6. Implement and Verify the Fix: Once you're confident in the identified cause, you can implement the fix. Verification doesn't stop at deployment - re-test under the same conditions and, if possible, beyond them. By confirming the fix in a controlled manner, you ensure that the solution is backed by evidence rather than wishful thinking. - Personally, I consider implementing end-to-end tests (e.g., with Playwright) that reproduce the bug and verify the fix to be a crucial part of this step. This both ensures that the bug doesn't reappear in the future due to changes in the codebase and avoids possible imprecisions of manual testing. Now, we can explore these steps in more detail, highlighting how the scientific method can guide us through the debugging process. Establishing Clear Debugging Questions (Formulating a Hypothesis) A hypothesis is a proposed explanation for a phenomenon that can be tested through experimentation. In a debugging context, that phenomenon is the bug or issue you're trying to resolve. Having a clear, falsifiable statement that you can prove or disprove ensures that you stay focused on the real problem rather than jumping haphazardly between possible causes. A properly formulated hypothesis lets you design precise experiments to evaluate whether your explanation holds true. To formulate a hypothesis effectively, you can follow these steps: 1. Clearly Identify the Symptom(s) Before forming any hypothesis, pin down the specific issue users are experiencing. For instance: - "Users intermittently see outdated profile information after updating their accounts." - "Some newly created user profiles don't reflect changes in certain parts of the application." Having a well-defined problem statement keeps your hypothesis focused on the actual issue. Just like a research question in science, the clarity of your symptom definition directly influences the quality of your hypothesis. 2. Draft a Tentative Explanation Next, convert your symptom into a statement that describes a _possible root cause_, such as: - "Data inconsistency occurs because the caching layer isn't invalidating or refreshing user data properly when profiles are updated." - "Stale data is displayed because the cache timeout is too long under certain load conditions." This step makes your assumption about the root cause explicit. As with the scientific method, your hypothesis should be something you can test and either confirm or refute with data or experimentation. 3. Ensure Falsifiability A valid hypothesis must be falsifiable - meaning it can be proven _wrong_. You'll struggle to design meaningful experiments if a hypothesis is too vague or broad. For example: - Not Falsifiable: "Occasionally, the application just shows weird data." - Falsifiable: "Users see stale data when the cache is not invalidated within 30 seconds of profile updates." Making your hypothesis specific enough to fail a test will pave the way for more precise debugging. 4. Align with Available Evidence Match your hypothesis to what you already know - logs, stack traces, metrics, and user reports. For example: - If logs reveal that cache invalidation events aren't firing, form a hypothesis explaining why those events fail or never occur. - If metrics show that data served from the cache is older than the configured TTL, hypothesize about how or why the TTL is being ignored. If your current explanation contradicts existing data, refine your hypothesis until it fits. 5. Plan for Controlled Tests Once you have a testable hypothesis, figure out how you'll attempt to _disprove_ it. This might involve: - Reproducing the environment: Set up a staging/local system that closely mimics production. For instance with the same cache layer configurations. - Varying one condition at a time: For example, only adjust cache invalidation policies or TTLs and then observe how data freshness changes. - Monitoring metrics: In our example, such monitoring would involve tracking user profile updates, cache hits/misses, and response times. These metrics should lead to confirming or rejecting your explanation. These plans become your blueprint for experiments in further debugging stages. Collecting and Evaluating Evidence After formulating a clear, testable hypothesis, the next crucial step is to gather data that can either support or refute it. This mirrors how scientists collect observations in a literature review or initial experiments. 1. Identify "Primary Sources" (Logs, Stack Traces, Code History): - Logs and Stack Traces: These are your direct pieces of evidence - treat them like raw experimental data. For instance, look closely at timestamps, caching-related events (e.g., invalidation triggers), and any error messages related to stale reads. - Code History: Look for related changes in your source control, e.g. using Git bisect. In our example, we would look for changes to caching mechanisms or references to cache libraries in commits, which could pinpoint when the inconsistency was introduced. Sometimes, reverting a commit that altered cache settings helps confirm whether the bug originated there. 2. Corroborate with "Secondary Sources" (Documentation, Q&A Forums): - Documentation: Check official docs for known behavior or configuration details that might differ from your assumptions. - Community Knowledge: Similar issues reported on GitHub or StackOverflow may reveal known pitfalls in a library you're using. 3. Assess Data Quality and Relevance: - Look for Patterns: For instance, does stale data appear only after certain update frequencies or at specific times of day? - Check Environmental Factors: For instance, does the bug happen only with particular deployment setups, container configurations, or memory constraints? - Watch Out for Biases: Avoid seeking only the data that confirms your hypothesis. Look for contradictory logs or metrics that might point to other root causes. You keep your hypothesis grounded in real-world system behavior by treating logs, stack traces, and code history as primary data - akin to raw experimental results. This evidence-first approach reduces guesswork and guides more precise experiments. Designing and Running Experiments With a hypothesis in hand and evidence gathered, it's time to test it through controlled experiments - much like scientists isolate variables to verify or debunk an explanation. 1. Set Up a Reproducible Environment: - Testing Environments: Replicate production conditions as closely as possible. In our example, that would involve ensuring the same caching configuration, library versions, and relevant data sets are in place. - Version Control Branches: Use a dedicated branch to experiment with different settings or configuration, e.g., cache invalidation strategies. This streamlines reverting changes if needed. 2. Control Variables One at a Time: - For instance, if you suspect data inconsistency is tied to cache invalidation events, first adjust only the invalidation timeout and re-test. - Or, if concurrency could be a factor (e.g., multiple requests updating user data simultaneously), test different concurrency levels to see if stale data issues become more pronounced. 3. Measure and Record Outcomes: - Automated Tests: Tests provide a great way to formalize and verify your assumptions. For instance, you could develop tests that intentionally update user profiles and check if the displayed data matches the latest state. - Monitoring Tools: Monitor relevant metrics before, during, and after each experiment. In our example, we might want to track cache hit rates, TTL durations, and query times. - Repeat Trials: Consistency across multiple runs boosts confidence in your findings. 4. Validate Against a Baseline: - If baseline tests manifest normal behavior, but your experimental changes manifest the bug, you've isolated the variable causing the issue. E.g. if the baseline tests show that data is consistently fresh under normal caching conditions but your experimental changes cause stale data. - Conversely, if your change eliminates the buggy behavior, it supports your hypothesis - e.g. that the cache configuration was the root cause. Each experiment outcome is a data point supporting or contradicting your hypothesis. Over time, these data points guide you toward the true cause. Analyzing Results and Iterating In scientific debugging, an unexpected result isn't a failure - it's valuable feedback that brings you closer to the right explanation. 1. Compare Outcomes to the hypothesis. For instance: - Did user data stay consistent after you reduced the cache TTL or fixed invalidation logic? - Did logs show caching events firing as expected, or did they reveal unexpected errors? - Are there only partial improvements that suggest multiple overlapping issues? 2. Incorporate Unexpected Observations: - Sometimes, debugging uncovers side effects - e.g. performance bottlenecks exposed by more frequent cache invalidations. Note these for future work. - If your hypothesis is disproven, revise it. For example, the cache may only be part of the problem, and a separate load balancer setting also needs attention. 3. Avoid Confirmation Bias: - Don't dismiss contrary data. For instance, if you see evidence that updates are fresh in some modules but stale in others, you may have found a more nuanced root cause (e.g., partial cache invalidation). - Consider other credible explanations if your teammates propose them. Test those with the same rigor. 4. Decide If You Need More Data: - If results aren't conclusive, add deeper instrumentation or enable debug modes to capture more detailed logs. - For production-only issues, implement distributed tracing or sampling logs to diagnose real-world usage patterns. 5. Document Each Iteration: - Record the results of each experiment, including any unexpected findings or new hypotheses that arise. - Through iterative experimentation and analysis, each cycle refines your understanding. By letting evidence shape your hypothesis, you ensure that your final conclusion aligns with reality. Implementing and Verifying the Fix Once you've identified the likely culprit - say, a misconfigured or missing cache invalidation policy - the next step is to implement a fix and verify its resilience. 1. Implementing the Change: - Scoped Changes: Adjust just the component pinpointed in your experiments. Avoid large-scale refactoring that might introduce other issues. - Code Reviews: Peer reviews can catch overlooked logic gaps or confirm that your changes align with best practices. 2. Regression Testing: - Re-run the same experiments that initially exposed the issue. In our stale data example, confirm that the data remains fresh under various conditions. - Conduct broader tests - like integration or end-to-end tests - to ensure no new bugs are introduced. 3. Monitoring in Production: - Even with positive test results, real-world scenarios can differ. Monitor logs and metrics (e.g. cache hit rates, user error reports) closely post-deployment. - If the buggy behavior reappears, revisit your hypothesis or consider additional factors, such as unpredicted user behavior. 4. Benchmarking and Performance Checks (If Relevant): - When making changes that affect the frequency of certain processes - such as how often a cache is refreshed - be sure to measure the performance impact. Verify you meet any latency or resource usage requirements. - Keep an eye on the trade-offs: For instance, more frequent cache invalidations might solve stale data but could also raise system load. By systematically verifying your fix - similar to confirming experimental results in research - you ensure that you've addressed the true cause and maintained overall software stability. Documenting the Debugging Process Good science relies on transparency, and so does effective debugging. Thorough documentation guarantees your findings are reproducible and valuable to future team members. 1. Record Your Hypothesis and Experiments: - Keep a concise log of your main hypothesis, the tests you performed, and the outcomes. - A simple markdown file within the repo can capture critical insights without being cumbersome. 2. Highlight Key Evidence and Observations: - Note the logs or metrics that were most instrumental - e.g., seeing repeated stale cache hits 10 minutes after updates. - Document any edge cases discovered along the way. 3. List Follow-Up Actions or Potential Risks: - If you discover additional issues - like memory spikes from more frequent invalidation - note them for future sprints. - Identify parts of the code that might need deeper testing or refactoring to prevent similar issues. 4. Share with Your Team: - Publish your debugging report on an internal wiki or ticket system. A well-documented troubleshooting narrative helps educate other developers. - Encouraging open discussion of the debugging process fosters a culture of continuous learning and collaboration. By paralleling scientific publication practices in your documentation, you establish a knowledge base to guide future debugging efforts and accelerate collective problem-solving. Conclusion Debugging can be as much a rigorous, methodical exercise as an art shaped by intuition and experience. By adopting the principles of scientific inquiry - forming hypotheses, designing controlled experiments, gathering evidence, and transparently documenting your process - you make your debugging approach both systematic and repeatable. The explicitness and structure of scientific debugging offer several benefits: - Better Root-Cause Discovery: Structured, hypothesis-driven debugging sheds light on the _true_ underlying factors causing defects rather than simply masking symptoms. - Informed Decisions: Data and evidence lead the way, minimizing guesswork and reducing the chance of reintroducing similar issues. - Knowledge Sharing: As in scientific research, detailed documentation of methods and outcomes helps others learn from your process and fosters a collaborative culture. Ultimately, whether you are diagnosing an intermittent crash or chasing elusive performance bottlenecks, scientific debugging brings clarity and objectivity to your workflow. By aligning your debugging practices with the scientific method, you build confidence in your solutions and empower your team to tackle complex software challenges with precision and reliability. But most importantly, do not get discouraged by the number of rigorous steps outlined above or by the fact you won't always manage to follow them all religiously. Debugging is a complex and often frustrating process, and it's okay to rely on your intuition and experience when needed. Feel free to adapt the debugging process to your needs and constraints, and as long as you keep the scientific mindset at heart, you'll be on the right track....

May 9, 2025

13 mins

JavaScript

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Setting Up React Navigation in Expo Web: A Practical Guide

Introduction

Getting started

Setting up the navigation

Creating our screens

Deep linking

Running the app

Handling dynamic routes

Conclusion

Chinedu Okpala

You might also like

Why is My React Reducer Called Twice and What the Heck is a Pure Function?

Improving INP in React and Next.js

Using React In Your Qwik Application

The Importance of a Scientific Mindset in Software Engineering: Part 2 (Debugging)

Let's innovate together!

You might also like

Why is My React Reducer Called Twice and What the Heck is a Pure Function?

Improving INP in React and Next.js

Using React In Your Qwik Application

The Importance of a Scientific Mindset in Software Engineering: Part 2 (Debugging)