Most charging apps just display data, charger location, status, availability. Functional, but flat. I wanted to see what happens when you treat the interface as a craft problem: how do you make real-time charging data feel responsive and alive?

I built it with React Native (Expo) and Rive, which let me create interactions that react to live data and user input. Charging status transitions smoothly. Animations respond to actual charger states. The whole interface feels like it's breathing with the data behind it.

It's a charging app, but built like you'd build a premium product.

Mood Board

I started by building a mood board to shape the app flow and interactions.

Moodboard Link: Excalidraw

Home 🏠

The Home screen is built using three Rive artboards:

• Battery board

• Charge unit

• Main Home layout

The driver’s vehicle takes center stage, displaying interactive stats like charge prompts, charging status, and notifications. As a playful touch, tapping the vehicle toggles the headlights on and off, a fun detail made seamless with Rive’s state machine.

Check out the Rive Interaction

The chargeunit and the Battery board artboards are nested in the main Home artboard and these are turned active based on input tied to the state machine; Useful to create conditional interactions/animations based on data received from the backend.

The charger has 2 inputs to trigger - “isCharging” and “showShadow”

• isCharging → activates charging animation.

• showShadow → casts a glow when headlights are on.

The charge unit design draws inspiration from Tesla chargers.

Map - Let’s get charge!

The map is built using the react-native-maps package, which runs on the device’s native maps library under the hood. This gives us the flexibility to add custom markers.

I had previously used custom images as markers, but I was curious about pushing it further. I came across a post on Twitter by Roman, where he showcased using Rive components as map markers in Flutter, and that inspired me to try the same in React Native.

Note: At the time of testing, the Expo maps package was not yet compatible with Rive assets as markers. To get it working, you’ll need to use an Expo development build with react-native-maps.

Markpin Interactions 📍

The state machine for markpin consists of 2 inputs - “portal” and “selected”

• selected → this gets active when the user clicks on a specific markpin on the map; it bounces up and down.

• portal → when the user proceeds to book a charger at a specific location; we transition to the portal state on the user click event. We get to see the markpin morphing as a mascout going into the portal to get to the Charge station!

  Check out the Rive Interaction

Portal Suspense

The Idea is to change the marker to a mascot on portal and suspend while we fetch data from the backend; When a user books a charger, the marker transforms into a mascot; ears flapping, fiery eye glowing, suspended midair until the backend responds. This keeps users entertained during loading, turning a typical “waiting state” into a moment of delight.

Check out the Rive Interaction

The mascot hovers in midair, ears flapping in the rush of wind as it scouts for the charge station. Once the backend responds, the state changes and the mascot swoops down to the selected charge station for booking.

This was an experiment to explore how interactions like these can keep users engaged during loading states. Unlike Lottie animations, which are static, Rive makes it possible to create dynamic, state-driven interactions that feel alive and responsive.

Scan in 3, 2, 1!

The Scanner page was created in Rive and includes a transparent area where we can overlay the camera display, allowing the user to see the QR code in real time. The main exploration here was demonstrating that Rive assets can coexist with native elements, positioned in front of or behind them. This sparked a thought: perhaps in the near future, entire UIs could be generated in Rive, with developers simply plugging in business logic :D a concept that feels both crazy and exciting.

Check out the Rive Interaction

Successful Transaction

After the user scans the QR code, a transaction is initiated to allocate a charge point. Since this process takes some time on the backend, it’s important to let the user know that it is in progress. To address this, I created a loader animation where the vehicle and charger sync to establish a connection, looping until the backend confirms with an “OK”

Check out the Rive Interaction

When the transaction is successful, the state machine updates the AnimationState from “0” to “1” to indicate completion. Seeing this transition play out is truly delightful!

Splash Screen

The splash screen ties the entire theme together. The background transitions through four symbolic elements, each reflecting Curo’s mission and vision:

Rocks → Foundation / Resources
Just like minerals form the foundation for batteries, Curo builds the infrastructure foundation for EV fleets. Rocks = strength, reliability, essential resources.

Ocean → Flow / Connectivity
The ocean symbolizes vast, seamless movement - Curo’s Virtual Depot network enables fluid, borderless EV operations, like an ocean current powering global mobility.

Vegetation / Moss → Sustainability / Renewal
Moss thrives anywhere, quietly regenerating ecosystems - like Curo’s platform, which turns underused assets into living infrastructure that supports a greener fleet ecosystem.

Mars → Innovation / Future Vision
Mars represents bold frontiers - Curo is pioneering the future of EV charging at scale, taking fleets from today’s challenges to tomorrow’s limitless opportunities.

Looking Ahead

As interactive technologies evolve and motion becomes central to every app experience, interfaces are no longer just screens. They respond. They guide. They invite you in.

The way we interact with apps is changing, and there’s so much potential to make every interaction feel alive and meaningful.

I’d love to hear what you think. Feel free to drop me a line at hey.dushyanth@gmail.com

Traditional filter systems aren’t built for this. So I built a concept demo called Vibe Match, designed to showcase how AI and vector search can make profile discovery more human and intuitive.

In this post, I’ll walk you through how it works.

The Great Wall of Filters

Most platforms rely on rigid filters. The more filters you add, the more complex the UI and query logic becomes. You quickly end up with a Great Wall of Filters, and even then, you can’t search for intangible, unstructured traits like personal interests or personality quirks.

That’s where vibe-based search comes in.

High-Level Solution

The idea is simple:

• Keep structured filters for things like eye color or hair style.

• Handle unstructured vibe preferences using vector search.

• Use an AI model to intelligently parse the user’s query and split it into structured filters and vibe-based search terms.

