DEV Community: Nikhil Sharma

The WebSocket Auth Problem: Cookies vs. Bearer Tokens

Nikhil Sharma — Wed, 03 Jun 2026 20:23:14 +0000

If you've ever built a real-time web app using WebSockets, you've probably hit this exact wall - how do I do the auth.

On the HTTP side, the answer is pretty simple. You either use a cookie, which has so many npm packages, or you attach an Authorization: Bearer <token> header to your requests, which is a simple JWT signed string. However, things get a bit weird on the WebSocket side of things.

The fundamental issue stems from how WebSocket connections are established. Before a WebSocket connection becomes a continuous bidirectional channel of data, it starts off as a simple HTTP GET request with an Upgrade header. This is known as the WebSocket Handshake.

Let's dive into why this handshake makes the seemingly simple task of authentication a surprisingly nuanced architectural decision.

Why Bearer Tokens are Clunky for WebSockets

If your application relies on Bearer tokens (usually stored in memory or local storage on the client side), you are used to attaching them via the Authorization header using an interceptor or a fetch wrapper.

// A typical HTTP request with a Bearer token
fetch('/api/data', {
  headers: {
    'Authorization': `Bearer ${myToken}`
  }
});

However, the native browser WebSocket API does not support custom headers.

// This is all we get.
const ws = new WebSocket('wss://api.myapp.com/socket');

Since you can't pass the token in an Authorization header during the initial HTTP Upgrade request, developers are forced into clunky workarounds:

