6 New React 19 Features Everyone Must Use

Boika Candy — Sun, 02 Nov 2025 10:13:04 +0000

If you're already comfortable with React and looking to level up, React 19 brings some really smart new features and improvements. In this post we’ll cover six of the most useful ones — each with a “before” (React 18 or earlier) and an “after” (React 19) snippet so you can see how things have changed.

1) Pass ref as a Prop (No More forwardRef)

Previously, forwarding refs in functional components required React.forwardRef and a little boilerplate. React 19 lets you pass ref directly as a normal prop in many cases.

Before (React 18)

import React, { forwardRef } from 'react';

const MyInput = forwardRef((props, ref) => {
  return <input {...props} ref={ref} />;
});

export default function Parent() {
  const inputRef = React.useRef();
  return <MyInput ref={inputRef} placeholder="Type here…" />;
}

After (React 19)

function MyInput({ placeholder, ref }) {
  return <input placeholder={placeholder} ref={ref} />;
}

export default function Parent() {
  const inputRef = React.useRef();
  return <MyInput ref={inputRef} placeholder="Type here…" />;
}

2. New use() API for Resources/Promises

Why it matters: The new use() hook lets you synchronously “read” a promise or resource inside a render. It works nicely with Suspense and server-rendering.

Before (React 18)

function Comments({ promise }) {
  const [comments, setComments] = React.useState(null);

  React.useEffect(() => {
    promise.then(data => setComments(data));
  }, [promise]);

  if (comments === null) {
    return <div>Loading…</div>;
  }

  return comments.map(c => <p key={c.id}>{c.text}</p>);
}

After (React 19)

import { use } from 'react';

function Comments({ commentsPromise }) {
  const comments = use(commentsPromise);
  return comments.map(c => <p key={c.id}>{c.text}</p>);
}

3. Built-in Form Actions + Hooks (useActionState, useFormStatus, useOptimistic)

React 19 introduces better support for form submissions and optimistic UI updates via Actions and hooks that track pending state.

Before (React 18)

function TodoList() {
  const [items, setItems] = React.useState([]);
  const [loading, setLoading] = React.useState(false);

  const handleSubmit = async event => {
    event.preventDefault();
    setLoading(true);
    const form = new FormData(event.target);
    const res = await fetch('/api/add', { method: 'POST', body: form });
    const newItem = await res.json();
    setItems([...items, newItem]);
    setLoading(false);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="item" placeholder="Add todo…" />
      <button type="submit" disabled={loading}>{loading ? "Saving…" : "Add"}</button>
    </form>
  );
}

After (React 19)

"use client";

import { useActionState } from 'react';

async function create(data) {
  // server-side logic
  return await fetch('/api/add', { method: 'POST', body: data }).then(r => r.json());
}

export default function TodoList() {
  const [error, submit, isPending] = useActionState(create);

  return (
    <form action={submit}>
      <input name="item" placeholder="Add todo…" />
      <button type="submit" disabled={isPending}>
        {isPending ? "Saving…" : "Add"}
      </button>
      {error && <p>{error}</p>}
    </form>
  );
}

4. Native Metadata, Stylesheets & Script Support in Components

React 19 allows you to declare metadata stylesheet dependencies and async scripts inside components more declaratively.

Before (react 18)

import React from 'react';
import { Helmet } from 'react-helmet';

function Page() {
  return (
    <>
      <Helmet>
        <title>My Page</title>
        <meta name="description" content="Hello world"/>
        <link rel="stylesheet" href="/styles.css"/>
      </Helmet>
      <div>Content</div>
    </>
  );
}

After (React 19)

function Page() {
  return (
    <>
      <title>My Page</title>
      <meta name="description" content="Hello world" />
      <link rel="stylesheet" href="/styles.css" />
      <div>Content</div>
    </>
  );
}

5. Improved Custom Element / Web Component Support

Now you can integrate Web Components more smoothly: props turn into properties (not just attributes) and SSR + client behave more consistently.

Before (React 18)

// Using a Web Component inside React – might need workarounds
<MyWebComponent some-prop="value" />

