DEV Community: Herbie

42: A Comprehensive Guide to Pipex

Herbie — Fri, 21 Apr 2023 08:34:49 +0000

Introduction

Pipex is a project you’ll likely encounter on your 42 journey, and one which may give you a bit of a headache. Its purpose is to teach you some basic UNIX operations, and will greatly help you in the completion of Minishell (a mandatory project you’ll face later).

Pipex focuses on three main concepts: pipelines, child processes and execution of commands. I will cover all three of these topics as best I can, and guide you through the main parts of the program.

Understanding the Whitelisted Functions

dup2(2)

dup2(2) helps you ‘replace’ open file descriptors. By default, FD 0, 1 and 2 are open and are set to stdin, stdout and stderr respectively. dup2(2) allows you to replace these with another FD, which you may obtain with open(2). This can be useful for redirecting output from one FD to another, like using printf(3) to print to a file instead of the terminal.

Here is an example of using dup2(2) to redirect the output of a process from the terminal to a file:

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main()
{
    int fd;

    fd = open("example.txt", O_WRONLY | O_CREAT, 0644);
    dup2(fd, STDOUT_FILENO);
    close(fd);
    printf("This is printed in example.txt!\n");

    return (0);
}

This program opens a file called example.txt and uses dup2(2) to redirect stdout to the file descriptor returned by open(2). This means that any output from printf(3) will be written to the file instead of the terminal. The file is then closed, and the printf(3) statement writes to the file.

access(2)

access(2) checks whether a process has permission to access a file or directory. It takes two arguments: the path to the file or directory, and a mode representing the type of access being checked. The mode is specified using constants such as R_OK, W_OK, and X_OK, which represent read, write, and execute permissions, respectively.

For example, the following program checks whether the process has read permission for the file example.txt:

#include <stdio.h>
#include <unistd.h>

int main()
{
    if (access("example.txt", R_OK) != -1)
        printf("I have permission\n");
    else
        printf("I don't have permission\n");

    return (0);
}

execve(2)

execve(2) is a system call that allows you to execute another program from within your program. It replaces the current process image with a new process image, effectively running a new program. It takes three arguments: the path to the program to be executed, an array of command line arguments, and an array of environment variables.

Here is an example of using execve(2) to run the ls command:

#include <unistd.h>
#include <stdio.h>

int main()
{
    char *args[3];

    args[0] = "ls";
    args[1] = "-l";
    args[2] = NULL;
    execve("/bin/ls", args, NULL);
    printf("This line will not be executed.\n");

    return (0);
}

In this code, the args array contains the command line arguments to be passed to the ls command. execve(2) is then called with the path to the ls command (/bin/ls), the args array, and NULL for the environment variables. This replaces the current process image with the ls command, and the output of ls -l will be printed to the terminal. The printf() statement after execve(2) will not be executed, as the process image has been replaced.

fork(2)

fork(2) is a system call that creates a new process by duplicating the calling process. The new process is known as the child process, while the original process is known as the parent process. After the fork, both processes execute the same code, but each has a separate memory space.

Here is an example of using fork(2) to create a child process:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
    pid_t pid;

    pid = fork();
    if (pid == -1)
    {
        perror("fork");
        exit(EXIT_FAILURE);
    }

    if (pid == 0)
        printf("This is the child process. (pid: %d)\n", getpid());
    else
        printf("This is the parent process. (pid: %d)\n", getpid());

    return (0);
}

In the above program, fork(2) is used to create a child process. The child process prints "This is the child process." to the terminal, while the parent process prints "This is the parent process." to the terminal. Both processes have a different pid and both exit after printing.

pipe(8)

pipe(8) is a system call that creates a unidirectional data channel that can be used for interprocess communication. The data written to one end of the pipe can be read from the other end of the pipe. Pipes are often used in combination with fork(2) to create a communication channel between parent and child processes.

