Forem: Richard Choi

React built-in hooks: useCallback

Richard Choi — Wed, 28 May 2025 21:32:53 +0000

If you didn't catch my previous React built-in hooks blog about useActionState, this is a continuation of that series.

Previously I was introduced to useCallback when I asked ChatGPT once to optimize my frontend code, but I never took a deeper look into it (and frankly I regret it now), so I used it everywhere I could along with useMemo (which I'll cover later in this series).

While it's not inherently a signficant bad thing to have useCallback all around your code, it can clutter up the readability of your code, but it's encouraged you use it where needed.

So when should you use it? useCallback is meant for expensive callback functions that are used in granular applications like drawing software, as it loads the initial function on render but does not re-render like React usually does with its functions unless the dependencies change.

app/components/menu.jsx

"use client";
import { useState, useCallback } from "react";
import axios from "axios";

export default function Menu({ setMenu, menu }) {
  const [newItem, setNewItem] = useState("");

  const handleClick = useCallback(async () => {
    try {
    if(newItem){
        const response = await axios.get("http://localhost:8000/menu");
        setMenu([{name: newItem}, ...response.data]);
    }else{
        const response = await axios.get("http://localhost:8000/menu");
        setMenu(response.data);
    }

    } catch (err) {
      console.error(err);
    }
  }, [newItem]);

  function addItem() {
    setMenu([...menu, { name: newItem }]);
  }

  return (
    <main>
      <button onClick={() => handleClick()}>Click</button>

      <input type="text" onChange={(e) => setNewItem(e.target.value)} />
      <button
        onClick={(e) => {
          e.preventDefault();
          addItem();
        }}
      >
        Add Item
      </button>

      {menu && menu.length ? (
        menu.map((item) => {
          return (
            <div key={item._id}>
              <section>{item.name}</section>
            </div>
          );
        })
      ) : (
        <>Something went wrong, please try again later</>
      )}
    </main>
  );
}

app/page.tsx

"use client"
import {useEffect, useState} from "react";
import axios from 'axios';
import Menu from "./components/menu.tsx";

export default function Home () {

const [menu, setMenu] = useState([]);
const [data, setData] = useState([]);

useEffect(()=>{
  async function getMenu (){
    const response = await axios.get("http://localhost:8000/menu");
    setData(response.data);
  }
  getMenu();

},[]);

  return(
    <main>
      {data.map((ele)=><>{ele.price}</>)}

      <Menu setMenu = {setMenu} menu = {menu}/>
    </main>
  )
}

My hope with this series is to bring underrated built-in hooks to light, as well as highlight some things you may not have known about familiar hooks.

React built-in hooks: useActionState

Richard Choi — Tue, 27 May 2025 20:18:34 +0000

This is the start of my React built-in hooks series, where I took some time to look at the React docs and have a deeper look into each respective built-in hook, even the ones I'm already very familiar with.

useActionState has some interesting use cases where it provides a way to store your state along with a loading transition for the action callback you pass for the form to trigger upon submission.

What this means is that by using a server function to grab your form input values by their unique name attributes, you're able to tell the code to wait for the form submission action to be completed before you're able to see the updated data.

Here is my demo, where you can see it in action (hehe). The code informs the user that it's currently loading until the form submission is complete. You can see this demonstration with the failed request in a delayed time to observe it in action and how quickly it runs without delay.

app/page.tsx

"use client"
import React, {useActionState} from "react";
import {addToCart} from "./hooks/addToCart";

export interface ICart {
  itemID: string,
  itemTitle: string,
  itemPrice: number,
  itemQuantity: number
}

export const cart: ICart[] = [];

function AddToCartForm({itemTitle, itemID, itemPrice}:{itemTitle: string, itemID: string, itemPrice: number}) {
 const [cartItem, cartAction, isPendingCart] = useActionState(addToCart, {itemTitle: "", cartID: "", itemPrice: 0, itemQuantity: 0});

  return (
      <form action = {cartAction}>
      <h2>{itemTitle} ${itemPrice}</h2>

      <input type="hidden" name="itemID" value={itemID} />
      <input type="hidden" name="itemTitle" value={itemTitle} />
      <input type="hidden" name="itemPrice" value={itemPrice} />
      <label>Add number of items to cart: </label><input type="number" name="itemQuantity"/>

      <button type="submit">Add to Cart</button>
      <span>{cartItem.message}</span>

      {isPendingCart ? "Loading..." : <section>
        <h2>{cartItem.itemTitle}</h2>
        <h4>{cartItem.total}</h4>
        </section>}
      </form>
  );
}

export default function Home(){
  return(
    <main>
      <AddToCartForm itemTitle={"Hatsune Miku shirt"} itemID = {"1"} itemPrice={12.12}/>
    </main>
  )
}

app/hooks/addToCart.ts

"use server"

export async function addToCart(prevState, queryData){
  const itemID:string = queryData.get('itemID');
  const itemTitle:string = queryData.get('itemTitle');
  const itemPrice:number = queryData.get('itemPrice');
  const itemQuantity:number = queryData.get('itemQuantity');

  const message = "Item was added to cart!"

  if (itemID && itemTitle && itemPrice && itemQuantity > 0) {
    const total = itemPrice * itemQuantity
    return {itemID, itemTitle, itemPrice, itemQuantity, message, total};
  } else {
    // Add a fake delay to make waiting noticeable.
    await new Promise(resolve => {
      setTimeout(resolve, 2000);
    });
    const total = itemPrice * itemQuantity
    const message = "Enter a valid quantity!"

    return {itemID, itemTitle, itemPrice, itemQuantity, message, total};
  }
}

My hope with this series is to bring underrated built-in hooks to light, as well as highlight some things you may not have known about familiar hooks.

My thoughts on Pieces

Richard Choi — Wed, 20 Nov 2024 17:18:56 +0000

There are a lot of AI tools to choose from in our current climate of AI. I ended up trying Pieces because I met some of their team members at THAT conference WI. It was free, and I figured why not at least give it a try. To this day, I still use it throughout my workday; however it's far from perfect, and I want to talk about it all: the good, the bad, and my overall thoughts.

What is Pieces

So what even is Pieces? To oversimplify it, Pieces is a Copilot AI tool. But it's more than that. It also lets you choose which LLM model you want to use. So if you're more particular to Claude, you can use it, or if you prefer ChatGPT, you can use that instead.

Offline features

You can also use it offline, giving you access to the many features Pieces currently provides without worrying about the quality of your internet connection.

Because it goes offline, you also never have to worry about any of the information you upload to the prompts being exposed because it's all on the device, unlike using ChatGPT on its own.

Code Snippets

If you want to save code snippets, you can do so by using the browser of your choice and the Pieces browser extension.

There are also code editor extensions like the Visual Code extension to give you access to Pieces while you're coding. This allows users to continue coding while reducing the need to keep going back and forth between coding and ChatGPT, allowing the user to stay focused on their code.

Long-term memory

Pieces also has a feature called Long Term Memory as of writing this blog, where you are able to upload files and folders to it. The files and folders provide the AI LLM model with the proper context to give you a more accurate answer for your prompts by using the content you provided.

What could Pieces improve on?

No product is perfect, and this also applies to Pieces. As of writing this blog, there are a few things I think Pieces as a product could be improved upon. For context, I'm using a Windows OS device.

Pieces OS

Firstly, it's inconvenient having to click on the prompt boxes every time I update the Pieces OS, especially since I have to open up the dropdown menu for both of them if I want to make my selection of network. I should only have to do these prompts once when I download Pieces initially.

Considering that Pieces OS needs to be running in the background for any Pieces features to work properly, I wish there was a hot key to run Pieces OS and disable it as well. I'm not sure if this is actually possible, but it would be very nice to have.

Long-Term Memory

When I want to use the Long Term Memory feature and upload a file or folder to provide context, the pop-up window gets hidden from view and I have to click in the taskbar to continue. This seems to be an issue specifically for Windows users, and this also has been occurring for the Pieces code editor extensions as well.

Snippets

I'll be very honest with you: I don't use the saved snippets feature for Pieces. The biggest reason is that I really like the convenience that Ctrl + C and Ctrl + V provide. There's less friction to copy and paste a code snippet versus opening up Pieces OS, downloading the Pieces browser extension, clicking on the copy code snippet button, and then pasting it.

Copilot

The quality of Pieces Copilot is based on the LLM models you select - Claude, ChatGPT, Gemini, Bison, etc. So I would recommend experimenting around with them since Pieces provides the platform to do so, especially since Pieces is free at the moment.

However, I should add that a lot of the LLM models have been configured to focus primarily on technology-based prompts, so if you're looking to use it for your everyday use, this product may not be for you.

As of writing this article, if you want to edit, delete, or use a prompt as context, you need to scroll all the way to the top in order to do so. This feels like a lot of scrolling as a user, and it discourages me from using any of those features in the first place. Thankfully you're able to copy the prompts by right-clicking on them.

Would I recommend the product?

Honestly, it's hard to say. With the recent hype of AI and the rampant increase of AI tools, it can be hard for me to recommend AI tools. Pieces still have ways to go as a product, but there is definitely potential there.

I would take everything you read in this article into consideration in order to determine if Pieces is the right product for you. If you would like to go deeper into what Pieces offers, I would take a look at their documentation.

Reach out to me here:
My Twitter
My Linkedin
My Bluesky
My Instagram

Zero to Hero: Building a Full-Stack App with PropelAuth, Vite, Typescript, Express, and MongoDB

Richard Choi — Mon, 18 Nov 2024 18:41:49 +0000

Have you ever built your Javascript full-stack applications and wanted to integrate seamless and secure authentication without setting up all the backend for the authentication logic? We’re going to build a full-stack application that does this using Propel Auth, a team-based authentication platform for B2B SaaS applications, with Vite as the framework, Typescript as the frontend, Express as the backend, and MongoDB as the database to store our data.

So why Propel Auth? Not only does Propel Auth allow a variety of authentication options like 2FA or SAML, it also allows you to manage your relationships with the created users, improving the overall user experience.

Setup Vite

We will need to set up the foundations of our application first, so use the command below and follow the wizard prompts for React and Typescript. Feel free to customize the project name, but for the sake of this example, we are going to call this project VTuberHub.

npm create vite@latest

Make sure to install the packages to run your Vite app, and test it locally to make sure you set it up correctly. Now that we have our framework set up, we can start working on setting up our Database!

Setup MongoDB

If you don’t have an account, you can sign up for a free account at the MongoDB site. Create an organization and customize the name for your purposes, but we will be calling it My-Project for this example.

Do the same for your project and its name.

Deploy your new cluster, where your Database will be located. For the sake of this example, we will be calling it Vtubers.

We are almost finished with setting up our database! Make sure to configure who has access to the Database under the Database Access sidebar navigation and set up a password for the user, we will need this for later.

Setup Propel Auth

If you haven't already, make sure to create a PropelAuth account. You'll want to create your project and give it a name. For this article, we'll be calling it my project.

We'll need to install propel auth to our project by using the following command:

npm install @propelauth/react

Go to Frontend integration and enter http://localhost:5173 under the Application URL input box. This way, we can tell Propel Auth where our Vite application is running locally, allowing requests like POST or GET from our project.

You'll need to copy and paste your Auth URL into your .env file so we can access it later.

VITE_AUTH_URL=https://something.propelauthtest.com

Make sure to set up your main.tsx properly for Vite by wrapping our application in the AuthProvider component so we can fetch the current user's authentication information.

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import App from "./App.tsx";
import "./index.css";
import { AuthProvider } from "@propelauth/react";

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <AuthProvider authUrl={import.meta.env.VITE_AUTH_URL}>
      <App />
    </AuthProvider>
  </StrictMode>,
);

