ReactJS

File Based Routing with Expo Router

Jan 10, 2024

8 min read

Introduction

If there is one thing most Javascript developers love, it is file-based routing, and with the advent of frameworks like Next.js, this form of routing has become more popular and most preferred when building applications. The React Native community will not be left out, as earlier this year, Expo released the Expo router, which implements the file-based routing convention. Currently, the Expo router is in V2, which is supported by version 49 of the Expo SDK.

In this article, we will take a look at the features that the Expo router offers and explore its file-based routing system.

What is Expo Router?

Expo Router is a file-based router for React Native and web applications. It allows you to manage navigation between screens in your app, allowing users to move seamlessly between different parts of your app's UI, using the same components on multiple platforms (Android, iOS, and web). It brings the best file-system routing concepts from the web to a universal application, allowing your routing to work across every platform. When a file is added to the app directory, the file automatically becomes a route in your navigation.

Features of Expo Router

Native: It is built on the React Navigation suite, Expo Router navigation is truly native and platform-optimized by default.
Shareable: Every screen in your app is automatically deep linkable, making any route in your app shareable with links.
Offline-first: Handles all incoming native URLs without a network connection or server. Apps are cached and run offline first, with automatic updates when you publish a new version.
Optimized: Routes are automatically optimized with lazy evaluation in production and deferred bundling in development.
Iteration: Universal Fast Refresh across Android, iOS, and the web, along with artifact memoization in the bundler to keep you moving fast at scale.
Universal: Android, iOS, and web share a unified navigation structure, with the ability to drop down to platform-specific APIs at the route level.
Discoverable: Expo Router enables build-time static rendering on the web and universal linking to native. Meaning your app content can be indexed by search engines.

Expo routing conventions

Let’s build a simple application to discuss the various routing conventions and explore some features of the Expo router.

To get started, all you need to do is run the following command

npx create-expo-app@latest -e with-router

This will create a bare-bone expo project with an Expo router. By default, it is not configured to use typescript. To add a typescript to the project, go to the root of the project and run:

Touch tsconfig.json
npx expo

Expo also provides a way to create a minimal project with the Expo Router library already installed. To create a project, run the command:

npx create-expo-app@latest --template tabs@49

For this article, we will stick with the first approach.

Now let’s create our first page. Create a file called app/index.tsx and add the following code:

import { Link, useRouter } from 'expo-router';
import { View, Pressable, Text, Button } from 'react-native';
const Login = () => {
  const router = useRouter();
  const handleLogin = () => {
    router.replace('/home');
  };
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Button onPress={handleLogin} title='Login' />
      <Link href="/register" asChild>
        <Pressable>
          <Text>Create account</Text>
        </Pressable>
      </Link>
    </View>
  );
};
export default Login;

From the above code, we see that the expo router provides a Link component for navigation. This is very familiar to how the web works with anchor tag <a> and the href attribute. The Link component wraps the children in a <Text> component by default; this is useful for accessibility but not always desired. You can customize the component by passing the asChild prop, which will forward all props to the first child of the Link component. The child component must support the onPress and onClick props, href and accessibilityRole will also be passed down.

Additionally, we can also use the useRouter hook to navigate to a route. This is very useful if navigating from a global store or custom hook.

Layout Routes

At the moment, any page we create covers the whole screen, and this is not perfect in most native apps. In that case, we can define a layout that will wrap our pages and add a header and footer, or in our case, a native stack component. This follows the same approach as the usual React Native stack, and we can define the different screens based on their file name. Let’s create a root layout app/_layout.tsx file:

import { Stack, useRouter } from 'expo-router';
import { Button } from 'react-native';
const StackLayout = () => {
  const router = useRouter();
  return (
    <Stack
      screenOptions={{
        headerStyle: {
          backgroundColor: '#f4511e',
        },
        headerTintColor: '#fff',
        headerTitleStyle: {
          fontWeight: 'bold',
        },
      }}
    >
      <Stack.Screen name="index" options={{ headerTitle: 'Login' }} />
      <Stack.Screen
        name="register"
        options={{
          headerTitle: 'Create account',
        }}
      />
    </Stack>
  );
};
export default StackLayout;