How Vibe Match Works?

1. Data Preparation

• Donor profiles have both structured attributes (e.g. hair color) and unstructured bios/interests.

• I preprocess the unstructured text (bios, hobbies, passions, goals, strengths) and convert them into vector embeddings.

• These embeddings are stored in a vector database. For this demo, I used Datastax Astra, but this would work with Pinecone, Weaviate, or others.

  

2. User Query Handling

When a user enters a query like:

“donors who love dancing and have brown hair”

• 

  The query is sent to the backend server.

• It’s processed by an LLM (via OpenAI’s API) using structured output parsing.

I defined a Zod schema to tell the model what structured fields to extract (like eye color, hair type etc.).
Currently, I’ve provided support for the following filters, we can extend it to support more.

• The LLM returns a structured JSON with:

  • Detected filters.

Example Response:

{
  "filters": {
    "hair_color": "brown"
  },
  "vibeQuery": "donors who love dancing"
}

2. Vector Search + Filtered Results

• The vibeQuery is converted into a vector embedding.

• I run a Vector search:

  • Apply the structured filters to narrow down profiles.

  • Use the vibe query embedding to find the most similar donor profiles based on vibe.

This combo delivers results that are both relevant and intuitive with a confidence score.

We can see that these profiles do match our vibe search! She is a dancer and has brown hair.

Similar Donor Suggestions

Each donor profile already has its own vector embedding.
When a user views a donor profile:

• I run a similarity search using that profile’s embedding.

• The system suggests other donors with a similar vibe, not just those matching filters.

This enhances discoverability and creates a more organic, exploratory experience.

Final Thoughts

This was a fun concept build to explore how AI and vector search can modernize matching experiences. While this demo was built independently for Cofertility as a prototype, I believe this kind of vibe-based discovery can elevate many industries — from fertility tech to dating apps to talent marketplaces.

👉 Source Code: https://github.com/IamDushu/Cofertility-AI

💬 I’d love to hear your experience trying it out!
If you have feedback, thoughts, or just want to say hi, feel free to reach out at hey.dushyanth@gmail.com

In this post, we’ll dive into a deceptively simple loop:

for range data {
    fmt.Println(<-data)
}

At first glance, this might look fine. But it doesn’t behave the way you might expect. Let’s explore why.

The Setup: A Goroutine and a Channel

Here’s the full code we’re analyzing:

package main

import "fmt"

func main() {
    data := make(chan string)

    go func() {
        for i := 0; i < 4; i++ {
            data <- "Hello " + string('0'+i)
        }
        close(data)
    }()

    for range data {
        fmt.Println(<-data)
    }

    // Correct version (commented out):
    // for value := range data {
    //     fmt.Println(value)
    // }
}

You might expect this to print:

Hello 0
Hello 1
Hello 2
Hello 3

But instead, it prints:

Hello 1
Hello 3

Wait… what?

What’s Going On?

Let’s break down the two loop variants:

✅ Correct Version:

for value := range data {
    fmt.Println(value)
}

• range data listens on the channel data.

• It automatically receives each value sent on the channel, assigns it to value, and runs the loop.

• When the channel is closed, the loop exits.

It reads one value per iteration - perfect.

❌ The Buggy Version:

for range data {
    fmt.Println(<-data)
}

This one’s sneaky.

• for range data still reads a value from the channel each iteration.

• But that value isn’t assigned or used - it’s just discarded.

• Then, inside the loop, you manually call <-data again — pulling a second value from the channel.

🚨 You're reading two values per iteration.

Let’s simulate what happens:

So only "Hello 1" and "Hello 3" get printed. The others are discarded during the range evaluation.

The Takeaway

In Go, for range already pulls values from a channel. If you also call <-data inside that loop, you're unintentionally skipping every other value!

✔️ Do this:

for value := range data {
    fmt.Println(value)
}

❌ Not this:

for range data {
    fmt.Println(<-data)
}

Let’s peel back the layers of abstraction and see what really happens under the hood when you write a character in Go.

Unicode vs UTF-8 vs Go Types

Let's Take a Character: త

This is a Telugu letter, pronounced “ta”.

Step 1: Unicode

Every character has a unique code point in the Unicode spec.

goCopyEditr := 'త'

fmt.Printf("Unicode: U+%04X\n", r) // Output: U+0C24

So 'త' has Unicode code point U+0C24 = 3108 in decimal.

Step 2: Convert to UTF-8

The Unicode code point is abstract — we need a way to store it in memory. That’s where UTF-8 comes in.

UTF-8 stores U+0C24 as:

• Bytes: [224, 176, 164]

• Hex: [0xE0, 0xB0, 0xA4]

• Binary:

    11100000 10110000 10100100
  

UTF-8 uses variable-length encoding. Since త is in the U+0800–U+FFFF range, it uses 3 bytes.

Step 3: See It in Go

Here's a complete Go function to visualise this transformation:

package main

import (
    "fmt"
)

func printUTF8Encoding(s string) {
    fmt.Printf("Input: %q\n\n", s)
    for i, r := range s {
        utf8Bytes := []byte(string(r))
        binaryUnicode := fmt.Sprintf("%016b", r)

        fmt.Printf("Character #%d: %q\n", i+1, r)
        fmt.Printf("→ Unicode:  U+%04X (decimal: %d)\n", r, r)
        fmt.Printf("→ Binary (Unicode): %s\n", insertEvery4Bits(binaryUnicode))
        fmt.Printf("→ UTF-8 Bytes: %v\n", utf8Bytes)

        fmt.Print("→ Hex:       ")
        for _, b := range utf8Bytes {
            fmt.Printf("0x%X ", b)
        }

        fmt.Print("\n→ Binary:    ")
        for _, b := range utf8Bytes {
            fmt.Printf("%08b ", b)
        }

        fmt.Println("\n---")
    }
}

