ReactJS

Setting Up React Navigation in Expo Web: A Practical Guide

Jun 5, 2023

5 min read

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.

Chinedu Okpala

@allstackDev @allStackDev1

Demystifying React Server Components

React Server Components (RSCs) are the latest addition to the React ecosystem, and they've caused a bit of a disruption to how we think about React. Dan Abramov recently wrote an article titled "The Two Reacts" that explores the paradigms of client component and server component mental models and leaves us with the thought on how we can cohesively combine these concepts in a meaningful way. It took me a while to finally give RSCs the proper exploration to truly understand the "new" model and grasp where React is heading. First off, the new model isn't really new so much as it introduces a few new concepts for us to consider when architecting our applications. Once I understood the pattern, I found an appreciation for the model and what it's trying to help us accomplish. In this post, I hope I can show you the progression of the React architecture in applications as I've experienced them and how I think RSCs help us improve this model and our apps. A "Brief" History of React Rendering and Data-Fetching Patterns One of the biggest challenges in React since its early days is "how do we server render pages?" Server-side rendering (SSR) is one of the techniques we can use to ensure users see data on initial load and helps with our site's SEO. Without SSR, users would see blank screens or loading spinners, and then a bunch of content would appear shortly after. An excellent graphic on Remix's website demonstrates this behavior from the end user's perspective and it's a problem we generally try to avoid as developers. This problem is so vast and difficult that we've been trying to solve it since 2015. Rick Hanlon from the React Core Team reminded us just how complicated this problem was recently. If you think react is complicated now, go back to 2015 when you had to configure babel and webpack yourself, you had to do SSR and routing yourself, you had to decide between flow and typescript, you had to learn flux and immutable.js, and you had to choose 1 of 100 boilerplates— Ricky (@rickhanlonii) January 28, 2024 But SSR has its issues too. Sometimes SSR is slow because we need to do a lot of data fetching for our page. Because of these large payloads, we'll defer their rendering using lazy loading patterns. All of a sudden we have spinners again! How we've managed these components has changed too. Over the years, we've seen a variety of patterns emerge for managing these problems. We had server-side pre-fetching where we had to hydrate our frontends application state. Then we tried controller-view patterned components for our lazily loaded client-side components. With the evolution of React, we were able to simplify the controller-view patterns to leverage hooks. Now, we're in a new era of multi-server entry points on a page with RSCs. The Benefits of React Server Components RSCs give us this new paradigm that allows us to have multiple entries into our server on a single page. Leveraging features like Next.js' streaming mode and caching, we can limit what our pages block on for SSR and optimize their performance. To illustrate this, let's look at this small block of PHP for something we might have done in the 2000s: index.php ` For simplicity, the blocks indicate server boundaries where we can execute PHP functionality. Once we exit that block, we can no longer leverage or communicate with the server. In this example, we're displaying a welcome message to a user and a list of posts. If we look at Next.js' page router leveraging getServerSideProps, we would maybe write this same page as follows: pages/posts.jsx ` In this case, we're having our server do a lot to fetch the data we need to render this page and all its components. This also makes the line between server and client much clearer as getServerSideProps runs before our client renders, and we're unable to go back to that function without an API route and client-side fetch. Now, let's look at Next.js' app router with server components. This same component could be rendered as follows: app/posts/page.tsx ` This moves us a bit closer back to our PHP version as we don't have to split our server and client functionality as explicitly. This example is relatively simple and only renders a few components that could be easily rendered as static content. This page also probably requires all the content to be rendered upfront. But, from this, we can see that we're able to simplify how server data fetching is done. If nothing else, we could use this pattern to make our SSR patterns better and client render the rest of our apps, but then we'd lose out on some of the additional benefits that we can get when we combine this with streaming. Let's look at a post page that probably has the content and a comments section. We don't need to render the comments immediately on page load or block on it because it's a secondary feature on the page. This is where we can pull in Suspense and make our page shine. Our code might look as follows: app/posts/[slug]/page.jsx ` Our PostComments are a server component that renders static content again, but we don't want its render to block our page from being served to the client. What we've done here is moved the fetch operation into the comments component and wrapped it in a Suspense boundary in our page to defer its render until its content has been fetched and then stream it onto the page into its render location. We could also add a fallback to our suspense boundary if we wanted to put a skeleton loader or other indication UI. With these changes, we're writing components similarly to how we've written them on the client historically but simplified our data fetch. What happens when we start to progressively enhance our features with client-side JavaScript? Client Components with RSCs All our examples focused on staying in the server context which is great for simple applications, but what happens when we want to add interactivity? If you were to put a useState, useEffect, onClick, or other client-side React feature into a server component, you'd find some error messages because you can't run client code from a server context. If we think back to our PHP example, that makes a lot of sense why this is the case, but how do we work around this? For me, this is where my first really mental challenge with RSCs started. Let's use our PostComments as an example to enhance by in-place sorting the section from the server. ` In this example, we're using a server component the same way as our previous example to do the initial data fetch and stream when ready. However, we're immediately passing the results to a client component that renders the elements and enhances our code with a list of sort options. When we select the sort we want, our code makes a request to the server at a predefined route and gets the new data that we re-render in the new order on screen. This is how we might have done things without RSCs before but without a useEffect for our initial rendering. If you're familiar with the old controller-view pattern, this is relatively similar to that pattern, but we have to relegate client re-fetching to the view (client) component, where we might have had all fetch and re-fetch patterns in the controller (server) component Another way to solve this same problem is leveraging server actions, but that would cause the page to re-render. Given the caching mechanisms in Next.js, this is probably fine, but it's not the user experience people are expecting. Server actions are a topic of their own, so I won't cover them in this post, but they're important for the holistic ecosystem experience in the new mindset. Interleaving Nested Server & Client Components These examples have shown a clean approach where we keep our server components at the top of our rendering tree and have a clear line where we move from server mode to client mode. But one of the advantages of RSCs is that we can interleave where our server component entry points may exist. Let's think about a product carousel on a storefront page for example. We may have built this as follows before: ` Here we're rendering carousels that render their cards and our tree goes server -> client -> server. This is not allowed in the new paradigm because the React compiler cannot detect that we moved back into a server component when we called ProductCards from a client component. Instead, we would need to refactor this to be: ` Here, we've changed ProductCarousel to accept children that are our ProductCards server component. This allows the compiler to detect the boundary and render it appropriately. I'd also recommend adding Suspense boundaries to these carousels but I omitted it for the sake of brevity in this example. Some Suggested Best Practices Our team has been using these new patterns for some time and have developed some patterns we've identified as best practices for us to help keep some of these boundaries clear that I thought worth sharing. 1. Be explicit with component types We've found that being explicit with component types is essential to expressing intent. Some components are strictly server, some are strictly client, and others can be used in both contexts. Our team likes using the server-only package to express this intent but we found we needed more. We've opted for the following naming conventions: Server only components: component-name.server.(jsx|tsx) Client only components: component-name.client.(jsx|tsx) Universal components: component-name.(jsx|tsx) This does not apply to special framework file names but we've found this helps us delineate where we are and to help with interleaving. 2. Defer Fetch when Cache is Available If we're trying to render a component that is a collection of other components, we've found deferring the fetch to the child allows our cache to do more for us in rendering in cases where the same element may exist in different locations. This is similar to how GraphQL's data loaders works and can ideally boost the performance of cached server components. So, in our product example above, we may only fetch the IDs of the products we need for the ProductCards and then fetch all the data per card. Yes, this is an extra fetch and causes an N+1, but if our cache is in play, end users will feel a performance gain. 3. Colocate loaders and queries If you're using GraphQL or need loading states for components for Suspense fallback, we recommend colocating those elements in the same file or directory. This makes it easier to modify and manage related elements for your components in a more meaningful way. 4. Use Suspense to defer non-essential content This will depend on your website and needs. Still, we recommend deferring as many non-essential elements to Suspense as possible. We define non-essential to be anything you could consider secondary to the page. On a blog post, this could be recommended posts or comments. On a product page, this could be reviews and related products. So long as the primary focus of your page is outside a Suspense boundary, your usage is probably acceptable. Conclusion RSCs represent a significant evolution in the React ecosystem, offering new paradigms and opportunities for improving the architecture of web applications. They enable multiple server entry points on a single page, optimizing server-side rendering, and simplifying data fetching. RSCs allow for a clearer separation between server and client functionality, enhancing both performance and maintainability. To make the most of RSCs, developers should consider best practices such as being explicit with component types, deferring fetch when caching is available, colocating loaders and queries, and using Suspense to defer non-essential content. Embracing these practices can help harness the potential of React Server Components and pave the way for more efficient and interactive web applications. We're excited about this development in the React ecosystem and the developments happening across teams and frameworks that are opting into using them. While Next.js offers a great solution, we're excited to see similar enhancements to Remix and RedwoodJS....

