DEV Community: Ndeye Fatou Diop

29 React Codebase Red Flags from a Senior Frontend Developer

Ndeye Fatou Diop — Tue, 21 Apr 2026 14:00:00 +0000

Hey, it's Fatou.

I've been writing React code as an engineer at Palantir for the past 6+ years.

These are the 29 red flags that tell me a React codebase is going to be painful to work with.

Ready? Let's dive in! 💪

1. 🚩 Using libraries for what vanilla JS can do

We've all done it:

Importing lodash just to use isNil instead of == null.
Using dayjs rather than Intl.DateTimeFormat for future use cases (spoiler alert: they end up never coming).
Etc.

But this is wrong because every dependency:

adds maintenance overhead: You have to update it when bugs are fixed, vulnerabilities disclosed, new versions come out.
adds to your bundle size.
can break when you upgrade React or TypeScript.

Before you add a dependency, ask yourself: can I do this with vanilla JS?

If the answer is yes, do that instead. It keeps your codebase lean.

2. 🚩 Reaching for heavy dependencies when lighter alternatives exist

moment.js is 75KB minified. day.js is 3KB with the same API.

axios is 14KB. The native fetch API is free.

I've reviewed PRs where someone added a 70KB library to do something a 3KB alternative handled just as well.

Nobody checked the size, because nobody had the habit. It adds up fast and your users on a 3G connection in Lagos or São Paulo are the ones who pay for it.

Before you install, check the bundle size on bundlephobia. If a lighter alternative exists, use it.

3. 🚩 No linter or formatter configured

Non-negotiable.

I once sat through a meeting where engineers spent 30 minutes arguing about whether to use tabs or spaces.

What settled the debate? Configuring the formatter for the entire repo and moving on.

Without repo-level config, every review becomes a style debate instead of a real conversation about the code.

Set it up once and move on.

4. 🚩 No consistent folder structure

I've wasted so many hours of my life trying to figure out where to put a new file 🥲.

One developer organises by feature, another by file type, a third just dumps things wherever.

Pick a convention – feature-based, domain-based, whatever works for your team – document it, and enforce it in reviews.

// 🚩 Red flag: chaotic structure
src/
  components/Button.tsx
  pages/home/helpers.ts
  utils/userStuff.ts
  lib/api.ts
  shared/Button.tsx // wait, there's already a Button?

5. 🚩 Junk drawer utils files

Every codebase has one. A utils.ts that starts with 3 helper functions and grows into 40 unrelated ones.

Nobody owns this file.
Everyone adds to it.
Nobody cleans it.

A simple change to one function can cause merge conflicts with a change to a completely unrelated function.

A small change can cause bugs in an unrelated function because they share the same scope.

In the example below, formatDate and calculateTax are neighbors for no reason.

// utils.ts — the junk drawer
export function formatDate(d: Date) { /* ... */ }
export function parseQueryString(s: string) { /* ... */ }
export function calculateTax(amount: number) { /* ... */ }
export function debounce(fn: Function, ms: number) { /* ... */ }
export function hexToRgb(hex: string) { /* ... */ }
// ...35 more

Instead, related functions should be grouped together: date-utils.ts, string-utils.ts, math-utils.ts.

If your utils file needs a table of contents, it's time to break it up.

6. 🚩 Related files not colocated

When a component lives in /components, its styles in /styles, its tests in /__tests__, and its helpers in /utils... you're constantly jumping across the project to understand one feature.

Files that change together should live together.

When I need to modify the UserProfile feature, I want to open one folder, not four. And when the feature gets killed, I want to delete one folder, not hunt through four directories for orphaned files.

PS: I'm not jumping that much between files these days: Claude does 😅. But still…

// 🚩 Red flag: scattered files
src/
  components/UserProfile.tsx
  styles/UserProfile.css
  __tests__/UserProfile.test.tsx
  utils/userProfileHelpers.ts

// ✅ Colocated
src/
  features/user-profile/
    UserProfile.tsx
    UserProfile.css
    UserProfile.test.tsx
    helpers.ts

7. 🚩 Barrel files that re-export everything

I've done that mistake too 🙈.

You want to simplify imports, so you create a components.ts file that re-exports everything in the folder.

Little did you know that this creates a hidden coupling between all those files.

In development, your bundler processes the entire barrel on every hot reload, even files you never touch.
You get weird compilation errors due to a file that you're not even using but is still being processed.
You have a hard time tracing where something is defined: you click through to the import and land in a wall of re-exports instead of the actual code.

If you must use barrel files, be explicit: name each export instead of using export *.

// 🚩 components.ts
export * from './Button'
export * from './Modal'
export * from './Table'
// ...50 more

8. 🚩 God components

Data fetching, state management, form validation, error handling - all in one file, all in 500+ lines.

Signs you have a God component:

Scrolling 30 seconds to find the return statement
Searching return gives you 20+ results

I've worked on components like this: you fix a bug in the form validation and accidentally break the data fetching because everything shares the same scope.

So break it up. Each piece should have one job.

9. 🚩 Passing entire objects when only one field is needed

// 🚩 Red flag
<UserAvatar user={user} />

// ✅ Better
<UserAvatar avatarUrl={user.avatarUrl} name={user.name} />

When you pass the whole object, the child component is coupled to the shape of user and re-renders whenever any field on that object changes, not just the ones it uses.

You also make the component harder to reuse: what if another part of the app has avatar data but it doesn't live in a user object?

So only pass components the data they need. It keeps them decoupled, reusable, more performant, and easier to test.

10. 🚩 Storing derived values in state

// 🚩 Red flag
const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')
const [fullName, setFullName] = useState('')

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

// ✅ Just compute it
const fullName = `${firstName} ${lastName}`

If a value can be calculated from other state or props, it's not state, it's a computation.

I've seen this cause real bugs: there's always a render where fullName is stale because the effect hasn't run yet.

The fix is simple: just compute it inline. If the computation is expensive, wrap it in useMemo. But don't store it in state.

11. 🚩 Using state when it should be a ref

Timer IDs, previous values, flags that shouldn't trigger a re-render: these belong in a useRef, not useState.

If changing the value shouldn't update the screen, it's not state.

// 🚩 Red flag: triggers a re-render every time
const [timerId, setTimerId] = useState(null)

// ✅ No re-render needed
const timerIdRef = useRef(null)

12. 🚩 Putting everything in a global store

Not everything needs to be in Redux or a global Context.

I've worked on codebases where tooltip visibility was stored in Redux: an action to open it, a reducer to track it, a selector to read it, all for state that only one component ever needed.

// 🚩 Red flag: global state for local UI
dispatch(setTooltipVisible(true))

// ✅ Keep it where it lives
const [isVisible, setIsVisible] = useState(false)

The rule: if no other part of the app needs to know about it, keep it local.

13. 🚩 A single massive Context that re-renders half the app

// 🚩 Red flag: one context for everything
const AppContext = createContext({
  user: null,
  theme: 'light',
  locale: 'en',
  sidebarOpen: false,
  notificationCount: 0,
})

Every time any of these changes, every consumer re-renders.

The sidebar toggles? Your notification badge re-renders. The locale changes? Your sidebar re-renders.

Split your contexts by concern: UserContext, ThemeContext, etc.

It's a small upfront cost that saves you from chasing phantom performance problems later.

And if your contexts start becoming unmanageable, that's a sign you need a state management library with more granular updates.

PS: If your app is simple enough, using a single context is fine 😉.

14. 🚩 Poor TypeScript hygiene

any everywhere. You're using TypeScript but typing things as any?

You're getting all the overhead with none of the safety.

That's just the start. Poor TypeScript hygiene also looks like:

No discriminated unions — you're allowing impossible states.
Switch statements without exhaustive checks — every new variant is a bug waiting to happen.

TypeScript is only as good as the types you write.

// 🚩 Red flag: allows impossible states
type FormState = {
  isSubmitting: boolean
  isSuccess: boolean
  errorMessage: string | null
}
// { isSubmitting: true, isSuccess: true } — shouldn't be possible, but is

// ✅ Discriminated union
type FormState =
  | { status: 'idle' }
  | { status: 'submitting' }
  | { status: 'success' }
  | { status: 'error'; message: string }

15. 🚩 `eslint-disable` to silence the exhaustive-deps warning

// 🚩 Red flag
useEffect(() => {
  fetchData(userId)
  // eslint-disable-next-line react-hooks/exhaustive-deps
}, [])

This looks harmless. It's not.

The linter is telling you: your effect depends on userId, but it won't re-run when userId changes. Two things can go wrong:

Your users see stale data whenever userId changes.
Someone adds a dependency inside fetchData later, gets no warning, and the bug ships silently.

The fix isn't to silence the warning — it's to understand it:

Maybe fetchData should be wrapped in useCallback.
Maybe the effect should list userId as a dependency.

Silencing the linter doesn't fix the underlying issue — it just hides it until a user reports stale data.

16. 🚩 Using array indices as keys

We've all written this at some point:

// 🚩 Red flag
{items.map((item, index) => (
  <TodoItem key={index} item={item} />
))}

React just needs something for key, right?

Here's what goes wrong. You have a list of 3 items. The user deletes item 0. React sees key={0} still exists so it reuses the first DOM node instead of removing it. The component doesn't reset. The stale state from the old item bleeds into the new one.

You'll see this as: inputs that don't clear, animations that fire on the wrong item, form values that belong to a deleted row.

// ✅ Use a stable, unique id
{items.map((item) => (
  <TodoItem key={item.id} item={item} />
))}

If your data doesn't have an id, generate one when it enters your system, not at render time.

17. 🚩 Using a hook when a plain function would do

Just because you're building components doesn't mean everything has to be a hook.

If your function doesn't call React state, effects, or other hooks, it's just a function.

Making it a hook means it can only be called at the top level of a component or another hook, not inside event handlers, loops, or conditionals.

A plain function can be called anywhere. It's also easier to test 😉.

// 🚩 Red flag: it's a hook for no reason
function useFormatCurrency(amount: number) {
  return new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
  }).format(amount)
}

// ✅ Just a function
function formatCurrency(amount: number) {
  return new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
  }).format(amount)
}

18. 🚩 Rolling your own data fetching layer

// 🚩 Red flag
useEffect(() => {
  setLoading(true)
  fetch(`/api/users/${id}`)
    .then(res => res.json())
    .then(data => {
      setData(data)
      setLoading(false)
    })
    .catch(err => {
      setError(err)
      setLoading(false)
    })
}, [id])

This code works. For a simple one-off fetch, it's fine.

The red flag is what comes next.

Your app needs a loading state. You add one. Then error handling. Then retry on failure. Then cache invalidation. Then request deduplication so the same request doesn't fire twice.