Here is an example of using pipe(8) to create a pipe and communicate between two processes:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
    int fd[2];
    pid_t pid;
    char buffer[13];

    if (pipe(fd) == -1)
    {
        perror("pipe");
        exit(EXIT_FAILURE);
    }

    pid = fork();
    if (pid == -1)
    {
        perror("fork");
        exit(EXIT_FAILURE);
    }

    if (pid == 0)
    {
        close(fd[0]); // close the read end of the pipe
        write(fd[1], "Hello parent!", 13);
        close(fd[1]); // close the write end of the pipe
        exit(EXIT_SUCCESS);
    }
    else
    {
        close(fd[1]); // close the write end of the pipe
        read(fd[0], buffer, 13);
        close(fd[0]); // close the read end of the pipe
        printf("Message from child: '%s'\n", buffer);
        exit(EXIT_SUCCESS);
    }
}

In this code, pipe(8) is used to create a pipe, and fork(2) is used to create a child process. The child process writes the string "Hello, parent!" to the write end of the pipe using write(2), and then exits. The parent process reads the string from the read end of the pipe using read(2), and then prints it to the terminal using printf(3). The pipe is then closed in both processes using close(2).

unlink(1)

unlink(1) is a command that removes a file from the file system. It takes a single argument, which is the path to the file to be removed.

Here is an example of using unlink(1) to remove a file called example.txt:

#include <stdio.h>
#include <unistd.h>

int main()
{
    if (unlink("example.txt") == 0)
        printf("File successfully deleted");
    else
        printf("Error deleting file");

    return (0);
}

In this code, unlink(1) is used to remove the file example.txt from the file system. unlink(1) returns 0 if all the files were deleted, and -1 if an error occurred.

The Program

Parsing

This is the first step of your program. It needs to make sure the input is correct, and how to handle unexpected data. This includes handling here_doc, opening the infile and outfile, and, if necessary, exiting the program (this includes closing all open FDs, freeing all memory, and using unlink(1) to remove the temporary file from here_doc, we’ll get back to this later).

Your main function may follow a similar pattern to the below pseudocode. It’s a simple structure, and provides you with the potential to exit the program at any given stage.

main()
{
    ft_init_pipex()
    ft_check_args()
    ft_parse_cmds()
    ft_parse_args()
    while (cmds)
        ft_exec()
}

ft_init_pipex is used to fill your struct with some default data, which may otherwise cause problems with Valgrind, as you may conditionally check the properties within your struct in your cleanup function.

I have a function ft_check_args which simply opens all files needed and handles here_doc. You should be able to get away with a custom get_next_line to complete here_doc.

I recommend having two functions to parse and store the inputs: one which will find the correct path using envp and store it in an array, and the other which will contain the arguments to the program. This will then help you build the required arguments for execve(2).

In this scenario, ft_parse_cmds will create an array like this: ["/bin/cat", "/usr/bin/head", "/usr/bin/wc"], and the ft_parse_args will use ft_split to yield a 2D array like this one: [["cat"], ["head", "-n", "5"], ["wc", "-l"]] (remember to NULL terminate your arrays!). I recommend using a struct and storing all the data within it (see the struct I used below).

Execution

The core idea of this program is to mimic the data flow between programs. Running the below scripts in your terminal should output the same data (you need to use double quotes for commands with arguments):

# input from a file

$ < Makefile cat | head -n 5 | wc -l > out
$ ./pipex Makefile cat "head -n 5" "wc -l" out

# input from `here_doc`

$ << EOF cat | head -n 5 | wc -l >> out
$ ./pipex here_doc EOF cat "head -n 5" "wc -l" out

The ft_exec() is where the magic happens. I’m not going to give you the code for it, because that would be too easy, so I will again write it in pseudocode:

ft_exec()
{
    pipe()
    fork()
    if (child)
    {
        dup2()
        execve()
    }
    else
    {
        dup2()
        waitpid()
    }
}

After creating the pipe and creating the child process, the child runs the command and redirects the stdout from the command into the write end of the pipe using dup2(2). The parent then ‘catches’ the output from the read end of the pipe, and outputs it back to the stdin. This is the main mechanism behind the relationship between parent and child process.

You will however have to have a unique dup2(2) call for both the first and last command, as they need to be redirected towards the input/output that the user requested.

You may have noticed you can’t even use printf(3) as dup2(2) replaces stdout with other FDs. The best solution I found was to hijack my ft_printf and turn it into a dprintf(3), which essentially does the same, except we can specify an FD, which we set to 2 (stderr).

