I will keep this short, since you can see the fully working code on Github here, and there are not that many changes since the last version.

Updates

The main difference is the file structure. In the previous version we only protected our routes by using a hook in our auth provider, but swiping back from the home page took you back to the login page, sometimes creating weird edge cases.

Now we use this file structure. The two folders (auth) and (public) helps us keep the authenticated paths protected.

This means that our AuthProvider now has this logic for protecting our routes:

function useProtectedRoute(user: User | null) {
  const segments = useSegments();

  useEffect(() => {
    const inAuthGroup = segments[0] === "(auth)";

    console.log(inAuthGroup);

    if (!user && inAuthGroup) {
      router.replace("/login");
    } else if (user && !inAuthGroup) {
      router.replace("/(auth)/(tabs)/");
    }
  }, [user, segments]);
}

Here’s is video on the finished results:

Conclusion

There you have it! Again, a super easy way to get a tab router in Expo Router v3 (Expo SDK 50). I’ve also thrown in Nativewind (tailwind) for styling.

Don’t forget to check out the repo on Github.

Hope this helps!

⚠️ Check out the new and improved Expo router v3 version: https://medium.com/@fredrik.burmester/bottom-tab-navigation-in-expo-router-3-sdk-50-with-authentication-b8d4529b2e0f

Introduction

In this tutorial, I will guide you through the process of setting up a bottom tab router using Expo Router, incorporating authentication routes and stack navigation. By the end, you’ll understand how to structure your files, create a tab router, and integrate authentication and stack routes. Check out the bottom of the article for a link to my git repo with a fully working example.

Step 1: File Structure

To get started, let’s organize our project’s file structure. Within the “app” folder, we will create two main groups: “auth” and “tabs”. Additionally, we’ll create two layout files and include all the desired tabs within the “tabs” group.

Inside the auth group, we create a single login file.

The other file routes can be whatever you want and will act as stacks, stacking on top of our tab navigation. If you instead want to navigate within the tabs navigation, you can nest navigations within the “tabs” folder.

- app/
  - (auth)/
    - login.tsx
  - (tabs)/
    - _layout.tsx
    - home.tsx
    - account.tsx
  - other.tsx
  - other/ 
  - _layout.tsx

Step 2: Layouts

Expo provides various layout options that you can use to create different navigation patterns and user interfaces. Some of the layout options are tabs, stacks, drawers etc.

Below I’ve created a tab router. The “initialRouteName” prop is set to “home”, indicating that the “home” screen is the initial screen displayed when the tab navigation is rendered. The “Tabs” component has multiple “Tabs.Screen” components. Each “Tabs.Screen” represents a tab screen. It defines the screen’s name and various options. This should correlate with the files in the file structure above.

// app/(tabs)/_layout.tsx

export default function TabsLayout() {
  return (
    <Tabs
      initialRouteName="home"
      screenOptions={{
        ...
      }}
      tabBar={(props) =>
        Platform.OS === "ios" ? (
          <BlurView
            style={{ position: "absolute", bottom: 0, left: 0, right: 0 }}
            tint={colorScheme == "dark" ? "dark" : "light"}
            intensity={95}
          >
            <BottomTabBar {...props} />
          </BlurView>
        ) : (
          <BottomTabBar {...props} />
        )
      }
    >
      <Tabs.Screen
        name="home"
        options={{
          href: "/home",
          tabBarIcon: ({ color }) => (
            ...
          ),
        }}
      />
      <Tabs.Screen
        name="account"
        options={{
          href: {
            pathname: "/account",
          },
          tabBarIcon: ({ color }) => (
            ...
          ),
        }}
      />
    </Tabs>
  );
}

Next is the main layout:

Defining the stack is not strictly necessary, but allows for more flexibility, allows for nice animations and allows us to differentiate between our tabs and other stack screens. Feel free to try replacing the <Stack /> (and everything in it) with <Slot /> and see what happens.

// app/_layout.tsx

import { AuthProvider } from "../context/AuthProvider";

export default function RootLayout() {
  return (
    <Stack
      screenOptions={{
        ...
      }}
    >
      <Stack.Screen
        name="(tabs)"
        options={{
          ...
        }}
      />
      {/* <Stack.Screen
        name="other"
        options={{
          ...
        }}
      /> */}
    </Stack>
  );
}

Inside each tab, make sure to export the function as such:

// app/(tabs)/account.tsx

export default function Account() {
  return ...
}

Step 3: Stack screens

All screens defined outside of the tab group will act as stack screens and stack on top of the tab navigation with a nice animation (if you define the stack layout above), allowing you to go back by pressing the back button in the upper left-hand corner.

Step 4: Authentication

I decided to include this part since many want to integrate authentication into their app and keep the rest of the app secure. Luckily it’s really simple!

