DEV Community: The Naija Debugger

Fetching API Data with TypeScript: Using Type Assertions

The Naija Debugger — Mon, 19 Jan 2026 19:19:08 +0000

Today, I dove deeper into TypeScript and explored how to safely fetch and use data from an API. Now I understand how TypeScript helps prevent bugs, improve developer experience, and makes code more maintainable.

Understanding the Problem
When we fetch data from an API in JavaScript, we usually do something like:

const response = await fetch("https://randomuser.me/api/?results=3"); const data = await response.json(); console.log(data);

JavaScript doesn't care about types. The code will run even if the API changes its structure or fields. But in TypeScript:
response.json() returns any (or unknown depending on settings)
TypeScript doesn't know the shape of the data, so we can't safely access nested properties without risking errors. This is where type assertions come in.

The images above illustrate the JSON structure returned by the RandomUser API and the EscuelaJS Products API respectively, which I used to practice TypeScript type assertions and API data typing. As you can see the structure of the data they return differs.
Using TypeScript Type Assertions
Type assertions tell TypeScript: "I know the structure of this data better than you do."

https://typescriptworld.com/a-deep-dive-into-typescript-type-assertions-from-basics-to-advanced-patterns

Example:
`const data = await response.json();

const users = data as unknown as {
results: {
name: { first: string; last: string };
email: string;
picture: { large: string };
}[];
};`

data is unkown after response.json()
as unknown as {…} tells TS: "Treat data as an object with a results array containing this exact structure"
This allows us to safely access nested properties like results[0].name.firstwithout TypeScript complaining.
The double assertion (as unknown as) is sometimes needed when TypeScript is too conservative and refuses a direct conversion.

Mapping API Data to Your Own Types
Even after asserting the type, I didn't want to expose the entire nested API structure in my app. So I mapped the data to my own simpler type:

`export type User = {
name: string;
email: string;
picture: string;
};

return users.results.map(u => ({
name: ${u.name.first} ${u.name.last},
email: u.email,
picture: u.picture.large
}));`

Now, the rest of my app can safely work with a clean, predictable User[] array, with proper typing and autocomplete support.

Why This Matters
Through this exercise, I realized how TypeScript helps in several ways:
Prevent runtime crashes: TS catches mistakes before the code runs
Autocompletion / IntelliSense: helps write code faster with fewer typos
Self-documenting code: types tell anyone reading the code exactly what data looks like
Safe refactoring: if I rename a field or the API changes, TS will warn me

Even small experiments like fetching users or products can teach you how typed async flows work in real projects.

Key points
TypeScript doesn't magically know API data, so we teach it using types or type assertions
Mapping API data to our own types makes apps safer and easier to work with

Building Bulletproof Dropdown Click Handling in React

The Naija Debugger — Sat, 10 Jan 2026 08:25:28 +0000

By using data attributes and .closest(), the click-handling logic becomes resilient to DOM changes and easier to maintain.

It focuses on the data (filter.id) rather than the DOM structure, making the component more reliable and scalable.

In React, avoid relying on DOM hierarchy for logic. I learnt this the hard back when I used parentElement for this. Use data attributes with .closest() for robust click handling.

The core idea is to listen for clicks on the entire document, then determine whether a click happened inside or outside your dropdown.

This approach is necessary because the dropdown doesn’t know when a user clicks elsewhere.The browser always bubbles clicks upward:

button -> div -> body -> document.

It works even if icons, labels, or nested elements change.

The dropdown ref points to the actual DOM node of the dropdown panel:
{activeDropdown && (

…

)}

Any click inside this element should not close the dropdown.

To determine where a click occurred:

Inside the document listener, check:

Was the click on a filter button?

const clickedFilterButton = event.target.closest("[data-filter]");
This finds the nearest ancestor with the data-filter attribute.

Was the click inside the dropdown panel?

Use contains() to check whether the clicked element is inside the dropdown.

If true, do nothing. The dropdown should stay open.

Why My Previous parentElement Logic Failed
The previous approach relied on event.target.parentElement.id to match the active dropdown’s ID.

However, event.target is unpredictable:

If the user clicks the icon inside a button, event.target becomes the element, not the .

event.target.parentElement.id may then point to a with no ID, rather than the intended button.

This approach is Harder to scale. Every nested element requires careful handling.

It is DOM-dependent, therfore, changes to the DOM structure break the logic.

This makes assumptions about parent-child relationships.

Dropdown Toggle Logic
activeDropdown stores the ID of the currently active dropdown (or null if none).

Clicking the same dropdown again closes it. Clicking a different one switches to the new dropdown.

The dropdown closes only if the click is outside.

