DEV Community: Tharun Chandra Lingala

TypeScript types I wish I knew when I started

Tharun Chandra Lingala — Mon, 18 May 2026 07:28:52 +0000

When I started using TypeScript I treated it like
JavaScript with one extra step — add a type here,
add an interface there, satisfy the compiler and
move on.

That approach works until it doesn't. You end up
with types that are technically correct but don't
actually prevent the bugs TypeScript is supposed to
prevent.

These are the features that changed how I use it.

Discriminated unions — for state that has multiple modes

I used to model loading states like this:

interface UserState {
  user: User | null
  loading: boolean
  error: string | null
}

The problem: this allows combinations that should be
impossible. loading: true and error: "something" at
the same time. user: someUser and loading: true
simultaneously.

TypeScript won't catch these. The types technically
allow them.

Discriminated unions model the actual possible states:

type UserState = 
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; user: User }
  | { status: 'error'; error: string }

Now TypeScript knows that when status is 'success',
user exists and error doesn't. When status is 'error',
error exists and user doesn't.

const renderUser = (state: UserState) => {
  switch (state.status) {
    case 'loading':
      return <Spinner />
    case 'success':
      return <Profile user={state.user} /> // user is User here, not User | null
    case 'error':
      return <Error message={state.error} /> // error is string here, not string | null
    case 'idle':
      return null
  }
}

The compiler knows exactly what's available in each
branch. No null checks, no "this should never happen"
comments.

Const assertions — for values that never change

I was defining arrays of options like this:

const DIRECTIONS = ['north', 'south', 'east', 'west']

TypeScript infers the type as string[]. If I try to
use a value from this array somewhere that expects
a specific direction type, it fails — even though
I know the values are exactly those four strings.

Const assertion fixes this:

const DIRECTIONS = ['north', 'south', 'east', 'west'] as const
// Type: readonly ["north", "south", "east", "west"]

type Direction = typeof DIRECTIONS[number]
// Type: "north" | "south" | "east" | "west"

Now Direction is a proper union type derived from the
array. If I add a fifth direction to the array, the
type updates automatically. One source of truth.

I use this constantly for:

Navigation link arrays
Status values
Configuration options
Any array that's treated as an enum

Template literal types — for string patterns

I needed a type for CSS color values — specifically
hex colors like #fff or #ffffff.

Before I knew about template literal types I either
used string (too broad) or wrote a runtime validation
function (works but TypeScript doesn't know about it
at compile time).

type HexColor = `#${string}`

const setColor = (color: HexColor) => {
  document.body.style.backgroundColor = color
}

setColor('#ff0000') // fine
setColor('red')     // TypeScript error — not a HexColor
setColor('#')       // technically passes — TypeScript can't 
                    // validate the full pattern, only the prefix

It's not perfect — TypeScript can't validate that the
characters after # are valid hex. But it catches the
obvious wrong inputs at compile time without any
runtime cost.

More useful examples:

// Event names that follow a pattern
type EventName = `on${Capitalize<string>}`
// Matches: onClick, onChange, onSubmit

// API endpoint patterns
type ApiRoute = `/api/${string}`
// Matches: /api/users, /api/products

// CSS size values
type Size = `${number}px` | `${number}rem` | `${number}%`
// Matches: 16px, 1.5rem, 100%

Mapped types — for transforming interfaces

I needed a "partial update" version of my User interface —
same fields but all optional, for PATCH requests.

My first approach: copy the interface and add ? to everything.

interface User {
  id: string
  name: string
  email: string
  role: 'admin' | 'user'
}

interface UserUpdate {
  id?: string
  name?: string
  email?: string
  role?: 'admin' | 'user'
}

This is a maintenance problem. Every time User changes,
UserUpdate needs to change too. You will forget. The
types will drift.

Mapped types solve this:

type UserUpdate = Partial<User>
// Exactly the same as writing all the optional fields manually
// But it updates automatically when User changes

TypeScript has several built-in mapped types worth knowing:

Partial<T>   // All fields optional
Required<T>  // All fields required
Readonly<T>  // All fields readonly
Pick<T, K>   // Only the fields you name
Omit<T, K>  // All fields except the ones you name

Real example:

interface User {
  id: string
  name: string
  email: string
  password: string
  createdAt: Date
}

// Safe to send to the client — no password, no internal fields
type PublicUser = Omit<User, 'password' | 'createdAt'>

// For update requests — everything optional except id
type UpdateUserRequest = Required<Pick<User, 'id'>> & 
  Partial<Omit<User, 'id' | 'createdAt'>>

The satisfies operator — new and genuinely useful

Added in TypeScript 4.9. I missed it for a long time
and when I found it I used it immediately.

The problem it solves: you want TypeScript to check that
a value matches a type, but you also want TypeScript to
remember the exact shape of the value (not just the type).

type Colors = {
  [key: string]: string | { light: string; dark: string }
}

// With a type annotation
const palette: Colors = {
  red: '#ff0000',
  blue: { light: '#add8e6', dark: '#00008b' }
}

// TypeScript thinks palette.red is string | { light: string; dark: string }
// even though we know it's just a string
palette.red.toUpperCase() // Error — might not be a string

With satisfies:

const palette = {
  red: '#ff0000',
  blue: { light: '#add8e6', dark: '#00008b' }
} satisfies Colors

// TypeScript remembers the exact types
palette.red.toUpperCase() // Fine — TypeScript knows red is a string
palette.blue.light        // Fine — TypeScript knows blue has light and dark

You get the type checking of an annotation without losing
the precision of inference. Best of both.

One thing I still get wrong

Generic constraints. I understand them, I write them,
I still occasionally write one that's more restrictive
than it needs to be and blocks a valid use case.