Query Parameters: Passing the token in the URL (wss://api.myapp.com/socket?token=ey...). This is generally considered a bad practice because URLs (and the sensitive tokens within them) end up in server logs, browser histories, and proxy logs.
First Message Auth: Opening the WebSocket connection unauthenticated, and then requiring the client to immediately send an authentication message containing the token before the server accepts any further messages. While secure, this adds latency and complexity to the connection lifecycle logic. You have to write boilerplate to handle connections that open but never authenticate.
Subprotocols: A hacky but working method where the token is passed as a WebSocket subprotocol (new WebSocket('wss://...', ['access_token', token])).

None of these feel particularly clean or idiomatic.

Why Cookies Work Naturally

This brings us to cookies, the method that I chose for Relay! Cookies are managed by the browser. Whenever the browser makes an HTTP request to a domain, it automatically attaches the cookies associated with that domain.

Because the WebSocket handshake is just a standard HTTP GET request, the browser automatically includes your cookies in the first request itself!

If your authentication system sets an HTTP-only cookie containing your JWT or session ID when the user logs in, you literally don't have to change any client-side code to authenticate your WebSockets. The browser handles it natively and securely.

// The browser automatically attaches the JWT auth cookie!
const ws = new WebSocket('wss://api.myapp.com/socket');

The Backend Implementation: Parsing the Cookie

While the client side becomes trivial, the backend need manual cookie parsing. When your WebSocket server receives the upgrade request, it hands you a raw Node.js IncomingMessage object.

Unlike Express requests which come with the cookies objects provided by middleware, the IncomingMessage just gives you the raw cookie header string. You have to parse it yourself before accepting the WebSocket connection.

Below is how I did the cookie parsing in Relay!

1. Extracting and Verifying the Token

First, we need a utility function to take the raw IncomingMessage, parse the cookie string, and verify our JWT.

import cookie from "cookie";
import jwt from "jsonwebtoken";
import type { IncomingMessage } from "http";
import { jwtPayloadSchema } from "../../http/schemas/auth.schema.js";

// Extract user ID from the raw HTTP upgrade request
export function extractUserId(req: IncomingMessage): string | null {
  // Parse the raw cookie header string
  const cookies = cookie.parse(req.headers.cookie ?? "");
  const token = cookies.token;

  if (!token) return null;

  try {
    // Verify the JWT signature
    const decoded = jwt.verify(token, process.env.JWT_SECRET as string);

    // Validate the payload shape
    const parsed = jwtPayloadSchema.safeParse(decoded);
    if (!parsed.success) {
      return null;
    }

    // Return the authenticated User ID
    return parsed.data.id;
  } catch {
    return null; // Token is invalid or expired
  }
}

2. The main Socket handling code

Now here, I integrate this utility into my WebSocket server initialisation. I intercept the connection, attempt to extract the user ID, and immediately close the connection with a 4001 Unauthorized status if the authentication fails.

import { WebSocketServer, type WebSocket } from "ws";
import type { Server as HttpServer } from "http";
import { extractUserId } from "./handlers/message.handler.js";
import { sockets } from "./store.js";

export function initWebSocketServer(server: HttpServer) {
  const wss = new WebSocketServer({ server });

  wss.on("connection", (ws: WebSocket, request: IncomingMessage) => {
    ws.on("error", console.error);

    // 1. Authenticate immediately using the parsed cookie
    const id = extractUserId(request);

    // 2. Reject unauthenticated connections at the handshake level
    if (!id) {
      ws.close(4001, "Unauthorized");
      return;
    }

    // 3. Connection is fully authenticated!
    // We can safely associate this socket with the user
    sockets.addUser(id, ws);

    // Proceed with authorized application logic...
    console.log(`User ${id} connected successfully.`);

    ws.on("message", async (data) => {
      // ... handle incoming messages knowing the sender's true identity
    });

    ws.on("close", () => {
      sockets.removeUserSocket(id, ws);
    });
  });
}

Wrapping up

When building real-time applications, relying on HTTP-only cookies for authentication eliminates the friction of securing WebSockets. By leaning on the browser's native cookie management, we avoid leaking tokens in URLs and bypass the complexity of first-message authentication handshakes. It requires a tiny bit of manual header parsing on the backend, but the resulting client-side simplicity and security posture are well worth the trade-off.

For those of you who would like to go through the codebase, you can do so here.
I'll be back with more next week. Until then, stay consistent!

I Built a Real-Time Chat App from scratch - Here's What I Learned

Nikhil Sharma — Tue, 26 May 2026 18:03:37 +0000

When dealing with WebSockets, most tutorials will straightaway hand you Socket.io and call it a day. You get a working chat app in short period of time but you have no idea what happened.

I actually wanted to understand what was going on, how WebSockets work, how auth happens, how to deal with cookies when working with WebSockets and so many more tiny things.
So I built Relay. A full stack real-time chat app with raw WebSockets, Express for the backend, React for the frontend and PostgreSQL.
The reason for doing everything manually was that I wanted to learn. I did not want to launch and make a chat app and sell it. I just wanted to learn the implementation of these technologies.

Thus, here we are. This is the first post in a series where I will be exploring the project and breaking down the most interesting technical problems I ran into. But first, let's see what Relay is, how it works, and why I built it the way I did.

What Relay Does

Real-time messaging — Messages are sent and received instantly over WebSockets. No polling, no long-polling, no hacks.
Persistent history — Every message is stored in PostgreSQL via Prisma ORM. Close the tab, logout, the messages will still be there when you come back.
Cookie-based auth — JWT tokens stored in httpOnly cookies. The WebSocket handshake authenticates by manually parsing cookies from the upgrade request headers.
Dual-protocol architecture — REST API(the express part) handles the CRUD stuff (auth, fetching users, loading message history). WebSockets handle the real-time stuff (sending messages, live delivery). Each protocol does what it's good at and that is exactly what I wanted to learn to do myself. And also the fact that how would I implement both these protocols in the same project for maximum efficiency.

Architecture and Flow

The app follows a fairly standard real-time chat architecture with a clear separation between frontend and backend responsibilities.

On the frontend, the application is built using React, TypeScript, and Vite. Authentication state is managed through an AuthContext, chat history is handled using a useMessages hook, and real-time communication is managed by a useWebSocket hook. The frontend communicates with the backend in two ways:

REST API calls using Axios over HTTP for things like authentication, fetching users, loading messages, and logout.
WebSocket connections (ws://) for real-time messaging and live updates.

On the backend, the application uses Node.js with Express for REST APIs and the ws library for WebSocket support. The backend exposes REST routes such as /signup, /signin, /users, /messages, /me, and /logout. Alongside this, a WebSocket server handles persistent connections, live message delivery, and connection management.

Both the REST API layer and WebSocket server interact with the database through Prisma ORM, which connects to a PostgreSQL database for storing users, messages, authentication data, and related application state.

Now for the flow. This is the part I find most interesting. Here's what happens when you hit send:

Frontend calls sendMessage(to, content) which writes a JSON frame to the open WebSocket: { type: "send_message", payload: { to, content } }
Backend WS handler receives it, validates the payload, and does two things simultaneously:
- Persists the message to PostgreSQL via Prisma
- Looks up the recipient's socket in the in-memory connection store (which I will update to be a singleton SocketManager class instead of just a map)
If the recipient is online, the backend pushes the message to their socket as a receive_message event, they see it instantly
If they're offline, the message is still in the database. Next time they open the chat, the frontend fetches history via the REST endpoint /messages?userId=...
The sender gets an ack back over the WebSocket confirming the message was processed

No message broker, no queue, no Redis (yet, as that is the plan for v2). Just an in-memory Map<userId, WebSocket> and a database. It's simple, it works for a single server, and it's the kind of thing that makes you appreciate what a system like Kafka(v2.5 maybe?) is actually solving when you eventually need it.

Here are the interesting bits

All of these will be individual posts in the coming days.

1. Cookie auth over WebSockets

Auth over REST is easy, but how does it happen when dealing with persistent connections. WebSockets don't have a middleware chain and also have no authorization header during the upgrade handshake.
The solution - cookies!.

2. The React Stale Closure bug

Imagine opening a chat in two tabs, you receive a message from User A, but see it silently render in the chat window for User B. No backend errors, just a complete UI mismatch.

3. The dual protocol magic

How the HTTP and WS protocols interleave.

4. Raw WS

How you create every feature you need using raw WebSockets instead of Socket.io and have so much more understanding of the concepts.

Wrapping up

For those of you who would like to go through the codebase, you can do so here.
I'll be back with more next week. Until then, stay consistent!

I Built a Real-Time Chat App from scratch - Here's What I Learned

Nikhil Sharma — Tue, 26 May 2026 18:03:37 +0000

When dealing with WebSockets, most tutorials will straightaway hand you Socket.io and call it a day. You get a working chat app in short period of time but you have no idea what happened.

What Relay Does

Real-time messaging — Messages are sent and received instantly over WebSockets. No polling, no long-polling, no hacks.
Persistent history — Every message is stored in PostgreSQL via Prisma ORM. Close the tab, logout, the messages will still be there when you come back.
Cookie-based auth — JWT tokens stored in httpOnly cookies. The WebSocket handshake authenticates by manually parsing cookies from the upgrade request headers.
Dual-protocol architecture — REST API(the express part) handles the CRUD stuff (auth, fetching users, loading message history). WebSockets handle the real-time stuff (sending messages, live delivery). Each protocol does what it's good at and that is exactly what I wanted to learn to do myself. And also the fact that how would I implement both these protocols in the same project for maximum efficiency.

Architecture and Flow

The app follows a fairly standard real-time chat architecture with a clear separation between frontend and backend responsibilities.

REST API calls using Axios over HTTP for things like authentication, fetching users, loading messages, and logout.
WebSocket connections (ws://) for real-time messaging and live updates.

Now for the flow. This is the part I find most interesting. Here's what happens when you hit send:

Frontend calls sendMessage(to, content) which writes a JSON frame to the open WebSocket: { type: "send_message", payload: { to, content } }
Backend WS handler receives it, validates the payload, and does two things simultaneously:
- Persists the message to PostgreSQL via Prisma
- Looks up the recipient's socket in the in-memory connection store (which I will update to be a singleton SocketManager class instead of just a map)
If the recipient is online, the backend pushes the message to their socket as a receive_message event, they see it instantly
If they're offline, the message is still in the database. Next time they open the chat, the frontend fetches history via the REST endpoint /messages?userId=...
The sender gets an ack back over the WebSocket confirming the message was processed

Here are the interesting bits

All of these will be individual posts in the coming days.

1. Cookie auth over WebSockets

2. The React Stale Closure bug

Imagine opening a chat in two tabs, you receive a message from User A, but see it silently render in the chat window for User B. No backend errors, just a complete UI mismatch.

3. The dual protocol magic

How the HTTP and WS protocols interleave.

4. Raw WS

How you create every feature you need using raw WebSockets instead of Socket.io and have so much more understanding of the concepts.

Wrapping up

For those of you who would like to go through the codebase, you can do so here.
I'll be back with more next week. Until then, stay consistent!

Week 12: Typescript Magic!

Nikhil Sharma — Sun, 01 Feb 2026 17:11:40 +0000

Last week, we talked about how Prisma helps us in simplifying our DB queries, but as a project grows, we face another massive challenge: consistency. When you have dozens of files and data moving between them, it's very easy to lose track of what "shape" an object has.

In plain JavaScript, you might call a property user_id in your database logic, userId in your controller, and just id in your frontend. In a small project, you can keep that in your head. In a production-level app?

It’s a straight-up disaster waiting to happen. You won't know something is broken until the code actually runs and crashes with the dreaded Cannot read property 'id' of undefined.

The solution is TypeScript. It’s not just "JavaScript with types"; it’s a high-tech safety net. It creates a development environment where the editor itself understands your data structures. It ensures that if you change a property name in one place, the rest of your app doesn't quietly crumble—it screams at you until you fix it.

1a. Setting Up the Environment📎

Unlike JavaScript, which Node.js or a browser can read directly, TypeScript needs to be "transpiled." Think of it as a pre-processing step where your type-heavy TS code is stripped down into clean, performant JS that engines can actually execute. To get started, the setup involves a few key commands that I now have on muscle memory:

# Initialize a node project to manage dependencies
npm init -y

# Install TypeScript as a dev dependency (we don't need it in production)
npm install typescript --save-dev

# Initialize the TypeScript compiler and create the config
npx tsc --init

This generates a tsconfig.json file. This file is the "brain" of your project. It’s where you tell the compiler exactly how strict you want to be, which version of JavaScript to target, and where to look for your files.

1b. Organizing with rootDir and outDir

In a professional workflow, you never want your source code (the stuff you edit) and the distribution code (the stuff that runs) mixed together. It makes version control a nightmare and the project structure confusing.

To solve this, we dive into the tsconfig.json and configure two crucial settings:

rootDir: This points the compiler to our source folder. Usually, we set this to ./src. This is where all our .ts files live.
outDir: This tells the compiler where to dump the generated JavaScript. We usually use ./dist (distribution) or ./build.

By setting these up, your workflow becomes streamlined: you write code in src, run npx tsc, and TypeScript replicates your entire folder structure inside dist, but converted to JavaScript. This keeps your project clean and ready for deployment.

2. Beyond Basics: Interfaces, Enums, and Generics

A. The Power of Interfaces

Interfaces enforce a "contract." If a blueprint says a house needs four windows, TypeScript won't let you build it with three.

export interface User {
    id: string;
    username: string;
    email: string;
    role: UserRole; // Using an Enum
    tags?: string[]; // Optional property
}

B. Enums: Eliminating "Magic Strings"

Don't use strings like "admin" or "guest" throughout your code. Use Enums to create a single source of truth for constant values.

enum UserRole {
    Admin = "ADMIN",
    Moderator = "MODERATOR",
    User = "USER"
}

const myUser: User = {
    id: "1",
    username: "Nikhil_Dev",
    email: "nikhil@example.com",
    role: UserRole.Admin // Type-safe and discoverable
};

C. Generics: Writing Reusable Logic

Generics allow you to create components that work over a variety of types rather than a single one. This is crucial for API responses.

interface ApiResponse<T> {
    status: number;
    data: T;
    error?: string;
}

// Now we can reuse this for Users, Products, or Orders
const userResponse: ApiResponse<User> = {
    status: 200,
    data: myUser
};

3. End-to-End Type Safety (Frontend + Backend)

The "Holy Grail" of development is sharing types across your stack. By exporting interfaces from a shared folder, your Frontend knows exactly what the Backend is sending.

Shared Function Signatures

Imagine a function that updates a user profile. In TypeScript, we can ensure the payload matches the expected structure before the API call is even made.

type UpdateUserPayload = Pick<User, "username" | "tags">;

async function updateUser(id: string, payload: UpdateUserPayload): Promise<void> {
    // TypeScript ensures payload only contains username or tags
    await fetch(`/api/user/${id}`, {
        method: 'POST',
        body: JSON.stringify(payload)
    });
}

New things I learnt this week🔄

The Power of strict: true: Turning this on in tsconfig is like playing a game on "Hard Mode." It forces you to handle null and undefined cases explicitly. It’s annoying at first, but it eliminates about 90% of common runtime bugs.
Targeting Environments: I learned that I can write modern ES6+ TypeScript but tell the compiler to output older ES5 code if I need to support legacy environments.
Type Inference: I realized I don't have to define everything. If I write let name = "Nikhil", TypeScript is smart enough to know it's a string. You only need to be explicit when things get complex.

Wrapping up

While the topics that I covered this week were small, they are crucial and of immense importance when building production-ready apps. If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Week 11: Prisma!

Nikhil Sharma — Wed, 17 Dec 2025 04:57:00 +0000

This week I explored the Prisma ORM, which simplifies our SQL journey by a LOT. Let’s get right into it!

Topics Covered✅

Last week, I worked with basic schemas and simple database interactions. But once our data starts to grow and multiple entities are involved, raw SQL queries or loosely typed database access quickly become messy and error-prone.

That’s where Prisma comes in.

This week revolved around:

Understanding what an ORM actually solves
Defining a database schema using Prisma
Generating type-safe database clients
Performing CRUD operations cleanly and safely

1. What is Prisma and why do we need it? 🧠

Prisma is an ORM (Object Relational Mapper). In simple terms, it acts as a bridge between our database and our application code.

Without Prisma, we might write raw SQL like this:

SELECT * FROM users WHERE email = 'test@gmail.com';

With Prisma, the same thing looks like:

const user = await prisma.user.findUnique({
  where: { email: "test@gmail.com" }
});

Why this matters

We don’t manually write SQL for every operation
Queries become type-safe
Refactoring database fields doesn’t silently break things
Autocomplete + compile-time checks save us from runtime bugs

2. Prisma Schema — the single source of truth 📄

First we initialise Prisma in our project (for which you can refer to the docs here).
At the heart of all generated files lies the schema.prisma file. This file defines:

our database connection
our models (tables)
relationships between models

A basic example:

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  name      String?
  createdAt DateTime @default(now())
}

This schema:

Creates a User table
Automatically enforces uniqueness on email
Generates types that our editor understands

Once this is written, running:

npx prisma generate

creates a fully typed Prisma Client for us — which we can just import in our DB setup files and use as simply as this -

import { PrismaPg } from '@prisma/adapter-pg'
import { PrismaClient } from "@/app/generated/prisma/client";

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
})
const prisma = new PrismaClient({
  adapter,
});