func insertEvery4Bits(s string) string {
    out := ""
    for i, c := range s {
        if i > 0 && (len(s)-i)%4 == 0 {
            out += " "
        }
        out += string(c)
    }
    return out
}

func main() {
    printUTF8Encoding("త")
}

🧪 Output:

Input: "త"

Character #1: 'త'
→ Unicode:  U+0C24 (decimal: 3108)
→ Binary (Unicode): 0000 1100 0010 0100
→ UTF-8 Bytes: [224 176 164]
→ Hex:       0xE0 0xB0 0xA4
→ Binary:    11100000 10110000 10100100

🔍 Summary

✨ Try More!

Pass any string into the function: "😊", "hi", "తెలుగు", "你好" — and you'll see how Go handles it.

In this blog post, I’ll walk you through how the Harbor Health app works under the hood - from user authentication to booking visits and jumping into real-time video calls. The app is built with React Native + Expo on the frontend and Go (Gin) + PostgreSQL on the backend. Let’s break it down.

🔐 1. Authentication Flow - say NO to JWT

Harbor Health uses a modern, passwordless authentication system, combining usability with security via PASETO tokens and temporary, unsigned JWTs.

Step 1: Request Login or Signup

The flow begins when a user submits their email - whether to log in or sign up - via:

POST /api/registration/email

Payload:

{
  "email": "user@example.com",
  "mode": "login" // or "signup"
}

Backend logic:

1. Normalize the email (lowercase, trim, etc.).

2. Check if a user with that email already exists.

3. Regardless of existence, generate:

   • An unsigned JWT containing metadata like sub, iat, and exp.

   • A random 5-digit code, hashed and stored in DB.

   • If the account exists, the code and token are valid for verification.

   • If not, they are immediately marked as expired (but the user never knows).

4. Send the email only if the account exists.

5. No indication is given to the user whether the account exists or not - preventing user enumeration.

🧾 We use a simple unsigned JWT (i.e., with "alg": "none") for the verification link/token. It contains only metadata and is not used for authentication.

Example payload:

{
  "alg": "none",
  "typ": "JWT"
}
.
{
  "sub": "user@example.com",
  "iat": 1729878701,
  "nbf": 1729878701,
  "exp": 1729880501
}

Step 2: Email Verification

The user receives the email with a code and submits it along with the token:

POST /api/registration/email/verify

Payload:

{
  "token": "<unsigned-jwt-token>",
  "digits": "46020"
}

Backend verification:

1. Look up the token in the database.

2. Validate the JWT structure and ensure it's not expired.

3. Hash the provided code and compare it with the stored one.

4. If the code is incorrect:

   • Increment an attempt counter.

   • Invalidate the token after 5 failed attempts.

5. If correct:

   • If the user doesn't exist yet, create the user but set onboarded = false.

   • Generate PASETO access and refresh tokens.

   • Return the session, user info, and a Stream token for real-time features.

Using sqlc vs gorm in Backend

🖼️ Frontend Behavior: Context-Driven Auth Flow.

If the user has entered the correct OTP and is a new user (i.e) Who hasn’t created a member account yet; then the user is automatically redirected to a Member Form as shown below:

To handle form inputs efficiently, we use React Hook Form in combination with Zod for schema validation. This setup provides a clean and declarative way to build forms while keeping performance in check. Zod schemas define the structure and validation rules for each form, which are then integrated into React Hook Form using the zodResolver. This approach ensures that all form inputs are type-safe, validated on submission (or as-you-type), and tightly coupled with the backend’s expectations - minimizing bugs and making the user experience smooth and predictable.

📱 App Flow: Booking Visits & Starting Calls

After logging in, users land on the Home Screen, which serves as the central hub of the app. From here, they can:

• 📅 Book a Visit :- Choose between an in-office or remote appointment with a provider, selecting a time that works for them.

• 🚨 Request an Urgent Video Chat :- Immediately initiate a real-time video call with an available provider. This is where Stream comes into play.

• 📍 Find Office Locations.

For urgent calls, the app creates a Stream video room and notifies the provider in real time. If accepted, both participants are connected to the same room using the Stream Video SDK, enabling a secure, low-latency WebRTC video call. The SDK also handles participant presence, call state, and UI components - giving us a production-ready video solution with full flexibility.

This unified experience - from finding a clinic, to booking a visit, to jumping into a call - makes the Harbor Health app feel seamless, responsive, and human.

📅 Booking a Visit: Multi-Step Flow with Zustand & UX Polish

The visit booking flow is designed to guide the member step-by-step while keeping the interface focused and intuitive.

Here’s how it works:

1. Visit Intent:
   The user starts by entering a brief description of what they want to cover in the visit - symptoms, concerns, or questions for the provider.

2. Location Selection:
   Next, they choose between nearby office locations.

3. Provider & Slot Selection:
   Based on availability, the user is shown a list of providers and their available time slots.

4. Confirmation Screen:
   Finally, the user reviews their selection and confirms the appointment.

🛠️ Under the Hood: UI Challenges & Zustand for State Management

One design quirk I encountered was with the confirmation screen. This screen needed to appear above the tab layout, without showing the tab bar at the bottom - which meant it couldn’t live within the main tab navigator tree.

That posed a problem: we needed to share state (like selected slot, provider, and visit info) across multiple screens, but without using props or context - since the confirmation screen lived outside the context tree.