Clicking a different dropdown switches the active state.

The .sort() in React improved my understanding of State, Mutation, and Data Flow

The Naija Debugger — Sat, 03 Jan 2026 13:14:08 +0000

I’ve just finished implementing the sort feature for my e-commerce website.

Initially, my sorting logic was scattered everywhere - Inside availability filters and within sort conditions themselves. While it worked, it was messy and hard to maintain. I realized that filtering decides what shows, while sorting decides the order. Sorting should happen once, only after all filters are applied. This separation made the logic easier to reason about and scale.

filteredProducts = filteredProducts.sort(...)

Sometimes it worked. Other times it didn’t.
That inconsistency was the red flag.

sort() mutates the array it’s called on.
In React, mutating an existing array - especially derived state like filteredProducts - can cause unpredictable UI behavior because React cannot detect the change. That’s why sorting would often fail.

It worked after I switched to the spread operator:
[...filteredProducts].sort(...)

[...filteredProducts] creates a new array reference, so .sort() only mutates the copy. React detects the new reference and re-renders correctly.

It is important to remmember:

[...array] is used when reordering data.

{ ...item } is used when updating object properties.

String Sorting
For alphabetical sorting, use localeCompare() - it handles uppercase vs. lowercase properly and produces a predictable order.

A to Z:
a.name.localeCompare(b.name)

Z to A:
b.name.localeCompare(a.name)

Price Sorting
Low to high:

a.price - b.price

b.price - a.price

Sorting by Date in Real E-commerce Apps
My initial data didn’t include dates, so I added them properly.
Dates are typically stored in ISO format:

"2024-11-02T14:30:00Z"

This format is backend-friendly, database-friendly, and JavaScript-friendly.

Most real apps use createdAt (when the product was added) or sometimes updatedAt.

Old to new:
new Date(a.createdAt) - new Date(b.createdAt)

New to old:
new Date(b.createdAt) - new Date(a.createdAt)

By separating filtering and sorting, avoiding direct mutation, and using consistent comparison methods, my sorting feature now works reliably — and my React state updates predictably.

github repo: https://github.com/victorugs-dev/shopco

live demo: https://shopco-store-sigma.vercel.app

onSubmit in React.js Forms: Why action="" and method="" don’t apply anymore

The Naija Debugger — Mon, 17 Nov 2025 17:50:05 +0000

Back then in HTML, we would use:

The browser handles everything automatically.

But in React, we don’t let the browser reload the page - we handle it manually.

Using onSubmit in React lets you control what happens when the form is submitted:

function MyForm() {
const handleSubmit = (e) ={
//
};

return (

  Submit

);
}

*Why this approach?
*
No page reloads

You control the logic

Perfect for validations

Works well with APIs (fetch/axios)

Better user experience

*Capturing inputs with useState
*
React uses controlled components:

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

value={name}
onChange={(e) => setName(e.target.value)}
/>

This gives you full control of the data.

React forms felt strange at first, but once you understand onSubmit, preventDefault(), and useState, everything starts to click.

Building My First To-Do List App with JavaScript

The Naija Debugger — Sat, 22 Feb 2025 20:22:35 +0000

Building My First To-Do List App with JavaScript

I built a simple To-Do List App where you can add tasks, mark them as done, and delete them. But there was a catch—everything disappeared on refresh! 😅

How It Works

✅ Add a task through a form
✅ Mark tasks as completed with a checkbox
✅ Delete tasks with a button

I used HTML, CSS, and JavaScript to bring it to life.

Biggest Challenges & Fixes

❌ Form refreshing on submit → Solved with event.preventDefault()
❌ Incorrect checkbox handling → Switched from click to change event
❌ Struggled with setAttribute('onclick') → Used addEventListener instead

Each bug taught me something new! 🚀

What’s Next?

I plan to store tasks in localStorage so they don’t disappear on refresh.

I plan to improve it's responsiveness so it can accommodate more tasks.

Check out the User-Interface and code and let me know what you think! What would you improve?💭

💻 Deployed the app on Vercel! Try it out here 👉 https://to-do-list-coral-three-64.vercel.app/

📂 Code is open-source—check out the repo on GitHub: https://github.com/cvictorugs/mini-projects/tree/main/to-do-list

📝 Wrote a full breakdown of the process on Medium: https://medium.com/@cvictorugs/building-my-first-to-do-list-app-with-html-css-and-javascript-b008dd8f84ec

What would you improve in this app? I’d love to see it! 🚀 Drop your link in the comments or tag me on Twitter: https://twitter.com/cvictorugsDEV LinkedIn : https://www.linkedin.com/in/chibuikem-victor-ugwu-b9710a344?trk=contact-info