Cleanup

After all your code has executed (or if an unlucky malloc(3) failed), you will need to clean up all the open FDs, allocated memory, and potentially the temporary here_doc file. For this, it’s best to allocate all memory within a t_pipex struct, and conditionally close/free whatever is necessary.

My struct looked like this, and it allowed me to exit the program at any stage, provided I had the struct within the scope of my function.

typedef enum e_bool
{
    false,
    true
} t_bool;

typedef struct s_pipex
{
    int in_fd;
    int out_fd;
    t_bool here_doc; // use `int` if you prefer
    char **cmd_paths;
    char ***cmd_args;
    int cmd_count;
} t_pipex;

Common Mistakes

Not using unlink(1) to remove temporary files.
Using the wrong permissions when using open(2). The outfile needs to be opened with different permission depending on whether or not here_doc was used.
Not appending NULL to the end of argv in execve(2). Doing so may lead to an invalid read.
Not setting default values to your struct. This may lead to warnings from Valgrind (which shouldn’t cause a fail) if you use these properties in a conditional check (if, else, while, etc…).
Mishandling invalid commands. You may not face this issue depending on how you developed your program, but in mine, it was possible to get NULL in cmd_paths, due to the command being invalid. If that’s your case too, it’s not a problem, just make sure you know what you’re doing.

Conclusion

I hope this helped, feel free to share if it did. You can leave me feedback if you feel like there’s anything to add, or if you see any mistakes, just reach out to me on Twitter.

Thanks for reading 🙂

Additional Resources

tRPC: The best way to build APIs in 2022?

Herbie — Fri, 26 Aug 2022 11:24:00 +0000

[originally published here]

We all know the hassle of building APIs. You install Express, or Nest if you’re developing for a big project, maybe GraphQL, and then you have to make everything yourself. From relational mapping to TypeScript support across your server and client. But what if I told you there was an all-in-one solution for that?

Too good to be true you might be thinking; well I’m writing this to tell you it’s not.

What is tRPC anyway?

tRPC is essentially just a way to call code. Think of it like an API endpoint, but the tRPC lingo is a procedure.

“So we can create API with this new tool; what’s different?”

tRPC isn’t just a way to create procedures, it has much more under the hood.

⚡️ Fast - No code generation or run-time bloat
🧙‍♂️ Typesafe - From DB to client
✅ Safe - Input and output validation with Zod
🍃 Light - tRPC has zero deps (@trpc/client@9.27.0 is only 4.9kb gzipped)
🔋 Batteries included - Available for React, Next, Express and Fastify (can be used with Nuxt & SvelteKit but API may not be complete)
⛑ React Query support - All queries, mutations and subscriptions use React Query

How does it compare?

REST

The caveat with REST is the lack of standardization. Simply put, REST is an architectural style of mapping URL paths to entities, and then exposing different HTTP methods to get or mutate said entities.

This approach is intuitive to most developers but it lacks standardization across the server and the client. Think of it as an imaginary obscured line between both parties. Not great for DX…

GraphQL

GraphQL on the other hand is standardized and was made for the exact problem cited above. It removes the line between server and client and provides an exact schema of what the server is intending to respond with.

The caveats however are the fact you have to learn GraphQL syntax and there’s a lot of overhead when setting up a project.

A look at some code

Defining a procedure

First of all, it’s best to define the schemas. In my case, I’ll be querying PokéAPI, which is using REST, so I’ll manually define the expected response using Zod.

const pokemonSchema = z.object({
  count: z.number(),
  next: z.string().nullish(),
  previous: z.string().nullish(),
  results: z.array(
    z.object({
      name: z.string(),
      url: z.string(),
    })
  ),
});

Then we can define a procedure to fetch pokemon, with an offset input for pagination.

export const pokemonRouter = createRouter().query("findAll", {
  // Create input schema
  input: z.object({
    offset: z.number(),
  }),
  async resolve({ input }) {
    const res = await (
      await fetch(`https://pokeapi.co/api/v2/pokemon?offset=${input.offset}`)
    ).json();

    // Validate the response
    return pokemonSchema.parse(res);
  },
});

In the above example, if the input or output criteria are not met, an error is thrown. All in just 30 lines of code!