3. Migrations — evolving the database safely 🔁

Databases are never static. Fields get added, removed, or changed. Prisma handles this through migrations.

Example:

npx prisma migrate dev --name add-user-model

What this does:

Creates a migration file
Applies changes to the database
Keeps history of schema evolution

This ensures our local DB, staging DB, and production DB all stay in sync. And the generated migration files are simply the SQL versions of the queries that we can write easily using Prisma.

4. CRUD operations with Prisma ✍️

Prisma makes CRUD operations intuitive and readable.

Create

await prisma.user.create({
  data: {
    email: "nikhil@gmail.com",
    name: "Nikhil"
  }
});

Read

const users = await prisma.user.findMany();

Update

await prisma.user.update({
  where: { id: 1 },
  data: { name: "Updated Name" }
});

Delete

await prisma.user.delete({
  where: { id: 1 }
});

Each of these operations is:

Typed
Validated at compile time
Predictable in behaviour

And to see what parameters these functions expect we can just refer to the docs.

5. Relations and foreign keys made simple 🔗

Defining relations in Prisma is surprisingly clean.

Example:

model User {
  id    Int    @id @default(autoincrement())
  posts Post[]
}

model Post {
  id     Int  @id @default(autoincrement())
  title  String
  user   User @relation(fields: [userId], references: [id])
  userId Int
}