Now we're all setup with our frontend, lets build a simple UI toggle depending on if the user is signed in or not!

import {
  withAuthInfo,
  useRedirectFunctions,
  useLogoutFunction,
  WithAuthInfoProps,
} from "@propelauth/react";

const YourApp = withAuthInfo((props: WithAuthInfoProps) => {

  const logoutFunction = useLogoutFunction();
  const { redirectToLoginPage, redirectToSignupPage, redirectToAccountPage } = useRedirectFunctions();

  if (props.isLoggedIn) {
    return (
      <div>
        <p>You are logged in as {props.user.email}</p>
        <button onClick={() => redirectToAccountPage()}>Account</button>
        <button onClick={() => logoutFunction(true)}>Logout</button>
      </div>
    );
  } else {
    return (
      <div>
        <p>You are not logged in</p>
        <button onClick={() => redirectToLoginPage()}>Login</button>
        <button onClick={() => redirectToSignupPage()}>Signup</button>
      </div>
    );
  }
});

export default YourApp;

Looks good, now let's start working on our backend so we can add data to our database from our frontend!

Setup Backend

We’ll need to now set up our backend so we can handle our frontend requests to send data to our Database. Make sure to create a separate folder for your backend before initializing the express backend using the following command:

npm init -y

We will need to install certain dependencies for our example application needs. Outside of Express and MongoDB, we will be using the dotenv package to prevent exposing our environment variables, and the cors package to enable our users to access our backend API requests.

 npm i cors dotenv express mongodb