Feb 2, 2024

9 mins

ReactNextJSArchitecture

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

In this episode of the Modern Web Podcast, hosts Tracy Lee, Ben Lesh, and Adam Rackis kick things off by discussing the progress of observables landing in the browser and the potential impact it could have on the use of RXJS. As developers, we're always on the lookout for new tools and technologies that can make our lives easier, and observables in the browser certainly have the potential to do just that. They talk about whether or not you should listen to your “customers” or have a strong vision that you want to push forward, like Ryan Carniato and his approach with Solid and Signals. The three also talk about AI tools, such as GPT and Co-Pilot, and how they are shaping the future of coding and ideation. Finally, Ben, Adam, and Tracy briefly touch on the potential impact of automation on job roles and the outsourcing of tech jobs. While automation can streamline certain tasks, it's important to remember that human creativity and problem-solving skills are irreplaceable. Download this episode here!...

Feb 16, 2024

1 min

ReactRxJSArtificial Intelligence

Announcing Qwik for starter.dev

Hello there! Today, I'm so excited to introduce our new Qwik starter kit, which comes with 4 different technologies configured, and is ready for use. These technologies are: Qwik City, Storybook, Tailwind CSS, and GraphQL. In this short article, we will talk about the core framework, the routing, example apps to get you started, the tools and technologies used in this kit, and how it is a great out-of-the-box starter for your next Qwik project. Qwik 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. Today we will be focusing on the Qwik framework starter kit. Technologies Used in the Starter Kit - Qwik City The kit is configured to make use of Qwik City, which offers directory-based routing (you don’t have to worry about colocation) and much more. Qwik City is a meta-framework of Qwik. It brings an opinionated and performant way to build sites at scale. - Storybook Storybook is a frontend workshop for building UI components and pages in isolation, testing, and documentation. It is open source and free. It is a great tool for testing and visualizing your components in different states. Qwik currently doesn’t have out-of-the-box support for Storybook, but we have figured out a way to configure it for Qwik. For more information on how we set up Storybook in Qwik, visit here. - Tailwind CSS Because Tailwind CSS is one of the most loved CSS libraries, we also included in this kit. Tailwind CSS is an open-source CSS framework. There is no special configuration to use Tailwind CSS in your Qwik app. You can use module CSS, or follow along with the kit (i.e we export the CSS classes as a variable). We will still achieve the same result, and make our code a bit cleaner, unlike when we write the CSS classes in the JSX directly. - GraphQL GraphQL is another great tool that was added to the kit. This gives you an out-of-the-box configuration to start making API calls to your GraphQL backend. GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. How to Get Started To get started, visit the Qwik starter.dev page for all the steps needed to create a new application with our starter.dev CLI, and run the application on your local system. Example Apps in the Starter Kit In this starter kit, we have two main components; - Counter - Greeting In the Counter component, we see how we can utilize the useStore hook provided by Qwik to store our counter state. In the Greeting component, we made use of the GraphQL config in the starter kit. The app sends a query request with the value entered in the input field, which is then returned back as a response from the API. With all of these configurations and code samples, we believe that with this Qwik starter kit, you can start building your production-scale application. Conclusion Qwik is still in its early days, and we will continue to update as we learn more. We welcome everyone to take a look, and 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....