We then have to link the pokemonRouter to the main router. This is also done with the tRPC function createRoute, and can be easily added with .merge().

import { pokemonRouter } from "./pokemon";

export const appRouter = createRouter()
  .transformer(superjson)
  .merge("pokemon.", pokemonRouter);

export type AppRouter = typeof appRouter;

As you can see, we’re exporting the type of appRouter, we need to do this so TypeScript can infer our procedures, and for autocomplete! We can easily create hooks to call our code with the line below (this is only necessary if using in Next or React):

export const trpc = createReactQueryHooks<AppRouter>();

We can then consume the data in a component like so:

const Home: NextPage = () => {
  // ...

  const { data, refetch } = trpc.useQuery(["pokemon.findAll", { offset }]);

  // ...
};

In my case, as I added pagination, I’ve got some extra functionality to make it work. As most of that stuff is React Query, I won’t include it here, but feel free to check out the source code here.

Thoughts

Overall, I strongly believe that tRPC is here to stay. As more and more businesses adopt this technology, we are going to see a stronger ecosystem and wider support across front-end and back-end frameworks.

If you want to give it a go, you can head over to their website to check out more about it.

Hope this helped 😃

Benchmarking Bun & Next against Deno and Fresh

Herbie — Fri, 19 Aug 2022 12:16:35 +0000

Originally posted here.

Yes, you heard that right, we’re going to be comparing the most popular react framework Next to a fresh new framework called Fresh (pun intended). Next will be running with a new runtime called Bun (you can checkout more about that here) and Fresh will be running with Deno. I’ve written 2 applications, a simple counter app, and a more complex app that renders some Pokémon. I’ll be using Hyperfine to benchmark the results. All the apps will be available on Github.

How am I measuring the performance?

We’re going to be looking at 5 metrics:

First Contentful Paint (FCP): Measures the time from when the page starts loading to when any part of the page's content is rendered on the screen.
Largest Contentful Paint (LCP): Marks the point in the page load timeline when the page's main content has likely loaded.
DOM Content Loaded Listener (DCL): Marks the point when the page's initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading.
Time to Interactive (TTI): Measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.
Lighthouse: A tool developed by Google to measure a website’s performance using an average of six metrics.

*Some definitions above come from the Google Dev Tools. They do a great job describing these APIs, so I decided to put them here instead of trying to explain them.

These four metrics and an overall Lighthouse score will determine which of these two frameworks is the fastest.

Also, keep in mind I’m doing this locally, so we’re not going to be using Vercel or Deno Deploy in our benchmarks.

Counter (CSR)

Framework	FCP	LCP	DCL	TTI	Lighthouse Score
Next	0.07s	0.07s	0.07s	0.07s	100
Fresh	0.07s	0.07s	0.09s	0.09s	100

As you can see, both stacks are very similar in speed. Next beat Fresh very slightly but that would never make a noticeable difference for the end-user.

Pokémon (SSR)

Framework	FCP	LCP	DCL	TTI	Lighthouse Score
Next	0.15s	0.15s	0.15s	0.15s	100
Deno	0.10s	0.10s	0.12s	0.12s	100

But for Server Side Rendering, Deno & Fresh are faster by quite a big margin. FCP is 33% faster than with Next, and TTI is 20% faster.

What makes Fresh faster than Next?

Fresh does things a bit differently from Next. Here are the core reasons why:

No JS overhead: Fresh only ships JavaScript when it needs to. This might include, like our examples above a Counter. If we made a fully static site, Fresh would ship no JS whatsoever, limiting the load time on the client.
JIT runtime: Deno runs TypeScript out of the box, which means there is no build step like we see with Next and Vercel.
Island hydration: When Fresh does ship JS, it hydrates it only on the client with the necessary props.

It’s these main advantages that give it an edge over Next.

Thoughts

Will Fresh & Deno take over the web ecosystem anytime soon? I don’t think so. It will be a long time still before we see a shift from Next to Fresh. The developer experience using Fresh isn’t always great either. Their documentation is limited, and the community is still very small. However, there is great potential. I can see Fresh being production ready in less than a year from now.

Enough rambling on about Fresh, why don’t you give it a go: https://fresh.deno.dev/