There's also a subtle bug already: if id changes quickly, the first response can overwrite the second, a race condition you'll need to handle with an AbortController.

You've just started rebuilding React Query. Poorly.

Libraries like React Query and SWR already solved all of this.

You don't have to use them — but if you find yourself adding more and more logic around useEffect + fetch, reach for a library instead of reinventing it.

19. 🚩 No error boundaries

I've seen an app where JSON.parse on a value with an unexpected shape crashed the entire app: navigation, sidebar, everything. Gone. TypeScript couldn't catch it: JSON.parse returns any, so the type system had no idea.

A single unhandled error shouldn't take down the whole page.

Wrap critical sections so the rest of the app keeps working. The user loses one capability instead of everything.

// ✅ Wrap critical sections
<ErrorBoundary fallback={<p>Something went wrong.</p>}>
  <UserDashboard />
</ErrorBoundary>

20. 🚩 Empty catch blocks

I can't tell you how many times I've seen this:

User complaints about an issue
You check the logs and see... nothing. No errors, no warnings, no clues at all.
You have to ship new code just to add logging and figure out what went wrong 🤦‍♀️.

The culprit is always the same:

// 🚩 Red flag
try {
  await saveData()
} catch (e) {}

At minimum, log the error. Better yet, tell the user something went wrong (+ how to fix it).

21. 🚩 No loading or error states

No loading spinner, no skeleton, no error message.

Just a blank screen when the API is slow and a crash when it fails.

Your users don't have localhost speeds and perfect networks. You need three states: loading, error, success.

// 🚩 Red flag: only handles success
function UserList() {
  const [users, setUsers] = useState([])
  useEffect(() => {
    fetch('/api/users').then(r => r.json()).then(setUsers)
  }, [])
  return <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>
}

22. 🚩 Accidentally breaking memoization with default values

I once introduced a new component to my codebase.

And for whatever reason, my app started crashing whenever I typed in an unrelated input.

The culprit? A ?? [] default value in the new component that was creating a new array on every render.

The fix:

// ✅ Define the default outside the component
const EMPTY_ITEMS = []

<ItemsList items={items ?? EMPTY_ITEMS} />

Same goes for {}, () => {}, and any other inline default. If it's passed as a prop and the child is memoized, define it outside the render.

23. 🚩 Unreadable conditional rendering

Nested ternaries and long && chains both make JSX impossible to follow:

// 🚩 Nested ternaries
{isLoading ? <Spinner /> : error ? <Error /> : data ? <Content /> : null}

// 🚩 Long && chains
{isLoggedIn && hasPermission && !isExpired && featureFlag && <SecretPanel />}

If you have to mentally parse boolean logic to understand what renders, extract it into a variable or use early returns:

// ✅ Clear and readable
if (isLoading) return <Spinner />
if (error) return <Error />
if (!data) return null
return <Content />

24. 🚩 No early returns

If you're five levels of indentation deep, flip your conditions and return early.

This makes the code easier to read.

// 🚩 Red flag: deeply nested
function UserProfile({ user }) {
  if (user) {
    if (user.isActive) {
      if (user.hasProfile) {
        return <Profile data={user.profile} />
      } else {
        return <CreateProfile />
      }
    } else {
      return <InactiveMessage />
    }
  } else {
    return <NotFound />
  }
}

// ✅ Early returns
function UserProfile({ user }) {
  if (!user) return <NotFound />
  if (!user.isActive) return <InactiveMessage />
  if (!user.hasProfile) return <CreateProfile />
  return <Profile data={user.profile} />
}

25. 🚩 Magic values with no explanation

I can't tell you how many times I've wanted to modify a value in the code but was too scared to change it because I had no idea why it was that value.

setTimeout(retry, 3000). Why 3 seconds?
pageSize: 37. Why 37?

If a value isn't self-explanatory, give it a name and document it.

// 🚩 Red flag
setTimeout(retry, 3000)
const PAGE_SIZE = 36

// ✅ Named and documented
const RETRY_DELAY_MS = 3000 // Matches the p95 API response time
const PAGE_SIZE = 36 // 4 columns × 9 rows in the grid layout

26. 🚩 The same conditional logic scattered everywhere

// 🚩 Red flag: scattered across the codebase
{user.role === 'admin' && <DeleteButton />}
{user.role === 'admin' && <AdminPanel />}
{user.role === 'admin' || user.role === 'moderator' && <ModTools />}

// ✅ Centralized
function canDelete(user: User) {
  return user.role === 'admin'
}
function canModerate(user: User) {
  return ['admin', 'moderator'].includes(user.role)
}

When if (user.role === 'admin') appears in 10 different components, you've built a maintenance trap.

The day someone adds a new role or changes what "admin" means, you don't want to hunt through 10 files.

Centralise it into permission helpers and import those everywhere.

27. 🚩 No abstraction layer over third-party libraries

// 🚩 Red flag: tightly coupled to recharts
import { LineChart, Line, XAxis, YAxis } from 'recharts'
// ...used directly in 20 components

// ✅ Wrapped behind your own interface
import { Chart } from '@/components/Chart'
<Chart type="line" data={data} xKey="date" yKey="revenue" />

If your charting library is imported directly in 20 components, you're one migration away from rewriting half the app.

A thin wrapper isn't always worth the effort for every dependency.

But for anything you use in more than a handful of places: charting, analytics, HTTP clients, etc. it pays for itself the first time you need to swap.

28. 🚩 Massive files nobody dares refactor

Every codebase has one.

The 1,200-line component that everyone is afraid to touch because there are no tests and everything might break. So it keeps growing. New features get bolted on. The fear compounds. Nobody refactors it. It just gets worse.

The fix is never as hard as the team fears.

Start small: extract one pure function. Write one test. Then another. You don't need to rewrite the whole thing in a weekend. You need to stop feeding it.

29. 🚩 Not memoizing context values

// 🚩 Red flag: new object on every render
<AuthContext.Provider value={{ user, login, logout }}>
  {children}
</AuthContext.Provider>

// ✅ Memoize the value
const value = useMemo(() => ({ user, login, logout }), [user, login, logout])
<AuthContext.Provider value={value}>
  {children}
</AuthContext.Provider>

Every time the provider re-renders, it creates a new value object.

Every consumer re-renders, even if nothing changed. If your context is near the top of the tree, that's potentially your entire app re-rendering for nothing. One line of useMemo prevents it.

None of these flags mean a codebase is doomed. Every one of them is fixable. I've introduced some of them myself: the first time you see a pattern is rarely the first time you've written it.

But if you're counting more than a handful in the same project, that's worth paying attention to. Not as a judgment, but as a signal that the codebase needs some care.

Start with the ones that hurt the most. Fix those. The rest will get easier.

That's a wrap 🎉

Leave a comment 📩 to share the red flags you've spotted in the wild.

And don't forget to drop a '💖🦄🔥'.

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

Devs: Own your growth — or regret it later

Ndeye Fatou Diop — Thu, 10 Jul 2025 10:00:00 +0000

In 2019, one year after joining a dream company, I was frustrated.

I realized I wanted to switch to another area of software engineering (frontend), but I didn’t know how 🤷‍♀️.

No one would give me a step-by-step plan to achieve it.

All my life, I was used to having either my parents, teachers, or family provide me with a simple roadmap to follow.

I was expecting the same from my managers here.

Fast forward to today: I’m a Senior Frontend Engineer, and I got here by owning my growth path.

In this post, I’ll explain why you always need to own your growth as a dev — and why not doing so is reckless.

Ready? Let’s get started! 🚀

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

What it means to own your growth as a dev

Owning your growth as a dev, especially a junior one, means:

Being clear about where you want to be in 1, 3, and 5 years.
Sharing your goals with people who can help you.
Having a plan to reach your goals (and refining it with your manager).
Following up on the plan.
Re-adapting and adjusting when things change.

Why it’s essential to own your growth

As a (junior) dev, it’s way too easy to be passive and wait for opportunities.

Don’t get me wrong: that’s not always bad.

You can get pretty far with a fantastic manager and a bit of luck on projects.

But it’s dangerous to stay in the backseat of your career. Here’s why:

Reason #1: “If you don't set goals, you will always work for someone who does.”

That’s just the truth.

If you don’t have a clear idea of where you want to go, you’ll end up working for someone else’s goals.

That’s not necessarily bad if your goals align.

But when they don’t, 5 years down the road, you might realize you’re unhappy, stuck in a role that doesn’t fulfill you 🥲.

Reason #2: Working toward your goals brings you more supporters

Have you heard of the analogy about pushing a broken car?

It goes like this:

It’s much easier to help someone who’s already pushing their broken car than someone who’s just standing next to it, waiting.

Why?

Because movement attracts help.

People are far more likely to jump in and assist when they see you taking action, even if it’s messy or slow.

So if you’re stuck, start pushing.

You’ll be amazed at who shows up to give you a hand.

Reason #3: Owning your growth gives you more credibility

When you own your growth, set goals, and work toward them, it’s easy to imagine you doing the same for a team.

Owning your growth shows strong ownership — a trait that accelerates your career.

Reason #4: Other people are also trying to figure it out

As a junior dev, I used to look at folks with 3+ years of experience and think:

“Wow, they’ve figured it all out.”

Fast forward to today — after 5+ years — I’ve realized you never really figure it out 😅.

The problems get harder.

As a manager, I see this too: I can give some advice, but until someone comes to me with clear goals, it can be pretty generic.

But if you arrive with a clear goal and a rough plan, it’s much easier to provide you with tailored, helpful advice.

Reason #5: Having clear goals helps you adjust when things change

Tech changes all the time. Look at how AI is reshaping everything.

Clear goals act like a north star. They let you reassess: is this new tech going to help or hurt in reaching them?

Without that, you’ll drift wherever the wind blows — and might wake up in a place you hate.

How to own your growth

Alright, so how do you actually do it?

Let me start with a personal example.

My story:

In 2019, I wanted to transition into frontend development. So I:

Made this goal clear to my manager.
Talked to as many people as possible who’d made the switch.
Applied all their tips (learned JavaScript, contributed to the product, etc.).
Shared my progress regularly with my manager.
Repeated the cycle — contribute → share → repeat — until the right opportunity came up. Then I made the transition.

What you can do:

If you’re not currently owning your growth, here’s how to start:

Set goals (or anti-goals):

Where do you want to be in 1, 3, 5 years? Do you want to be an IC, a manager, or earn a specific comp?

Can’t come up with goals?

👉 Try anti-goals: what does your nightmare life look like? (low pay, endless meetings, outdated skills). Then work backwards to avoid it.
Come up with a plan:

Start with a simple 3-year plan, a clearer 2-year plan, and a more detailed 1-year plan.

The plan doesn’t have to be perfect or set in stone. It’s mainly a conversation starter.

Remember, “Complexity is the enemy of execution.”
Share and refine the plan:

Don’t just tell your manager, “This is what I want.”

Say, “This is what I want, and here’s how I plan to get there.”

Then gather feedback, adjust accordingly, and ensure it aligns with the business's needs as well.
Work toward the plan every day:

Show up consistently. Small steps daily beat occasional giant leaps.
Share your progress:

Don’t be shy. Sharing wins builds trust and shows commitment.
Reassess and adjust:

Plans change. Don’t abandon ship at the first hurdle — some things take time.

As Warren Buffett said, “You can't produce a baby in one month by getting nine women pregnant.”.

But also don’t be afraid to pivot if needed.
Keep setting goals:

It’s easy to coast when things go well. But this is a never-ending process.

Summary

You’re cheating yourself if you’re not owning your growth as a dev.

Owning your growth means having goals (or anti-goals) and working toward them.

If you don’t, you’re 99% more likely to wake up one day in the wrong place, full of regrets.

It’s not that hard: set goals, build a plan, share it, work on it, show your progress, adjust — repeat.

That’s it.

You’ve got this.

Become the amazing developer you’re meant to be 💪.

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

✨ 17 React Hooks That Power 90% of Modern Components

Ndeye Fatou Diop — Tue, 20 May 2025 17:32:36 +0000

New to React?

If yes, you’ve probably wondered what hooks you really need—or worse, you’ve been copying the same logic over and over without realizing it.

This post covers all the React hooks you’ll likely need in your project.

Let’s dive in 🎉.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

1. useState

This hook is unavoidable.

Whenever you need dynamic state that persists across re-renders, this is the one.

const [count, setCount] = useState(0);

2. useReducer

Once your state becomes complex (e.g. multiple correlated fields), useReducer becomes your friend.

It also pairs really well with useContext, letting you update state with simple dispatch calls.

const reducer = (state, action) => {
  switch (action.type) {
    case "addTodo":
      return { todos: [...state.todos, action.todo] };
    case "removeTodo":
      // TODO: Implement logic
    case "toggleTodo":
      // TODO: Implement logic
    default:
      return state;
  }
};

const [state, dispatch] = useReducer(reducer, { todos: [] });

3. useContext

When prop drilling gets out of hand, this hook saves the day.

Prop drilling = passing props through multiple layers just to reach a deeply nested component.

Use useContext to:

manage global state in small apps
share data like the authenticated user
avoid passing props manually everywhere

const UserContext = createContext();

function App() {
  const user = useUser();
  return (
    <UserContext.Provider value={user}>
      {/* ... */}
    </UserContext.Provider>
  );
}

function Profile() {
  const user = useContext(UserContext);
  return <div>Hello {user.name}</div>;
}

4. useEffect

You should avoid it 99% of the time.

(See: You Might Not Need an Effect)

But in real life, you’ll still need it—especially for things like syncing with external systems.

function useSetDocumentTitle(title: string) {
  useEffect(() => {
    document.title = title;
  }, [title]);
}

5. useRef

You should never directly manipulate the DOM in React.

But when you must (e.g. for canvas, chart libraries…), useRef is the safe way.

function ExampleChart({ data }) {
  const canvasRef = useRef();

  useEffect(() => {
    const ctx = canvasRef.current;
    if (!ctx) return;

    const chart = new Chart(ctx, {
      type: "bar",
      data: {
        labels: data.map((row) => row.year),
        datasets: [{ label: "Likes", data: data.map((r) => r.count) }],
      },
    });

    return () => chart.destroy();
  }, []);

  return <canvas ref={canvasRef} />;
}

6. useMemo / useCallback

These may become optional thanks to the new React Compiler—but for now, they’re still useful.

Use useMemo when:

an expensive computation should not re-run on every render
you're memoizing a non-primitive dependency
you're passing values to memo-wrapped components

Use useCallback to memoize functions.

const total = useMemo(() => computeTotal(items), [items]);

const handleClick = useCallback(() => {
  console.log("clicked");
}, []);

7. useLayoutEffect

This one is rare but useful.

It runs before paint, which helps prevent layout shifts or flickering UI.

See real examples here: No more flickering UI

If you’re not comfortable with React components lifecycle, check my post ✨ React Lifecycle in 3 Minutes 😉.

useLayoutEffect(() => {
  const height = ref.current.offsetHeight;
  setHeight(height);
}, []);

8. useSWR / useQuery

SWR and TanStack Query are becoming the standard for fetching data in React.

SWR is simpler and great for most use cases while TanStack Query is more complex and powerful.

SWR

const fetcher = (url) => fetch(url).then((res) => res.json());

const { data, error, isLoading } = useSWR("/api/user", fetcher);

TanStack Query

const getUser = () => fetch("/api/user").then((res) => res.json());

const { data, isLoading } = useQuery({
  queryKey: ["user"],
  queryFn: getUser,
});

9. useSelector, useDispatch, or other state hooks

Sometimes React’s built-in state tools aren’t enough.

You’ll then see these hooks depending on the state library:

useSelector, useDispatch from react-redux
useAtom from Jotai
etc.

10. useNavigate

React Router is very popular.

So is its navigation hook:

const navigate = useNavigate();
navigate("/profile");

Now, let’s talk about hooks I reach for in nearly every app—even though they’re not built into React.

11. useBoolean

One of my all-time favorites.

It makes managing boolean state super clean.

const { value: isOpen, setFalse, toggle } = useBoolean();

return (
  <>
    <button onClick={toggle}>
      {isOpen ? "Close form" : "Open form"}
    </button>
    <Dialog isOpen={isOpen} onClose={setFalse}>
      {/* Form content */}
    </Dialog>
  </>
);

12. useCopyToClipboard

Perfect for "copy" buttons.

const [copiedText, copy] = useCopyToClipboard();

const handleCopy = () => {
  copy("Hello World").catch(err => {
    errorToast("Failed to copy!", err);
  });
};

return (
  <>
    <button onClick={handleCopy}>Copy</button>
    {copiedText && <span>Copied!</span>}
  </>
);

13. usePrevious

Use this to compare current vs. previous values.

Great for triggering actions based on changes.

const prevCount = usePrevious(count);
const didIncrease = prevCount !== undefined && count > prevCount;

useEffect(() => {
  if (didIncrease) {
    console.log("Count increased!");
  }
}, [didIncrease]);

14. useDebounce

Debounce your requests to avoid unnecessary API calls.

const [query, setQuery] = useState("");
const [debouncedQuery] = useDebounce(query, 500);

const { data } = useSWR(`/api/search?q=${debouncedQuery}`, fetcher);

return (
  <> 
    <input
      value={query}
      onChange={(e) => setQuery(e.target.value)}
      placeholder="Search..."
    />
    {/* TODO: Show data */}
  </>

);

15. useMediaQuery

Want to render different things based on screen size? This hook is for you.

const isMobile = useMediaQuery("(max-width: 768px)");

return <div>{isMobile ? "Mobile View" : "Desktop View"}</div>;

16. useResizeObserver

Useful for responsive layouts or libraries like react-window.

const ref = useRef(null);
const { width = 0, height = 0 } = useResizeObserver({ ref });

return (
  <div ref={ref}>
    Width: {width}, Height: {height}
  </div>
);

17. useLocalStorage

Store and sync data with localStorage easily.

const [theme, setTheme] = useLocalStorage("theme", "light");

return (
  <button onClick={() => setTheme(theme === "light" ? "dark" : "light")}>
    Switch to {theme === "light" ? "dark" : "light"}
  </button>
);

Summary

That’s it!

These 17 hooks are more than enough to cover most use cases in any React app.

Pick your favorites and use them in your next project 😉.

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

✨ 7 Things I Do Regularly as a Senior Frontend Developer

Ndeye Fatou Diop — Wed, 07 May 2025 14:00:00 +0000

I’ve been a frontend developer at Palantir for the past 5+ years.

In this post, I’ll share habits that helped me go from overwhelmed junior dev to confident senior dev.

Ready?

Let’s get started! 🎉

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

Habit #1: Educate yourself outside of work

If you’re not learning outside of work, you’re falling behind.

Even if you have the best employer in the world, your education is your responsibility.

So, at least once every 2–4 weeks:

Pick up books like The Pragmatic Programmer, Effective TypeScript, or Advanced React
Read blog posts from experts like Matt Pocock (Total TypeScript), Josh Comeau (joshwcomeau.com), Kent C. Dodds (Epic React), etc.
Watch courses to review your basics (Udemy, FrontendMasters, etc.)

The more you learn, the more efficient you’ll be at work.

Habit #2: Work on different projects and skills every month

The worst thing that can happen to a frontend dev?

👉 Getting stale.

Especially in the age of AI.

Working on the same type of project over and over slows your growth.

Why?

You have fewer tools to solve problems
You get less flexible and adaptable
You become easier to replace

Try new things every month. If you can’t at work, explore with side projects.

Habit #3: Get enough rest

The less sleep I get, the more bugs I ship 😅.

Your brain needs rest. And what that looks like depends on you.

But one thing’s for sure: you can’t cheat sleep.

Getting enough rest keeps your mind sharp and your code cleaner.

Habit #4: Stay in touch with what’s happening in the frontend world

I still see devs who ignore AI (and other new tech trends).

This breaks my heart 🥲.

Most devs who ignore change will eventually get replaced by it.

You don’t need to jump on every trend. You don’t need to use the latest framework.

But you do need to stay aware. Pay attention. Adapt when it makes sense.

Otherwise? You’ll slowly become obsolete.

Habit #5: Review code regularly

Code reviews are underrated 🙂.

Not just for the code author, but for you.

I’ve learned countless patterns and tricks just by reviewing code.

It’s a simple way to grow while helping your teammates.

No access to reviews at work? Browse open-source projects on GitHub and read PRs.

💡 Check out these examples of large, production-grade open-source React apps.

Habit #6: Teach back what you learn

“If you can't explain it simply, you don't understand it well enough.” — Albert Einstein

Teaching forces you to understand things deeply.

I’ve often thought I knew something—until I tried to explain it.

That’s when I realize I don’t actually get it yet.

Teaching is a shortcut to mastery.

Run internal sessions at work.
Write on a blog.
Record short videos.

Anything works 😉.

Habit #7: Avoid tutorials and copy/pasting

Tutorials are fine—in small doses.

But they quickly become a way to avoid learning, not to encourage it.