To solve this, I used Zustand - a lightweight, scalable global state library - to persist the visit booking state throughout the flow. It worked beautifully, letting us avoid prop drilling and keeping logic clean and localized.

💫 Smooth UX with Shimmer Effects

While loading providers and slots, we also implemented shimmer loading placeholders using a React Native shimmer library. This added a touch of polish, making the app feel fast and responsive even when data was still fetching.

🧩 Backend Logic: Slot Locking & Transactional Integrity

Once a user selects a slot and confirms the booking, we ensure that the same time slot cannot be double-booked.

Here’s how we handle it on the backend:

• When a booking is confirmed, the backend:

  1. Validates that the slot is still available.

  2. Marks the slot as reserved or removes it from the availability pool.

  3. Uses a database transaction to wrap the entire booking logic - including slot validation, creation of the booking record, and updates to related tables.

✅ This ensures atomicity - either the whole booking succeeds, or none of it does - preventing race conditions and data inconsistencies.

• Once booked, that slot is no longer returned in future availability queries.

This approach helps us maintain consistency even under high concurrency, avoids duplicate appointments, and keeps the system safe from overlapping bookings.

📱 Urgent Video Chat

One of the key flows I wanted to explore was how Harbor Health could support urgent or time-sensitive consultations - for example, when a member needs immediate attention from a provider.

In the MVP, I implemented an "urgent call" mechanism that allows a member to initiate a real-time video call with a provider. Here's how it works:

• Initiation: A member taps “Urgent Video Call” from the app, which instantly creates a call room via Stream’s video SDK.

• Push Notification: The provider receives a push notification and in-app alert, with clear labeling to indicate urgency.

• Join Flow: Once the provider accepts, both users are routed to the same video room. The call screen handles edge cases like double joins or stale state using internal hasAnswered flags and call state listeners.

• Lightweight Experience: The goal was to make the experience as frictionless as possible - no extra screens, no unnecessary loading, just an immediate connection.

This setup opens up possibilities for triage-like experiences, crisis counseling, or simply faster access to care in moments when timing matters.

💊 Prescription Renewals.

The app includes a simple flow for managing and renewing prescriptions. Users can view their active prescriptions, select one for renewal, choose a pharmacy, and submit the request - all in just a few taps.

It's designed for quick, mobile-first interactions, and sets the foundation for future features like pharmacy integration and provider approvals.

📍 Locations Map: Nearby Clinics & Mobile Tracking

In the Locations section of the app, users can view all available clinic locations on an interactive map. This helps them find the nearest physical location when booking an in-office visit.

But we went one step further.

🚐 Mobile Clinic Tracking

In addition to static clinic pins, the map also displays the live location of our mobile clinic - allowing users to see exactly where it is and when it might be near them.

• 📌 Each location is shown as a marker on the map with labels (e.g. "Downtown Clinic" or "Mobile Unit").

• 📡 The mobile clinic’s location is updated dynamically, giving users real-time context on where care is available.

• 🔍 Users can tap on any location to get more info.

🛠️ Under the Hood

• We use React Native Maps for rendering the map view.

• Location data is fetched from the backend and displayed as markers.

• The mobile clinic’s location is synced periodically or in real time depending on system configuration.

• We integrated a bottom sheet that slides up from the bottom of the screen, showing a scrollable list of all available locations - fully synced with the map view.

  • As users browse the list, the map automatically highlights the corresponding location.

This map feature creates a more transparent and convenient user experience - whether the user prefers to walk into a clinic or catch the mobile unit while it’s nearby.

Backend Deployment & Monitoring.

The Go backend was containerized using a Docker image and deployed to Railway, making it easy to manage builds, environment variables, and scaling.

For basic monitoring, I set up UptimeRobot to ping the health check endpoint - ensuring the service stays live and alerting on downtime.

💬 I’d love to hear your experience trying it out!
If you have feedback, thoughts, or just want to say hi, feel free to reach out at hey.dushyanth@gmail.com

In this post, we’ll dive into how to use Zustand in combination with Immer to handle state updates, especially when working with deeply nested state or immutable updates.

What is Zustand?

Zustand is a small, fast state management library for React. It is very lightweight and has a minimalistic API, making it a great choice for small to medium-sized applications. Zustand makes state management simple by allowing you to create stores (state containers) that can be accessed and updated easily across your components.

What is Immer?

Immer is a library that helps with immutable state updates. In JavaScript, state updates often require creating a new copy of the state object to avoid mutating it directly. This can be tedious, especially when the state is deeply nested. Immer allows you to mutate the state directly (just like working with mutable objects), while ensuring that the changes are applied immutably behind the scenes.

The Power of Zustand + Immer

When combined, Zustand and Immer offer an elegant solution for managing complex state. Immer’s ability to handle immutable state and Zustand’s simplicity make for a great pairing, especially when working with deeply nested objects or arrays.

Getting Started with Zustand + Immer

Before we dive into best practices, let's set up Zustand with Immer. Here’s how you can create a Zustand store using Immer:

import create from 'zustand';
import { immer } from 'zustand/middleware/immer';

const useStore = create(
  immer((set) => ({
    count: 0,
    increment: () => {
      set((state) => {
        state.count++;  // Direct mutation of the draft state
      });
    },
  }))
);

In this simple store, we have a count state, and we use the increment method to update it. Notice how we mutate state.count directly inside the set() function. Thanks to Immer, the state update is immutable, and we don’t need to return a new object.

Directly Mutating Nested Objects in Immer

One of the most powerful features of Immer is its ability to handle deeply nested objects without requiring us to manually copy or spread them. Let’s take an example where we need to update a nested property in an array of objects.

Scenario: Updating a Set in a Workout