Now Prisma understands:

One user → many posts
How to join data internally
How to fetch nested data safely

Fetching related data:

const user = await prisma.user.findUnique({
  where: { id: 1 },
  include: { posts: true }
});

New things I learnt this week 🔄

Prisma acts as an intermediary between our code and database - increasing our ease while also giving type safety, which is an absolute game changer.
Schema-first design prevents an entire class of bugs

Wrapping up

While Prisma might feel like “just another tool”, it fundamentally changes how confidently we interact with our database. Clean schemas and safe migrations make production systems far more reliable.

If you have any questions or feedback, make sure to comment and let me know! Also, if you have any project ideas for me, please drop em in the comments!

I’ll be back next week with more. Until then, stay consistent!

Week 10: Databases - The Real Backbone of Our Apps!

Nikhil Sharma — Mon, 08 Dec 2025 18:14:30 +0000

This week, I went deeper into something that quietly run the entire show behind our apps - databases.

Honestly, this was one of those weeks where everything just clicked. The more I understood, the more things felt structured and “ohhh, so that's how it's done.” Let’s get right into it!

🗂️ Types of Databases

At the highest level, we can split databases into two big families:

1. SQL Databases (Relational)

These are structured, rigid, strict but all in a good way.

Data lives in tables
Tables have columns with fixed types
There are relationships between tables
Everything is based on a schema we define upfront
We interact using SQL (Structured Query Language)

Examples: PostgreSQL, MySQL, MariaDB, SQL Server

2. NoSQL Databases (Non-Relational)

These are way more flexible and relaxed with structure.

No fixed schema
Great for rapidly changing data
Designed for quick reads, massive scale
Data can be documents, key-value pairs, graphs, columns…

Examples: MongoDB, Redis, Cassandra, DynamoDB

Where MongoDB Fits

MongoDB is a NoSQL Document Database.

Instead of rows and columns, MongoDB stores data as documents that look like JSON.

A user record might look like this:

{
  "name": "Ayu",
  "age": 20,
  "hobbies": ["painting", "reading"]
}

This is super flexible! We can add or remove fields anytime and get no schema alerts.

MongoDB Advantages

MongoDB does a bunch of things really well:

Schema flexibility - perfect for fast prototyping
Horizontal scaling - adding more servers is easier
Great for document-shaped data
Works naturally with JavaScript since it uses JSON-like syntax
High read performance when queries align with document structure

When we want speed and flexibility(say in a hackathon), MongoDB feels amazing.

But MongoDB Has Its Downsides Too

As we scale, we start to notice some cracks:

Relationships are painful Joining data across collections feels messy.
Data integrity isn’t guaranteed by default If we expect strict correctness → things get tricky.
Query patterns can degrade performance Indexing becomes super important and manually tuned.
Harder to enforce structure Which means bugs can slip into the data layer.

MongoDB is perfect until we need the kind of discipline that big systems demand.

🧠 Why Most Companies Still Prefer SQL

Across the industry, SQL remains the default, and once we dig into it, the reasons feel obvious.

SQL databases like Postgres give us:

Structure
Predictability
Reliability
Better Relationships
ACID guarantees
Rich querying capabilities

When correctness matters, SQL usually wins.

Say in payments, inventory, authentication, banking, analytics, logistics and so many more. Basically anything where one mistake can cause a lot of trouble, SQL wins.

Why SQL (especially Postgres) feels better for many use cases:

Every table has a schema → fewer “surprise bugs”
Strong JOIN support → complex relationships are easy
Transactions → either everything succeeds or nothing does
Indices, constraints, triggers → very mature tooling
Postgres-specific power-ups:
- JSON support (best of both worlds)
- Window functions
- Full-text search
- Extensions like pgvector, PostGIS

Postgres feels like that reliable friend who just never drops the ball.

⚠️ But SQL Has Some Cons Too

Nothing is perfect.

Schema changes can be heavy
Horizontal scaling is harder
Rigid structure might feel slow during rapid iteration
Requires more planning upfront

Still, for most of the systems we want to build, SQL’s strengths massively outweigh its weaknesses.

🐘 Our Choice This Week: PostgreSQL

So this week was all about Postgres, one of the most powerful SQL databases out there.

We focused on understanding:

How tables are created
How constraints keep our data safe
How relationships work using foreign keys
How SQL queries are structured
Why good database design matters

And since we’re building in the JavaScript ecosystem, we’ll be pairing Postgres with Prisma as our ORM but that’s a whole topic by itself, so that’s coming next week.

This week is pure SQL.

SQL Examples — With Intuition

▶ Creating a Table

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL
);

What’s happening?

We’re designing a structure where:

id auto-increments
name must always exist
email must be unique
Postgres will now enforce these rules for us

