What is the optimization in react:
Typically optimization in react refers to improve the user experience by reducing the load time and minimizing the unnecessary re-rendering in the DOM.
Developers have handled optimization manually by applying techniques
like lazy loading , React.memo and using optimization hooks such as useMemo and useCallBack.
Before diving into the new feature of React compiler presented in react 19 version, let us understand the techniques developers have been using to improve performance and optimization.1. Performance Hooks:- UseMemo :In JavaScript, objects and arrays are passed by reference. This means that during a re-render, even if their content doesn't change, a new reference is created.
In the context of react , re-rendering will create new reference for the object/array, so we need to cache the result of a calculation between re-renders.
UseMemo come to address this issue and returns a memoized value.
let us understand by the example below when a user object will be memoized and will refer to a new reference only when one of its dependencies changes.
⛶import React, { useState, useMemo } from "react";

const UserProfile = () = {
const [username, setUsername] = useState("");
const [age, setAge] = useState(20);

// user object is stable unless username or age changes
const user = useMemo(() = {
return {
name: username,
age: age,
};
}, [username, age]);

return (
div
input
placeholder="Enter name"
value={username}
onChange={(e) = setUsername(e.target.value)}
/
p{user.name} is {user.age} years old/p
/div
);
};-useCallBack:The useCallback is similar to useMemo Hooks. The main difference is that useCallback returns a memoized function instead of memoized value.
let's understand the example below from w3school.com
without useCallbackat each time countchange Appcomponent re-rendering so a new reference of addTodofunction will be created and then Todoscomponent will be re-rendered (as addTodo one of its props).
⛶import { useState, useCallback } from "react";
import ReactDOM from "react-dom/client";
import Todos from "./Todos";

const App = () = {
const [count, setCount] = useState(0);
const [todos, setTodos] = useState([]);

const increment = () = {
setCount((c) = c + 1);
};
const addTodo = useCallback(() = {
setTodos((t) = [...t, "New Todo"]);
}, [todos]);

return (

Todos todos={todos} addTodo={addTodo} /
hr /
div
Count: {count}
button onClick={increment}+/button
/div
/
);
};

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(App /);
//Todo component
import { memo } from "react";

const Todos = ({ todos, addTodo }) = {
console.log("child render");
return (

h2My Todos/h2
{todos.map((todo, index) = {
return p key={index}{todo}/p;
})}
button onClick={addTodo}Add Todo/button
/
);
};