Once we install all our packages, we will need to import them into our backend code logic using the require() function. Make sure to use the cors function to enable its use by frontend users, the critical function express.json() for JSON data handling, and the express server hosting for the backend.

require('dotenv').config();
const express = require('express');
const app = express();
const cors = require('cors');

app.use(express.json());
app.use(cors());

// Start the server
app.listen(3000, () => {
  console.log('Server running on port 3000');
});

Now we need to set up the connection from our backend to the MongoDB database we just created. Remember the password I mentioned in the MongoDB set up section?

We need it here for the MongoDB connection URL, which you can find in Clusters → Connect → Drivers → Copy the MongoDB connection string and replace the password with the one you created in the MongoDB setup section. This is the connection URL you will be using in your .env file to protect exposing it, and for the sake of this example, we will be calling it MONGO_URL. Make sure your .env file is in the same folder as your backend files so they can grab the MONGO_URL environment variable.

Connect your MongoDB client with the backend and make sure your backend is properly connecting to MongoDB before proceeding forward.

const { MongoClient, ServerApiVersion } = require("mongodb");
const mongoUrl = process.env.MONGO_URL

const client = new MongoClient(mongoUrl,  {
    serverApi: {
        version: ServerApiVersion.v1,
        strict: true,
        deprecationErrors: true,
    }
});

async function run() {
  try {
    // Connect the client to the server (optional starting in v4.7)
    await client.connect();
    // Send a ping to confirm a successful connection
    await client.db("admin").command({ ping: 1 });
    console.log("Pinged your deployment. You successfully connected to MongoDB!");
  } catch(error){
    res.send(`Error connecting to server, ${error}`)
  }
}

run().catch(console.dir);

Now for our final step, we gotta let our backend accept CRUD requests so we can create documents in our Database.

const myDB = client.db("myDB");
const myColl = myDB.collection("users");

app.post("/createVtuber", async(req, res) => {
  try{
    const result = await myColl.insertOne(req.body);
    console.log(
       `A document was inserted with the _id: ${result.insertedId}`,
    );
  }catch(err){
    res.send(`error sending request, ${err}`)
  }

});

Frontend

Time to finish up our Frontend, we still need to make the actual request to our backend and send our data! We’re going to install the Axios package to handle our API requests from the frontend.

 npm i axios

Now we can create a function to make the POST request for our button!

import axios from "axios"

async function addDB(){
 await axios.post("http://localhost:3000/createVtuber", {name: "hatsune miku", colors: "blue"});
}