This is the kind of discipline that NoSQL doesn’t enforce.

▶ Inserting Data

INSERT INTO users (name, email)
VALUES ('Ayu', 'ayu@example.com');

This just means:

“Put a new row into the users table with these values.”

SQL has a learning curve which could be slow in the beginning but, as is the case with everything, gets easier with practice.

▶ Querying Data

SELECT * FROM users WHERE email = 'ayu@example.com';

We’re pulling only the data that matters.

This precision is where SQL shines.

▶ Updating Data

UPDATE users
SET name = 'Ayu'
WHERE id = 1;

We’re telling Postgres:

“Find the row where id = 1”
“Change the name to Ayu”

▶ Deleting Data

DELETE FROM users WHERE id = 1;

Again - clean and readable(because our use-case is simple – SQL queries can get very complex, but an ORM helps simplify it further).

Wrapping Up

This week gave us a solid foundation in understanding why databases behave the way they do, and why SQL (especially Postgres) is still the king for most real-world applications. MongoDB is incredible for flexibility and fast-moving projects but SQL is unbeatable for consistency and correctness.

Next week, we’ll take all this knowledge and plug it into Prisma, making database interactions feel a LOT easier.

If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Week 9: Using Recoil in React!

Nikhil Sharma — Mon, 01 Dec 2025 18:28:41 +0000

Back after 2 weeks of vacation!(it was actually a continuous battle with so many evaluations and exams at college). During this time I've been covering State Management with context API and Recoil! Let's get right into it!

Topics Covered✅

Context API
Problems with Context API
Recoil and why it's better
Atoms & Selectors
Recoil hooks (useRecoilState, useRecoilValue, useSetRecoilState)
Using RecoilRoot
When to still use useState

1. Starting with the Context API 🧩

Last week, we spoke about prop drilling and how passing props through multiple layers can make your code look messy. The Context API is React’s built-in solution to this.

It lets you create global-ish state without prop drilling.

Here’s a tiny example:

// UserContext.jsx
import { createContext } from "react";

export const UserContext = createContext(null);
// App.jsx
import React, { useState } from "react";
import { UserContext } from "./UserContext";

function App() {
  const [user, setUser] = useState("Nikhil");

  return (
    <UserContext.Provider value={{ user, setUser }}>
      <Parent />
    </UserContext.Provider>
  );
}

export default App;
// Child.jsx
import { useContext } from "react";
import { UserContext } from "./UserContext";

function Child() {
  const { user } = useContext(UserContext);

  return <h2>Hello, {user}!</h2>;
}

export default Child;

This appears to work well. But it does so only for small and simple apps.

2. The problem? 😵‍💫

As our app grows, Context API introduces a few issues:

1. Re-renders

Any value change in the context re-renders every component that consumes it, even if only one component actually needed the update.

2. Too many contexts

You often end up creating multiple contexts:

UserContext
ThemeContext
NotificationContext

and so on.

This becomes hard to organise and maintain.

3. Not a full state management solution

Context wasn't designed for big, complex global state. It's more of a “prop drilling escape hatch”.

3. Recoil ⚛️ - The solution

Recoil is a super-lightweight state management library made for React. It fixes the problems above without introducing the complexity of Redux.

Why Recoil feels so good:

It updates only the components that need the state.
You don’t need multiple providers — everything sits under one RecoilRoot.
It’s extremely intuitive because it feels like working with React’s useState.
Recoil introduces atoms, which are simply pieces of global state.

4. Getting started with Recoil

Step 1: Wrap your app in a RecoilRoot

// index.jsx
import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";
import { RecoilRoot } from "recoil";

ReactDOM.createRoot(document.getElementById("root")).render(
    <RecoilRoot>
    <App />
  </RecoilRoot>
);

Step 2:Creating an atom

Atoms store global state. We usually create them in a separate folder and export them from there and then we can use them globally.

// atoms/userAtom.jsx
import { atom } from "recoil";

export const userAtom = atom({
    key: "userAtom",
  default: "Nikhil",
});

Step 3:Using the globally declared states in Components

For this we use majorly three functions

useRecoilState → like useState but global

import { useRecoilState } from "recoil";
import { userAtom } from "./atoms/userAtom";

function UserUpdater() {
  const [user, setUser] = useRecoilState(userAtom);

  return (
    <button onClick={() => setUser("Ayu")}>
      Change User
    </button>
  );
}

useRecoilValue → read-only access- so it basically just gives us the variable and not the function to change its value.

import { useRecoilValue } from "recoil";
import { userAtom } from "./atoms/userAtom";

function UserDisplay() {
  const user = useRecoilValue(userAtom);
  return <h2>Hello, {user}!</h2>;
}

useSetRecoilState → write-only access

import { useSetRecoilState } from "recoil";
import { userAtom } from "./atoms/userAtom";

function LogoutButton() {
  const setUser = useSetRecoilState(userAtom);

  return <button onClick={() => setUser(null)}>Logout</button>;
}

Selectors -

Selectors let you derive data from atoms, say computed values. This is how we'd create one.

import { selector } from "recoil";
import { userAtom } from "./userAtom";

export const capitalisedUserSelector = selector({
  key: "capitalisedUserSelector",
  get: ({ get }) => {
    const user = get(userAtom);
    return user.toUpperCase();
  }
});

And to use it we do this-

import { useRecoilValue } from "recoil";
import { capitalisedUserSelector } from "./atoms/selectors";

function Display() {
  const name = useRecoilValue(capitalisedUserSelector);
  return <h3>{name}</h3>;
}

5. Should we ditch useState now?

Not at all.
If a state variable is only needed by 1–2 components, using Recoil is unnecessary.

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <>
      <p>{count}</p>
      <button onClick={() => setCount(count + 1)}>+</button>
    </>
  );
}

No reason to make count global here. React’s local state is still perfect for component-specific logic.
We use Recoil only when:

Many components need the same state
Passing props becomes painful
Context starts slowing down your UI ## Things I found interesting this week
Seeing how Recoil prevents unnecessary re-renders felt magical. The component isolation makes the app feel snappier.
Atoms being global state and also visually being "global state" made the learning curve super smooth for me. ## Wrapping up🔄 Interesting week.