From the above code, we added the native stack component to define the different screens on the app. We also added screenOptions to add some basic header styles This is useful if you want to define the layout style for all routes. You can also change the layout for each screen by adding various style options to the options property in the <Stack.screen> component.

Furthermore, if you create a directory that groups different routes, you can create a layout for those routes.

Unmatched Routes

From our example above, we do not have a register page, so if we try to click on the link and visit that page, we will get an unmatched error page. Expo router provides a default unmatched route. This is the fallback page when you try to reach a route that does not exist. You can customise this route by creating a file called app/[...unmatched].tsx and exporting any component you want to render instead. Be sure to have a link to ‘/’ so users can navigate back to the home screen.

Groups

Groups are used to organize sections of the app. When we wrap a directory name in parenthesis (e.g., (profile)), it does so without adding segment to the URL. This is mostly useful when you are developing for the web, and you don’t want the group name to exist as a segment on the URL. Let’s create a group named (tabs). This will contain two tab files: home and account.

Create a file name apps/(tabs)/home.tsx and add the following code:

import { View, Text } from 'react-native';
const HomePage = () => {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text>I am the home screen</Text>
    </View>
  );
};
export default HomePage;

Create another file called apps/(tabs)/account.ts and add the following code:

import { View, Text } from 'react-native';
const AccountPage = () => {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text>This is the profile page</Text>
    </View>
  );
};
export default AccountPage;

We can now add a layout to the (tabs) group. The layout won’t use a <Stack> component but will use a <Tabs> component. Create a _layout.tsx file inside the (tabs) directory and add the following code:

import { Link, Tabs } from 'expo-router';
import { FontAwesome5 } from '@expo/vector-icons';
import { Pressable, Text } from 'react-native';
const TabsLayout = () => {
  return (
    <Tabs>
      <Tabs.Screen
        name="home"
        options={{
          tabBarLabel: 'Home',
          headerTitle: 'Home',
          tabBarIcon: ({ color, size }) => <FontAwesome5 name="home" size={size} color={color} />,
          headerRight: () => (
            <Link href="/" asChild replace>
              <Pressable>
                <Text>Logout</Text>
              </Pressable>
            </Link>
          ),
        }}
      />
      <Tabs.Screen
        name="account"
        options={{
          tabBarLabel: 'Account',
          headerTitle: 'My Account',
          tabBarIcon: ({ color, size }) => <FontAwesome5 name="user" size={size} color={color} />,
        }}
      />
    </Tabs>
  );
};
export default TabsLayout;

From the above code, we created two tabs for the Home page and the Account page. We added the appropriate icons for those tabs. On the homepage, we added a Logout link. In the Link component, we added a replace attribute because using the Link component is almost the same as calling router.push(). It adds the route on top of the stack. But since this is a Logout link, we need to replace all existing navigation stacks with the route.

By default, you should be able to navigate to the tabs screen, but you will notice that it has multiple header sections as seen below: multiple header sections - react expo router

You will notice that there are two header sections. The first header with the title (tabs) is inferred by the Expo router, and it uses the styling from the root layout. The second header was created when we added some options in the <Tab.screen> component. We can remove any of the headers depending on our app design. To remove the first header, we must add the (tabs) route as a screen to the root layout and set the headerShown to false. So go to the _layout.tsx file on the root of the app directory and add the following code:

…
<Stack.Screen
  name="(tabs)"
  options={{
    headerShown: false,
  }}
/>

We are setting the headerShown to false because the (tabs) group also has a layout, and each tab on the layout has an option that sets the headerTitle and other header properties. That is the header we would show, as they will change for the different tabs. If we want a static header for both tabs, we can add headerShown: false to all tabs options on the tab layout.

Shared routes

To match the same URL with different layouts, use groups with overlapping child routes. This pattern is very common in native apps. For example, in the Twitter app, a profile can be viewed in every tab (such as home, search, and profile). However, there is only one URL that is required to access this route.

Here is an example of how a shared route is structured: shared routes in expo router

Shared routes can be navigated directly by including the group name in the route. For example, /(search)/victor navigates to /victor in the "search" layout.