const YourApp = withAuthInfo((props: WithAuthInfoProps) => {
  const logoutFunction = useLogoutFunction();
  const { redirectToLoginPage, redirectToSignupPage, redirectToAccountPage } = useRedirectFunctions();

if (props.isLoggedIn) {
    return (
      <div>
        <p>You are logged in as {props.user.email}</p>
        <button onClick={() => redirectToAccountPage()}>Account</button>
        <button onClick={() => logoutFunction(true)}>Logout</button>
        <button onClick={() => addDB()}>Create Vtuber</button>
      </div>
    );
  } else {
    return (
      <div>
        <p>You are not logged in</p>
        <button onClick={() => redirectToLoginPage()}>Login</button>
        <button onClick={() => redirectToSignupPage()}>Signup</button>
      </div>
    );
}}

Of course, our data wouldn’t be statically hard-coded like this, we would use state management to manage our data.

But we don’t want just anyone using our backend, right? So let’s make it so only authorized users are able to access our backend.

Adding authorized users

Going back to our backend folder, we’re going to install Propel Auth for express.

npm i @propelauth/express

Make sure to grab your Propel Auth URL and API key, which you can find under Backend Integration in our Propel Auth project dashboard. We will be storing these values in our backend .env file as well, which for the sake of this example will be called AUTH_URL and SECRET_KEY.

We’ll need to import initAuth to initialize the authentication services in our backend and add our AUTH_URL and SECRET_KEY variables into the initAuth method.

const { initAuth } = require("@propelauth/express");

const {
    requireUser,
} = initAuth({
    authUrl: process.env.AUTH_URL,
    apiKey: process.env.SECRET_KEY, 
});

app.post("/createUser", requireUser, async (req, res) => {
  try {
    const result = await myColl.insertOne(req.body);
    console.log(`A document was inserted with the _id: ${result.insertedId}`);
  } catch (err) {
    res.send(`error sending request, ${err}`);
  }
});

For our frontend, we just have to add the access token to our headers when we make our POST request, and if we’re signed in, we will have the proper authorization to make the request to our backend server.

  async function addDB() {
    const data = await axios.post(
      "http://localhost:3000/createUser",
      {
        name: "hatsune miku",
        colors: "blue",
      },
      {
        headers: {
          Authorization: `Bearer ${props.accessToken}`,
        },
      }
    );
  }

So our frontend should look like this:

 async function addDB() {
    const data = await axios.post(
      "http://localhost:3000/createUser",
      {
        name: "hatsune miku",
        colors: "blue",
      },
      {
        headers: {
          Authorization: `Bearer ${props.accessToken}`,
        },
      }
    );
  }

Use Tailwind/CSS to make the app look pretty, and voila! Our example full-stack application is finished, and we know how to integrate Propel Auth with Express, Vite, TypeScript, and MongoDB. For a deeper dive into Propel Auth and what it provides, look into their API Key Authentication, or how they manage role permission.

Low-Level Documentation

Richard Choi — Tue, 05 Nov 2024 13:33:11 +0000

Frontend: TypeScript

Problem:

We need to decide what frontend technology stack we want to use alongside Next.

Solution Requirements:

The technology stack needs to be compatible with Next
The technology stack needs to offer features that will make development more smooth

Solution:

TypeScript will be used to check the types of all possible data types within the code without having to write any additional code for conditional statements to check for data types. Also, Typescript provides an easier debugging experience, as it always catches errors in the code without having to run it.

TypeScript is a bit more complex when going in deeper, but on the surface level, it is quite easy to pick up if you already know React; if you know HTML and JS already, you are halfway there.

Detailed Design:

The intent is to use TypeScript for components and elements of the code that would benefit greatly from the type-checking nature of TypeScript.

import {countContext} from "../components/Context"
import {useStore} from "../components/Zustand"
import api from "../api/api"
import {Test} from "../components/Test"
import {Values} from "../components/Values.tsx"

export default function Home(){
    return(
        <main>
            {Test({firstName: "Mumei", lastName: "Nanshi", "email": "mumei@email.com", age: 26})}
            {Values({firstName: "Mumei", lastName: "Nanshi", "email": "mumei@email.com", age: 26})}
        </main>
    )
}

The Test and Values components have identical arguments passed through them to demonstrate the similarities and differences between React and TypeScript components.

React Component

export function Test(values){
  return(
    <main>
      {values.firstName}
      {values.lastName}
      {values.email}
      {values.age}
    </main>
  )
}

TypeScript Component

import React from "react"

interface Test{
firstName: string,
lastName: string,
age: number,
email: string
}

export function Test(values: Test){
  return(
    <main>
      {values.firstName}
      {values.lastName}
      {values.email}
      {values.age}
    </main>
  )
}

The Test component here demonstrates what it would look like to use a component in React, and the Values component demonstrates what it would look like to use the same component in TypeScript.

See Figma Example of using Typescript in the Gridiron Survivor application

Here, a simple design has been created to demonstrate a use-case for TypeScript, where the type-checking in TypeScript is used to ensure that all the data values are the appropriate data types.

Tests

TypeScript detects errors in code without running it, otherwise known as static checking. It also checks the types of any data type (obj, string, number, etc), making sure to send warnings when the wrong data type is being used or passed through. There is also the option of printing the code output to the console to ensure that the code is working as intended.

Sources

TypeScript Official Documentation

Module Builder: Webpack 5

Problem:

We need a module builder that will handle the bundling of our JS application and allow us to configure the particular type of build.

Solution Requirements:

The module builder needs to be compatible with Next.js
The module builder needs to be able to handle the bundling of our JS application
The module builder needs to allow the configuration of the type of build

Solution:

Webpack 5 is included upon installation of Next, and it let you bundle your JavaScript applications, supporting both ESM and CommonJS. They also allow the configuration of the type of build for your application.

Detailed Design:

Upon creating a new Next application using the create-next-app@latest command, the following default configurations for Webpack 5 will be shown in the tsconfig.json file.

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts", "jest.config.ts"],
  "exclude": ["node_modules"]
}

What each property means for Webpack 5:

Next Create App Features

Target: tells runtime code to generate in a specific environment

Lib: defines the libraries that will be included in the compilation process

AllowJs: enables the compilation of JavaScript files

SkipLibCheck: skips the type checking of declaration files (files with .d.ts extensions)

Strict: enables strict type-checking options mode for TypeScript

Noemit: prevents TypeScript from emitting output files

Esmoduleinterop: enables the compatibility between ESmodules and commonJS

Module: specifies the module code generation

Module resolution: determines how Webpack will resolve modules

ResolveJsonModule: allows TypeScript to import JSON modules directly

Isolated Modules: ensures each file is treated as a separate module. This can improve build performance

JSX: specifies JSX factory function to use.

Incremental: enables incremental compilation, allowing TypeScript to cache compilation results and speed up subsequent builds

Plugins: an array of TypeScript plugins

Paths: defines path mapping for module imports

Include: specifies files to include in TypeScript compilation

Exclude: specifies files to exclude in TypeScript compilation

Resources:

Next official documentation on Webpack 5 Adoption

Next official documentation on configuring your custom webpack

Webpack official website

Routing: Next App Routing

Problem:

We need a way to create different pages so the user can navigate through the application

Problem Requirements:

The feature needs to be able to allow the creation of new pages, where each new page will represent a new route domain within the application

Solution:

Next Routing moves to different pages of the application while remaining a single-page application. It is also automatically available upon installing Next, and there is a simple setup available upon creating a new Next application using the create-next-app@latest command.

The goal is to assign different pages to different elements of the application. Not only to be able to organize the code into separate pages but also to find a way to host an API and/or HTTP requests for the application.

Detailed Design:

Without requiring a separate application to host the backend and receive the HTML requests that will be made, the API Routes will allow us to define our API routes in our application. Not only will this be more convenient, but this will also save time and make collaboration between the backend team and the frontend/functional team more smooth and streamlined.

Figma Design Example of using Next Routing in the Gridiron Survivor Application

The idea is to have a separate page for the main component, ie. a page for authentication called pages/authentication, a page for the user profile called pages/userProfile, etc.

App Router Setup:

Github Repository Example of using Next App Routing

Page Router Setup:

Github Repository Example of using Next Page Routing

Testing:

For the API routes, print to the console to make sure that each API route is being registered properly and it was set up properly.

Resources:

Next official documentation on building your application routing

State Management: Context API and Zustand

Authors: Richard Choi

Problem:

We need a way to manage all of our states while avoiding the pitfall of prop drilling
We need a way to re-render our entire application upon successful authentication to prepare the authenticated content post-authentication

Problem Requirements:

It needs to be able to not only store the state and the state values but also make them available on every level of the application to prevent prop drilling
It needs to be able to cause the entire application to re-render for authentication and post-authentication

Solution:

Context API and Zustand manage your states, making them available at any level of the application. If set up correctly, Context API can cause the entire application to re-render and make the data globally available throughout the application, while Zustand focuses more on the individual level of making the states and state values available in the application.

Both solutions avoid the pitfall of using prop drilling, as they can be made available at any level of the application. They make states more organized, giving the other team members a better understanding of each state's usage, and functionality, and it makes it easier for them to navigate through.

Detailed Design:

They handle state changes, mostly from input, and they also allow us to access all kinds of data from any level of the application using Zutand and Context API.

Zutand: Setup state store in a separate file, and categorize each store object into the respective components, creating nested stores when/if necessary. Access the necessary store(s) from the file path including the Zutand stores, and reinitialize variables to access the necessary states/functions/values from the Zutand store objects.

Context: Setup context middleware file/folder, accessing the created context to wrap the context provider around the components that need to access the respective data/states. Implement the states/values/functions using the value property, and access them from your controlled child components using the useContext hook.

Figma Design Example of using Zustand States and local States in the Gridiron Survivor Application

Next App Zustand Setup

Github repository example of using Zustand in a Next application

Tests

Upon creating a state and path for them, we intend to print to the console to test if the states work properly by printing the values that correspond to the state. We will know when these features stop working when the console prints out undefined/null/falsy values.

Launch

To launch these features, one must change/update the state value that corresponds to the state manager. To monitor the state managers, the React Developer Tools are a good way to determine what is being re-rendered upon a state update.

Resources

Zustand Official Documentation

Documentation about the React hook useContext

React official documentation on Passing Data Deeply with Context

Caching: Session Storage and Local State

Authors: Richard Choi

Problem:

We need a way to persist our data so that when the user leaves the application tab or refreshes the screen, the data will remain upon returning

Problem Requirements:

This feature needs to be able to persist data regardless of refresh or exiting the tab
This feature also needs to be able to be timed out after a certain amount of time to ensure the data does not persist forever

Solution:

Session storage only maintains the session/data of the current tab/page. A new one is created every time a new tab is created. Local state only maintains the data when exiting the tab, not the window, and does not maintain the data upon refreshing the screen.

They help us maintain the data on screen/for code despite other circumstances. They also provide convenience to the user, so if they input something, but they accidentally exit out of the program, their “place” is “saved” thanks to cache storage. It gives a kind of safety net for other team members when testing the application, preventing them from “losing” their “saved data” from an accidental click/exit. Context API can be used to re-render the entire application to implement localization and to ensure content is rendered upon successful authentication.

Detailed Design:

Figma Design Example of using Cache in the Gridiron Survivor Project

Have objects to represent all the session storage/local storage we plan to use, using unique names for each object and key name, and store them all in one file called cache. Export those objects, and import them into components that need to access those cache data to implement more clean and organized code.

Testing:

Print to the console for session storage to make sure that the values are being saved properly, or you can also use the inspect tool, and under the application tab under storage, you can visibly see the different properties you have to check the values of them all.

Resources:

MDN documentation about session storage

Consistency is King, and here's why.

Richard Choi — Mon, 04 Nov 2024 14:00:25 +0000

Have you ever started something but never finished it, like learning a new language, a regimented workout routine, or a coding application? I have. Frankly, it was too many times to count, and I became tired of it.

So what did I do? I did what any good developer does: break down the problem into digestible chunks and tackle them one by one. So I bought a journal and wrote down those chunks into actionable items I wanted to accomplish for that day, like stretching, building a component, or writing the introduction of a blog 😉, and I would work on those actions daily to build towards accomplishing the overall goal.

What you do doesn't need to accomplish a lot nor does it need to be every day. They can be small items like walking outside for 5 minutes every day or practicing piano for 10 minutes every Monday. It may seem like these small items won't achieve anything on their own, but that was never the goal.

We want to build up a good habit by making the process as frictionless as possible to introduce a new activity into your daily schedule, and then iterate on it as we continue doing it daily. For instance, once we are consistently drawing for 10 minutes every weekday, we increase the period we're drawing for from 10 minutes to 20 minutes. Then when we're comfortable drawing for 20 minutes, we increase it to 30 minutes, and so on.

Does this even work?

You may be reading this and thinking: does this method truly work? Well, dear reader, I have a real-life example that perfectly showcases this approach in action, all starting with me doing small bit-sized daily tasks, and then eventually having them grow into fully-fledged habits and transforming myself to be highly adept and skilled at said activity.

Drawing

I always wanted to draw ever since I watched Avatar the Last Airbender, but I didn't know how. It seemed intimidating at first to approach, with all the complicated lines and details. But I was determined. There were so many cool things I wanted to be able to eventually create on a piece of paper on my own, so I started small.

My Beginnings

Pokemon was my main source of learning from the beginning, and I was struggling. I tried to trace to make the start easier for me to transition into free-form drawing, but it was a lot of hard and consistent work. Eventually, I was able to get to a point where I had drawn enough Pokemon daily and I got my drawings looking aesthetically good.

Experimenting and familiarizing

So I kept going, pushing myself to iterate on what I had already accomplished. I started drawing anime and cartoon characters, familiarizing myself with the general anatomy of humans and how to translate it into paper. I also started experimenting around with ink outlines and color. I wasn't at the point where I could call myself an artist, but I was slowly moving the needle one small step at a time.

Seeing progress

Every day I would draw, and bit by bit I would see progress. I would start being able to identify specific parts of my drawings that could be better or specific parts of my drawings that I did well on. The difference between my current drawings from my Pokemon drawings was becoming bigger and bigger, and I was able to visibly see the progress I was making as an artist.

Expanding my possibilities

I could have stopped here, but I wanted to keep improving and keep experimenting around. I wanted to see what else I could accomplish. So I started shading, and honestly, my shading at the start had a lot to be desired. Looking back at it now, I sort of cringe at the quality I had produced. But this feeling of cringe was also a positive feeling because it showed that at the time I was able to recognize what my past self needed to work on, establishing the evolution I had undergone since I started.

Learning from failure