Note: While learning Recoil this week, I actually didn’t know that the library had been archived. Since I had already started, I went ahead and completed it anyway — the concepts are super useful to understand. I’ll be moving to Jotai soon since it’s lightweight, actively maintained, and follows a similar mental model to Recoil, so the transition should feel smooth.

If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Vacation week!

Nikhil Sharma — Mon, 17 Nov 2025 16:39:25 +0000

This week wasn’t about new concepts or heavy learning.
Exams are around the corner, I’ve been traveling back and forth between home and college, and it was also the birthday of someone very close to me. So life was a little full in the best ways.

So this became a vacation week. A breather I honestly needed.

I'll be back with more next week! Till then, stay consistent.

Week 8: Routing, Lazy Loading and more in React!🎨

Nikhil Sharma — Mon, 10 Nov 2025 18:00:04 +0000

This week I delved into an absolute essential for building a web application! Client-side routing and lazy loading. Let's get right into it!

Topics Covered✅

Client-side routing
Lazy-loading
Prop-drilling and its solutions

1. Routing📎

Routing is one of the first things that I'd do if I was in a hackathon and needed to get a project up and running quickly.

React enables us to build single-page applications (SPAs), where navigating between pages doesn’t trigger a full page reload. Instead of reloading the entire site and fetching a new HTML file each time, React uses client-side routing. This means the app dynamically updates the content and changes the URL without requesting a new page from the server.

This approach makes navigation faster and smoother, since the JavaScript bundle is loaded only once, and React handles rendering the appropriate components for each route.

This is how we'd change the route in a very superficial way

import React from "react";

function Home() {
  const goToAbout = () => {
    // This causes a full page reload instead of client-side routing
    window.location.href = "/about";
  };

  return (
    <div>
      <h1>Welcome to Home Page</h1>
      <button onClick={goToAbout}>Go to About</button>
    </div>
  );
}

export default Home;

But you'll notice that here too , the page hard reloads. To avoid this, we use a library that helps in routing — 'react-router-dom'. Here is how we'd use that to do the same routing as above

import React from "react";
import { useNavigate } from "react-router-dom";

function Home() {
  const navigate = useNavigate();

  const goToAbout = () => {
    // This changes route without reloading the page
    navigate("/about");
  };

  return (
    <div>
      <h1>Welcome to Home Page</h1>
      <button onClick={goToAbout}>Go to About</button>
    </div>
  );
}
export default Home;

But there's a little caveat that comes with the useNavigate()hook we use here. It can only be used inside components that are wrapped by a Router. This means that for the useNavigate hook to work, the component must be rendered within a Router context provided by react-router-dom.
This is how our App() function should look for the above to work-

import React from "react";
import { BrowserRouter, Routes, Route } from "react-router-dom";
import Home from "./Home";
import About from "./About";

function App() {
  return (
    //  useNavigate works only inside components wrapped by a Router
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </BrowserRouter>
  );
}

export default App;

This stops the page from hard reloading and instead does client-side routing! This is crucial for building fast web applications.

2. Lazy loading 💤

Another thing we can do to optimise the user's experience is to add lazy-loading to our application. But that is truly useful only if our application has grown large enough.

But below is an example of how to do it.

import React, { Suspense } from "react";
import { BrowserRouter, Routes, Route } from "react-router-dom";

// Lazy load the About component
const About = React.lazy(() => import("./About"));
import Home from "./Home";

function App() {
  return (
    <BrowserRouter>
      {/* Suspense shows fallback while About is being loaded */}
      <Suspense fallback={<div>Loading...</div>}>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/about" element={<About />} />
        </Routes>
      </Suspense>
    </BrowserRouter>
  );
}

export default App;

Notice here that we have to use the Suspense API along with lazy loading else React throws us an error. What this API does is that it allows us to add a "fallback" in case the user's network is too slow and the component cannot load in time.

Another benefit for lazy loading is that it reduces the initial bundle size of our application, leading to faster load times and improved performance, especially for users with slower internet connections.

3. Prop Drilling

In one of the earlier blog posts, when we read about various app optimisation techniques and the need to lower our re-renders we studied how we should push down state to the lowest common ancestors of the nodes that need those state variables.

But this could still lead to scenarios where the state variable is being passed down through multiple components that don't need the variables for themselves but still have to pass it down. This leads to code that can look very unappealing and overtime become difficult to manage.

This visually and syntactically bad looking problem is what we call Prop Drilling. Note that prop drilling doesn't have much to do with performance issues as much as it is about the visual and structural complexity it causes.

Below is a small example of prop drilling-

import React from "react";

function App() {
  const user = "Nikhil";
  return <Parent user={user} />;
}

function Parent({ user }) {
  //Parent doesn't need 'user', but passes it down anyway
  return <Child user={user} />;
}

function Child({ user }) {
  return <GrandChild user={user} />;
}

function GrandChild({ user }) {
  return <h2>Hello, {user}!</h2>;
}

export default App;

Observe here how the user prop travels through multiple components (Parent, Child) that don’t actually need it — they just pass it along so GrandChild can use it. This is prop drilling.

The solution -

The solution, as we discussed earlier, is to somehow move all of the state logic outside the components, so that they exist globally. That way, any component that needs it can just call it and use it without it being needed to passed down.

We can do this using two things-

The Context API which is built into React but has its limitations like-
- It can lead to unnecessary re-renders if not used carefully.
- It is not a full-fledged state management solution and may not be suitable for very complex state management needs.
A state management library like RTK(redux tool kit), Recoil(now archived) or some lightweight library built on principles of Recoil, like Jotai or Zustand. These libraries provide more robust solutions for managing global state in larger applications.

We cover both of these topics in the next blog together!

Things I found interesting this week

Lazy loading was such a cool concept! Seeing the components load one-by-one in the networks tab was really interesting.
Client-side-routing really tickled a corner of my brain that I did not know wanted to be tickled. Taught me how the URL change in the search bar when we click on different links on a site.

Wrapping up🔄

Another week gone and some more fundamentals mastered. Really interested to do a state-management library next week. If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Week 7: React hooks and more!

Nikhil Sharma — Mon, 03 Nov 2025 18:25:04 +0000

This week was very light. I did not cover anything that was too new or too hard because I needed a break and also wanted to stay in touch! So let's get right into it.

Topics Covered✅

React returns- the need to return just one parent component
Re-Renders and minimising them
Keys in React
Wrapper components and children
Hooks
React.memo