Feb 15, 2023

3 mins

Qwik

How to Go from Software Engineer to AI Engineer with Shawn Wang

Shawn Wang discusses AI engineering’s potential impact on the software development labor market and developer experience. With the rise of artificial intelligence technologies, there is an increasing demand for professionals who can bridge the gap between AI and software engineering, and engineers are looking around for guidance on how to best learn AI. Shawn emphasizes the importance of acquiring core knowledge and skills in AI engineering, highlighting the need for a systematic approach to education and development. He envisions a future where AI engineering becomes a recognized profession, with specialized training programs and certifications. He further talks about mental models for approaching AI literacy, and skill building. Shawn also discusses the use of advanced AI technology in software development. He showcases tools like GPT Vision, which can automate tasks and generate code efficiently. While acknowledging the potential of AI in enhancing productivity, Shawn emphasizes the need to leverage AI tools to augment human capabilities rather than replace them. Download this episode here....

Apr 17, 2024

1 min

Artificial IntelligenceEngineering Leadership

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

Demystifying React Server Components

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

Announcing Qwik for starter.dev

How to Go from Software Engineer to AI Engineer with Shawn Wang

You might also like

Demystifying React Server Components

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

Announcing Qwik for starter.dev

How to Go from Software Engineer to AI Engineer with Shawn Wang