Kindly note that for web apps, when you directly type/victor on your browser, the Expo router cannot tell which [user].tsx you are trying to reach, so it gets the first route that matches the path from your file tree (In the case above, it is the (home)/[user].tsx). Shared routes are most useful in tab navigations because it is easier to know the group from which the route was visited and keep the tab active.

Arrays

Instead of defining the same route multiple times with different layouts, we can use the array syntax (,) to duplicate the children of a group. For example, app/(home,profile,search)/[user].tsx creates app/(home)/[user].tsx, app/(profile)/[user].tsx and app/(search)/[user].tsx in memory.

To distinguish between the two routes, use a layout's segment prop:

const DynamicLayout = ({ segment }) => {
  if (segment === '(search)') {
    return <SearchStack />;
  }
    if (segment === ‘(profile)’) {
    return <ProfileStack />;
  }
  return <Stack />;
}
export default DynamicLayout;

Dynamic Route

Dynamic routes match any unmatched path at a given segment level. For example, if I have a directory named contacts, I can create a dynamic route for each contact app/contacts/[slug].tsx. This is very useful if you have a list of contacts and you want to show the details of one contact.

Routes with higher specificity will be matched before a dynamic route. For example, contacts/victor will match app/contacts/victor.tsx before app/contacts/[user].tsx.

Multiple slugs can be matched in a single route using the rest of the syntax (...). For example, app/contacts/[…rest].tsx matches /contacts/123/settings. Dynamic segments are accessible as search parameters in the page component.

import { useLocalSearchParams } from 'expo-router';
import { Text } from 'react-native';
Const ContactPage = () => {
  const { slug } = useLocalSearchParams();
  return <Text>Contact {slug}</Text>;
}

export default ContactPage;

Conclusion

In this article, we learned about the Expo Router, how it works, its core features, and its tradeoffs using some example codes. Expo Router offers a minimalistic API with a straightforward approach to navigation using the file-system routing concepts. The Expo router is most useful if you are not dealing with a complex navigation system in your project. File-based routing provides a smooth navigation experience for mobile applications, and Expo Router implements this solution into its library.

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.

Victor Umeh

Software Engineer. Passionate about web developement with specialty in Reactjs and Nextjs. He also interested in web3 and blockchain development. In his free time he plays soccer.

@Vyktoreumeh @vyktoremario

CSS Hooks: A new way to style your React apps