Let's get into them in detail.

1. React Returns

If you notice that when we try to return sibling components out of a React component, React screams a huge NO. This is because React components must return a single root element. Returning multiple sibling elements isn’t allowed because each component needs one clear root in the virtual DOM tree. This structure enables React’s reconciliation process to work efficiently.

2. Re-Renders and minimising them

A re-render in React happens when a component’s output (its JSX) is recalculated, and React determines whether the DOM needs to be updated or not. Unnecessary or frequent re-renders can impact performance if not managed properly, thus, we need to minimise them.

If a parent component re-renders then all its child components re-render along with it. One way to optimise re-renders is to push down state into the lowest common ancestor of the nodes(or components) which need the state. We can also use something called React.memo which we will cover later in this blog.

Realistically, we would do this by pushing all state outside our core logic and using a state-management tool like Recoil(archived), RTK(Redux Toolkit) or something light like Jotai or Zustand.

3. Keys in React

Whenever we render something in react which is a list of items like we did in our last blog.

export function Todos({todos , setTodos}){
    return <div>
        {todos.map((todo)=>{
            return <div key={todo.id}>
               <h1>{todo.title}</h1>
               <h1>{todo.description}</h1>
               {todo.completed?<span>Completed</span>:<button onClick={()=>{
                handleCompleted(todo._id,todos ,setTodos);
               }}>Mark as done</button>}
                </div>
        })}
    </div>
}

Here, React gives a soft warning when in StrictMode which says -
"Warning: Each child in an array or iterator should have a unique "key" prop. Check the render method of TodoList. See fb.me/react-warning-keys for more information."

What this means is that React needs some sort of a key to recognise which item in the list is being manipulated, deleted, moved around or anything of the sorts.

We can do this by adding a key prop to each todo as follows

return <div key={todo._id}> // parent div

4. Wrapper Components and children

Wrapper components come in handy when we want uniformity across components written by different people working on a project. In such cases, one person can define a wrapper component that handles common structure, styling, or logic. Other developers can then pass their component content as children to this wrapper.

An example of this is as follows-

function Card({ children }) {
  return <div className="card">{children}</div>;
}

// Usage
<Card>
  <h2>Title</h2>
  <p>This is inside the card!</p>
</Card>

5. React.memo

React.memo is a higher-order component that helps optimize performance by preventing unnecessary re-renders of functional components.

When you wrap a component with React.memo, React will only re-render it if its props change. If the props remain the same between renders, React skips rendering that component and reuses the previous result.

const TodoItem = React.memo(function TodoItem({ title, description }) {
  console.log("Rendered:", title);
  return (
    <div>
      <h1>{title}</h1>
      <p>{description}</p>
    </div>
  );
});

If the parent component re-renders but the props (title, description) for a particular TodoItem stay the same, that TodoItem won’t re-render and this saves computation time.

This is especially useful when you have large lists or expensive UI components that don’t need to update unless their data actually changes. But again this will be handled even better when we use a state-management library.

6. Hooks

While we did use some hooks like useState and useEffect in last week's project, this was more of an official definition. Hooks are functions that allow us to hook into react state and lifecycle features from functional components. And while there are a lot of hooks, only a handful are used in most code bases.

Wrapping up🔚

While this week was more theoretical and very light, it does set up some paths that will be very interesting in the upcoming weeks. Especially the state-management part is quite interesting. Some very intriguing stuff coming in the next weeks. If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Week 6: Understanding React through a project🎨

Nikhil Sharma — Mon, 27 Oct 2025 18:30:34 +0000

This week I decided to go deeper into React with a small project. The knowledge required to do this was not vast by any means, but it was nice to move away from snippets and theory to do something more practical. While the project was technically full stack, in this post I'll be delving primarily into the frontend. For the backend, you can see the full code on my GitHub here. Let's get right into it.

The Project - a very basic todo application✅

The project was a simple todo application that consisted of both a backend and a frontend.

The backend 🌐

The backend had the following endpoints-

POST /todos - allows the user to add a todo. The zod schema for this was

const createTodo = z.object({
  title: z.string(),
  description: z.string()
});

GET /todos - allows the user to get all their existing todos.
PUT /completed - allows the user to update an existing todo and mark it as done. The zod schema for this was -

const updateTodo = z.object({
  id: z.string(),
});

As I already said, the backend is quite simple and we've already covered these topics in our previous blogs, but you can get the full code at my GitHub. Let's get into the frontend now!

The frontend 💡

Now this bit is interesting(gotten a little bored with the backend:). I initialised an empty vite project, cleared the boilerplate code and setup the App.jsx to have only a couple of things — the rest of the stuff would be structured away neatly for modularity and readability.
In the App.jsx I declared my todos as a state variable which would be updated everytime the site re-renders(when a new todo is added or an existing todo is marked as done). For the first render, we would use the useEffect hook to update todos.

The useEffect hook🪝 -

Let's see the syntax first.

  useEffect(() => {
    fetch("http://localhost:3000/todos")
      .then(async (res) => {
        const json = await res.json();
        setTodos(json.todos);
      });
  }, []);

This makes it so that what's written in the function executes only when the React app mounts(or on specified conditions — we'll see that soon). This gives us great control over how many fetch requests we send out and on which re-renders the request runs.

This is controlled through the second argument in the useEffect hook which is called the dependency array. This array is where we pass in the dependencies which decide when the function in the first argument runs.

For eg. say I add a state variable 'a' to this dependency array. Then whenever 'a' updates, the first function runs. If we leave the dependency array empty then it gives the desired result in our case, which is the fetch request going out only on the app mount.

A couple of things to note here🚨-

We can't make the function in the first argument async. This is because useEffect hook expects the first argument to be a function that returns either nothing or a cleanup function. But an async function always returns a promise.
We should not put a state variable in the dependency array that is being updated in the function in the first argument as this would trigger an infinite loop.

The next part in the App.jsx was that it would return a div which would have two components as follows -

return (
<div>
  <CreateTodo setTodos={setTodos} />
  <Todos todos={todos} setTodos={setTodos} />
</div>
)

Let's delve into the components-

1. CreateTodo

I created the file 'CreateTodo.jsx' in the components folder in the src folder.
This was a relatively simple component which just returned a div with the input fields necessary to add a new todo.