Go back to the main _layout.tsx file and add your auth provider like so:

// app/_layout.tsx

export default function RootLayout() {
  return (
    <AuthProvider>
      <Stack>
       ...
      </Stack>
    </AuthProvider>
  );
}

The only extra code we need to add is within our AuthProvider. This is inspired by the auth tutorial in the Expo Router docs.

export function AuthProvider({ children }: { children: JSX.Element }): JSX.Element {
  
  ...
  useProtectedRoute(user);
  ...

  return <AuthContext.Provider value={authContext}>{children}</AuthContext.Provider>;
}

function useProtectedRoute(user: any) {
  const segments = useSegments();
  const router = useRouter();

  useEffect(() => {
    const inAuthGroup = segments[0] === "(auth)";

    if (
      // If the user is not signed in and the initial segment is not anything in the auth group.
      !user &&
      !inAuthGroup
    ) {
      // Redirect to the sign-in page.
      router.replace("/login");
    } else if (user && inAuthGroup) {
      // Redirect away from the sign-in page.
      router.replace("/home");
    }
  }, [user, segments]);
}

Conclusion

Here’s a link to my repo with a working example!

Thank you for following along with this tutorial. I hope you found it helpful in implementing bottom tab routers with auth and stacks in your Expo project. Happy coding!

For the better part of a week, I’ve been trying to set up FileRun in a docker container. Posting on r/unRAID for help and getting some awesome feedback. Now I’d like to share what I’ve learned!

I’d like to thank u/m-jeri for all the help setting up the container: https://www.reddit.com/r/unRAID/comments/an7225/trying_to_install_filerun_docker_container/
and u/theworldisweird_ for help with Nginx.

Prerequisites:

1. MariaDB (container already set up and working)
2. NginxProxyManager (container and port forwarding already set up and working)
3. A CNAME sub-domain that points to your external IP. (DuckDNS or similar is recommended).

Creating the database

Start by creating a user and a database in MariaDB that FileRun can use. And, of course, it’s recommended to use secure passwords. Here are all the commands you need to enter one line at a time (ignore the comments):

mysql -uroot -p; /* Enter your mariadb password when prompted. */
 CREATE USER '<user_name>' IDENTIFIED by '<user_password>'; /* Choose any username and password. */
 CREATE DATABASE IF NOT EXISTS <file_run_db_name>; /* Choose any database name. */
 GRANT ALL PRIVILEGES ON <file_run_db_name>.* TO '<user_name>' IDENTIFIED BY '<user_password>'; 
 FLUSH PRIVILEGES;
 exit

Now you have a DB that FileRun can use.

Data storage

Decide if you want to store all files within FileRun or link your current shares. If you want to link your shares you can create a folder within your appdata folder (or make it a share if you plan to store files in the FileRun instance) named filerun. Inside this folder, create three more, named: html, db and user-files. The file structure will look like this:

appdata 
 +- filerun
 | +- db
 | +- html
 | +- user-files

Installing the Docker container

Now we can start setting up the Docker container. The images below show how the container should look.

— Do not add Host Path 4 at the bottom. This is for step 7
 — Icon URL is: https://avatars2.githubusercontent.com/u/6422152?s=400&v=4
 — Fill in the fields that are blank in the image with your MariaDB username, DB and password and so on (i used filerun as username and mypassword as password everywhere to make it easy for myself, do not do this of course).
 — Note that host paths do not have a slash at the end, for some reason, it didn’t work for me with a slash.
 — Also note that you don’t need to change the WebUI. Leave it as http://[IP]:[PORT:8080]/.
 — You do not need to forward port 8080 in your router.

Start the container

You can now start up the container and enter the login credentials `superuser` and `superuser`.
Now you have a fully working FileRun setup. In the next step, I will explain how to access it from WAN with HTTPS.

NginxProxyManager

Open NginxProxyManager and create a new proxy host according to this:

The IP address is the address you entered in the container setup, which should be the IP of your unRAID server. Make sure the port is the port of your FileRun container. And because FileRun doesn’t natively run on HTTPS you should have HTTP selected.
On the next page, SSL, you should request a new certificate.
Now you have your FileRun instance running HTTPS accessed by https://filerun.mydomain.com. In the next step, I will show how to link your existing unRAID shares to your FileRun account.

Create a new user

Logged in to the superuser account, create a new user, go to permissions for that user and give it the path `/user-files/username` and click create folder now. (You choose your username.)

FileRun Permissions

Add the Host Path 4 mentioned in step 3. The container path should be /user-files/username. And host path should be /mnt/user if you want to add all your shares. If not, specify that share, like /mnt/user/Documents for example.