Imagine we have a workout app with workouts, and each workout has a series of sets. We want to update the reps and weight of a specific exercise set.

Here’s an example of how you might use Zustand with Immer to update a nested ExerciseSet:

const useStore = create(
  immer((set) => ({
    currentWorkout: {
      exercises: [
        { id: 1, sets: [{ id: 1, reps: 10, weight: 100 }] },
        { id: 2, sets: [{ id: 2, reps: 8, weight: 120 }] },
      ],
    },
    updateSet: (setId, updatedFields) => {
      set(({ currentWorkout }) => {
        const setToUpdate = currentWorkout.exercises
          .flatMap((e) => e.sets)
          .find((s) => s.id === setId);

        if (!setToUpdate) {
          return;
        }

        //Direct mutation: update the set's properties
        if (updatedFields.reps !== undefined) {
          setToUpdate.reps = updatedFields.reps;
        }

        if (updatedFields.weight !== undefined) {
          setToUpdate.weight = updatedFields.weight;
        }
      });
    },
  }))
);

Why Direct Mutation Works with Immer

Here’s the key idea: Immer provides a mutable draft of the state that you can directly modify. Normally, in state management libraries like Redux or Zustand, state is immutable, and any mutation requires creating a new copy of the object (to preserve immutability). However, with Immer, you can mutate the draft directly, and Immer will handle the creation of the new immutable state for you behind the scenes.

Key Points:

1. Mutability of the draft: Inside set(), you can mutate the draft state directly.

2. Automatic immutability: Immer ensures that the state remains immutable, even though you mutate it directly.

3. No need to return a new state: Unlike traditional state management, you don’t need to manually return a new state object after mutation. Immer takes care of that for you.

Avoid Reassigning State in Immer

A common mistake when working with Immer is reassigning state or nested objects within the draft, which can break Immer's internal mechanism for handling updates. Let’s look at a typical error you might see:

Incorrect Code (Reassigning the Draft):

updateSet: (setId, updatedFields) => {
  set(({ currentWorkout }) => {
    const setToUpdate = currentWorkout.exercises
      .flatMap((e) => e.sets)
      .find((s) => s.id === setId);

    if (!setToUpdate) {
      return;
    }

    // Incorrect! Reassigning the draft will break Immer's state tracking
    setToUpdate = updateSet(current(setToUpdate), updatedFields);
  });
};

Correct Approach:

Instead of reassigning the draft object, mutate the properties directly:

updateSet: (setId, updatedFields) => {
  set(({ currentWorkout }) => {
    const setToUpdate = currentWorkout.exercises
      .flatMap((e) => e.sets)
      .find((s) => s.id === setId);

    if (!setToUpdate) {
      return;
    }

    // Correct! Mutate the properties directly on the draft
    if (updatedFields.reps !== undefined) {
      setToUpdate.reps = updatedFields.reps;
    }

    if (updatedFields.weight !== undefined) {
      setToUpdate.weight = updatedFields.weight;
    }
  });
};

Why This Works:

• Direct mutation: We directly modify setToUpdate.reps and setToUpdate.weight on the draft, rather than assigning a new object to setToUpdate.

• Immer manages the immutability: Immer tracks the mutation and ensures the new state is created immutably when needed.

Keep Aware of this pitfall!

1. Mutate directly on the draft: You can modify the draft state directly. Avoid reassigning variables or returning a new state object manually.

Conclusion

By combining Zustand and Immer, we can simplify state management in our React apps while ensuring that the state remains immutable and easily updatable. Immer makes it easy to mutate deeply nested state directly without breaking immutability, while Zustand provides a simple, performant store to manage that state. Together, they provide a seamless experience for handling complex state updates efficiently.

Hopefully, this guide has given you a better understanding of how to use Zustand with Immer for managing state in your React applications. Happy coding! ✌️

Project Installation:

• pnpm dlx create-expo-app@latest Fitness --template (or)
  npx create-expo-app@latest Fitness --template

• Choose a template: › Blank (TypeScript)

• pnpm start to start the project.

App router:

Reference: https://docs.expo.dev/router/installation/

• create src > app folder structure for the router.

• Add “paths” to tsconfig.json, useful while importing.

1. Install dependencies

pnpm dlx expo install expo-router react-native-safe-area-context react-native-screens expo-linking expo-constants expo-status-bar

2. Setup entry point in package.json

{
  "main": "expo-router/entry",
}

3. Modify project config in app.json; include “scheme” for deep-linking.

{
  "scheme": "your-app-scheme"
}

If you are developing your app for web, install the following dependencies:

pnpm dlx expo install react-native-web react-dom

Then include “bundler” in app.json for “web”

{
  "web": {
    "bundler": "metro"
  }
}

Now Start the app

pnpm start -- --clear

Create an index.tsx file inside app folder and you are ready to roll! 🎉

What Are Refs in React?

Refs (short for references) are a way to access DOM nodes or React components directly. They are commonly used for:

• Managing focus, text selection, or media playback.

• Triggering imperative animations.

• Integrating with third-party DOM libraries.

In React, refs are created using the useRef hook (for functional components) or the createRef method (for class components).

The Traditional Way: Using forwardRef

Before React 19, if you wanted to pass a ref from a parent component to a child component, you had to use React.forwardRef. This was necessary because ref is not a regular prop—it’s treated specially by React.

Example with forwardRef:

import React, { useRef, forwardRef } from 'react';

// Child component using forwardRef
const ChildComponent = forwardRef((props, ref) => {
  return <div ref={ref}>Child Component</div>;
});