Projects are on Github.

Thanks for reading 😃

Pushing the limits of TypeScript

Herbie — Mon, 15 Aug 2022 09:53:21 +0000

I often get stuck with TypeScript, and when I do, I want to throw my Mac out of the window. So I’ve created this article, to help you and I write better code. I’ll be updating this post when I stumbled upon new and useful TypeScript hacks. In the meantime, feel free to get inspired to create your own cool TS magic, or to just steal some code, I won’t judge… 😜

First index of array

You might want to get the type of the first index in an array, and if so, this utility type is for you.

type First<T extends any[]> = T extends [infer P, ...any[]] ? P : never;

It’s a rather simple utility type to help you infer the type of the first index of an array.

type Test1 = First<[() => string, "a", "b"]>;
//   ^ Test1: () => string

type Test2 = First<[undefined, 4]>;
//   ^ Test2: undefined

type Test3 = First<[]>;
//   ^ Test3: never

As a bonus, to get the last element of the tuple, change [infer P, ...any[]] to [...any[], infer P]!

If you’d like to use a variable of type tuple, you’ll be better off using the bracket notation to access the first element of the array, like this: T[0].

type First<T extends readonly any[]> = T[0];

And then pass the typeof your tuple.

const numbers = [1, 2, 3, 4, 5] as const;

type Test = First<typeof numbers>;
//   ^ Test: () => 1

Note: remember to cast your array as a const, using as const, TypeScript will then infer it as readonly [1, 2, 3, 4, 5].

Infer the type of each element when using map()

Let’s say you have an array of vowels, or string[]. Now, let’s say you want to loop over the array using Array.map(). You would have something like this:

const vowels = ["a", "e", "i", "o", "u"];

vowels.map((v: string) => {});
//          ^ v: string

An easy, yet underused approach is to cast the array to a tuple using as const. Doing so will allow Array.map() to return the possible values obtainable by Array.map(). So now, your code should lok something like this.

const vowels = ["a", "e", "i", "o", "u"] as const;

vowels.map((v) => {});
//          ^ v: "a" | "e" | "i" | "o" | "u"

Casting your array as a const does come with a drawback, however. You won’t be able to mutate it after the fact. That means no more Array.push(), Array.pop(), etc…

Getting the length of a tuple