// Too restrictive
const getProperty = <T extends object, K extends keyof T>(
  obj: T, 
  key: K
): T[K] => obj[key]

// I've written constraints like this when the function 
// worked fine with a simpler signature

If you find yourself fighting TypeScript's type checker
on something that should obviously work — check your
constraints first. They might be the problem.

TypeScript's value is in the bugs you never write, not
just the ones it catches. The types above moved me from
"TypeScript stops the obvious mistakes" to "TypeScript
makes impossible states actually impossible."

That's the version of TypeScript worth learning.

Why I stopped using useEffect for everything and what I do instead

Tharun Chandra Lingala — Mon, 18 May 2026 05:40:20 +0000

There was a point in my React journey where useEffect
was my answer to everything.

Data needs to load when the component mounts? useEffect.
Something needs to happen when a prop changes? useEffect.
Need to sync two pieces of state? useEffect.

Six months ago I looked at a component I'd written and
counted seven useEffect calls. The component worked.
It was also completely impossible to follow. Bugs were
showing up that I couldn't reproduce consistently and
fixing one would break another.

That component forced me to actually understand what
useEffect is for — and more importantly, what it isn't for.

What useEffect is actually for

useEffect exists for one purpose: synchronizing your
component with something outside of React.

That's it. Outside of React means:

A browser API (document.title, addEventListener)
A third party library that doesn't know about React
A network request
A WebSocket connection
An interval or timeout

If what you're doing doesn't involve something outside
of React, useEffect is probably the wrong tool.

The mistake I made most often

Syncing state with state.

// What I used to write
const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')
const [fullName, setFullName] = useState('')

useEffect(() => {
  setFullName(`${firstName} ${lastName}`)
}, [firstName, lastName])

This looks reasonable. It's actually creating a problem.

Every time firstName or lastName changes, React renders
the component, then runs the effect, then sets fullName,
then renders the component again. Two renders for every
one change.

The fix is just a variable:

const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')

// Calculated during render — no effect needed
const fullName = `${firstName} ${lastName}`

React calculates this on every render anyway. You're not
saving any work by putting it in state — you're adding work.

Fetching data — where it gets complicated

Data fetching is the useEffect use case everyone learns first:

useEffect(() => {
  fetch('/api/user')
    .then(res => res.json())
    .then(data => setUser(data))
}, [])

This works. It also has several problems that don't show
up until your app gets bigger:

No loading state. The component renders before the
data arrives. If you're not handling that, you get
undefined errors or blank flashes.

No error handling. If the fetch fails, nothing happens.
The user sees nothing and doesn't know why.

No cleanup. If the component unmounts before the fetch
completes, you're trying to set state on an unmounted
component.

Race conditions. If the user triggers two fetches
quickly (navigating back and forth), you can't guarantee
which one resolves last. The slower one might overwrite
the faster one.

A more complete version:

useEffect(() => {
  let cancelled = false

  setLoading(true)
  setError(null)

  fetch('/api/user')
    .then(res => {
      if (!res.ok) throw new Error('Request failed')
      return res.json()
    })
    .then(data => {
      if (!cancelled) setUser(data)
    })
    .catch(err => {
      if (!cancelled) setError(err.message)
    })
    .finally(() => {
      if (!cancelled) setLoading(false)
    })

  return () => { cancelled = true }
}, [])

This handles all four problems. It's also 25 lines for
what should be a simple data fetch.

This is why libraries like React Query and SWR exist.
They handle all of this — loading state, error state,
cancellation, deduplication, caching — so you don't
have to write it every time.

I'm not saying never write your own fetch logic. I'm saying
understand what you're giving up when you simplify it.

Event listeners — a genuine useEffect use case

This is wher
e useEffect actually belongs:

useEffect(() => {
  const handleKeyDown = (e: KeyboardEvent) => {
    if (e.key === 'Escape') closeModal()
  }

  document.addEventListener('keydown', handleKeyDown)

  return () => {
    document.removeEventListener('keydown', handleKeyDown)
  }
}, [closeModal])

You're synchronizing React with a browser API. There's no
React-native way to listen to keyboard events. useEffect
is exactly right here.

The cleanup function matters. Without it, every time this
component mounts you add a new listener and never remove
the old one. After ten mounts you have ten listeners all
calling closeModal at the same time.

What I use instead now

For derived state: just calculate it during render.
No hook needed.

For expensive calculations: useMemo, but only when
profiling shows it's actually slow. Not as a default.

// Only if the calculation is genuinely expensive
const sortedItems = useMemo(() => {
  return items.sort((a, b) => a.name.localeCompare(b.name))
}, [items])

For data fetching: React Query in any app that fetches
from an API. The caching alone is worth it.

For browser APIs: useEffect with proper cleanup.

For syncing with external libraries: useEffect,
but isolate it in a custom hook so the component
code stays clean.

// Custom hook isolates the external sync
const useDocumentTitle = (title: string) => {
  useEffect(() => {
    const original = document.title
    document.title = title
    return () => { document.title = original }
  }, [title])
}

// Component stays clean
const ProductPage = ({ product }: Props) => {
  useDocumentTitle(product.name)
  return <div>...</div>
}

The question I ask before every useEffect

Before I write useEffect now I ask: am I synchronizing
with something outside of React?

If the answer is no, I look for a different approach first.
Derived value, event handler, library, custom hook.

useEffect isn't bad. It's a precise tool for a specific
job. Using it for everything is like using a screwdriver
to hammer a nail — it works sometimes, but it's not
what it's for.

That seven-useEffect component I mentioned at the start?
I refactored it to two. One for a WebSocket connection,
one for a document title update.

Everything else moved into derived values, a custom hook,
and React Query.

It's been three months and I haven't touched it since.