I continued to push myself into projects that seemed too intimidating or larger than what I felt I could do. There were numerous amounts of failures, drawings that took hours only to turn out badly or to be thrown away. But from those failures, I was able to discover what not to do for future drawings.

Current Me

Stretching myself to the upper limits of my art skills, I started moving towards drawings that would take multiple days to finish. I was transitioning from finishing a drawing every day to working on one drawing every day. They were much bigger projects, taking more energy and more care into each of the details, but seeing the end results of the projects and the progress I was making was worth it.

So what now?

Take it upon yourself to find that one activity you have always wanted to do, like finish a coding project, or working out every day, and break them down into smaller, more digestible actions.

So let's take our coding project example, if we assume it's a simple full-stack web application, we can break this down into the following: frontend, backend, and hosting. But we can break this down even further, where the frontend can be separated into the following categories: testing, components, design, pages, error boundary, etc.

Lets break this down even more, where we separate it into the pages we want to implement: home, login, signup, account, cart, shopping hub, etc. Then one more time for good measure with the login: labels, text and password inputs, login button, login function, and login data state management.

Now we have it where we're just building the code for one login button instead of a whole frontend. We have an actionable step and a specific direction we can go towards, and while it's a slow journey to our destination, it's much more manageable and flexible. After all, slow and steady wins the race.

See me being consistent in the following social platforms:
My Twitter
My Linkedin
My Bluesky
My Instagram

My journey

Richard Choi — Wed, 04 Sep 2024 17:14:21 +0000

What does a journey look like for you? For me, it has been an ongoing journey that started 2+ years ago. Every journey needs a good beginning, and mine is quite literally the opposite of what you would call a "good" beginning. I was stagnant, listless, bored, and empty: words that could easily describe a long wait at the DMV. I only chose my major out of necessity, not out of desire, passion, or ambition. My job selection was no different, randomly selecting job applications and going through the daily motions. The only passions I had to cling to were my love for drawing, watching anime, reading manga, and listening to music.

It seemed like this would be how the rest of my life panned out, but there was no self-realization regarding this. Not yet, anyway. Turns out, all I needed was a chance to self-reflect and analyze my life choices, and Co-Vid was my golden opportunity. I had finally escaped, and I felt free to re-examine myself and started finding ways to challenge my current career path. I realized I felt unsatisfied and frustrated at my current state, and I needed to take action to change this. So I took a risk, a big one: I quit my job to search for part-time jobs. It was time to start taking control of my life, and I had to ask myself: what career field do I want to pursue? I had always been interested in computers and decided to give that an opportunity. My initial thought process was to apply for an online college to get my CS Bachelor's degree. However, I quickly realized the price was not worth it for me, and I dropped out as fast as I could.

I moved on to the self-taught path, where I found myself trapped in what is famously known as "tutorial hell" among developers.

From tutorial to tutorial, I jumped and leaped and tripped and dropped. Nothing was sticking, I felt overwhelmed and lost, and I had no idea where the start line was. That was until I discovered 100 Devs. At first, I was suspicious. A 100% free training agency that had nothing but good reviews? It seemed too good to be true. It had to be a scam, this couldn't be true, could it?

100Devs

Would you be surprised if I told you 100Devs' primary focus was not to teach coding, but to help people in the community get their first job in the tech field? This is because the current organizer of 100Devs Leon Noel believes that coding is a skill that anyone can learn on their own, either through tutorials, documentation, or free online resources; however 100Devs provides something those resources don't, and that is a community.

A sense of community is so much stronger than you might imagine. It gives you the strength to move forward and never give up, knowing there are many others besides you taking the same journey you are or have taken the same journey before. The emotional support helps lift you, as you return the favor to those who may be struggling as well. Having many experienced members be a part of this community as well also provided a great platform for technical help whenever you were struggling on that front.

It was a great starting point for me. 100 Devs gave me a sense of focus and it set a solid foundation for my engineering career. Giving the support and resources to ease my way into the "seemingly intimidating" nature of coding, while providing an interconnecting pathway from multiple coding languages, tools, and libraries, 100 Devs was the perfect start of my tech journey.

Non-Profits, Meetups, Oh My!

After leaving 100 Devs, I was a bit unsure of what direction to take next. There are so many libraries, languages, and tools online to learn. Since I already set the base foundations of my coding knowledge, I was able to find the next steps of my journey much faster compared to when I started it. I slowly added more tasks to my daily schedule to prevent myself from burning myself out, like learning React, re-implementing my old project with React, and optimizing my React code. I also started planning for the next day with what I wanted to accomplish and changed how I planned out my day according to what I accomplished in the past.

Once I settled into a consistent schedule, I started to seek out meeting new people in the tech career field. I came across New York Code and Coffee, a meetup group that is organized bi-weekly where people from the tech field make new friends and exchange conversations. I reached out to multiple people online to not only become more active in the tech online community but to also meet new people and potentially make new online friends! I also started seeking developer experience even if it was unpaid experience, and I came across Linguistics Justice League and Betheli9ht Foundation, where I volunteered as a developer for a good amount of time.

I was finally at a point in my life where I could confidently say that I was happy with my career path. Although I did not have a paid job yet, I enjoyed learning new concepts, building and iterating on projects, solving problems, and experimenting with code syntax. While I was satisfied with what I had accomplished up to this point, I was still hungry to see myself improve and challenge my skills to a different height. And that's when I joined Gridiron Survivor, the perfect environment to try new things and push myself to my upper limitations.

Gridiron Survivor

I didn't find Gridiron Survivor, Gridiron found me. It all started with a Twitter post, where said group truly began its origins. Shashi Lo Senior UX Engineer at Microsoft and current team leader of Gridiron Survivor, presented us with an opportunity for a product, where his friend wanted to have an application built to customize his football survivor games. Instead of creating the app on his own, Shashi suggested the idea of incorporating agile methodologies into the project to make it as similar to a corporate environment as possible while keeping it a safe environment. A few of us, me included, expressed our interest in the project and it was there where our beginnings for Gridiron Survivor began.

