DEV Community: dsmith_sys

[Read Once!!]

dsmith_sys — Sat, 12 Sep 2026 16:01:52 +0000

dsmith_sys

Sep 11

React Core 1: Understanding the Basics

#frontend #javascript #react #tutorial

8 min read

React Core 1: Understanding the Basics

dsmith_sys — Fri, 11 Sep 2026 05:05:19 +0000

Introduction

React is a JavaScript library for building user interfaces. I don't want to talk too much about the introduction—you can Google it or ask an AI about it. Here in this blog, I'll focus on the core concepts you should understand to become comfortable with React. I hope you'll stick around until the end.

JSX & How React Renders UI

JSX is a syntax extension for JavaScript that allows us to write HTML-like markup inside JavaScript.

For example:

function App() {
  return (
    <div>
      <h1>Hello World</h1>
      <button>Click me</button>
    </div>
  );
}

The browser does not directly understand JSX syntax. During the development/build process, our build tools transform JSX into regular JavaScript that the browser can execute.

You can think of the flow roughly like this:

JSX + JavaScript source code
          ↓
     Build tooling
          ↓
JavaScript/CSS/assets the browser can load
          ↓
        Browser
          ↓
      React starts
          ↓
React renders your components
          ↓
React reconciles the UI
          ↓
Necessary DOM updates
          ↓
      Browser paints
          ↓
       You see the UI

For example, when the browser loads a typical React application, it first loads the HTML file. The HTML contains something like:

<div id="root"></div>

Then the JavaScript application runs and React mounts the application into that root:

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

React then uses your components to determine what the UI should look like.

You may have heard the term Virtual DOM. It is useful as a mental model for understanding that React maintains an internal representation of the UI and uses reconciliation to determine what needs to change in the actual DOM. The browser itself does not know about React's Virtual DOM.

The important flow to remember is:

State/props change
       ↓
React renders the component again
       ↓
React gets a new description of the UI
       ↓
React reconciles it with the previous one
       ↓
React commits the necessary DOM changes

Element vs Component

This is pretty simple.

Consider this:

function App() {
  return (
    <div>
      <h1>Hello World</h1>
      <button>Click me</button>
    </div>
  );
}

<h1>, <button>, and <div> are JSX that create React elements.

App is a component.

A React element is an immutable plain object that describes what should appear in the UI. A component is a function (or class) that returns React elements.

You can think of it like this:

Component
    ↓
returns
    ↓
React elements
    ↓
React uses them to determine the UI

So:

function App() {
  return <h1>Hello World</h1>;
}

App → component

<h1>Hello World</h1> → React element created from JSX

Props vs State

Let's talk about two things you'll use constantly in React: props and state.

Props

Props are inputs passed from a parent component to a child component.

They are similar to function arguments.

For example:

function User({ name }) {
  return <h1>Hello {name}</h1>;
}

And the parent can pass the prop like this:

<User name="Rahul" />

You can think of it roughly like:

Parent
   ↓
passes props
   ↓
User({ name: "Rahul" })

Props are read-only from the child component's perspective. A child should not modify its props directly.

State

State is data managed by React that belongs to a component instance and can change over time.

For example:

const [count, setCount] = useState(0);

Here:

count is the current state value.
setCount is the function we use to request an update to that state.

When the state changes, React schedules a re-render.

One very important thing: a re-render does not mean React destroys the state and creates it again.

For example:

function Counter() {
  const [count, setCount] = useState(0);

  console.log("render");

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={() => setCount(count + 1)}>
        +1
      </button>
    </div>
  );
}

Initially:

count = 0
   ↓
<h1>0</h1>

After clicking the button:

setCount(1)
   ↓
React schedules a render
   ↓
Counter runs again
   ↓
count = 1
   ↓
<h1>1</h1>

The state is preserved between renders.

A re-render simply means React runs the component again to determine what the UI should look like with the current props and state.

Also, don't confuse a re-render with a page reload. A page reload reloads the entire web page, while a React re-render is part of React's normal rendering process.

React state is stored in memory. If a component is removed from the React tree, its state is no longer preserved. A full page reload also resets in-memory React state.

If you need data to survive a page reload, you need some form of persistence, such as localStorage, a database, or another storage mechanism.

State and props should be treated as immutable

You should not directly mutate state:

count = count + 1;

Instead, use the setter:

setCount(count + 1);

Similarly, don't directly modify props inside a child component.

So remember:

Props are read-only from the child's perspective, and state should be treated as immutable and updated through its setter.

Now let's put props and state together.

Try to run this example and follow the whole flow of execution from start to end. You'll get a much better idea of how they work together:

function Counter({ name }) {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>
        {name}: {count}
      </h1>

      <button onClick={() => setCount(count + 1)}>
        +1
      </button>
    </div>
  );
}