import { useState } from "react";
export function CreateTodo({setTodos}) {
    const [title, setTitle] = useState("");
    const [description, setDescription] = useState("");
    return (<div>
        <input type="text" placeholder="Title" onChange={(e) => {
            const value = e.target.value;
            setTitle(value);
        }}></input><br />
        <input type="text" placeholder="Description" onChange={(e) => {
            const value = e.target.value;
            setDescription(value);
        }}></input><br />
        <button onClick={() => {
            fetch("http://localhost:3000/todos", {
                method: "POST",
                headers: {
                    "Content-Type": "application/json"
                },
                body: JSON.stringify({
                    title: title,
                    description: description
                })

            }).then(async (res) => {
                fetch("http://localhost:3000/todos")
                    .then(async (res) => {
                        const json = await res.json();
                        setTodos(json.todos);
                    });
            });
        }}>Add a todo</button>
    </div>);
}

Now this may seem jarring at first, but let's break it down.

We have two state variables for each of the input fields which update whenever the user types in them. These are used to send the backend calls necessary to add a new todo.
The button which has a pretty big onClick function which does two things. Firstly, it sends the POST request to add a new todo. You can see the syntax above to send the body with the request. After this, it asynchronously sends another request to GET the newly updated todos from the backend and updates the todos state variable. This causes a re-render in the <Todos> component and updates the displayed todos.

2. Todos

This is the component-

export function Todos({todos , setTodos}){
    return <div>
        {todos.map((todo)=>{
            return <div>
               <h1>{todo.title}</h1>
               <h1>{todo.description}</h1>
               {todo.completed?<span>Completed</span>:<button onClick={()=>{
                handleCompleted(todo._id,todos ,setTodos);
               }}>Mark as done</button>}
                </div>
        })}
    </div>
}

This is pretty simple and a very good use-case of the map method. It simply maps all the todos in the variable to be displayed individually in divs on the screen.

The main magic here is in the handleCompleted function.

function handleCompleted(id,todos,setTodos){
    fetch("http://localhost:3000/completed",{
        method:"PUT",
        headers:{
            "Content-Type":"application/json"
        },
        body: JSON.stringify({
            id
        })
    })
    .then (async(res)=>{
        const modifiedTodo = await res.json();
        const newTodos = todos.map((t) =>
        t._id === modifiedTodo.updatedTodo._id ? modifiedTodo.updatedTodo : t
      );

      setTodos(newTodos);
    })
}

This sends the PUT request to the endpoint to update the todo to mark it as done. Then it updates the todos to include the new updated todo instead of the old one (very good use-case of the ternary operator).

Some new things I learned🧨

The useEffect hook - nature of its two arguments!
How these backend calls do not actually hit the backend unless we include "CORS" in the backend which enables the backend to be hit from any URL.
The syntax of sending these requests can seem a bit verbose and jarring but we simplify it by using the Axios library which we will study soon!

Wrapping up🔚

The practicality of this week's assignment kept me hooked. Now that we have some more understanding of React, we dive deeper into React next week. Some more hooks and smaller topics. If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Week 5: Dipping into React🎨

Nikhil Sharma — Mon, 20 Oct 2025 17:06:33 +0000

This week, I took my first steps towards learning React! For now it was all about learning about state, hooks and most importantly, getting familiar with the syntax. Let's get right into it!

Topics Covered✅

The volume of topics I covered this week was modest, and the individual topics were pretty simple once I had dedicated some time to them. Here's a list of the topics I covered:

Basic File structure in the vite repository
useState hook
Components and props
Hooks vs side-effects

As usual, these topics were discovered slowly through assignments (and also with some help from the React docs).

Creating my first React app and learning about useState🚀

I used Vite to create my React app. For that, all I had to do was run

npm create vite@latest

in the terminal and then follow the steps on screen.

Everything I have to deal with for now is in the src folder.
I emptied out the two default css files and went straight to mess with the App.jsx file.

I then replaced the boilerplate code there with this-

import { useState } from 'react'

function App() {
  const [count,setCount] = useState(0);
  function onClickHandler(){
    // count++; not the right way to set state variables
    setCount(count+1);
  }

  return (
      <div>
        <button onClick={onClickHandler}>Counter {count}</button>
      </div>    
  )
}

export default App

And that, was my first React app.
Now I'm aware that this is as simple as it gets, but we all start somewhere right? This helped me learn about the useState hook.

This hook returns us a variable which is a state variable and a function that updates the state variable. We can give it a default value by specifying it in the brackets.

Something that was a bit strange to me here was how the App function returns a div. Initially, I thought I was returning plain HTML here, but it was actually JSX — a JavaScript syntax extension that looks like HTML but lets you embed JS expressions inside curly braces leading to some very interesting use-cases.

Components and props💡

Then I learned how it was better to have all the different parts of my React App as separate components.

A component is basically just a function that you declare with a capital first letter. We can use this name as a tag and pass in whatever parameters the function requires as props.

import { useState } from 'react'

function App() {

  const [count,setCount] = useState(0);
  return (
      <div>
        <CustomButton count={count} setCount={setCount}/>
      </div>    
  )
}
//component
function CustomButton(props){
  function onClickHandler(){
    props.setCount(props.count+1);
  }
  return <button onClick={onClickHandler}>Counter {props.count}</button>
}

export default App

Here is the exact same app as before, but this has the button as a separate component in the same file named as CustomButton. We pass down both count and setCount to the component with the shown syntax. We can then access all passed parameters which we get as an object called props. Thus we change the onClickHandler to use 'props.count' and 'props.setCount()'.

Structuring our app as a bunch of separate components just helps in code readability and modularity.

New things I learnt this week🔄

Structure of a React app
Hooks - just inbuilt React functions with special purposes
Using the useState hook
Object Destructuring - This is one I found very interesting.

When we pass down props to a component, we don't necessarily need to use the 'props.' syntax. Instead, we can destructure the props object to individually use all props. The syntax is as follows -

  function CustomButton({ count , setCount }){
  function onClickHandler(){
    setCount(count+1);
  }
  return 
  <button onClick={onClickHandler}>Counter {count}</button>
  }

This feels a bit cleaner to me. And we can destructure any object – not just the props object.

Wrapping up🔚

This week felt very fresh. A change of topics can do a lot to re-ignite interest. I'll cover some leftover topics I studied later on. Next week, we dive deeper into React with a project. If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!