The problem is that all the files that FileRun creates are locked and if you try to access those files from another application or SMB share you will not have permission to do so. Therefore we have to change the permission of all files that FileRun creates. Go to where you placed your filerun folder and open `/mnt/user/appdata/filerun/html/customizables/config.php` if the file doesn’t exist then create it. And enter this:

<?php 
 umask(000);
 php?>

This is not considered safe because your files are not protected at all now.
See this for more info: https://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html

Hide certain folders from FileRun

Now if you’re like me and don’t want all shares showing up in FileRun you can add some lines to the `config.php` file to exclude them from FileRun.

<?php 
 umask(000);
 $config['app']['hidden_folder_names'][] = "appdata";
 $config['app']['hidden_folder_names'][] = "appdata-backup";
 $config['app']['hidden_folder_names'][] = "isos";
 $config['app']['hidden_folder_names'][] = "domains";
 $config['app']['hidden_folder_names'][] = "system";
 php?>

For more info: https://docs.filerun.com/advanced_configuration.

Now you have FileRun all set up and ready to go! Have fun!

I hope this helps someone in their journey or maybe teaches some of you something. I know that I’ve learned a lot from all this.

What are Cloudflare workers?

Cloudflare workers is a way of running serverless functions on the Cloudflare global network. You can run almost anything, like, APIs, chat apps and websites. For some examples, check out their examples page.

If you want to know more about how exactly workers work, check out their documentation on workers.

Setting up the Nuxt 3 project

Go to Nuxt 3 docs and follow the instructions to get a Nuxt app going.

Setting up GitHub Actions

When you have a Nuxt project up and running, the next step is to publish the app. There are a few ways to publish to Cloudflare: using wrangler with nitro, direct upload from the wrangler2 CLI or manually by uploading a folder with all the compiled files, creating a page from Cloudflare’s interface, or with Github actions. We will use this guide made by Nitro using wrangler2.

Creating configuration files

Start by creating an action for your repository. Do this by creating a file in the root of your repository

.github/workflows/<name>.yml

where the name is your workflow’s name, for example:

.github/workflows/cloudflare.yml

Next, we will fill this file with publishing instructions. We will define our build environment and the publish script inside this file.

name: cloudflare

on:
  push:
    branches:
      - main
      - develop

jobs:
  ci:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        os: [ ubuntu-latest ]
        node: [ 16 ]

    steps:
      - uses: actions/setup-node@v1
        with:
          node-version: 16

      - name: Checkout
        uses: actions/checkout@master

      - name: Cache node_modules
        uses: actions/cache@v2
        with:
          path: node_modules
          key: ubuntu-latest-node-v16-deps-${{ hashFiles(format('{0}{1}', github.workspace, '/yarn.lock')) }}

      - name: Install Dependencies
        if: steps.cache.outputs.cache-hit != 'true'
        run: yarn

      - name: Build
        run: yarn build
        env:
          NITRO_PRESET: cloudflare
          NUXT_API_URL: 'https://cms.fredrikburmester.com/'
          NUXT_SSR: 'true'

      - name: Publish to Cloudflare
        uses: cloudflare/wrangler-action@2.0.0
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}
          command: publish --name fb-nuxt-${{ github.ref_name }}
name: cloudflare

Build environment

As you can see, we are telling the action to publish on a push to the main or develop branch. We are using the latest ubuntu environment with node 16.

Nuxt 3 requires the node version to be >16 and <17. Setting the GitHub action node version to 17 will not result in 17.0.0 but rather the latest 17 version. Setting the GitHub action node version to 16 will result in the latest 16 version, for example, 16.8.0.

Caching node modules

We then cache the node_modules, for which several methods exist on the internet. Choose the one that suits you.

Building the application

We use yarn here to build the application but if you are using npm, then use the respective command.

By adding the env section, we can control some variables based on our environment, like dev och prod.

Publishing to Cloudflare

Usually, we don’t include the build command here. We typically opt out of the with command since it’s unnecessary if we do the next step as Nitro does in the guide. But we want to make environment-specific publications, and since using separate environments is not supported inside a single worker, we need to build separately named workers to act as prod and dev environments. We do this by suffixing the worker name with the GitHub repository branch name.

Wrangler setup

Next, we’ll look at the instructions in the guide I mentioned above. We will create a wrangler.toml file for some variables. We will exclude the name in this config since we set the name in the build command in the chapter above.

main = "./.output/server/index.mjs"
workers_dev = true
compatibility_date = "2022–10–17"
account_id = "<cloudflare_worker_account_id>"
[site]
bucket = ".output/public"

We tell wrangler where the files end up from the `yarn build` command, which is in ./.output/public, and we also set the main js file and the Cloudflare account id, which you can find in the Cloudflare console in the worker section on the right.

And that’s it! ✅

Now, this GitHub Action will kick in every time you push to your dev and main branch, building and pushing the Nuxt app to the Cloudflare edge network.