function App() {
  return <Counter name="Rahul" />;
}

Here, name comes from props, while count is managed using state.

Controlled & Uncontrolled Components

This concept mostly comes up with form inputs.

Controlled components

An input is controlled when React state controls its value.

For example:

function Form() {
  const [name, setName] = useState("");

  return (
    <input
      value={name}
      onChange={(e) => setName(e.target.value)}
    />
  );
}

The flow is:

User types
    ↓
onChange runs
    ↓
setName(...)
    ↓
React state changes
    ↓
React re-renders
    ↓
input receives the new value

Here, React is the source of truth for the input's value.

Uncontrolled components

An input is uncontrolled when the DOM itself maintains the current value.

For example:

function Form() {
  const inputRef = useRef(null);

  function handleSubmit() {
    console.log(inputRef.current.value);
  }

  return (
    <form onSubmit={handleSubmit}>
      <input ref={inputRef} />

      <button type="submit">
        Submit
      </button>
    </form>
  );
}

Here, React isn't storing the input value in state. The DOM maintains it.

useRef gives us a way to access the DOM node:

inputRef.current

Important: useRef itself does not make an input uncontrolled. The input is uncontrolled because its value is maintained by the DOM rather than being driven by React state.

Also remember:

useState
→ changing state causes a re-render

useRef
→ changing ref.current does not cause a re-render

A ref can also store mutable values that persist across renders.

So the simple rule is:

Use controlled components when you want React to control the input value through state. Use uncontrolled components when you want the DOM to manage the input value.

TASK: Write a simple form using both a controlled and an uncontrolled input. Submit the form and compare how you access their values.

`key` Prop in Lists

The key prop is needed when we're rendering multiple elements from a collection.

It helps React identify which items have changed, been added, removed, or moved between renders.

For example:

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

const listItems = numbers.map((number) => (
  <li key={number.toString()}>
    {number}
  </li>
));

Keys give elements a stable identity:

key = 1 → first item
key = 2 → second item
key = 3 → third item

Keys should be unique among siblings. They don't need to be globally unique across your entire application.

For example:

const users = [
  { id: 1, name: "Alice" },
  { id: 2, name: "Bob" },
  { id: 3, name: "Charlie" }
];

const userElements = users.map((user) => (
  <p key={user.id}>
    {user.name}
  </p>
));

Notice that the elements are <p> elements, not <li> elements. The key prop is not specific to lists or <li>. It is needed when React is dealing with multiple dynamically generated siblings.

What about array indexes?

You might see this:

users.map((user, index) => (
  <User key={index} user={user} />
));

It works, but it can cause bugs when the list can be reordered, inserted into, or have items removed.

For example:

Before:

key=0 → Alice
key=1 → Bob
key=2 → Charlie

If Alice is removed:

After:

key=0 → Bob
key=1 → Charlie

The keys stayed the same, but the items associated with those keys changed.

If those components contain their own state, React may preserve the state of the old component instance and associate it with a different item.

That's why a stable ID from your data is usually a better key:

<User key={user.id} user={user} />

Using an index can be okay when the list is static and its order/membership never changes.

Also, don't generate keys like this:

key={Math.random()}

or:

key={Date.now()}

Those values can change between renders. React can then treat the element as a completely new element, causing component instances to be recreated and potentially losing their state.

NOTE: The goal isn't simply "make the key unique." The key should be stable and unique among siblings.

Lifting State Up

This is a pretty interesting and useful React pattern.

Imagine you have two child components, and both of them need to share the same piece of state.

For example:

        Parent
       /      \
   Child A   Child B

If both children need access to count, where should count live?

We can lift the state up to their closest common ancestor:

        Parent
        count
       /     \
      ↓       ↓
 Child A   Child B

The parent owns the state and passes the required data and update functions down through props.

For example:

function ParentCounter() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        +1
      </button>

      <ChildBlue value={count} />
      <ChildGreen value={count} />
    </>
  );
}

Now both children receive the same count:

function ChildBlue({ value }) {
  return <p>{value}</p>;
}

function ChildGreen({ value }) {
  return <p>{value}</p>;
}

The important idea is:

Move shared state to the closest common ancestor of the components that need it.

This doesn't mean we should move every piece of state all the way up to <App />.

If two components can share state through a lower-level parent, keep the state there.

Moving state unnecessarily high can lead to unnecessary prop drilling and make state ownership harder to understand.

TASK: Build a simple counter app with two child components. The first child should display the count in blue, while the second displays it in green. Keep the count state in their parent and pass it down through props.

What about Context?

Now imagine that the component that needs the state is deeply nested:

Parent
  ↓
Child
  ↓
AnotherChild
  ↓
AnotherChild
  ↓
DeepChild ← needs the data