The flow of the project timeline was presented, showcasing how each phase would represent the important components of the overall application's development and production. We were then tasked with going on our own to research various technology languages, libraries, and tools to determine which would serve the best for our specific application and why. We then had to present our findings to the entire team, receive feedback, finalize our research documentation, and re-presented our research.

It was then that I had an epiphany thanks to Shashi pointing it out while we talked one-on-one. I realized that my time researching, organizing, and writing my documentation was fun and interesting. Noticing this, Shashi decided to pivot me to be the Documentation/Technical Writer for the application, while also allowing me to cross-function when the project needed me to.

I immediately started to familiarize myself with the world of technical writing, reading various articles and blogs talking about the writing conventions and thought process that goes into writing technical documentation. I then started going through existing technical documentation to receive inspiration from them and learn to differentiate good documentation from bad documentation. It was then that I came across Vincent Ge, who at the time was Appwrite's technical writer. I requested a coffee chat with him, where I was able to not only become closer to him but also receive sage advice regarding how I should approach writing technical writing and his thought process when writing technical documentation.

During our conversation, I expressed my ongoing journey to find a job in the technology career field. Once it was publically posted and available by Appwrite, Vincent forwarded me the link to the Appwrite Technical Writer Intern position. Thanks to my time with Gridiron Survivor, I was able to demonstrate my work ethic, collaboration, teamwork abilities, my ability to talk in front of others about what I accomplished, and my technical documentation skills by building in public. I also was blessed with amazing people who were willing to send in strong referrals of their free will.

The Next Chapter

I don't know what the future holds for me, but I know what I want to accomplish tomorrow. Day by day, I keep moving forward as I try to survive in the game we all know as life. Having accomplished a big milestone in my life by becoming a Technical Writer Intern at Appwrite, I hope to continue accomplishing great things throughout my life and be happy. And I cannot wait to see what the next chapter of my life has in store for me.

My Personal Intro to TailwindCSS

Richard Choi — Wed, 04 Sep 2024 00:29:52 +0000

I heard of Tailwind, but I never used it or Bootstrap for a long time, and my reasoning behind this was that I wanted to keep practicing my CSS skills while not relying on the convenience of CSS frameworks. However, I have seen Tailwind syntax across other projects when working with a group of developers, which introduced me to how tailwind syntax functions. Coming across an open role at Tailwind, I wanted to try applying, and I decided to build a small application talking about myself and my accomplishments using Tailwind.

Tailwind is Convenient

Implementing my own Tailwind syntax throughout my code, the first thing that stood out to me was how clean my CSS page looked. Not having to create any of my styling or classes, it was nice to have such a clean-looking CSS page for a change. Before Tailwind, I would have to manage my CSS styling specificities, making sure certain HTML elements didn't have their styles overridden from other style rules, or ensuring particular CSS rules weren't too high in specificity. Now I no longer have to worry about managing the CSS specificities so much and can just go straight to implementing the Tailwind CSS.

It was difficult creating consistent CSS class names across my multiple projects without good documentation for those CSS classes, and those projects not referencing the same CSS styling sheet. Thankfully Tailwind has both good documentation and a singular location to reference for styling. Tailwinds' consistent naming conventions for their classes reduce human error when working in a team, allowing easier communication and better teamwork. It also allows user customization for existing tailwind styles, providing flexibility for styles that may not make sense to include in certain website themes.

<div className="flex flex-col flex-nowrap justify-center w-4/6 mr-2 px-10">
</div

As an example of Tailwind's consistent naming pattern, let's look at the above example. For any styles that are subcategories like flex-direction or flex-wrap, Tailwind usually uses the hyphen to categorize the parent style and the child style. So when making an element's flex-direction column, Tailwind goes for flex-col to keep it short, simple, and effective. For styles that require choosing the direction for the style being implemented, Tailwind goes for the x and y-axis to represent said directions and make it easy to remember for repeated usage.

What I observed

When I was building my application with Tailwind, I observed as I added more Tailwind classes to an element, the more cluttered my code looked. Granted there are times when an element only needs one class, but there are also occasions where an element requires a lot of classes. As demonstrated below, there can be a lot of Tailwind classes on one element. Alternatively, using CSS without Tailwind also comes with this drawback as well, where you would need to go through many lines of code to find what you're looking for.

 <button
      className="border-b-2 text-4xl pb-1 pt-8 mb-8 hover:pb-3 hover:ease-in hover:duration-300 min-[2400px]:text-8xl min-[2400px]:leading-[6rem]"
      onClick={(e: React.MouseEvent<HTMLButtonElement, MouseEvent>) => {
        e.preventDefault();
        buttonProps.onClick();
      }}
    >
      {buttonProps.text}
    </button>

I already mentioned Tailwind's specificity and how it provides the convenience of not worrying about managing your own CSS specificities. However, this does come with one drawback, and that is being unable to switch the specificities of the Tailwind code without using the important (!) option. While that may not seem like too much of a drawback, for some developers, they may not want to include the important (!) option in their CSS no matter what.

Conclusion

Overall my experience was very positive and I am glad that I tried using Tailwind. I will be using Tailwind again for my future projects, but I do want to go back to using CSS without Tailwind from time to time to keep my skills as a CSS magician. 🪄 It saves so much time when initially building your application, and can be very convenient to use. However, I do not regret sticking with pure CSS for as long as I did because I was able to learn from that experience as well. I'm looking forward to learning more about what Tailwind provides!

Tailwind documentation: https://tailwindcss.com/

Conquering Fears: A Guide to an Empowered Developer Journey

Richard Choi — Tue, 27 Aug 2024 18:20:05 +0000

Over the years, I have experienced and overcome many of my fears. But the scariest part wasn't experiencing it; it was before I tried, the anticipation of it, the unknown factor of it all, not being able to control or know what's going to happen next. That's what filled me with the most fear before plunging in, only to discover it wasn't as bad as I thought.

THAT Conference

Recently, I overcame one of my biggest fears at a tech conference called THAT. Before, I was traumatized as both a kid and a young teenager from riding rollercoasters. I became terrified of them and still am terrified of them. I was always the designated bag holder, watching my friends go through the lines.