// Parent component
const ParentComponent = () => {
  const childRef = useRef(null);

  const handleClick = () => {
    console.log(childRef.current); // Access the child's DOM element
  };

  return (
    <div>
      <ChildComponent ref={childRef} />
      <button onClick={handleClick}>Log Ref</button>
    </div>
  );
};

export default ParentComponent;

Why forwardRef Was Necessary

React treats ref differently from other props to ensure that it doesn’t get passed down unintentionally. forwardRef was introduced to explicitly forward refs to child components.

What’s New in React 19?

React 19 introduces a significant improvement: you can now pass ref directly as a prop to a child component without needing forwardRef. This simplifies the code and makes it more intuitive.

Example in React 19:

import React, { useRef } from 'react';

// Child component (no need for forwardRef)
const ChildComponent = ({ ref }) => {
  return <div ref={ref}>Child Component</div>;
};

// Parent component
const ParentComponent = () => {
  const childRef = useRef(null);

  const handleClick = () => {
    console.log(childRef.current); // Access the child's DOM element
  };

  return (
    <div>
      <ChildComponent ref={childRef} />
      <button onClick={handleClick}>Log Ref</button>
    </div>
  );
};

export default ParentComponent;

Benefits of the New Approach

1. Less Boilerplate: No need to wrap your component with forwardRef.

2. More Intuitive: Passing ref as a prop feels more natural and aligns with how other props are handled.

3. Improved Readability: The code is cleaner and easier to understand.

When to Use forwardRef in React 19

While React 19 allows you to pass ref directly as a prop, forwardRef is still supported and can be useful in certain scenarios:

1. Backward Compatibility: If you’re working on a codebase that needs to support older versions of React, you should continue using forwardRef.

2. Explicit Ref Forwarding: If you want to make it clear that a component is designed to forward refs, forwardRef can serve as a signal to other developers.

Conclusion

React 19 makes working with refs easier and more intuitive by allowing you to pass ref directly as a prop to child components. This eliminates the need for forwardRef in most cases, reducing boilerplate and improving code readability. However, forwardRef is still available for backward compatibility and explicit ref forwarding.

Thanks to the React Team for making this change.

Happy coding! 🚀

Explanation of the Code

1. rand.Int(rand.Reader, big.NewInt(9000)):

   • Generates a random number in the range [0, 8999]. Using 9000 ensures the number can go up to 8999.

2. int(n.Int64()) + 1000:

   • Adds 1000 to shift the range from [0, 8999] to [1000, 9999], resulting in a secure 4-digit OTP.

Using math/rand

One simple way to generate a 6-digit OTP is by using the math/rand package, which provides basic random number generation. However, for true randomness (e.g., in production), it’s usually recommended to use crypto/rand, as it provides cryptographically secure random numbers.

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func generateOTP() int {
    rand.Seed(time.Now().UnixNano()) // Seed with current time
    return 1000 + rand.Intn(9000) // Generate a random number in [1000, 9999]
}

func main() {
    otp := generateOTP()
    fmt.Printf("Generated OTP: %04d\n", otp)
}

Note: Starting with Go 1.20, rand.Seed() has been deprecated for cryptographic purposes due to its predictability and the availability of better, more secure options. Instead, for non-cryptographic random numbers, you should now create a new instance of math/rand using rand.New() with a source that’s properly seeded, or switch entirely to crypto/rand for security-sensitive applications.

If you generate OTPs using math/rand, an attacker could potentially guess the sequence if they know the seed, especially if it’s based on something predictable like the current timestamp. However, crypto/rand is resistant to this kind of attack because it pulls from sources that are practically unpredictable.

THE END

Deprecated: As of Go 1.20 there is no reason to call Seed with a random value. Programs that call Seed with a known value to get a specific sequence of results should use New(NewSource(seed)) to obtain a local random generator.

Let's look at the example below:

package util 

import (
    "math/rand"
    "time"
)

func init() {
    rand.Seed(time.Now().UnixNano())
}

// RandomInt generates a random integer between min and max
func RandomInt(min, max int64) int64 {
    return min + rand.Int63n(max-min+1)
}

In the above example; The init() function will be called automatically when the package is first used. In this function, we set the seed value for the random generator by calling rand.Seed()
Normally the seed value is often set to the current time. As rand.Seed() expects an int64 as input, we convert it to unix nano before passing it to the function. (UnixNano a Unix time, the number of nanoseconds elapsed since January 1, 1970 UTC. i.e int64)

But now that rand.Seed() has been deprecated (since Go version 1.20); Let's look at the below example on how we can implement the same.

package util

import (
    "math/rand"
    "time"
)

var randomSource *rand.Rand

func init() {
    randomSource = rand.New(rand.NewSource(time.Now().UnixNano()))
}

// RandomInt generates a random integer between min and max
func RandomInt(min, max int64) int64 {
    return min + randomSource.Int63n(max-min+1)
}

var randomSource *rand.Rand This line declares a package-level variable named randomSource of type *rand.Rand. This variable will hold an instance of the rand.Rand type, which is used for generating random numbers.

Here, Inside the init():
rand.New(...): Creates a new rand.Rand instance initialised with the source generated by rand.NewSource(...). This rand.Rand instance is then assigned to the randomSource variable.

And that's how you work with random numbers!

Setting the Stage

Let's start with a common scenario: implementing a custom error type for a square root function that doesn't accept negative numbers. You can look at the referred code from the go tour.

type ErrNegativeSqrt float64

func (e ErrNegativeSqrt) Error() string {
    return fmt.Sprintf("cannot Sqrt negative number: %v", e)
}

func (e ErrNegativeSqrt) String() string {
    return fmt.Sprintf("%v", float64(e))
}