Passing the same prop through every component can become annoying. This is called prop drilling.

In this situation, we can use the Context API.

Context allows a value to be made available to components within a particular provider subtree without manually passing it through every intermediate component.

For example:

Provider
   ↓
   ├── Component A
   │
   ├── Component B
   │      ↓
   │   Component C
   │      ↓
   │   DeepChild ← useContext()
   │
   └── Component D

Context isn't necessarily "global state." It is better to think of it as a way to make a value available to a subtree of components.

Also, Context doesn't manage state by itself.

You can combine Context with useState:

const [user, setUser] = useState(null);

<UserContext.Provider value={{ user, setUser }}>
  <App />
</UserContext.Provider>

Here:

useState
   ↓
manages the state

Context
   ↓
makes that state available to descendants

So don't use Context for every piece of state. If two nearby components need to share state, lifting the state up and passing props is often simpler.

Context becomes useful when many components in a subtree need the same value and passing props through multiple levels becomes inconvenient.

Conclusion

That's it for React Core 1.

We've covered some of the concepts that form the foundation of React:

JSX
How React renders UI
Elements vs Components
Props vs State
Controlled vs Uncontrolled Components
useState vs useRef
The key prop
Lifting State Up
Context and Prop Drilling

i think this is enough for now, it covers mostly the basics of react. In the next blog, we'll cover more advanced topics, it will be interesting, so stay tuned.

Happy coding!

Brief About How the Protocol Switch Happens in WebSocket

dsmith_sys — Tue, 07 Jul 2026 12:54:26 +0000

Understanding What Actually Happens During a WebSocket Connection

If you've ever used WebSocket through libraries like ws or Socket.IO, you probably know that it enables real-time communication. But have you ever wondered what actually happens under the hood when a WebSocket connection is established?

Most explanations jump straight to APIs, but I wanted to understand how the protocol switch actually happens.

Before diving into the internals, let's first understand the problem WebSocket was trying to solve.

The Problem with HTTP

HTTP follows a request-response model.

A client sends a request, the server processes it, and then sends back a response. After that, the conversation is over unless the client sends another request.

That works perfectly for applications like loading web pages or fetching data. However, it becomes inefficient for real-time applications such as:

Chat applications
Multiplayer games
Live notifications
Stock or cryptocurrency price updates
Collaborative editors like Google Docs

In these applications, the server should also be able to send data whenever something changes instead of waiting for the client to ask every time.

WebSocket solves this problem by reusing the existing TCP connection.

Instead of creating a completely new transport protocol, it first performs a one-time HTTP Upgrade Handshake. Once both the client and the server agree, they stop communicating using HTTP rules and start communicating using WebSocket rules—all over the same TCP connection.

Now that we know why WebSocket exists, let's understand how this protocol switch actually happens.

Let's Understand TCP

TCP (Transmission Control Protocol) was introduced by Vint Cerf and Bob Kahn as part of the TCP/IP protocol suite.

It follows a three-way handshake to establish a reliable connection between the client and the server.

TCP is a transport-layer protocol. It does not know the meaning of the data it is transporting.

The data is transported in an ordered manner using sequence numbers, which help TCP reconstruct the byte stream correctly at the receiving end.

It ensures reliable delivery. If any data is lost or corrupted during transmission, TCP retransmits it.

To TCP, everything is simply a stream of bytes.

Whether those bytes represent HTTP, WebSocket, JSON, an image, or anything else is none of TCP's concern.

How HTTP Is Built on Top of TCP

Here, the TCP connection is not changing in any way.

We simply interpret the byte stream using HTTP's text-based rules.

When the client sends data following the HTTP format (such as GET, headers, CRLF, etc.), the server in its HTTP state starts the HTTP parser and parses the incoming bytes as an HTTP request.

If the incoming bytes do not follow HTTP's formatting rules, the HTTP parser treats the request as invalid and usually returns an error or closes the connection.

Finally... How Does the Protocol Switch Happen?

So far, we know:

TCP is simply the transporter (or the road).
Different protocols can run on top of the same TCP connection.

That means HTTP and WebSocket are simply different sets of rules for interpreting the same byte stream.

What Are the WebSocket Rules?

The WebSocket protocol consists of two parts:

HTTP Upgrade Handshake (used only once to switch the protocol)
Binary Framing (used for all communication after the protocol switch)

Similarly, HTTP has its own rules like:

GET
Headers
Status codes
CRLF formatting

Now let's understand the first part.

HTTP Upgrade Handshake

The HTTP Upgrade Handshake is the moment where both the client and server agree to stop speaking HTTP and start speaking WebSocket.

In simple terms:

They stop parsing incoming bytes using HTTP rules and start parsing them using WebSocket rules.

Internally, you can imagine something like:

let currentState = "http";

// After successful handshake
currentState = "websocket";