In the world of web development, the management of styles has always been a crucial aspect of building modern and responsive user interfaces. With the rise of CSS in JS libraries like Material UI and Chakra, developers have started creating dynamic and reusable styles using JavaScript; however, the performance implications of these libraries have led to the exploration of alternative solutions. One such solution is CSS Hooks, a library that offers a different approach to managing styles in web applications. The Problem with CSS in React and CSS in JS Libraries In React applications, you typically write styles directly with the style prop by applying classes with className, or if you’re using a framework like Material UI or Chakra then you may use the sx attribute, which is more powerful than the baseline attributes. There are some performance concerns in the case of the sx attribute specifically. The framework has to dynamically generate classes with your styles and apply them to the document whenever it is used. This can become an issue with large and complex applications as your styles will be regularly regenerated on the fly as the user navigates through the application. This has led developers to seek alternative solutions that offer similar flexibility but with better performance. Introduction to CSS Hooks CSS Hooks improve upon the aforementioned issues by pre-generating your CSS using configuration hooks. The styles that these hooks generate remain static during the lifetime of the application and are reused wherever possible. CSS variables are utilized under the hood whenever dynamic behavior is needed. By dynamic behavior, I’m referring to advanced CSS features such as pseudo-class selectors and media queries, which are both traditionally unavailable for use with inline styles. CSS Hooks utilize an interesting trick under the hood to accomplish this, which we will now explore. The Power of CSS Variables and the Fallback Trick As mentioned before, CSS variables are utilized in order to support using advanced dynamic behavior such as pseudo-selectors in our inline styles. CSS variables are core to something known as the “fallback trick”. The gist of how the fallback trick works is to have the pseudo-selector or media query toggle the state of a variable between initial and an empty invalid value, and then we put the value that we actually want to toggle as the “fallback” value in the reference to the CSS variable inside of the inline style itself. Changing this fallback value inside of an inline style essentially allows us to control the values used by the pseudo-selector without having to regenerate linked stylesheets as we only have to change the inline style attribute. This is best explained with an example: ` This plain HTML and CSS code effectively allows us to utilize the focus pseudo-selector on any element that we want using inline styles only. This is what CSS Hooks effectively does in the background when you use dynamic styles. No nasty re-renders and mucking with stylesheets needed! How to use CSS Hooks Now that we know how CSS Hooks fundamentally work, let’s try using them. The library itself is much easier to use than the aforementioned example. Installation and usage of CSS Hooks is easy. Firstly, we must install the @css-hooks/react package into a React project with the package manager of your choice (npm, pnpm yarn, etc). Once that’s done, all that’s left is a little bit of configuration. You have to first use a utility function called createHooks that is exported from the package we just installed. The result of that function returns a couple of variables in an array that can be deconstructed, the first being a stylesheet in the form of a string, and the second being a function. ` I recommend putting this in a separate file that can be imported from multiple other places in the project as this is where we will be configuring hooks across the project. We’re exporting both hooks and css, and both are important. We need to include hooks into the DOM as it contains the styles of the hooks that we’ll be referencing in our components. In your root component you need to add the following tag so that the generated CSS can be used. ` How this is done may vary based on the libraries that you are using. After that’s done, you can integrate CSS Hooks into your components while writing inline styles mostly just like you would do normally, with the only change being the addition of an additional call to the css function that we exported earlier: ` Now that the core boilerplate is set up, your components can now utilize CSS Hooks in theory; however we need to actually add some hooks to start with before we can use them, or else we’ll just be limited to basic styles in the same way that React inline styles are. Make your own hooks We can define our hooks inside of the css-hooks file that we created earlier, the same one that exports the css helper function that gets CSS Hooks working with our components. Hooks are defined in the options parameters that are currently empty. Defining a simple hook that allows us to define inline hover styles for a component is very easy and can be done as follows: ` Although both the key and the value in this example are the same, they both serve different purposes. The key is the name of the hook that we reference when we want to use it, while the value is the spec. The spec is the actual CSS selector that we’re writing. The name can be anything that you want it to be so long as it doesn’t clash with any existing style properties or hooks. Recommended hooks Although making your own hooks may be necessary at times, there is another repository provided by the CSS Hooks authors that adds a way to generate many useful hooks called @css-hooks/recommended. I highly recommend using this library to generate your hooks if at all possible, and the usage is pretty simple. Here’s an example showing how you can use it to generate media queries, color scheme specific styles and pseudo-selectors: ` Then with that done, these can be utilized as follows: ` We can also modify the hooks configuration to add our own hooks in addition to the recommended hooks by using the spread operator: ` Then that custom hook can be used by simply using its key name: ` Summary CSS Hooks offers a performant alternative to traditional CSS in JS libraries by leveraging CSS variables and providing a unique approach to managing styles in web applications. By pre-generating the stylesheet based on configured hooks and utilizing CSS Variables for dynamic behavior, developers can create reusable styles without the performance overhead associated with dynamic stylesheet generation. If you're interested in exploring CSS Hooks further, be sure to check out @CSSHooks for more information. You can also find some of the examples demonstrated here in a working app in our demos repository. Thank you for reading!...

Feb 28, 2024

5 mins

CSSReact

Next.js Route Groups

Starting from Next.js 13.4, Vercel introduced the App Router with a whole set of new and exciting features. The way we organize the routing in our application has changed radically compared to previous versions of Next.js, as well as the definition and usage of Layouts for our pages. In this article, we will focus on what is called Route Groups, their use cases, and how they can help us in our developer experience. Basic introduction to the new App Router In version 13, Next.js introduced a new App Router built on React Server Components, which supports shared layouts, nested routing, loading states, error handling, and more. The App Router works in a new directory named app Creating a page.tsx file inside the app/test-page folder allows you to define what users are going to see when they navigate to /test-page. So folder’s names inside app directory define your app routes. You can also have nested routes like this: In this case, the URL of your page will be /test-page/nested-page By default, components inside app are React Server Components. This is a performance optimization and allows you to easily adopt them, and you can also use Client Components. Layouts In Next.js, a Layout file is a special component that is used to define the common structure and layout of multiple pages in your application. It acts as a wrapper around the content of each page, providing consistent styling, structure, and functionality. The purpose of a Layout file is to encapsulate shared elements such as headers, footers, navigation menus, sidebars, or any other components that should be present on multiple pages. By using a Layout file, you can avoid duplicating code across multiple pages and ensure a consistent user experience throughout your application. To create a Layout file in Next.js, you typically create a separate component file, such as Layout.tsx, and define the desired layout structure within it. This component can then be imported and used on individual pages where you want to apply the shared layout. By wrapping your page content with the Layout component, Next.js will render the shared layout around each page, providing a consistent look and feel. This approach simplifies the management of common elements and allows for easy updates or modifications to the layout across multiple pages. Here is an example of how to use a Layout file with the new App Router Route Groups In Next.js, the folders in your app directory usually correspond to URL paths. But if you mark a folder as a Route Group, it won't be included in the URL path of the route. This means you can organize your routes and project files into groups without changing the URL structure. Route groups are helpful for: 1. Organizing routes into groups based on site sections, intent, or teams. 2. Creating nested layouts within the same route segment level: - You can have multiple nested layouts in the same segment, even multiple root layouts. - You can add a layout to only a subset of routes within a common segment. To create a route group inside your app folder you just need to wrap the folder’s name in parenthesis: (folderName) Since route groups won’t change the URL structure your page.tsx content will be shown under the/inside-route-group path. Use cases Route groups are amazing when you want to create multiple layouts inside your page: Or if you want to specify a layout for a specific group of pages You need to be careful because all the examples above can lead you to some misunderstanding. *What is root layout? The top-most layout is called the Root Layout. This required layout is shared across all pages in an application.* As you can see, the route folder in the two examples above always has a well-defined root layout. This means that the specific layouts we have defined for the various groups will not replace the root layout, but will be added to it. However, Route Groups also allow us to redefine the root layout. Specifically, they allow us to define different root layouts for different segments of pages. All we have to do is remove the common Root Layout file, create some Route groups, and re-define the different Root layout files for every group in the route folder: In this way, we will have pages with different root layouts, and our paths will once again not be affected by the folder name used in parentheses. Conclusion In conclusion, Next.js route groups offer a powerful and flexible solution for organizing and managing routes in your Next.js applications. By grouping related routes together, you can improve code organization, enhance maintainability, and promote code reusability. Route groups allow for the use of shared layout components, and the customization of root layouts for different segments of pages. With Next.js route groups, you can streamline your development process, create a more intuitive routing structure, and ultimately deliver a better user experience....

Feb 7, 2024

6 mins

NextJSReact

How to Handle Async Data Fetching Using CreateResource in SolidJS

In this article, you will learn how to handle async data fetching using createResource in SolidJS. The article assumes that you have a basic understanding of SolidJS. If you need a refresher, I recommend looking at the official SolidJS website to get started with SolidJS. You can also visit solidjs.framework.dev/ for a list of SolidJS libraries and resources. What is createResource? createResource is a special Signal designed specifically to handle async data fetching. Signals are the cornerstone of reactivity in SolidJS. They contain values that change over time, but unlike typical values, Signals are also event emitters. When the data kept in the Signal is changed, the Signal emits events in the system so things that depend on the Signal value can be notified. Signals are similar to “observables'', “streams”, or “subjects” in other reactive programming technologies. For more information on Signals, check out the SolidJS Documentation. The purpose of createResource is to wrap async values (any value that returns as a promise) in a way that makes them easy to interact with in Solid's execution model. This is useful because it ensures that the async function is non-blocking. How does createResource work? For createResource to work, it needs an argument which is a function that returns a promise. It returns a data getter that wraps the value returned from the fetcher function. Easy right? The resulting Resource Signal (products) also contains reactive loading and error properties that make it easy to control the view based on the current status. Let’s see how all of these are used in an example. In this example, we created a fetcher function that makes a call to get a list of products, and this function is passed in as an argument to createResource. createResource returns a Signal which has reactive properties like loading, error, latest, etc. We use the properties to conditionally render JSX based on the current reactive state. createResources can also take in a source Signal as the first argument and the async fetcher function as the second. The source Signal is provided as the query to the async fetcher function which returns a promise. A change in the source Signal calls an internal fetch method to fetch new data based on the change. If you are familiar with React-query, source Signals are similar to query keys. Let’s write an example that fetches users’ profiles from GitHub. It takes the username as input and returns the user’s profile details. Here we are fetching a GitHub user’s info. We have an input field that receives the username and set it as a Signal. The createResource takes the source Signal as the first argument and the async fetcher function as the second argument. An internal fetch method will be called anytime the Signal value changes. So if we enter a different username into the input field, createResource is aware of that change, and fetches new data based on the new Signal value. Refetch and Mutate The second value that comes back from createResource contains a mutate method for directly updating the internal Signal, and a refetch method to reload the current query even if the source hasn't changed. Mutate is useful for "optimistic mutations" like when you want to automatically update a todo list that is fetched from the server when someone clicks the add button. Refetch is useful when you know the data returned from the server changes constantly and you would like to get the latest information. For example, if you are building an application that needs to show the current price of Bitcoin in US dollars, you will need to refetch the data because the prices fluctuate. Why is createResources special? For small examples, createResource can be as simple as just setting a Signal. However, it interacts with the broader Solid framework in different ways: When your app is server-side rendered, createResource is fetched on the server while effects and Signal setters aren't, so resources work a lot better with solid start. Any loading resources will put your app in suspense mode which can automatically provide benefits when interacting with the Solid router. Conclusion In this article, we saw how to handle async data fetching using createResource. We also explored some use cases, and when and how to use some properties and methods returned by createResource. You can find the live example for this blog post on StackBlitz. If you would like to learn more about SolidJS, check out solidjs.framework.dev for a list of libraries and resources....

Feb 27, 2023

5 mins

JavaScript

What’s New for Astro & TypeScript + “Team Islands” with Elian, Josh, & Chris (Backstage @ CityJS Conf)

Elian Van Cutsem, Josh Goldberg, and Chris Noring, joined Tracy Lee backstage at CityJS Conf London to talk about what’s new in the Astro, and TypeScript ecosystems. The conversation also touched on the utilization of iterators in JavaScript and their potential to augment web application functionality. The group weighed in on hot topics in web development, like islands, resumability, and the nuanced interplay between TypeScript and iterators were explored, offering profound insights into optimizing code for enhanced user experiences. The discourse also highlighted the paramount importance of collaboration in driving advancements within web development. Despite perceived competition among technologies, the group emphasized the importance of collaboration for propelling innovation. By fostering a collaborative environment where different technologies learn from each other's strengths, address shared challenges, and collectively evolve, the web ecosystem becomes more inclusive and progressive. Furthermore, the podcast episode explored the empowering aspects of the Astro ecosystem, and TypeScript. The group elaborated on the latest updates and advancements in these tools, emphasizing their capacity to empower developers. Astro, renowned for its modern approach to front-end development, alongside the robust capabilities of TypeScript, equips developers with the means to craft scalable, maintainable code and exceptional web experiences....

May 1, 2024

1 min

TypeScriptAstro

File Based Routing with Expo Router

Introduction

What is Expo Router?

Features of Expo Router

Expo routing conventions

Route navigation

Layout Routes

Unmatched Routes

Groups

Shared routes

Arrays

Dynamic Route

Conclusion

Victor Umeh

You might also like

CSS Hooks: A new way to style your React apps

Next.js Route Groups

How to Handle Async Data Fetching Using CreateResource in SolidJS

What’s New for Astro & TypeScript + “Team Islands” with Elian, Josh, & Chris (Backstage @ CityJS Conf)

You might also like

CSS Hooks: A new way to style your React apps

Next.js Route Groups

How to Handle Async Data Fetching Using CreateResource in SolidJS

What’s New for Astro & TypeScript + “Team Islands” with Elian, Josh, & Chris (Backstage @ CityJS Conf)