DEV Community: CodeSmithNazim

Built a weather app with AI-generated summaries and city bookmarking—feedback welcome (took me 9-10 days; learned a lot)

CodeSmithNazim — Sat, 25 Jul 2026 14:10:31 +0000

Hey everyone, wanted to share a project I just finished. It's a weather app, but I tried to push past the typical "fetch API, show temperature" tutorial project.

Features:

AI-generated natural language weather summaries instead of raw numbers
Dynamic backgrounds that change based on real weather conditions
City search with live suggestions as you type
Bookmark/favorite cities, persisted with localStorage

Stack: React + Vite, deployed on Vercel

Stuff that actually gave me trouble:

Debouncing the city search so it doesn't spam the API on every keystroke
Duplicate city names across countries messing up search results
Bookmarks kept vanishing on refresh until I realized I wasn't persisting state properly
Syncing background image changes with API response timing without a jarring flash

It took about 9-10 days total, mostly because I kept refactoring state management once bookmarks, search, and multi-city display all had to interact. Still learning, so genuinely open to criticism — especially on component structure, since that's where I feel least confident.

Live: Live url
Repo: GitHub

Why does my React component crash on the first render when using data fetched inside useEffect()?

CodeSmithNazim — Thu, 16 Jul 2026 08:13:32 +0000

When you fetch data inside useEffect(), the network request is asynchronous and only runs after the initial render has already completed and painted to the screen.

Because React cannot pause rendering to wait for your API response, your component's state is still its initial value (like null or undefined) during that first render. If you try to read properties from your data (like user.name) before the data actually arrives, your app will crash.

⏳ Step-by-Step: The Async Lifecycle

function UserProfile({ userId }) {
  const [user, setUser] = useState(null); // Starts as null

  useEffect(() => {
    fetchUser(userId).then(setUser); // Async API call
  }, [userId]);

  // ⚠️ Safety check is mandatory!
  return (
    <div>
      {user ? <h1>{user.name}</h1> : <div>Loading...</div>}
    </div>
  );
}

Step 1: The Initial Render (The "Loading" State)

React mounts the component.
It initializes the state: user is set to null.
React must return JSX immediately. It cannot halt the browser to wait on a server.
React runs your return statement. Since user is currently null, the ternary operator evaluates the fallback and renders: <div>Loading...</div>.
The browser paints "Loading..." on the screen. The first render is now complete.

Step 2: The `useEffect` Fires (After Paint)

Now that the first render is safely on the screen, React triggers the useEffect().

It kicks off your asynchronous network call: fetchUser('123').

While the browser is waiting for the server to reply, nothing changes on the screen. It still shows "Loading..."

Step 3: State Updates

Sometime later (e.g., 300ms), the server responds with { name: "Alex" }.

The promise resolves and calls setUser({ name: "Alex" }).

Setting state signals React: "Hey! The data is here. We need to re-render!"

Step 4: The Second Render (The "Data" State)

React re-runs theUserProfile` function.

This time, the user is not null; it is { name: "Alex" }.

The return statement runs again. The ternary operator evaluates to truthy and returns: <h1>Alex</h1>.

The browser updates, replacing "Loading..." with "Alex."

⚠️ Why Conditional Guards Are Mandatory

Because of this exact asynchronous timeline, if you do not write a guard condition, your application will crash during Step 1.

javascript // ❌ THIS WILL CRASH IMMEDIATELY return ( <div> <h1>{user.name}</h1> </div> );

During the initial render, user is still null. JavaScript will try to read null.name and throw the classic error:
💡 TypeError: Cannot read properties of null (reading 'name')
Always protect your renders from empty async states using either ternary operators, logical AND (&&), or optional chaining (?.):

`javascript
// Option A: Ternary Operator (Great for loading states)
{user ?

{user.name}

: Loading...}

// Option B: Optional Chaining (Safely returns undefined instead of crashing)

{user?.name}

Put your comments; I'll be happy to see feedback if it helps anyone.
Follow me for more.

The React 2013 "Marketing Pitch"

CodeSmithNazim — Thu, 16 Jul 2026 05:39:36 +0000

When React was first introduced in 2013, the web development world was dominated by frameworks like jQuery, Backbone, and AngularJS. In those frameworks, developers had to manually update the browser DOM, or the framework would heavily slow down the browser by sweeping the entire real DOM on every change.

React's biggest selling point was the following:

Stop worrying about manual DOM updates. Just write your UI declaratively. The Virtual DOM will magically do the work of reducing renders.

To sell this idea simply to a skeptical developer audience, the creators packaged the message into:

We minimize rendering
It was a highly effective marketing pitch, even if it technically blurred the lines between the JavaScript render phase and the browser paint phase.

React Official Docs Change: -

The React Team Literally Changed the Docs to Fix This!
The confusion grew so massive that when the React team rewrote the official documentation from scratch (moving to the modern react.dev), they explicitly rewrote the guide to fix this exact misunderstanding.

If you look at the modern "Render and Commit" section of the official docs, they now explicitly separate the process into three distinct steps—Trigger, Render, and Commit—and they added an

Epilogue
Just for the browser:

Epilogue: Browser paint
After rendering is done and React updated the DOM, the browser will repaint the screen. Although this process is known as

browser rendering
, we'll refer to it as
painting
to avoid confusion throughout the docs.

They literally had to invent their own terminology "painting"
to stop developers from confusing React's in-memory calculations with actual browser screen updates!

component re-render and React reconciliation mechanism: a brief overview

CodeSmithNazim — Wed, 15 Jul 2026 18:38:07 +0000

If we have 1000 a list's items and only one of them changes, React will re-render all the1000` items and will make a new virtual DOM tree.
The newly made DOM tree will be compared with the old DOM tree, as we added only one list, so in the actual DOM only one change will occur: the addition of the new list item.
That's the brief and easy under-the-hood explanation of React's reconciliation mechanism.
For more detail you can check in my rest of posts.

React's Reconciliation

CodeSmithNazim — Wed, 15 Jul 2026 18:24:34 +0000

Brief Definition:

Reconciliation is React's process of comparing the previous and new Virtual DOM trees to determine the minimum necessary changes to the real DOM

The Biggest Misconception About React Reconciliation (Render vs. Paint) 2nd part

CodeSmithNazim — Wed, 15 Jul 2026 14:56:17 +0000

second part:

The Clash of Two "Renders"

The biggest culprit is that the word "render" means two completely different things in computer science, and React tried to use both at the same time:

Browser Rendering: This is when the browser engine calculates layouts, builds render trees, and paints pixels on your screen.

React Rendering: This is when React calls your component functions to build a JavaScript object tree (virtual DOM) in memory.

Because the browser's process was already called "rendering," React's creators used the same word for their virtual DOM creation. For years, when the docs said "React prevents unnecessary renders," developers read that as "React prevents my components from running their JavaScript." It took years for the community to realize we were talking about two entirely different concepts!

The 2013 "Marketing Pitch"

React's biggest selling point was "Stop worrying about manual DOM updates." Just write your UI declaratively. The Virtual DOM will magically do the work of reducing renders."

To sell this idea simply to a skeptical developer audience, the creators packaged the message into "We minimize rendering." It was a highly effective marketing pitch, even if it technically blurred the lines between the JavaScript render phase and the browser paint phase.

The React Team Literally Changed the Docs to Fix This!

The confusion grew so massive that when the React team rewrote the official documentation from scratch (moving to the modern react.dev), they explicitly rewrote the guide to fix this exact misunderstanding.

If you look at the modern "Render and Commit" section of the official docs, they now explicitly separate the process into three distinct steps—Trigger, Render, and Commit—and they added an "Epilogue" just for the browser:

"Epilogue: Browser paint

After rendering is done and React updates the DOM, the browser will repaint the screen. Although this process is known as "browser rendering," we'll refer to it as "painting" to avoid confusion throughout the docs.

They literally had to invent their own terminology ("painting") to stop developers from confusing React's in-memory calculations with actual browser screen updates!

The Verdict:-

When people say "reconciliation decreases the amount of things re-rendered," they are usually using "re-render" as a layman's term for "affecting the actual browser screen."

If you could understand the above two posts, then you understand React's core architecture better than many developers who have been writing it for years.

The Biggest Misconception About React Reconciliation (Render vs. Paint)

CodeSmithNazim — Wed, 15 Jul 2026 12:25:52 +0000

Hey everyone,

I recently had an "aha!" moment regarding how React handles updates under the hood, and I wanted to share it because I realize a ton of developers (including myself, until recently) trip over this exact concept.

The common mental model is that React Reconciliation compares the Virtual DOM directly to the Real Browser DOM and surgically updates only what changed.

But that’s fundamentally incorrect. React never reads or directly compares the real DOM during the diffing process. It actually splits the process into two entirely separate phases —The Render Phase and The Commit Phase —which creates a massive distinction between Re-rendering and Re-painting.

Here is the exact breakdown of what happens when a single state change affects just 1 out of 100 divs in a component:

The Render Phase (Pure JavaScript) When state changes, React calls your component function. It doesn't know which of your 100 divs changed yet, so it has to evaluate the entire JSX block.

The Scope: React re-renders all 100 virtual divs in memory.

The Process: It builds a brand-new Virtual DOM tree and compares it to the previous Virtual DOM tree (JavaScript object vs. JavaScript object).

The Outcome: It spots that 99divs are identical, but 1 div has an update. It flags that single virtual node with an "Update" tag.

Because this happens purely in-memory as JavaScript, it is incredibly fast and cheap.

The Commit Phase (The Real DOM Update) This is where Reconciliation does its primary job. It acts as a shield to protect the browser from doing unnecessary work.

The Scope: React completely ignores the 99 unchanged elements.

The Process: It surgically targets the single real browser div associated with the flagged Virtual DOM element and updates only its modified property (e.g., element.textContent = "New Value").

The Outcome: The browser repaints only 1 single div on the screen.

The Conclusion: Reconciliation isn't about stopping React from re-rendering (re-running JS to calculate the UI). It is about controlling the browser's re-painting so that the expensive UI updates are kept to an absolute minimum.

Would love to hear how you guys explain this concept to juniors or if this distinction changed how you approach optimization!
continue reading the rest of this post here