TypeScript is really clever, as it lets us access the prototype of an element. So instead of regular JS, where we use Array.length, for TS Types, we can use any[]['length] to access the length. And if that array turns out to be a tuple, TS can directly infer the length!

type Length<T extends readonly any[]> = T["length"];

Using it is simple, either pass a tuple directly into the type…

type Test1 = Length<["a", "b", "c"]>;
//   ^ Test1: 3

Or, a more practical approach is to pass a variable of type tuple…

const letters = ["a", "b", "c"] as const;

type Test2 = Length<typeof letters>;
//   ^ Test2: 3

Reminder: the above method only works with variables of type tuple, so arrays unfortunately will not work…

Conclusion

That’s it! I hope this helped someone out there. I’ll be updating this post when I stumble upon some other fancy TS trick. In the meantime, you can check out this post about Bun. It’s worth the read; I promise.

Thanks for reading 😊

What’s the deal with Bun?

Herbie — Fri, 05 Aug 2022 16:02:00 +0000

If you stumbled upon this article, you’re probably wondering what Bun is. You’re in luck, as I’m about to tell you everything there is to know about Bun.

So what is Bun? Essentially, it’s a new JS runtime, similar to Node. Unlike Node, however, Bun is insanely fast. Like seriously, seriously fast. We’ll look at that later though, let’s first look at the existing problem with Node.

What’s wrong with Node?

Node has been around since 2009. Since then, the web and server ecosystem has vastly changed. Many of Node’s issues have been covered by the creator, Ryan Dahl (in this conference). A quick TL;DR is that Node doesn’t support built-in TypeScript, JSX, or Environment Variables. Moreover, its package manager, NPM, is famous for the node_modules folder of doom.

How is it so fast?

Bun is built with Zig, a low-level programming language with manual memory management. It uses the JavaScriptCore Engine, which tends to be a little more performant than Google’s V8 Engine.

Bun mostly accredits its speed to Zig, stating the following on their website:

Zig’s low-level control over memory and lack of hidden control flow makes it much simpler to write fast software.

Benchmarks

Jarred Sumner, has made numerous benchmarks on Twitter regarding the speed of Bun compared to Node and Deno. Below, I’m going to be running some tests locally to see if Bun really stands up to these other runtimes. In each test, the script will simply save a text file locally. I’m using Mitata to test the speed.

Testing Bun

// ./scripts/bun.js

import { write } from "bun";
import { bench, run } from "mitata";

const file = "./out/bun.txt";

bench("bun:write", async () => {
    await write(file, "hello world");
})

await run();

➜  bench bun ./scripts/bun.js
cpu: Apple M1
runtime: bun 0.1.6 (arm64-darwin)

benchmark      time (avg)             (min … max)       p75       p99      p995
------------------------------------------------- -----------------------------
bun:write   76.86 µs/iter    (64.79 µs … 2.35 ms)   75.5 µs 139.38 µs 246.17 µs

Testing Node

// ./scripts/node.mjs

import { writeFileSync } from "fs";
import { bench, run } from "mitata";

const file = "./out/node.txt";

bench("node:write", async () => {
    writeFileSync(file, "hello world");
})

await run();

➜  bench node ./scripts/node.mjs
cpu: Apple M1
runtime: node v18.7.0 (arm64-darwin)

benchmark       time (avg)             (min … max)       p75       p99      p995
-------------------------------------------------- -----------------------------
node:write   94.55 µs/iter   (65.92 µs … 29.59 ms)  78.29 µs 129.25 µs 217.13 µs

Testing Deno

// ./scripts/deno.mjs

import { bench, run } from "https://esm.run/mitata";

const file = "./out/deno.txt";

bench("deno:write", async () => {
    Deno.writeTextFileSync(file, "hello world");
})

await run();

➜  bench deno run -A ./scripts/deno.mjs
Download https://cdn.jsdelivr.net/npm/fs/+esm
cpu: Apple M1
runtime: deno 1.24.2 (aarch64-apple-darwin)

benchmark       time (avg)             (min … max)       p75       p99      p995
-------------------------------------------------- -----------------------------
deno:write  110.66 µs/iter    (74.25 µs … 5.88 ms) 129.79 µs 162.33 µs 179.75 µs

On all three occasions, a file was written to storage. Below is a table containing the runtime used, the native API used, and the final speed.

Runtime	API	Average Speed
Bun	Bun.write()	76.86µs
Node	fs.writeFileSync	94.55µs
Deno	Deno.writeTextFileSync	110.66µs

As you can see, Bun is clearly ahead of Node and Deno in terms of server-side operations. I say server-side operation, as Bun doesn't fare as well when using client-side operations. In an upcoming post, I’ll be comparing Bun + Next.js against Deno + Fresh.

Also, a quick reminder that Bun is still in development. What you’ve seen in this post may be irrelevant in a few months. Just keep that in mind.

Anyway, I hope you found this article helpful 😄

Please consider sharing + following

React Native custom theme selector

Herbie — Mon, 01 Nov 2021 18:15:05 +0000

Theming a mobile app can be a tricky thing to do, and quite daunting if you're new to the react native and javascript ecosystem. But I've tried to make this post clear and straightforward, so you shouldn't have any issues (and if you do, leave them in the comments).

Step 1 - Defining your colors

Create a file and add all of your colors to it (I added it to ./src/lib/constants.ts [see a live example here])

You don't have to stick with light and dark, you can add custom themes such as sepia or navy.

Step 2 - Create functions to communicate with the native storage API

You need to create two functions to communicate with the native storage provider. This serves two purposes

It persists the theme on the local device
Allows local storage access for web, iOS and Android

You will need to this package to manage local storage in React Native.

The functions will look something like this:

const os = Platform.OS   
const webStorage = window.localStorage    
const appStorage = AsyncStorage  

const getItem = async (key: string) => {     
  if (key) {
    return os === 'web'
      ? webStorage.getItem(key)
      : await appStorage.getItem(key)
  }  

  return null      
}    



const setItem = async (key: string, payload: string) => {
  if (key && payload) {
    return os === 'web'
      ? webStorage.setItem(key, payload)
      : await appStorage.setItem(key, payload)
  }      

  return null      
}

I saved this file here: ./src/lib/storage.ts

Step 3 - Creating a theme context

Due to the theme data being shared only with components, we can use React's Context API. This will provide a globally accessible state that you can use within all of your app. The context will hold two variables:

theme: 'light' | 'dark': you need this to know what theme is selected
setTheme: React.Dispatch<React.SetStateAction<'light' | 'dark'>>: this is to change the theme

The context will look something like this:

import { useColorScheme } from 'react-native'
import { getItem, setItem } from '../lib/storage'

export type ThemeOptions = 'light' | 'dark'

export interface ThemeContextInterface {
  theme: ThemeOptions
  setTheme: Dispatch<SetStateAction<ThemeOptions>>
}

export const ThemeContext = React.createContext<ThemeContextInterface | null>(
  null
)

const ThemeProvider: React.FC<{}> = ({ children }) => {
  // default theme to the system
  const scheme = useColorScheme()
  const [theme, setTheme] = useState<ThemeOptions>(scheme ?? 'dark')

  // fetch locally cached theme
  useEffect(() => {
    const fetchTheme = async () => {
      const localTheme = await getItem('theme')

      return localTheme
    }

    fetchTheme().then((localTheme) => {
      if (localTheme === 'dark' || localTheme === 'light') {
        setTheme(localTheme)
      }
    })
  }, [])

  // set new theme to local storage
  useEffect(() => {
    setItem('theme', theme)
  }, [theme])

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      {children}
    </ThemeContext.Provider>
  )
}