At first glance, this looks perfectly reasonable. We have an Error() method to satisfy the error interface, and a String() method for custom string representation. But here's where things get interesting.

The Compiler's Warning

When compiling this code, you might encounter a surprising warning:

fmt.Sprintf format %v with arg e causes recursive (play.ErrNegativeSqrt).Error method call

Wait, what? A recursive Error() method call? But we have a String() method defined, shouldn't that be used instead?

Unraveling the Mystery

To understand what's happening, we need to delve into Go's method resolution rules for string formatting.

When using fmt.Sprintf (or any of the fmt package's formatting functions) with the %v verb, Go follows this order of precedence:

1. If the type implements fmt.Formatter, use that.

2. If the type implements error, use Error().

3. If the type implements String(), use that.

4. If none of the above apply, use a default formatting.

In our case, ErrNegativeSqrt implements both error (via Error()) and Stringer (via String()). According to the rules, Error() should take precedence over String() when using %v.

The Plot Thickens

But here's the twist: in practice, this code often works just fine! The String() method is indeed called, preventing the recursive loop that the compiler warning suggests.

So why the warning? It appears that the Go compiler is being extra cautious. It sees a potential for recursion (even if it doesn't actually occur at runtime) and flags it as a warning.

Lessons Learned

This scenario teaches us several valuable lessons about Go:

1. Method Resolution is Complex: Go's rules for method resolution, especially in formatting contexts, are more nuanced than they might first appear.

2. Compiler Warnings Are Conservative: The Go compiler may warn about potential issues even if they don't manifest in practice. These warnings are valuable prompts for code review.

3. Explicit is Better than Implicit: To avoid confusion, it's often better to be explicit in our code. We could rewrite our Error() method like this:

func (e ErrNegativeSqrt) Error() string {
    return fmt.Sprintf("cannot Sqrt negative number: %s", e.String())
}

This makes our intentions clear and sidesteps any ambiguity.

1. Understanding the Underlying Mechanisms: This case underscores the importance of understanding not just the syntax of Go, but also its underlying mechanisms and design philosophies.

Conclusion

Go's simplicity is one of its greatest strengths, but as we've seen, there are depths to explore beneath that simple surface. By diving into edge cases like this one, we not only become better Go programmers but also gain insights into the intricacies of language design and compiler behavior.

The next time you encounter a surprising compiler warning or unexpected behavior in Go, remember this case. It might just be an opportunity to learn something fascinating about the language you thought you knew so well.

Happy coding, Gophers!

What Is a Database Driver?

A database driver is a piece of software (a library) that knows how to communicate with a specific type of database. It implements the protocols and rules needed to:

1. Establish a connection to the database.

2. Send SQL queries to the database.

3. Receive and interpret results from the database.

4. Handle things like data serialization (turning Go types into SQL-compatible types and vice versa).

For PostgreSQL, the drivers lib/pq and pgx do all of these things. Without a driver, your Go application wouldn’t know how to talk to the PostgreSQL database directly.

Why Do We Need a Driver?

Here’s why using a driver is essential:

1. Database-Specific Communication Protocols:

   • PostgreSQL has its own communication protocol for how it expects queries, connections, and data to be sent and received.

   • The driver implements this protocol so that you don’t have to deal with it directly. You can just write Go code, and the driver will handle the rest.

2. Data Serialization and Deserialization:

   • The driver takes care of converting Go types (like string, int, float, structs, etc.) into SQL-compatible types (like VARCHAR, INTEGER, DECIMAL, etc.) when sending queries.

   • Similarly, when the database sends back data, the driver converts it into Go types that your application can work with.

3. Connection Management:

   • Database drivers manage the low-level details of connecting to the database, including opening connections, maintaining a pool of connections, and handling issues like timeouts or network failures.

4. Simplifies Coding:

   • Without a driver, you’d have to write a lot of low-level code to handle networking, data conversion, and more. The driver abstracts all that complexity so that you can focus on writing SQL queries and business logic.

lib/pq vs pgx: What’s the Difference?

Both lib/pq and pgx are popular drivers for connecting to PostgreSQL from Go, but they have some differences:

1. lib/pq:

   • It’s a pure Go driver that implements the PostgreSQL protocol.

   • It was one of the earlier drivers available for Go and is stable and well-tested.

   • However, it is no longer actively maintained. It still works fine for most use cases, but it lacks newer features and improvements.

2. pgx:

   • pgx is newer and is actively maintained. It has a lot more features compared to lib/pq.

   • It can be used in two ways: as a standalone driver (similar to lib/pq) or as a full-fledged PostgreSQL client with features like connection pooling, support for COPY operations, and native types.

   • It tends to be faster and more performant than lib/pq because it has optimizations and a better understanding of PostgreSQL’s internals.

Example: How It Works

When you write Go code like this:

goCopy codepackage main

import (
    "database/sql"
    _ "github.com/lib/pq"
)

func main() {
    connStr := "user=username dbname=mydb sslmode=disable"
    db, err := sql.Open("postgres", connStr)
    if err != nil {
        panic(err)
    }
    defer db.Close()

    // Run queries here
}

• The line import _ "github.com/lib/pq" tells Go to load the lib/pq driver so it can handle PostgreSQL connections.

• When you call sql.Open("postgres", connStr), the Go standard library’s database/sql package knows how to delegate the connection management to lib/pq, because lib/pq has registered itself as a driver for the postgres database.

• From there on, the driver handles all the low-level communication between your application and the PostgreSQL server.

Final words

In essence, a database driver is crucial because it abstracts away the complex, low-level details of talking to a database. It enables you to write Go code that interacts with the database easily and efficiently, without needing to worry about the underlying protocols and data conversions.

1. Here's a detailed breakdown of the differences:

• varchar: This defines a variable-length character string with no specified maximum length. It can store strings of any length, up to the maximum limit imposed by PostgreSQL, which is about 1 GB.

• varchar(n): This defines a variable-length character string with a specified maximum length of n characters. If you attempt to store a string longer than n, PostgreSQL will raise an error.

2. Storage:

• Both varchar and varchar(n) store data in a variable-length format, which means they use only the amount of storage necessary to hold the actual string, plus a small amount of overhead (1 or 4 bytes depending on the string length).

3. Length Constraints:

• varchar: There are no constraints on the length of the strings that can be stored. You can store strings of any length, up to the maximum supported by PostgreSQL.

• varchar(n): There is a constraint on the length. For example, if you define a column as varchar(6), you can only store strings with up to 6 characters. Attempting to insert a longer string will result in an error.

4. Performance:

• In general, there is no significant performance difference between varchar and varchar(n) for most use cases. However, using varchar(n) can help enforce data integrity by ensuring that strings do not exceed a certain length, which can prevent issues downstream in your application logic.

5. Indexing:

• Both varchar and varchar(n) types can be indexed. However, if you use varchar(n), PostgreSQL can optimize storage and performance slightly better in some cases because it knows the maximum length of the data it has to deal with.

An interface type is defined as a set of method signatures. A value of interface type can hold any value that implements those methods. Take a look at the below example taken from Go tour.

package main

import (
    "fmt"
    "math"
)

type Abser interface {
    Abs() float64
}

func main() {
    var a Abser
    f := MyFloat(-math.Sqrt2)
    v := Vertex{3, 4}

    a = f  // a MyFloat implements Abser
    a = &v // a *Vertex implements Abser

    // In the following line, v is a Vertex (not *Vertex)
    // and does NOT implement Abser.
    a = v

    fmt.Println(a.Abs())
}

type MyFloat float64

func (f MyFloat) Abs() float64 {
    if f < 0 {
        return float64(-f)
    }
    return float64(f)
}

type Vertex struct {
    X, Y float64
}

func (v *Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

Note: There is an error in the example code on line 22. Vertex (the value type) doesn't implement Abser because the Abs method is defined only on *Vertex (the pointer type).

But if i write func (v Vertex) abs() then also a = &v works! why?

In Go, when you define a method with a receiver type (like v *Vertex or v Vertex), the receiver can be a pointer or a value type. This distinction is important because it determines what can call the method.

The original case: func (v *Vertex) Abs()

In our original code, the Abs() method is defined with a pointer receiver:

func (v *Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

This means the method can only be called on a *Vertex (a pointer to a Vertex), not a Vertex itself.

• When you do a = &v, you're assigning a pointer to v (*Vertex), which works fine because the method Abs() is defined on *Vertex, and so &v implements Abser.

However, when you do a = v (without the &), v is of type Vertex, not *Vertex. Since the method is defined on *Vertex, v does not implement the Abser interface, hence the error.

What happens if you change the method to (v Vertex) Abs()?

If you change the method signature to use a value receiver:

func (v Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

Now the method is defined on the Vertex type (the value type), so it can be called on both values of type Vertex and pointers of type *Vertex. This is because Go will automatically dereference the pointer for you.

• If you have a value v of type Vertex, calling v.Abs() works.

• If you have a pointer &v of type *Vertex, calling (&v).Abs() works too because Go automatically dereferences the pointer behind the scenes.

Why does a = &v work with a value receiver?

When the method is defined with a value receiver like this:

func (v Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

It can be called on a pointer (*Vertex) as well. The reason is that Go will implicitly dereference the pointer when needed. So, even though the method expects a value (Vertex), you can still pass a pointer (*Vertex) because Go will automatically turn *v into v by dereferencing.

This implicit dereferencing works because a value receiver is less restrictive: the method doesn't modify the original struct (since it's a copy), so Go allows calling it on a pointer too, as it's safe!

Consider the following example of a custom error type in Go:

type MyError float64

func (e MyError) Error() string {
    // Potentially dangerous code
    return fmt.Sprint(e)
}

func main() {
    var e error = MyError(3.14)
    fmt.Println(e.Error()) // Infinite loop!
}

At first glance, this implementation might seem harmless. However, running the program results in an infinite loop and a stack overflow.

Why does this happen? The fmt.Sprint function has special behavior for types that implement the error interface. It calls the Error() method of the type to produce a string representation.

Here’s the sequence of events:

1. The Error() method calls fmt.Sprint(e).

2. fmt.Sprint(e) recognizes that e implements the error interface and calls e.Error().

3. This leads back to step 1, creating an infinite recursion.

This recursion will continue until the program runs out of stack space and crashes.

The Solution: Converting the Type

To prevent this infinite loop, we need to break the chain of recursion. One way to achieve this is by converting the value to a non-error type before calling fmt.Sprint. For example, you can convert e to a float64:

type MyError float64

func (e MyError) Error() string {
    // Convert `e` to float64 to avoid recursion
    return fmt.Sprint(float64(e))
}

func main() {
    var e error = MyError(3.14)
    fmt.Println(e.Error()) // Prints "3.14"
}

By explicitly converting e to float64, fmt.Sprint no longer treats it as an error and simply formats it as a number. This avoids calling the Error() method and resolves the infinite loop

Why Does This Work?

The Go runtime uses type assertions to determine how to handle values passed to fmt.Sprint. When the value is of type error, fmt.Sprint calls its Error() method. By converting the value to another type, such as float64, you effectively tell fmt.Sprint to treat it as a plain number rather than an error.