After (React 19)

<MyWebComponent someProp={value} />

Drop a comment below I'd love to hear your thoughts!

Myths and Facts about Thread Pool in Node.js

Boika Candy — Sat, 01 Nov 2025 16:50:39 +0000

Node.js is renowned for its non-blocking, event-driven architecture, often touted as "single-threaded" to emphasize its efficiency with I/O-bound tasks. However, this simplicity hides a crucial component: the libuv thread pool, a set of background worker threads that handle blocking operations without stalling the main event loop. In this post, we'll debunk common myths and lay out key facts to help you leverage the thread pool effectively in your Node.js applications.

- Myth #1: Node.js is Truly Single-Threaded

A persistent belief in the Node.js community is that the runtime operates on a single thread, making multi-threading impossible or unnecessary. This stems from JavaScript's execution model on the V8 engine, where the event loop processes tasks sequentially.

The Fact: Node.js isn't entirely single-threaded. While the main JavaScript thread handles the event loop, libuv (Node's C++ backend for async I/O) maintains a default pool of 4 worker threads for offloading CPU-intensive or blocking tasks. This "hidden" multi-threading allows Node.js to perform operations like file reads or cryptographic hashing in parallel without blocking the primary thread. In essence, it's more like a 5-thread model: one for the event loop and four for the pool. Ignoring this can lead to performance bottlenecks in I/O-heavy apps.

Myth #2: The Thread Pool Handles All Async Operations

Many developers assume that every asynchronous API in Node.js (like fs.readFile or crypto.randomBytes) magically runs non-blockingly on the event loop without any overhead.

The Fact: The thread pool is selective—it's only used for operations lacking native non-blocking OS support, such as certain file system I/O, DNS lookups, compression (zlib), and cryptography tasks. Network I/O, for instance, uses OS-level mechanisms like epoll (Linux) directly on the event loop, bypassing the pool entirely. Overloading the pool with mismatched tasks can cause queuing delays, as workers process one task at a time from a shared queue.

Myth #3: Thread Pool Size Doesn't Matter—Just Set It and Forget It

It's a common misconception that the default configuration is "good enough" for all workloads, especially since Node.js scales via clustering or worker threads for true parallelism.

The Fact: The default pool size is 4 threads, tunable via the UV_THREADPOOL_SIZE environment variable (up to 1024, but practically limited by CPU cores). For CPU-bound tasks (e.g., heavy hashing), bumping it to match your logical cores can boost throughput. However, in a cluster setup (using the cluster module), each worker process gets its own pool, so tune per process to avoid resource contention. Mismatches here can turn your app into a bottleneck, especially under high load.

Myth #4: Worker Threads Are the Same as the Libuv Thread Pool

With the introduction of the worker_threads module, some conflate it with the libuv pool, thinking they're interchangeable for parallelism.

The Fact: They're distinct: libuv's pool is a low-level C++ mechanism in Node's async I/O library, offloading blocking native ops (e.g., file I/O like fs.readFileSync or crypto like crypto.pbkdf2) to 4 default worker threads without enabling parallel JS execution. Worker threads, however, spawn explicit JS threads with their own V8 instances for true parallel JS, suiting CPU-bound tasks like data processing—but with serialization overhead for inter-thread communication.

Drop a comment below I'd love to hear your thread pool war stories!

Forem: Boika Candy

6 New React 19 Features Everyone Must Use

1) Pass ref as a Prop (No More forwardRef)

2. New use() API for Resources/Promises

3. Built-in Form Actions + Hooks (useActionState, useFormStatus, useOptimistic)

4. Native Metadata, Stylesheets & Script Support in Components

5. Improved Custom Element / Web Component Support

Myths and Facts about Thread Pool in Node.js

- Myth #1: Node.js is Truly Single-Threaded

Myth #2: The Thread Pool Handles All Async Operations

Myth #3: Thread Pool Size Doesn't Matter—Just Set It and Forget It

Myth #4: Worker Threads Are the Same as the Libuv Thread Pool