export default memo(Todos);2. React memo:By default a child component will be re-rendered if its parent component re-renders , using memo will cause React to skip rendering a component if its props have not changed.
The example used in useCallBack example already used React.memo
to avoid re-rendering when count state changed (countstate will only cause re-rendering in the Appcomponent , not in the child component Todos.3. Lazy loading:It is used for code splitting , in React, it is a technique that allows you to load components, modules, or assets asynchronously, improving the loading time of your application. It can be achieved by using the built-in React.lazy() method and Suspense component.
the example below show the way to implement it ,Loadingcomponent here is the UI to display when the loading is processing , it could be simply
⛶p....Loadingp⛶import { lazy, Suspense } from 'react';

const MarkdownPreview = lazy(() = import('./MarkdownPreview'));

function App() {
return (
Suspense fallback={Loading /}
h2Preview/h2
MarkdownPreview /
/Suspense
);
}4. React 19: the react compiler RC:So now as we are familiar with the manual way of fixing optimization and implementing the necessary techniques that address it.
The react compiler presented in the 19th version comes essentially to enhance the performance and optimization without the intervention of developers.
And as it states its documentation that it’s easy to forget applying memoization or applying them incorrectly can lead to inefficient updates as React has to check parts of your UI that don’t have any meaningful changes.
The compiler uses its knowledge of JavaScript and React’s rules to automatically memoize values or groups of values within your components and hooks.


Conclusion:
Should we handle optimization manually ? short answer, No, React compiler will do it for us.
Is still worth to understand techniques of optimization in react?
*Yes * it worths as majoriy of projects and apps used by companies still need the manual way, in addition, according to react documentation RC isn't stable yet even it was tested by Meta in production.

On January 7th, 2024, I committed to a project that would demand both technical discipline and creative resolve: authoring a book on Darwin Information Typing Architecture (DITA). The result was DITA Decoded — a structured, reference-grade manual built to reduce friction for developers and technical writers working with structured content systems.This wasn’t born out of sudden inspiration. It came from real friction. I was navigating DITA myself — parsing documentation, reverse-engineering implementations, and building repeatable documentation workflows. The gap was obvious: resources were either too abstract or hyper-specific. No single source mapped the complete terrain. So I decided to build one.


Problem Identification: Why DITA Decoded?
DITA is not casual documentation. It’s a semantic XML-based architecture that demands precision in authoring, metadata management, localization workflows, and automation. And yet, most available resources either assumed prior knowledge or skipped over real-world implementation challenges.What was missing was a clear guide that could:
Introduce the fundamentals of DITA to developers and writers new to structured content
Scale up to more advanced concepts such as keyrefs, conditional processing, and publishing pipelines
Do all this without diluting technical accuracy
This gap was the reason DITA Decoded had to exist.


Project Planning: Structuring the Build
I started with an outline — much like a software project. Think of it as a modular design system. The chapters were the modules, loosely categorized into:
Core syntax and semantics (XML, specialization, content reuse)
Authoring workflows (topic-based writing, maps, conditional filtering)
Automation tooling (DITA Open Toolkit, versioning, output generation)
Enterprise concerns (scalability, localization, version control)
The objective wasn’t to create another textbook. It had to function like good technical documentation: searchable, scannable, reliable.


Technical Debt Learning Curve
It didn’t take long to realize the size of this build. Writing a book on DITA meant verifying every line of code, re-running transformations, and modeling diagrams that explained conditional branches, relationship tables, and reuse strategies.Each page was a merge of technical deep dives, XML parsing logic, use case analysis, and accurate visual documentation.This wasn’t made easier by the fact that I was doing it while holding down a full-time job. Every late-night commit came with burnout risks. But skipping it would have meant leaving too many “TODOs” in the field.


Versioning My Own Understanding
One recurring bug in the process? Self-doubt.Why should someone read my book when others with 15+ years in technical documentation exist?Here’s what I eventually understood: Experience doesn’t always equate to clarity. My fresh take — as someone going through the onboarding pain themselves — allowed me to write from the perspective of the reader I once was. I knew exactly where the friction points lay, because I had just debugged them.I wasn't writing as an expert. I was writing for the next dev or tech writer trying to adopt DITA at scale.


Quality Assurance: Ensuring Accuracy
Every workflow, code block, and DITA map in the book had to work — not theoretically, but in production environments. The tolerance for error in technical writing is low. I spent significant time testing outputs through DITA-OT, breaking and rebuilding content maps, and checking rendering pipelines.The diagrams weren’t just visuals — they were part of the information architecture. Each one mapped to a use case or design pattern I’d seen in real systems.


Motivation and Mental Overhead
Midway through, I had to revisit my motivation. Why continue?Because building DITA Decoded wasn't about credentials or career leverage — it was about solving a problem I faced, and I knew others were facing it too.I wasn't building a book. I was building infrastructure: a repeatable system of understanding, deploying, and scaling structured content workflows using DITA.


Lessons in Dev-Style Documentation
Some hard-earned lessons that applied throughout:

Shipping Matters More Than Scope: Don’t aim for a 100% comprehensive solution. Aim for 100% clarity on what you do cover.

Fresh Perspective Deep Experience: New adopters often explain things more intuitively than seasoned practitioners. Use that to your advantage.

Community Feedback is a Feature: Peer reviews and beta readers caught edge cases and blind spots I couldn’t have spotted on my own.



The Final Release
By early January 2025, I wrapped production. On January 19th, I launched DITA Decoded across platforms including Amazon and Notionpress.Shipping the book felt like pushing a major feature live after a year in dev branches.The response was affirming — developers, writers, and information architects reached out saying it helped them bridge gaps they’d struggled with for months. That made the effort worth it.


To Anyone Planning a Tech Book
Here’s what I’ll say to other devs or tech writers thinking about writing a technical book:
Don’t wait until you “qualify.” If you’ve built something, debugged something, or learned something deeply — document it.
Version early. Write drafts. Get feedback.
Think in workflows. Every chapter should solve a real problem, not just describe a concept.



TL;DR

Started on Jan 7, 2024 with the intent to demystify DITA
Faced typical technical writing challenges: accuracy, clarity, real examples
Shipped after 12+ months of writing, revising, and validating
Launched on Jan 19, 2025 — and still evolving based on reader feedback
If you're a developer, technical writer, or engineer trying to scale documentation with structure, DITA Decoded might just be the framework guide you've been missing.? Get Your Copy
Order on Amazon or NotionpressFeel free to DM me for anything around DITA, structured documentation, or publishing workflows.

Modern web apps often use JWTs for stateless authentication. Access tokens have short lifetimes (minutes) while refresh tokens live longer (hours or days). To keep users logged in securely, you rotate (issue a new) refresh token on each use.


The Race Condition
Imagine two almost-simultaneous API calls:
Client calls /api/protected with an expired access token.
Server sees the refresh token is still valid, issues a new access token and a new refresh token.
Client receives the new tokens, stores them.
But—what if two identical requests raced to that refresh endpoint?Both see the old refresh token as valid, both get back tokens, but only the last one is truly valid server-side. The other “wins” on the token store and invalidates its peer.The client’s second response writes over the first, and whichever response arrives later will overwrite the client’s stored refresh token. If that one is the stale, already-revoked token, the next refresh fails and the user is logged out.


Why It Matters


User Friction: Unexpected logouts for users who simply “clicked twice”

Edge Bugs: Hard to reproduce, intermittent

Security: Orphaned refresh tokens can linger or be replayed



A Simple Mitigation: Skew Your Cookie Expiry
Instead of setting your refresh‐token cookie’s Expires exactly to match the JWT’s exp claim, subtract a small delta—say, 30 seconds:
⛶const REFRESH_TOKEN_LIFETIME = 60 * 60; // e.g. 1 hour in seconds
const COOKIE_SKEW_SECONDS = 30; // safety buffer

const refreshTokenExp = Date.now() + REFRESH_TOKEN_LIFETIME * 1000;
res.cookie('refresh_token', newRefreshToken, {
httpOnly: true,
secure: true,
sameSite: 'Strict',
expires: new Date(refreshTokenExp - COOKIE_SKEW_SECONDS * 1000),
});The browser will stop sending the cookie ~30 s before the server considers the token truly expired.It prevents the race where one “losing” request arrives after the cookie has already been dropped, so it never attempts to rotate again with a stale token.Picking the Right Delta
30 s–2 m buffer is usually plenty.
Longer if your network is high-latency or clients might queue multiple requests offline.



other posts:

Practicing politeness in javascript code
Timing attacks in node.js
Express.js honeypot
Legendary emails in node.js with MJML
Let's connect!!: ?LinkedIn
GitHub