This isn't the actual implementation, but it provides the correct mental model.

Step 1 — Browser Sends an Upgrade Request

The browser sends a normal HTTP GET request containing headers like:

GET /chat HTTP/1.1
Host: example.com
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Important headers:

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key (used for handshake verification)

Step 2 — Server Verifies the Request

The server parses the request as a completely normal HTTP request.

When it sees the upgrade request, it:

Appends a fixed WebSocket magic GUID to the received Sec-WebSocket-Key.
Hashes the result using SHA-1.
Base64 encodes the hash.
Places the result inside the Sec-WebSocket-Accept header.
Sends back a 101 Switching Protocols response.

Example:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

The browser performs the exact same calculation independently.

If both values match:

The handshake succeeds.
Both browser and server switch from HTTP mode to WebSocket mode.

If they don't match, the connection is rejected.

Binary Framing

Once the protocol has been switched, the browser no longer sends HTTP requests over that connection.

Instead, every message follows the WebSocket frame format.

This is simply another set of rules for interpreting the byte stream.

A WebSocket parser reads each frame in a predefined structure:

FIN bit → Is this the final fragment?
Opcode → Text, binary, ping, pong, close, etc.
Mask bit → Whether the payload is masked.
Payload Length → How many bytes belong to the payload.

After reading this metadata, the parser extracts the payload correctly.

Because every message now follows this frame structure, the server no longer tries to interpret the bytes as an HTTP request.

The TCP connection never changes.

Only the parser sitting on top of TCP changes.

Visualizing the Switch

                TCP Connection
────────────────────────────────────────────

Client                         Server

HTTP Request  ───────────────►  HTTP Parser

GET
Connection: Upgrade
Upgrade: websocket

                Handshake

HTTP 101 Switching Protocols ◄──────────────

        Protocol Switch Happens

WebSocket Frames ─────────────► WebSocket Parser

Frame
Frame
Frame
Frame

Still the SAME TCP connection.
Only the protocol rules changed.

Why Didn't WebSocket Create a Brand-New Protocol?

Now that we understand how the protocol switch happens, the next obvious question is:

Why did WebSocket choose to upgrade HTTP instead of creating an entirely new protocol?

This was one question that kept bothering me.

If WebSocket has its own framing protocol, why not just create a completely new protocol from day one?

A few reasons came to mind.

1. Easier Implementation (Partially)

My first thought was:

"Probably because it's easier."

And that's partially true.

Instead of inventing a brand-new protocol and convincing everyone to support it, WebSocket simply borrows HTTP for a few moments and then says:

"Thanks, I'll take it from here."

2. HTTP Was Already the King 👑

This is the real reason.

By the time WebSocket was introduced, HTTP was everywhere.

Browsers understood it.
Servers understood it.
Reverse proxies understood it.
Firewalls understood it.
Load balancers understood it.

Basically, the entire internet had already agreed:

"Yep... we all speak HTTP."

Imagine if WebSocket had suddenly appeared and said:

"Hey everyone! I've invented a brand-new protocol. Please update your browsers, proxies, firewalls, servers, and every piece of networking infrastructure on Earth."

Yeah... good luck with that.

Instead, WebSocket made the smartest move possible.

It started as a completely normal HTTP request, passed through all the existing infrastructure without raising any eyebrows, and only after both sides agreed did it quietly switch to its own protocol.

No new TCP connection.
No special ports.
No reinventing the web.

Just one HTTP handshake and then...

"Alright HTTP, you've done your job. I'll handle the rest."

In One Sentence

WebSocket didn't replace HTTP—it used HTTP's popularity to get through the front door, and once both the client and server agreed, it switched to its own binary framing protocol while continuing to use the same TCP connection.

DEV Community: dsmith_sys

[Read Once!!]

React Core 1: Understanding the Basics

React Core 1: Understanding the Basics

Introduction

JSX & How React Renders UI

Element vs Component

Props vs State

Props

State

State and props should be treated as immutable

Controlled & Uncontrolled Components

Controlled components

Uncontrolled components

key Prop in Lists

What about array indexes?

Lifting State Up

What about Context?

Conclusion

Brief About How the Protocol Switch Happens in WebSocket

Understanding What Actually Happens During a WebSocket Connection

The Problem with HTTP

Let's Understand TCP

How HTTP Is Built on Top of TCP

Finally... How Does the Protocol Switch Happen?

What Are the WebSocket Rules?

HTTP Upgrade Handshake

Step 1 — Browser Sends an Upgrade Request

Step 2 — Server Verifies the Request

Binary Framing

Visualizing the Switch

Why Didn't WebSocket Create a Brand-New Protocol?

1. Easier Implementation (Partially)

2. HTTP Was Already the King 👑

In One Sentence

`key` Prop in Lists