It wasn't until I was at the top of the stairs of an AquaLoop, a ride where you're loaded in a chamber that drops the platform beneath you into a vertical water slide, that my fear and anxiety started to kick in. My friends noticed this behavior and asked if I was okay, so I responded honestly: "No, but I want to experience this."

My heart was beating out of my chest, my stomach was running laps, my head was spinning, and I was gripping my arms so hard it felt like a boa constrictor had its scaley grip on me. My friends did one final check on me, which I reassured them. But perhaps I was lying to them and myself. A part of me was screaming to leave, to run down those long flights of stairs back to safety and comfort.

But I was determined. So I walked up and hesitantly put one foot after another onto the cold platform. As the glass door surrounded me, I felt my breath becoming shallower as I crossed my arms and legs. I felt myself plunging into a spiral of emotions that left me dizzy and nauseous.

The drop was sudden and fast. It happened before I could reasonably understand what was happening. Left and right, I turned as the speed of the water blew straight into my hair. I felt weightless at first, with nothing to support me but my arms and the icy steel of the slide against my back. Then I felt myself sliding into the water pool at a speed that would make Sonic the Hedgehog jealous. It was finally over.

But the strange part was that I didn't hate any of it. In fact, it was quite enjoyable. Although I did hurt my left ankle, and the back of my head felt like it was hit at least 10-15 times, I felt relieved that I was encouraged to participate in this ride. One of my friends started to apologize for encouraging me to try the ride, but I assured them I enjoyed my experience. Looking back at it now, I'm grateful they encouraged me to experience something new.

And it was only because of the community around me that I was able to take that step forward. Their encouragement and their displays of concern were what helped me get past my initial doubts and fears because I knew they were there for me. Without them, I would have gone back to safety, back to the comforts of who I used to be, without ever really changing or challenging myself. With a great and supportive community, you can really grow and change as a person.

Community

If it wasn't for my community, I definitely wouldn't be where I am today. I most likely would have gone back to my old, tiresome bank teller days and lived the rest of my days repetitively and listlessly being the same person every day. It's thanks to my community that I was able to transform into a developer in the first place.

To me, 100Devs was a community first and a place to learn code and get a job second. The people in the 100Devs community were and still are encouraging while remaining realistic, helping each other reach the finish line while striving for our goals and dreams. We helped each other overcome our own fears, like imposter syndrome or fear of not being able to land a developer job.

For example, one of the assignments that was asked (not mandatory by any means) was to find our own freelance client and get paid money to build a web application. At first, this seemed like a terrifying expectation to reach. However, after all of us at 100Devs received a lot of encouragement from Leon Noel, the founder of 100Devs, I started on my unknown journey to finding my first freelance client.

Imposter Syndrome

I had no idea where to begin, but I knew one thing: I was scared, and I wasn't sure what I was doing. So I started off safe, going after forums like Reddit, Facebook, or Craigslist (yes, I know) to see if anyone was hiring a freelance web developer. Unfortunately, this process was fruitless, and I was slowly becoming more dispirited and discouraged as the days went by. Deciding being passive wasn't good enough, I decided to be more active and post online on Facebook, Instagram, Twitter, LinkedIn, and Reddit to ask if anyone was looking for a web developer freelancer to hire.

While I did find a few potential interested parties, they did not lead to anything fruitful. I knew what I had to do, but knowing I would be receiving a lot of rejections was scary to imagine. But I kept reminding myself that the other person on the phone was just a human being just like me - wearing clothes like me, brushing their teeth like me, and eating food like me. So I went out and called as many local businesses in my area as I could that I found didn't have their own websites, or I felt I could improve their existing websites.

Just as expected, there were a lot of rejections. Most of them were short and abrupt, and there were a rare few that were also rude. But I persisted. And as I continued, I found the process easier and less scary as I went on. I became more comfortable and felt more sure of myself. And I realized my initial fear was, in retrospect, kind of ridiculous compared to the imposter syndrome I was feeling from all the rejections.

Receiving email job rejections was one thing, but hearing a rejection directly from another person's voice was another, especially when you do it one after another. I felt defeated and hopeless: it felt like I was walking in a heavy mist, tripping over every other step I took. But I was determined. I didn't want to give up, nor would I give up. So I continued, taking breaks here and there from all the rejections, and continued cold calling company after company.

And then it happened. I finally found that one phone call. It only took one, but all the imposter syndrome I was drowning myself in dissipated like a balloon releasing all its air. But then, a new fear started to arise, and I began to be afraid of the website's quality matching the client's expectations. Even now, looking back at the current state of the website, I wonder if there was something I could have done better at the time.

Each time I conquered a fear, it felt like a new fear started to form inside of me, and it felt scarier than the previous fear. But everytime I conquered a fear, I also felt like I became a better developer and person, and those fears shaped the confidence that I was able to form. And this wouldn't have happened if I didn't take the initiative to join the 100Devs community and find my freelance client.

Taking Initiative

When I was trying to get my first tech-related job, an advice I heard often from more experienced developers was "go out and network." And as someone who is on the more shy side, this was intimidating. The thought of reaching out to a complete stranger that I had never talked to and having a virtual video chat with them seemed like such a daunting idea at the time.

I would be so nervous leading up to the actual video chat, feeling the pace of my heart speed up and progressively get louder. To mitigate my nervousness, I would write down questions I would ask to decrease the amount of silence in the chat itself. But because of this, I never really connected to the other person I was chatting with; I was too focused on having a coffee chat and networking.

But then I took the initiative to go to my first in-person meetup at NY Code and Coffee because I had always wanted to go to my first in-person developer meetup, but I was always afraid to travel to NYC by myself. When I connected with people outside of a screen, I realized I was connecting with people the incorrect way.

I started to go to more NY Code and Coffee meetups to become more comfortable with connecting with people outside of screens. As I took the initiative to keep talking to people both offline and online, I became better at conversations and communicating with others. I also noticed that I became more confident in myself and became more sure of myself.

Moving Forward

So take that initiative. Become more comfortable with being uncomfortable, and explore new experiences so you can grow in your journey as both as a person and as a developer. Go to your first conference, your first meetup, and experience new things like your first milkshake! And who knows, you could meet someone that will become your lifelong friend.

My socials:
Twitter
LinkedIn