Instead of binge-watching, try to build something. Use tutorials only when you’re stuck.

Same with copy/pasting code.

If you don’t understand what you’re pasting, you won’t remember it. And you’ll keep repeating the cycle.

💡 Quick tip: if it’s a piece of code you use often but don’t want to memorize, save it as a snippet (like in VS Code snippets).

Summary

Becoming a great frontend dev takes time.

But these 7 small habits can make a huge difference over the long run.

What’s next?

Pick just one—and try it this week 🙂.

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

✨ Don’t do this (unless you want sh*t frontend code)

Ndeye Fatou Diop — Mon, 05 May 2025 14:30:00 +0000

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

It’s easy to end up with messy frontend code.

In this post, I’ll show you 17 things to avoid if you want to keep your frontend code clean and maintainable.

Let’s dive in 👇

Mistake #1: Using too many global variables

Global variables are accessible from anywhere in your app, which makes them risky.

If you change one in a random place, you can unintentionally break something elsewhere, and that’s a nightmare to debug.

They also make testing harder, since the function's behavior might change depending on the global state.

Use function arguments or scoped variables instead.

❌ Bad:

let userRole = 'guest';

function canEditPost() {
  return userRole === 'admin';
}

userRole = 'admin'; // Changes app behavior unexpectedly

✅ Better:

function canEditPost(userRole) {
  return userRole === 'admin';
}

const role = 'admin';
canEditPost(role);

Mistake #2: Poor variable and function names

Using vague names like x, data, or handleStuff slows everyone down.

Readers (including future you) will need to guess what each thing does — or worse, scroll around to find out.

A good rule of thumb: the bigger the scope, the more descriptive the name should be.

Short loops? i is fine.

Longer scope? Use names that tell the whole story.

❌ Bad:

function d(a, b) {
  return a - b;
}

const x = d(100, 50);

✅ Better:

function calculateDiscount(originalPrice, discountAmount) {
  return originalPrice - discountAmount;
}

const finalPrice = calculateDiscount(100, 50);

Mistake #3: “God” functions

These functions try to do everything — validate input, update UI, fetch data, handle errors — all in one place.

The result? Long, messy functions that are painful to test and debug.

Instead, split logic into smaller, focused functions.

This improves readability, makes it easier to write unit tests, and helps you reuse logic in other places too.

❌ Bad:

function handleFormSubmit(event) {
  event.preventDefault();

  const name = event.target.name.value;
  const email = event.target.email.value;

  if (!name || !email.includes("@")) {
    alert("Invalid form");
    return;
  }

  setLoading(true);

  fetch("/api/submit", {
    method: "POST",
    body: JSON.stringify({ name, email }),
  })
    .then(res => res.json())
    .then(data => {
      setUser(data.user);
      navigate("/dashboard");
    })
    .catch(() => {
      alert("Something went wrong");
    })
    .finally(() => setLoading(false));
}

✅ Better:

function handleFormSubmit(event) {
  event.preventDefault();

  const formData = getFormData(event);

  if (!isValidForm(formData)) {
    alert("Invalid form");
    return;
  }

  submitForm(formData);
}

function getFormData(event) {
  return {
    name: event.target.name.value,
    email: event.target.email.value,
  };
}

function isValidForm({ name, email }) {
  return name && email.includes("@");
}

async function submitForm(data) {
  try {
    setLoading(true);
    const response = await fetch("/api/submit", {
      method: "POST",
      body: JSON.stringify(data),
    });

    const result = await response.json();
    setUser(result.user);
    navigate("/dashboard");
  } catch (e) {
    alert("Something went wrong");
  } finally {
    setLoading(false);
  }
}

Mistake #4: Functions with many same-type params

When a function has several parameters of the same type — like booleans or strings — it’s easy to mix them up.

Instead, pass an object with named keys.

That way, it’s clear what each value is for — and you don’t need to jump to the function definition to understand what’s going on.

❌ Bad:

createUser("Alice", true, false, true);

✅ Better:

createUser({ name: "Alice", isAdmin: true, isVerified: false, isActive: true });

Mistake #5: Not cleaning up resources

Whenever you add an event listener, create intervals, set timeouts, or use useEffect in React, clean them up once they’re no longer needed.

If you don’t, you could end up with memory leaks, stacked event listeners, or ghost network calls.

For frontend apps that run for a long time (such as dashboards or admin panels), these bugs can significantly impact performance — or even crash your app entirely.

❌ Bad (React):

useEffect(() => {   window.addEventListener('resize', handleResize); }, []);

✅ Better:

useEffect(() => {
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []);

Mistake #6: Unit-less variables

If a value has a unit — like milliseconds, pixels, or megabytes — include that unit in the variable name.

Otherwise, other devs (or future you) will have to guess what the number means.

❌ Bad:

const timeout = 3000;

✅ Better:

const timeoutMs = 3000;

Mistake #7: Nesting conditionals >3 levels deep

When your logic is nested more than 2 or 3 levels, it becomes hard to read and reason about, especially if you have lots of if/else blocks.

Instead, try to “flatten” your code:

Return early
Invert the conditions
Split logic into smaller functions

That makes each block easier to read and debug.

❌ Bad:

if (user) {
  if (user.isAdmin) {
    if (user.hasAccess) {
      // do stuff
    }
  }
}

✅ Better:

if (!user || !user.isAdmin || !user.hasAccess) return;

// do stuff

Mistake #8: Hardcoding URLs or config in the code

Hardcoding things like URLs, API keys, or environment-specific config is a trap.

The moment that value changes, you’ll have to hunt it down across the codebase.

Instead, store config values in constants or environment variables, then import them where needed.

You’ll avoid bugs, desyncs, and hours of wasted time.

❌ Bad:

fetch('https://api.example.com/posts');

✅ Better:

const API_BASE_URL = process.env.API_BASE_URL;
fetch(`${API_BASE_URL}/posts`);

Mistake #9: Keeping dead code “just in case”

We’ve all done it — comment out some code and leave it there “just in case.”

But here’s the truth: 99% of the time, no one will ever use it 😅. And no one wants to scroll past it.

Use GitHub or GitLab and delete that code.

❌ Bad:

// old validation logic (maybe needed later)
// function validateInput(input) { ... }

✅ Better: Just delete it.

Mistake #10: Giant “utils” files

The classic utils.js file always starts innocent, then slowly turns into a kitchen sink of random functions.

Before you know it, it’s hundreds of lines long and impossible to navigate.

Instead, colocate utility functions near the code that uses them.

Or, split them into focused files like arrayUtils.js, dateUtils.js, etc.

❌ Bad:

// utils.js
export function doStuff() {}

✅ Better:

// listUtils.js (next to List component)
export function getVisibleItems(items, filter) {
  return items.filter(item => item.visible && item.category === filter);
}

Mistake #11: Swallowing errors

If your code might throw an error, don’t just ignore it.

Swallowed errors are a nightmare to debug, especially in production.

Even a simple console.error can save hours of guessing.

And if users are affected, show an indication in the UI so they know something went wrong (instead of a blank screen).

❌ Bad:

try {
  riskyFunction();
} catch (e) {
  // nothing
}

✅ Better:

try {
  riskyFunction();
} catch (e) {
  console.error("Error in riskyFunction:", e);
  showToast("TODO: Useful error message + actions");
}

Mistake #12: One giant file

When everything is contained in a single file — components, logic, styling, and state — the file grows rapidly.

You end up with 800+ lines of scroll hell 🔥.

Instead:

Split things up.
Group related code into folders and give each file a clear role.

It lowers the cognitive load and makes onboarding new devs much easier.

❌ Bad:

// App.js — 1000+ lines of code

✅ Better: Split it up into folders:

/components
/context
/pages

Mistake #13: No linter

Linters like ESLint catch issues before they hit production, from simple bugs to missing React dependencies in useEffect.

They also help standardize code style across a team.

Please ensure you read and act on the warnings: don’t just slap // eslint-disable everywhere 😉.

❌ Bad:

useEffect(() => {
  fetchData();
}, []); // missing fetchData in deps

✅ Better: Use ESLint + React hooks plugin. It will warn you:

React Hook useEffect has a missing dependency: 'fetchData'.

Mistake #14: Messy folder structure

Your project folder shouldn’t feel like a junk drawer.

When files are scattered randomly, it’s challenging to find anything, and this difficulty is compounded when scaling the app.

Instead, use a structure based on features or domains.

Group related files together so new devs can quickly understand what’s what.

❌ Bad:

/src
  App.js
  helpers.js
  styles.css
  randomStuff.js

✅ Better:

/src
  /components
  /services
  App.js

Mistake #15: Commenting obvious code

You don’t need to explain what let count = 0 means.

Trust your reader 😉.

If something’s confusing, try simplifying the logic or using clearer names.

Comments should explain why something is done, not what a line of code does.

❌ Bad:

// Set count to 0
let count = 0;

✅ Better:

let itemCount = 0;

Mistake #16: No comments for weird logic

Sometimes you need to add a workaround or support a legacy case.

That’s fine — but explain *why*.

Without a comment, your teammates (or future you) will waste time trying to understand what magicFix42(data) means.

Leave a short note. You’ll thank yourself later.

❌ Bad:

const result = magicFix42(data);

✅ Better:

// Applies patch for backend bug #321. Read ticket for more context 
const result = magicFix42(data);

Mistake #17: Rewriting what already exists

Don’t reinvent the wheel.

There are tons of small, reliable libraries built by people smarter than us.

If you can solve the problem with a trusted package, use it.

Just keep your dependencies in check so your bundle size doesn’t balloon (check my post ✨ How I Reduced My React Bundle Size by 30% (With Real Examples)).

🟠 Ok:

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

✅ Easier:

import { debounce} from 'lodash-es';

const debouncedFn = debounce(myFn, 300);

Summary

Frontend code can get messy fast.

Avoid these 17 mistakes, and your code will be easier to read, debug, and maintain.

Your future self—and your teammates—will thank you.

<iframe src="https://embeds.beehiiv.com/4b52f101-5150-4e42-abc6-28785fdd68cd" data-test-id="beehiiv-embed" width="100%" height="320" frameborder="0" style="border-radius: 4px; border: 2px solid #e5e7eb; margin: 0; background-color: transparent;"></iframe>

That's a wrap 🎉.

Leave a comment 📩 to add one more tip.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

Typescript to Know for React

Ndeye Fatou Diop — Wed, 16 Apr 2025 11:00:00 +0000

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

Two weeks ago, I stumbled upon this post on Reddit: Should I learn React with TypeScript or JavaScript?

I see these posts all the time—and honestly, it breaks my heart 🥲

If you’re a React dev still using JavaScript, you’re making your life harder.

The time you spend learning TypeScript will 100% pay off in the time you save debugging weird bugs.

So here’s a guide to help you make the switch.

Just the essentials. No fluff 😉.

How TypeScript works

TypeScript adds extra syntax on top of JavaScript to help catch errors early—before they crash your app.

It compiles to JavaScript in the end.

The best part? You can slowly migrate to TypeScript.

Follow this guide for more.

Why you should switch to TypeScript ASAP

Here’s why I think it’s a no-brainer:

Benefit #1: Catch bugs before they reach production

This JavaScript code looks fine… until it explodes:

function printFirstChar(users, userIndex) {
  const name = users[userIndex];
  console.log(name[0]);
}

const users = ['Fatou', 'Bob'];

printFirstChar(users, 5); // ❌ Runtime error: Cannot read properties of undefined

Here’s the TypeScript version:

function printFirstChar(users: string[], userIndex: number) {
  const name = users[userIndex];

  if (name != null) {
    console.log(name[0]);
  }
}

TypeScript doesn’t fix your logic, but it gives you early warnings like “hey, this might be undefined 👀”

Benefit #2: Get autocompletion with libraries

Especially useful when you're exploring a new library.

If that library has TypeScript types, you can get autocompletion inside most editors.

Benefit #3: Make your code more resilient to changes

When you type things properly, TypeScript acts like a safety net.

For example:

Without TypeScript, this code can break without you noticing.

function getLabel(status) {
  switch (status) {
    case 'idle':
      return 'Idle';
    case 'loading':
      return 'Loading';
    case 'success':
      return 'Success';
  }
}

getLabel('loading'); // ✅ works

// Months later...

getLabel('error'); // ❌ returns undefined, but no JS error

With TypeScript, you need to handle changes.

type Status = 'idle' | 'loading' | 'success';

function getLabel(status: Status): string {
  switch (status) {
    case 'idle':
      return 'Idle';
    case 'loading':
      return 'Loading';
    case 'success':
      return 'Success';
    case 'error':
      return 'Error';
  }
}

// Months later...
type Status = 'idle' | 'loading' | 'success' | 'error'; // added 'error'

// ✅ TypeScript will show an error for the `getLabel` function: "Not all code paths return a value"

If you forget to handle a case, TypeScript yells at you. And that’s precisely what you want 😄.

TypeScript error when we forget to handle a case

The TypeScript concepts you need for React

Let’s cover the bare minimum to get started.

✅ Types

Types let you describe the shape of your data and enforce it.

There are native types in TypeScript, and types defined by users.

Native types

These types come by default.

const name = 'Ada'; // string
const age: number = 31; // number
const isActive = true; // boolean
const scores: number[] = [90, 85, 100]; // number[]

💡 In some of the examples above, I typed values explicitly (like const age: number = 31).

You don’t need to do that in real code—TypeScript can infer the types by looking at the values.

Custom types

You can create new types using the native types.

type User = {
  id: number;
  name: string;
};

const user: User = {
  id: 1,
  name: 'Fatou',
};

❌ Avoid `any`

Unless you’re in the middle of a migration, don’t use any.

It’s JavaScript in disguise.

Use unknown instead—it forces you to check the type before using it.

// ❌ Bad: no warning, crashes at runtime
function logLength(value: any) {
  console.log(value.length);
}

logLength(123);

// ✅ Safer
function logLength(value: unknown) {
  if (typeof value === 'string' || Array.isArray(value)) {
    console.log(value.length);
  }
}

// ✅✅ Better: use an explicit type
function logLength(value: string | ArrayLike<unknown>){
  console.log(value.length);
}

🧩 Union & intersection types

Unions let a value be one of many types.

type Status = 'idle' | 'loading' | 'error';

let currentStatus: Status = 'idle';

Intersections combine multiple types into one.

type Name = { name: string };
type Age = { age: number };

type Person = Name & Age;

const person: Person = { name: 'Ada', age: 30 };

🧱 Interfaces

Interfaces define the structure of an object.

interface User {
  name: string;
  age: number;
}

You can extend interfaces:

interface Admin extends User {
  role: string;
}

When to use type vs interface? Doesn’t matter much.

But here’s an interesting guide:

👉 Type vs Interface: Which Should You Use?

🔁 Generics

Generics let you write reusable types with flexible data.

Let’s say you’re typing an API response.

Without generics:

type UserResponse = {
  status: number;
  data: User;
  error?: string;
};

type ProductResponse = {
  status: number;
  data: Product;
  error?: string;
};

That’s a lot of repetition.

With generics:

type ApiResponse<T> = {
  status: number;
  data: T;
  error?: string;
};

type UserResponse = ApiResponse<User>;
type ProductResponse = ApiResponse<Product>;

You can use generics in functions too:

function wrap<T>(value: T): T[] {
  return [value];
}

wrap(42); // type: number[]
wrap('hi'); // type: string[]

I like to think of generics like function parameters—but for types 😉.

🔧 Function types

You can type function parameters and return values.

You always need to type the parameters, but don’t need to type the returned value every time.

// This works
function add(a: number, b: number): number {
  return a + b;
}

// This also works: you don't need to type the returned value
function add(a: number, b: number) {
  return a + b; // inferred as number
}

You can also type the function variable:

const add: (a: number, b: number) => number = (a, b) => a + b;

Depending on the context, you may want to type the return type. When in doubt, type the return type.

You can learn more about return types here:

How to use TypeScript with React

Props

Props are just objects. Type them like any other object.

With type:

type GreetingProps = {
  name: string;
};

function Greeting({ name }: GreetingProps) {
  return <p>Hello {name}</p>;
}

With interface :

interface GreetingProps {
  name: string;
}

function Greeting({ name }: GreetingProps) {
  return <p>Hello {name}</p>;
}

State

useState accepts a generic type, but TypeScript can also infer it.

const [count, setCount] = useState(0); // inferred as number

But if it can’t, be explicit:

const [user, setUser] = useState<{ id: number; name: string } | null>(null);

Component variables and functions

Just like normal TypeScript:

const users: User[] = [{name: "Fatou", age: 31}, {name: "Bob", age: 25} ];
const age = 30; // inferred as number

When you have some functions like event handlers, you can hover over the DOM elements to see the types to use.

const handleClick = (event: React.MouseEvent<HTMLButtonElement>) => {
  console.log('Clicked!', event);
};

// Or:
const handleClick: React.MouseEventHandler<HTMLButtonElement> = (event) => {
  console.log('Clicked!', event);
};

Re-using types across components

You can extend or combine types/interfaces to avoid duplication.

With interfaces:

interface ButtonProps {
  label: string;
}

interface IconButtonProps extends ButtonProps {
  icon: React.ReactNode;
}

With union types:

type ButtonProps = {
  label: string;
};

type IconButtonProps = ButtonProps & {
  icon: React.ReactNode;
};

Hooks

Hooks are just functions, so you can use the same TypeScript tools that apply to functions.

Native hooks

Pretty much all the native hooks have generic params.

const [count, setCount] = useState<number>(0);
// or let TS infer:
const [count, setCount] = useState(0);

const inputRef = useRef<HTMLInputElement>(null);

const [state, dispatch] = useReducer(
  (state: number, action: 'inc' | 'dec') => {
    switch (action) {
      case 'inc':
        return state + 1;
      case 'dec':
        return state - 1;
    }
  },
  0
);

Custom hooks

function useToggle(initial: boolean): [boolean, () => void] {
  const [state, setState] = useState(initial);
  const toggle = () => setState((prev) => !prev);
  return [state, toggle];
}

const [isOpen, toggleOpen] = useToggle(false);

Where to learn more

If you want to go deeper with TypeScript, here are some great resources to explore:

🧠 TypeScript Official Docs: The best place to start. It’s clear, well-structured, and packed with examples. Also includes a playground to test things out.
🎯 Total TypeScript: A fantastic site by Matt Pocock—especially for React devs.

It has a free beginner course, advanced patterns, and many real-world examples.
✨ TypeScript Style Guide: Short, practical tips on how to write clean and consistent TypeScript code. Highly recommended once you start building real apps.
🧩 Type Challenges: A collection of TypeScript puzzles—from beginner to insane. Great if you learn best by solving problems and want to flex your type system skills.
📘 Effective TypeScript: A book + blog by Dan Vanderkam. More advanced, but teaches you how to write better TypeScript. Worth it once you know the basics.
⚛️ React TypeScript Cheatsheets: Tailored for React devs. Covers everything from typing components to context and hooks. Very beginner-friendly, and super helpful as a quick reference.

💡 Make sure to also check out the TypeScript section of my 101 React Tips & Tricks post 😉.

Summary

Using TypeScript with React is one of the best upgrades you can make.

It helps you catch bugs early, gives you better tooling, and makes your code easier to maintain.

The best part? You don’t need to learn everything up front. Start with the basics—types, interfaces, generics—and grow from there.

Many examples are online if you get stuck, and AI tools can help you unblock fast.

Let me know if you have any questions 🙂.

<iframe src="https://embeds.beehiiv.com/4b52f101-5150-4e42-abc6-28785fdd68cd" data-test-id="beehiiv-embed" width="100%" height="320" frameborder="0" scrolling="no" style="border-radius: 4px; border: 2px solid #e5e7eb; margin: 0; background-color: transparent;"></iframe>

That's a wrap 🎉.

Leave a comment 📩 to join the discussion.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

Why Junior Developers Must Seize Control of Their Growth Journey Today

Ndeye Fatou Diop — Thu, 10 Apr 2025 07:00:00 +0000

3 years ago, I found myself at a crossroads.

I was enjoying the work and the learnings, but I couldn’t clearly articulate my impact—or even tell if I was heading in the right direction.

I was doing the work I was asked to do, going with the flow, not questioning anything.

After some reflection, I realized I did want to grow—both financially and technically—but my current actions wouldn’t get me there.

That’s when I saw I was making the same mistake most juniors make:

Not owning your growth and just letting things be.

Fast forward a few months, I became the go-to dev for a product and started making real career progress.

In this post, I’ll share:

Why it’s important to own your growth
Why it’s so tempting to fall into the trap
And what you can do about it

Let’s dive in 👇

What it means to own your career growth

When I say “own your career growth,” I mean:

Being intentional about your work and whether it’s taking you where you want to go
Advocating for yourself—sharing your goals and expectations
Having a rough vision of where you want to be in 1, 3, 5, or even 10 years

Now, let’s look at why this matters.

Why it’s important to own your career growth

Reason #1: Only you know what you truly need

Even with the best manager in the world, only you know what drives you.

Is it more pay? More ownership? More technical challenge?

Everyone’s different. So your version of growth will look different than your colleague’s.

You have to own that. No one else will.

Reason #2: “If you don't have a plan, you become part of somebody else's plan.”

The more you say “yes,” the more you risk ending up on projects that don’t serve you long-term.

Unless you want to be a “yes” person—which is totally valid 🙂—have opinions about where you want to grow.

Because if you don’t have a plan, rest assured you’ll be helping execute someone else’s. And that might not be what you want.

Reason #3: Goals make the journey more satisfying

I thrive on setting goals and reaching them.

It gives me a sense of progress. A feeling that I’m getting better.

But that feeling disappears if all I do is jump from project to project with no cohesion.

And work becomes... meh 🤣.

Why you might not be owning your growth (yet)

Especially early on, it’s easy to fall into one of these traps:

Trap #1: You're just happy to be here

When I landed my first dev job, I was blown away—getting paid that much for work I mostly enjoyed? Wild.

I got comfortable. Too comfortable. I wasn’t pushing myself or questioning the work.

But eventually, I realized:

Progress is important.

Especially progress in the right direction.

If your work feels disconnected, it’s hard to tell what you’re becoming great at—or what makes you unique.

Once the joy of simply “being in tech” disappears, start thinking about your next milestones.

Trap #2: You think learning = progress

If you want to explore and learn as much as possible, that’s 100% valid. That’s a plan in itself.

But don’t confuse learning with progress.

You can know everything in the world—but if you’re not applying it in ways that move the business or your career forward, that knowledge won’t help much.

To grow (especially in pay), you must build deep expertise in something.

T-shaped skills are a great model here.

Trap #3: You don’t know what’s possible

Good news—this one’s easy to fix.

You can:

Talk to role models in your company. Ask how they got where they are. Or just watch them closely.
Ask your manager about growth paths that align with your strengths.
Start with life goals. Need to buy a house? Pay for kids’ school? Cool—reverse-engineer what you’ll need in skills, roles, and pay to get there.

How to start owning your growth

Here’s what worked for me when I decided to become a major actor in my career 😅:

Step #1: Set goals

Set SMART goals—specific, measurable, and realistic.

I had a simple written goal: Become the go-to dev for this product.

Fast forward to today, I am the dev lead for that product.

Having that goal gave me clarity and direction.

Step #2: Track your progress

Without tracking, goals are just dreams.

Make sure you’re doing something each day that moves you toward them.

Step #3: Share your goals

Let your manager and teammates know what you’re aiming for.

They can’t help you if they don’t know what you care about.

Once you share your goals, people will start forwarding you the right projects—and stop handing you stuff that doesn't align.

Step #4: Evaluate tasks through your goals

Now that you know where you’re headed, filter your tasks through that lens.

If something doesn’t move you closer, either:

Delegate it
Or knock it out quickly and move on

Step #5: Take initiative when the path isn’t clear

Sometimes, no task or project helps you grow in the way you want.

That’s okay.

But don’t stay stuck.

You can:

Push for new projects or initiatives
Switch to a better-fit team
Or, if needed, change companies entirely

Step #6: Copy what works

Working with great colleagues? Lucky you.

Watch them. Steal Copy their playbook.

If someone’s doing what you want to be doing, study how they act, what they prioritize, and how they communicate.

Then try those things at your level.

It works.

Summary

If you landed a job in tech—congrats 🎉

You earned it.

But don’t get stuck in “grateful mode.”

Don’t use that as an excuse to take every task, say yes to everything, or never question the direction you're headed in.

Be intentional. Be strategic. Own where your day is taking you.

Because especially in a world with AI and layoffs, you don’t want to wake up one day and realize you weren’t building the right skills.

Remember:

“When writing the story of your life, don't let anyone else hold the pen.”

How I Reduced My React Bundle Size by 30% (With Real Examples)

Ndeye Fatou Diop — Mon, 07 Apr 2025 13:50:00 +0000

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

Ever had this happen?

You start building a new frontend app.

Everything is fast. Production builds take seconds. Users are happy 🥰.

But as time goes on…

Build times start to drag.
The app feels slower.
Users complain.

You’re unsure why — you’ve just been writing “normal” code.

What’s going on?

99% of the time, it’s because your bundle size spiraled out of control.

In this post, I’ll show you 7 proven ways to reduce bundle size and speed up your builds — with a real demo you can try.

⚡️ Before vs After

By the end of this guide, we will go from:

📦 283.39 kB → 198.33 kB

That’s a 30%+ size reduction, just by applying simple tips.

🛠️ Setup

For this demo, I built a React app (generated with V0) available on GitHub:

👉 GitHub repo

Key details:

Run npm run build to bundle the app for production.
Each optimization step has a dedicated branch (step-1-remove-side-effects, step-2-remove-unused-files-packages, etc.).
The main branch contains the unoptimized version, and the fully optimized code is in the step-7-lazy-load-components branch.

💡 Note:

- Each step builds on the previous one: branch step-3-… includes fixes from step-1-… and step-2-…

- I’m using global CSS here (for speed). In real apps, prefer CSS Modules or tools like Tailwind.

Tooling

I used vite-bundle-analyzer to visualize bundle contents.

Here’s the initial bundle from the main branch:

Step #1: Eliminate Side Effects in Files

👉 Code changes

Bundlers rely on tree-shaking to exclude unused code from the final bundle—unless a file has side effects (see #Benefit 3 in my post about bundlers).

Side effects (like modifying the window object) force the bundler to include the file, even if unused.

🧪 Example:

In our demo, the file HelloWorld.js contains a side effect:

window.someBadSideEffect =
  "I'm a side effect and I will be included inside the bundle even if not used";

Result:

Even though the file isn’t used, its code appears in the bundle file (dist/assets/index-[hash].js).

Fix: Remove the side effect. The file is now excluded from the bundle.

Step #2: Hunt Down Unused Files & Packages

👉 Code changes

Unused files/packages usually don’t bloat your bundle—but they:

Slow down bundling (more files to process).
Risk breaking tree-shaking (if they contain side effects).

Tool Recommendation:

Run npx knip or npx depcheck to detect dead code.

In our demo:

HelloWorld.js and lodash-es were flagged as unused.
After removing them, the number of modules processed dropped from 44 to 42.

The impact would be more significant in more complex applications, and your app will build even faster ⚡️.

Step #3: Avoid Barrel Files

👉 Code changes

Barrel files (like src/components/index.js) consolidate exports for cleaner imports:

import { Dashboard, UserManagement, Settings, Clock } from "./components";

But they introduce downsides:

Side effects propagate: If any exported file has side effects, the bundler can include it. This is why the side effects were present in Step #1.
More files to process: The module bundler will have to process more (or even irrelevant files if someone forgot to delete them). This results in slower builds.

In my demo app, I removed all the barrels in the step-3-remove-barrel-files branch.

Result: The number of modules transformed went from 42 → 37.

Step #4: Export Functions Directly, Not Objects/Classes

👉 Code changes

When you export an object or class, all its methods are bundled—even unused ones.

In our demo app, the time.js file exports a utility object, but only getTimeInFormat is used. Yet, the entire object landed in the bundle.

Fix: Export functions individually. Now, unused utilities are stripped automatically.

Result: There is a slight decrease in the bundle size.

Step #5: Swap Heavy Libraries for Lighter Alternatives

👉 Code changes

This is a big one.

In the demo app, I used moment.js.

But if you check Bundlephobia, you’ll see it’s huge.

A better choice? dayjs — smaller and modern.

Swapping moment for dayjs gives you an instant bundle size drop.

Pro tip: Also check for ESM support—it helps with tree-shaking.

Step #6: Lazy-Load Non-Critical Packages

👉 Code changes

If a package isn’t needed immediately, don’t load it at startup.

Example:

I use Fuse.js for fuzzy search, but only when the user starts typing.

Solution:

Instead of importing it statically, I load it when needed using dynamic imports:

// Lazy load Fuse.js
const Fuse = import("fuse.js").then((module) => module.default);

Result: fuse.js splits into a separate chunk, reducing the initial load.

Step #7: [React] Lazy-Load Non-Critical Components

👉 Code changes

Same idea — if components aren’t needed at startup, don’t load them immediately.

In my demo, files like Dashboard.jsx and Settings.jsx are only required when the user clicks a button.

So I lazy-load them using React.lazy:

const Settings = lazy(() =>
  import("./components/Settings").then((module) => ({
    default: module.Settings,
  }))
);

Result: A smaller initial bundle, which results in faster first load of your app.

Bonus 🪄

A few more ideas you could explore:

Add "sideEffects": false in package.json to improve tree-shaking
Use Bundlewatch or Size Limit to monitor size in CI
Enable more code-splitting or compression with Vite plugins

✅ Cheatsheet

Quick recap of everything we did:

✅ Remove side effects from files  
✅ Delete unused files and packages  
✅ Avoid barrel files  
✅ Export functions directly  
✅ Use smaller libraries (dayjs > moment)  
✅ Lazy-load heavy packages  
✅ Lazy-load components

👉 Code changes

Summary

Frontend apps often get slower over time — even without adding “heavy” code.

But if you apply these tips regularly, you can stay fast, keep build times short, and make life easier for your team and users.

Got other tips? I'd love to hear them 🙂.

That's a wrap 🎉.

Leave a comment 📩 to share more tips.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

✨ Your Manager Should Never Have to Ping You

Ndeye Fatou Diop — Sun, 16 Mar 2025 13:37:58 +0000

On my first work assignment, I thought I was doing great work 😎.

I was talking to customers, handling their requirements, making them happy, etc.

However, to my surprise, my manager didn’t share my point of view.

She didn’t realize all the work I was doing and couldn’t articulate the value I was providing.

I was pretty shocked. I thought my work was speaking for itself.

We agreed that I would post a daily update in the team chat to keep them informed. I still didn’t see the need.

But hey, why not?

Fast forward to today—as a team lead, I totally get it 😅.

If I don’t hear from a junior dev on my team regularly, I start getting slightly worried that things are going wrong.

Even with meetings, it’s impossible to have an accurate picture of what everyone is doing unless they communicate it.

In this post, I’ll share why you must over-communicate as a junior dev—and how to do it properly.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

What Happens When You Don’t Over-Communicate

Imagine you ask your younger sibling (3-4 years old) to help you with something.

They’ve never done it before and have no experience.

How would you feel if they stayed silent the whole day?

Chances are, you’d feel uneasy—scared they might be doing something completely wrong (and your mom will kill you 😅).

Having a junior dev on the team can feel the same way 😅.

As mentors, our responsibilities are to:

Make sure they are doing as well as they can
Prevent them from going down rabbit holes
Ensure they don’t make mistakes and try to fix them in silence

So when a junior dev doesn’t communicate progress often, something feels off.

As a junior dev:

You should have multiple questions daily.
You should encounter blockers (and ask for help).
You should share progress frequently.

Even if you’re amazing and don’t need help, you should communicate progress at least twice daily (personal preference).

If you don’t, your mentors will feel stressed or have to ping you regularly.

As a rule of thumb: After the first few weeks, no one should have to ask you for status updates.

How to Over-Communicate Properly

This is as easy as it gets.

It depends on your circumstances:

If you sit next to your manager or team lead, talk to them periodically—ask questions, provide status updates, etc.
If you’re remote, send updates using your team’s communication channels (Slack, messages, etc.).

As a junior dev staffed on a task, you should:

Clarify how long the task is expected to take
Work your best to meet expectations by asking for help when needed

If you can split your task into smaller steps, that would be even better. This will clearly show that you’re actively working and making progress.

In general, communicate with your manager about:

Anything wrong—even if it’s not your fault (e.g., issues caused by another team that impact your work)
Anything blocking or bothering you

Communication doesn’t always have to be written. Opening pull requests and writing code are also ways to show progress.

Over time, you’ll have to communicate less because your manager will trust that you can work independently.

Caveat: My advice applies to someone in a healthy team—which has been my case for the past six years at Palantir. If that’s not your case, frequent questions may not be welcomed.

However, you should still communicate your progress regularly, even if it’s just: “I’m blocked by A and B, but I’m currently doing X and Y to get unblocked.”

Your Challenge This Week:

If you’re a junior developer, evaluate how often your manager has to ping you for an update.

If they regularly ping you, start giving them updates before they ask.
If they don’t, that’s a good sign—but it could also mean they don’t want to be intrusive or don’t care.

Either way, make sure you share daily progress on your tasks.

Summary

Even if you’re doing an excellent job as a junior dev, your main job is to reassure your manager/team lead by over-communicating.

Share updates as often as possible (at least twice daily).

The more you do this, the more trust you’ll build. Over time, you’ll have to do it less frequently 😉.

That's a wrap 🎉.

Leave a comment 📩 to keep the discussion going.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1897195388924494128-854'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1897195388924494128&theme=dark" }

✨ Module Bundlers, Demystified: What You Actually Need to Know

Ndeye Fatou Diop — Mon, 24 Feb 2025 14:00:00 +0000

When I first heard module bundler as a front-end developer, I thought, “What is that magic again?” 😅

I remember trying to read about them or even use one, but I didn’t see the usefulness.

All I knew was that every article recommended using module bundlers like Webpack—and setting them up was hell 🔥.

I later realized that they’re one of the most crucial parts of modern frontend development, and you absolutely need to understand them.

In this post, I’ll share what I wish I had known about module bundlers.

Let’s get started. 🚀

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

First, what do module bundlers do?

Let’s start with an example.

For this post, I made a React app called demo_bundling_esbuild (Github code).

It’s a simple app that displays my name, age, and other personal information. (I know it's it's a bit self-centered 😅)

It uses esbuild as a module bundler and is structured like this:

project/
├── src/
│   ├── App.tsx
│   ├── index.tsx
│   ├── data.json
│   ├── utils.ts
│   └── constants.ts
├── index.html
├── build.js
└── package.json

Once I finished development, I needed to build the app so I could have an index.html file to load in the browser.

This is roughly what the app looks like:

But then something interesting happens...

When I open my Network tab, I don’t see the same files as in my code editor.

I can see the index.html file, but where are App.tsx, index.tsx, and constants.ts? 🤷‍♀️

Instead, I see a single file: dist/bundle.js.

When I open it (see in this gif link), I find the content of App.tsx, index.tsx, and utils.ts—but in a weird/minified format.

So, what happened?

How did I go from 5 files (index.tsx, utils.ts, constants.ts, App.tsx, data.json) to 1 file (dist/bundle.js)?

How did all these files turn into a single big file?

👉 Bundling happened.

My module bundler (esbuild) took all the .ts and .json files and compiled them into one file: dist/bundle.js.

PS: You can find the configuration here 👉 build.js.

In summary:

Module bundlers are tools that combine multiple files in your codebase into fewer files.

And this is amazing for several reasons.

Why bundling is important

Benefit #1. It ensures your dependencies load in the correct order

If you’re using dependencies (i.e., npm packages), you probably import them like this:

import { partition } from "lodash-es";
import { v4 as uuidv4 } from 'uuid';

In the past, these imports didn’t work in all browsers.

Module bundlers solve this by ensuring that dependencies load correctly.

For example, if File A depends on File B, which depends on File C, the bundler makes sure all necessary files are present before execution.

Benefit #2. It reduces the number of HTTP requests

Without bundling, every file would need to be loaded separately.

Browsers limit the number of parallel network requests, so for large apps, this could mean waiting minutes (or even hours) just for files to download and parse.

Bundlers reduce the number of files (usually 1–2 for small apps), significantly speeding up the loading process.

Benefit #3. It optimizes the size of your files

Before bundling your files, module bundlers apply optimizations to make them as small as possible.

Some of the key optimizations include:

🌴 Tree-shaking: If you import a package but don’t use it, the bundler doesn’t include it in the final bundle. The bundler only consists of the code needed.
✂️ Minification: It removes unnecessary whitespace and comments and renames variables to make files smaller.

In our example app, I have a constant called NOT_USED_CONSTANT that I am importing inside index.tsx but not using. So it won’t be inside bundle.js.

Benefit #4. It enables dynamic imports (a.k.a. code-splitting)

Let’s say part of your app is only needed for specific users (e.g., a dashboard for logged-in users).

You don’t want to load everything upfront—you want to lazy-load that code only when needed.

You can tell your module bundler to “put some piece of code in a separate file and load it only when required.

When you do this, you increase your app speed 🚀 since there are fewer files to download.

Benefit #5. (Bonus) It supports different file types (.ts, .json, etc.)

By default, bundlers work with JavaScript files.

But they also support other formats (.ts, .json, .jsx, etc.) using loaders (Webpack, Esbuild, etc.)

Without this, you’d need to manually process these files before bundling them.

Do I need to know how to configure a module bundler?

👉 No.

Unless you’re very unlucky, you shouldn’t have to.

For this post, I asked v0.dev to generate the esbuild setup for me 😅.

In my professional life, I’ve never had to configure bundlers myself—our great infra team handles it.

If you don’t have an infra team, here are your options:

Use tools (like Vite) that configure bundlers for you.
Google how to do it (plenty of examples out there).
Ask AI (which is what I did).

What matters is understanding what bundlers do so you don’t get in their way.

Summary

Module bundlers (esbuild, Rollup, Webpack, etc.) are not hard to understand.

They take many files and output fewer files.

They’re useful because they:

✅ Ensure dependencies load in the correct order.

✅ Reduce the number of HTTP requests needed.

✅ Optimize file sizes for faster downloads.

✅ Enable code-splitting for better performance.

✅ (Bonus) Support non-JS files like .ts and .json.

So, pick a bundler, play with it, and see it in action.

In my next post, I’ll share tips to optimize bundle size.

That's a wrap 🎉.

Leave a comment 📩 to keep the discussion going.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1875150173443362895-292'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1875150173443362895&theme=dark" }

✨ How to Be More Confident as a Junior Dev—Even When You’re Overwhelmed

Ndeye Fatou Diop — Thu, 23 Jan 2025 08:48:18 +0000

Do you constantly look under-confident at your job and need to be pumped?

If yes, stop.

It’s OK to feel overwhelmed, but it’s not OK to constantly show it.

In this article, I will explain why it’s important to display confidence and how to achieve it.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

Why it is important to display confidence

Have you noticed how we are all attracted to confident leaders?

Because they are reassuring and look like they know where they are going.

Well, turns out confidence is not just a good thing for leaders.

It will also tremendously help you as a junior frontend dev.

Here are 3 reasons why:

Reason #1: The more confidence you display, the easier it is to trust you

Imagine you are sick 🥴.

You go to the hospital and have the option between two doctors for your treatment.

The first doctor talks confidently, speaks assertively and can reassure you while being honest.
The second doctor talks tentatively, hesitates a lot, and doesn’t give you a clear answer.

Which doctor are you more likely to choose?

If you’re like me and most people, you would choose the first doctor.

Because if someone doesn’t trust themselves, why should you trust them?

This also applies to you as a junior frontend dev.

If you don’t trust yourself and make this evident to everyone, it will be harder for others to trust you.

Reason #2: The more confidence you display, the more ownership you can get

Since you get more trust, you’ll also have more opportunities than a less confident dev.

And when you can turn these opportunities around, you get even more ownership.

Reason #3: The more confidence you display, the less effort it takes to reassure you

Unfortunately, people will generally try to comfort you when you show under-confidence.

This is OK in small doses.

However, if you consistently need reassurance, it could be tiring in the long term.

Time that could have been spent mentoring you is now spent comforting you.

This is rarely sustainable.

How to Build (and Show) Your Confidence

Displaying confidence is hard.

I know because I still have to force myself to do it after 5+ years of experience 😅.

However, you can use these 5 hacks to feel and look more confident.

Hack #1: Don’t bite more than you can chew

This hack is obvious.

However, it is easy to fall into this trap 🪤.

We generally fall into it because:

We volunteer for too many projects to show willingness
We volunteer for projects without knowing the scale or discussing with a more senior dev first
We suffer from people-pleasing and can’t say “No”

Unfortunately, when you bite more than you can chew, your confidence will take a toll since you are more likely to:

underperform on tasks and lose some of your confidence
overwork, which leads to tiredness and feeling overwhelmed
etc.

What to do instead:

Have a clear idea of your workload and make it clear to your manager
Only volunteer for projects you have 100% confidence in at the beginning, then be more audacious over time
Re-evaluate your workload with your manager regularly (and drop some tasks if needed)

Hack #2: Give yourself permission to ask for help

Whenever I felt under-confident, I wanted to do everything alone and didn’t want to ask for help.

As a result, I would get stuck and not ask for help 🤪.

This would undermine my confidence since I was expecting to do something, then realized I couldn’t.

A good remedy is to ask for help when you’re stuck after some time.

This is great because:

It stops the stress buildup since you’re forced to stop and interact with others
It helps you brainstorm with other people and feel less alone
It often enables you to realize the task was more challenging than you expected

Hack #3: Take regular breaks

After working long hours, your productivity drops, and further work can become counterproductive.

Your brain is tired, and you make more mistakes than actual progress.

Unfortunately, this can break your confidence since you keep spending time on the problem without progress.

The solution is simple: take regular breaks. At least one break every 90 minutes.

Unfortunately, this can be hard to do (at least for me 😅).

What helps is to:

Schedule catchups/meetings that force you to stop
Interact with your colleagues
Do something not related to coding, like code reviews

Hack #4: Track your achievements regularly

You may not realize it, but you’ve already achieved much as a junior frontend dev 👏.

Unfortunately, it’s easy to focus on what you don’t know instead of what you’ve learned.

This can undermine your confidence since you feel like you don’t know enough.

I have some good news: “None of us know enough. What we don’t know is way more than what we know.”

So don’t let this hold you back.

Have a place to track your achievements to see how far you’ve already come.

This will boost your confidence 💪.

Hack #5: Share experiences with your peers or discuss your journey with others

As soon as you talk with other junior devs or senior devs about their early experiences, you’ll realize that feeling overwhelmed is normal.

In fact, the tech space is fast-changing, complex, and varied.

It’s normal to feel overwhelmed initially, especially when navigating old code or completing your first tasks.

Instead of panicking, embrace the process 😌.

Expect discomfort to be part of the job.

Stay calm and learn.

Summary

Feeling overwhelmed as a junior frontend developer is normal.

However, just because you feel overwhelmed doesn’t mean you have to show it.

Instead, strive to display confidence so you get more opportunities and trust.

Ensure you don’t bite more than you can chew, build a support system, and interact with your peers.

I trust you’ll be successful 🚀.

That's it.

Don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

🐞 SPOT THE BUG

// Detect dark theme var iframe = document.getElementById('tweet-1879498832100442408-554'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1879498832100442408&theme=dark" }

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1879438387150811498-216'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1879438387150811498&theme=dark" }

7 Critical Pitfalls New Developers Must Avoid in Their First Weeks

Ndeye Fatou Diop — Tue, 14 Jan 2025 13:00:00 +0000

For the past 6+ years, I’ve worked across 5+ teams at Palantir.

I wish someone had warned me about these 7 mistakes at the start of my career.

Ready? Let’s get started.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

Mistake #1: Giving strong opinions about things you don’t fully understand yet

We want to prove our value during the first days of a job.

It’s natural to want to show your colleagues that you were worth hiring 😀.

However, this can lead to giving strong opinions on things you don’t fully understand yet.

Examples

Someone asks about testing → you proclaim, “It’s criminal not to have 100% coverage.”
Someone talks about state management libraries → you question why the team uses Redux and suggest Zustand.
The team decides to cut features to meet a deadline → you talk about how this would’ve backfired at your previous company, lost users, yada yada...

I can tell you right now: this will not land well 99% of the time.

Why?

You don’t have the full context, so your input is, at best, noisy and, at worst, counterproductive.
You waste your colleagues’ time as they argue or explain things to you.
You may come across as “show-offy” without realizing it. This isn’t the best way to make friends 😅.

So, should you keep quiet during your first weeks? Absolutely not.

You were hired to contribute to the team and share your perspective. However, make sure that:

You collect as much context about the team and product as possible—ask “why” first.
You don’t get too attached to your opinions. Present them as suggestions rather than hard truths.
You “show, don’t tell” whenever possible.

Mistake #2: Trying to figure out everything by yourself

Unless you’re the only person on your team, ask for help.

Ask after trying for a reasonable amount of time. What’s reasonable depends on the type of question:

If you’re sure you won’t find a solution even after an hour—or if the issue blocks your productivity—ask immediately. For example, you should ask questions like “How do I set up this computer to work with tests?” instantly.
If it’s a technical problem you can solve by Googling or using AI tools, try that first. If it doesn’t work, ask for help after 30 minutes.

Why ask for help?

You don’t know what you don’t know.
Time spent figuring out what others already know is time you could spend on productive work.

If you’re in an environment where help isn’t readily available, you’ll have to figure things out.

Make sure to document your findings for the next person. This builds a knowledge base and earns you “good teammate” points.

Mistake #3: Focusing too much on onboarding and ignoring your colleagues’ work

I’m super introverted 🙈.

So, I find it hard to reach out randomly to new people.

However, whenever I’ve joined new teams, I’ve forced myself to talk to teammates—and it’s always paid off.

How?

Onboarding felt less intimidating when I realized my colleagues were normal people willing to help.
I gained valuable context and understood what mattered most to the team.
I built a network of people I could turn to for support.

So, as soon as you join a new team, set up 1-on-1 meetings with teammates.

Ask them about their work, the team’s history, how they see their role, and any advice they might have.

Mistake #4: Trying to memorize everything

On my first team, I felt super lost 😅.

People used acronyms in meetings, and I struggled to follow conversations. Even when I knew some of the acronyms, I still felt overwhelmed.

I tried to memorize everything.

But this was pointless.

Everything will eventually become second nature. It’s normal to feel overwhelmed at first.

The key is to keep asking clarifying questions.

Over time, you’ll understand things better and build muscle memory.

Mistake #5: Complaining excessively about your team systems

No codebase is perfect.

No team is perfect.

Books and blogs often give the impression that:

Everyone should use the latest libraries or frameworks.
All legacy code should be refactored.

When you land on a team with different practices or “messy” code, you might start complaining.

You might even make a list of everything that’s “wrong.” 🤦‍♀️

This is the worst way to start a new job.

Unless you were hired to overhaul the team and its processes (and even then), don’t do this.

Why?

You’re implying that the team is “poor” for missing things.
You’re adding unsolicited work for your colleagues.
You’re alienating people who built the systems without understanding the constraints they faced.

Instead, have a positive attitude:

Look for ways to provide value.
Show, don’t tell: introduce better patterns in your pull requests.
Open technical discussions with the team.

If you’re unhappy with the systems, consider interviewing elsewhere 😌.

Mistake #6: Attempting to refactor code without context

I’ve made this mistake.

I wanted to provide value, so I refactored code without being asked.

It didn’t go as well as I hoped.

Later, when someone joined the team and refactored my code without asking, I got a taste of my own medicine 😅.

Refactoring someone’s code without context can feel like an attack. It’s like someone spoiling your art.

Don’t @ me: I know this is not healthy😅.

Why it’s a problem:

You miss the context for why the code exists.
You overlook more essential tasks.

Instead, only refactor code if:

Someone asks for help.
You can integrate the refactor into meaningful work (e.g., a pull request).

Mistake #7: Setting unrealistic expectations

Don’t work 12–14 hours a day during your first weeks unless you plan to do so long-term.

It might seem like a good idea because:

You want to prove your value.
You feel there’s too much to learn.
You’re on probation.

But this can backfire:

It sets unrealistic expectations for your team. Scaling back later could create friction.
It’s unsustainable and might lead to burnout.

Instead:

Meet the team’s expectations first.
If you want to do more, ensure it’s sustainable and beneficial.

The first weeks are a grace period. People expect you to learn, not to immediately deliver value.

That's a wrap 🎉.

Onboarding is challenging.

But some mistakes can make it far worse:

Sharing strong opinions without context.
Taking actions without context.
Not leveraging your colleagues.

Avoid these mistakes, and you’ll settle into your new team quickly.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

💡 TIP OF THE WEEK

// Detect dark theme var iframe = document.getElementById('tweet-1877747297402142883-419'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1877747297402142883&theme=dark" }

🍔 FOOD FOR THOUGHT

// Detect dark theme var iframe = document.getElementById('tweet-1876901704563872142-960'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1876901704563872142&theme=dark" }

DEV Community: Ndeye Fatou Diop

29 React Codebase Red Flags from a Senior Frontend Developer

1. 🚩 Using libraries for what vanilla JS can do

2. 🚩 Reaching for heavy dependencies when lighter alternatives exist

3. 🚩 No linter or formatter configured

4. 🚩 No consistent folder structure

5. 🚩 Junk drawer utils files

6. 🚩 Related files not colocated

7. 🚩 Barrel files that re-export everything

8. 🚩 God components

9. 🚩 Passing entire objects when only one field is needed

10. 🚩 Storing derived values in state

11. 🚩 Using state when it should be a ref

12. 🚩 Putting everything in a global store

13. 🚩 A single massive Context that re-renders half the app

14. 🚩 Poor TypeScript hygiene

15. 🚩 eslint-disable to silence the exhaustive-deps warning

16. 🚩 Using array indices as keys

17. 🚩 Using a hook when a plain function would do

18. 🚩 Rolling your own data fetching layer

19. 🚩 No error boundaries

20. 🚩 Empty catch blocks

21. 🚩 No loading or error states

22. 🚩 Accidentally breaking memoization with default values

23. 🚩 Unreadable conditional rendering

24. 🚩 No early returns

25. 🚩 Magic values with no explanation

26. 🚩 The same conditional logic scattered everywhere

27. 🚩 No abstraction layer over third-party libraries

28. 🚩 Massive files nobody dares refactor

29. 🚩 Not memoizing context values

Devs: Own your growth — or regret it later

What it means to own your growth as a dev

Why it’s essential to own your growth

Reason #1: “If you don't set goals, you will always work for someone who does.”

Reason #2: Working toward your goals brings you more supporters

Reason #3: Owning your growth gives you more credibility

Reason #4: Other people are also trying to figure it out

Reason #5: Having clear goals helps you adjust when things change

How to own your growth

Summary

✨ 17 React Hooks That Power 90% of Modern Components

1. useState

2. useReducer

3. useContext

4. useEffect

5. useRef

6. useMemo / useCallback

7. useLayoutEffect

8. useSWR / useQuery

SWR

TanStack Query

9. useSelector, useDispatch, or other state hooks

10. useNavigate

11. useBoolean

12. useCopyToClipboard

13. usePrevious

14. useDebounce

15. useMediaQuery

16. useResizeObserver

17. useLocalStorage

Summary

✨ 7 Things I Do Regularly as a Senior Frontend Developer

Habit #1: Educate yourself outside of work

Habit #2: Work on different projects and skills every month

Habit #3: Get enough rest

Habit #4: Stay in touch with what’s happening in the frontend world

Habit #5: Review code regularly

Habit #6: Teach back what you learn

Habit #7: Avoid tutorials and copy/pasting

Summary

✨ Don’t do this (unless you want sh*t frontend code)

Mistake #1: Using too many global variables

Mistake #2: Poor variable and function names

Mistake #3: “God” functions

Mistake #4: Functions with many same-type params

Mistake #5: Not cleaning up resources

Mistake #6: Unit-less variables

Mistake #7: Nesting conditionals >3 levels deep

Mistake #8: Hardcoding URLs or config in the code

15. 🚩 `eslint-disable` to silence the exhaustive-deps warning

❌ Avoid `any`