Step 4 - Creating the hook

The hook is the middleman between the state and the UI. Its main purpose is to deliver the correct colors based on the Theme Context.

The useTheme hook looks like this:

// import ThemeContext and your colors

export interface Theme {
  background: string
  backgroundVariant: string
  text: string
  variant: string
  secondary: string
  secondaryVariant: string
  accent: string
  success: string
  warning: string
  error: string
}

const lightTheme: Theme = {
  background: LIGHT_THEME_BACKGROUND,
  backgroundVariant: LIGHT_THEME_BACKGROUND_VARIANT,
  text: LIGHT_THEME_TEXT,
  variant: LIGHT_THEME_VARIANT,
  secondary: LIGHT_THEME_SECONDARY,
  secondaryVariant: LIGHT_THEME_SECONDARY_VARIANT,
  accent: SEMERU_BRAND,
  success: SUCCESS,
  warning: WARNING,
  error: ERROR,
}

const darkTheme: Theme = {
  background: DARK_THEME_BACKGROUND,
  backgroundVariant: DARK_THEME_BACKGROUND_VARIANT,
  text: DARK_THEME_TEXT,
  variant: DARK_THEME_VARIANT,
  secondary: DARK_THEME_SECONDARY,
  secondaryVariant: DARK_THEME_SECONDARY_VARIANT,
  accent: SEMERU_BRAND,
  success: SUCCESS,
  warning: WARNING,
  error: ERROR,
}

interface UseThemeHook {
  theme: Theme
  setTheme: Dispatch<SetStateAction<'light' | 'dark'>>
}

const useTheme = (): UseThemeHook => {
  const { theme, setTheme } = useContext(ThemeContext)!

  if (theme === 'dark') {
    return {
      theme: darkTheme,
      setTheme,
    }
  }

  return {
    theme: lightTheme,
    setTheme,
  }
}

Step 5 - Enjoy!

All you need to do now is to use it in your UI. Import useTheme and use it as you please!

An example of consuming the colors:

const App: React.FC = () => {
  const { theme } = useTheme()

  return (
    <View style={{ background: theme.background }}>
      ...
    </View>
  )
}

An example of mutating the colors:

const App: React.FC = () => {
  const { setTheme } = useTheme()

  return (
    <Pressable onPress={() => setTheme(prev => prev === 'light' ? 'dark' : 'light')}>
      <Text>Change theme</Text>
    </Pressable>
  )
}

And that's it!

There is however a step 6, and that simply involves liking this post and sharing on Twitter. I would really appreciate it :)