DEV Community: Richard Dillman

Why Your React Component Is a Hot Mess (and How to Fix It)

Richard Dillman — Wed, 25 Jun 2025 17:27:44 +0000

Writing React components is kind of like doing laundry. Sure, you could toss everything in together and hope for the best… but you'll probably end up with pink socks and runtime errors. A clean, consistent order inside your functional components helps your code stay readable, maintainable, and most importantly, not broken.

React’s Rules of Hooks are like those “do not put metal in the microwave” warnings. They exist because someone did put useEffect inside a for loop, and things caught fire.

Let’s walk through a solid, time-tested order for organizing logic inside a functional component. You won’t always need every section, but knowing the ideal flow can save you from future debugging-induced hair loss.

Why Hook Order Matters

React tracks hooks by position, not by name. Think of it like calling roll in class, if someone swaps seats, the teacher starts marking the wrong student absent.

If your hook order changes between renders (say, putting a hook inside an if statement), React gets confused. Confused React is not fun React. You’ll likely see this cryptic gem:

React has encountered a hook call that is inconsistent with previous renders.

1 Hooks - Built-in (useState, useEffect, etc.)

Why they go first:

React’s built-in hooks need to run in the exact same order every time. No surprises, no detours, no mystery meat. Putting them right at the top ensures everything is predictable and in line with React’s rules.

function ExampleComponent() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState("Guest");
}

Think of this section as the “meet the characters” part of a movie. Everyone’s introduced early, so the plot (i.e., the render) makes sense.

2 Custom Hooks

Why they’re next:

Custom hooks are like those helpful friends who show up with a toolbox and a pot of coffee. They usually rely on built-in hooks, so we want the foundation laid before they come in and start tightening bolts.

const user = useUser();
const theme = useTheme();

Stacking them under the built-ins gives you a nice clean "hooks zone" where all the magic starts.

3 Derived Data (from props or state)

Why it goes here:

Once you’ve got your raw ingredients (props, destructured props, and state), it’s time to prep them. Derived variables are like chopping onions, not exciting, but necessary before you start cooking the actual dish.

const { user } = props;
const isLoggedIn = Boolean(user);
const displayName = user?.name?.trim() ?? "Anonymous";

Put these right after hooks so you’re always working with declared and up-to-date values.

4 Callbacks (useCallback, useMemo, useRef, etc.)

What now:

Callbacks and memoized values depend on state or props, and you want them nicely memoized before you start rendering or passing them down. Think of this as labeling your leftovers before you put them in the fridge.

Note: If it can be easily done, move these outside the component, but if they rely on the hooks or modify them, don't.

const handleClick = useCallback(() => {
  setCount((prev) => prev + 1);
}, []);

Keeps things neat. Prevents unnecessary re-renders. Your future self will thank you.

5 Effects (useEffect, useLayoutEffect, etc.)

Why are they down here:

Effects are the "cleanup crew" running after shadow dom has been generated the browser. Effects are hooks so order still matters. Even if you wind up not needing a hook it is still counted. They need to be after other types of hooks, or data, but before any conditional logic.

useEffect(() => {
  console.log("Component mounted or count changed");
}, [count]);

6 Conditional Logic (Conditionals, loops, fragments, etc.)

Why it's here:

Before React can draw the UI, you might need to make decisions, like whether to show a login prompt or a dashboard. This is where that logic lives.

Critical rule:
Never put conditionals above your hooks. That’s how you get runtime gremlins.

if (!isLoggedIn) {
  return <LoginPrompt />;
}

const items = [1, 2, 3].map((item) => (
  <li key={item}>{item}</li>
));

This section is your last prep before serving the dish.

7 Return JSX

Why is this last:

It’s the final product! The visual output. The “ta-da!” moment. This is what the user sees, and it should be the last thing, after all your setup work.

return (
  <div>
    <h1>Hello, {displayName}!</h1>
    <button onClick={handleClick}>Click me ({count})</button>
    <ul>{items}</ul>
  </div>
);

Final Thoughts

React won’t force you to follow this order, but following a logical structure helps future-you (or your teammates) understand what’s happening and reduces the chance of hook-related surprises.

Want to enforce it automatically? Tools like ESLint (with eslint-plugin-react-hooks) and Prettier can keep your components nice and tidy.

Working with an LLM like Claude or ChatGPT? Add this structure to its coding style guide so your AI pair-programmer doesn’t throw spaghetti at your component tree.

Bonus dad joke: What do you call a TV vaccination?
A screenshot.

Hero Image Optimization Techniques

Richard Dillman — Tue, 17 Jan 2023 06:17:55 +0000

Page speed is essential in determining a website's user experience. If a user can’t experience the content, they’ll bounce. A site's ideal complete load time is below 2 seconds. Studies show that most users will abandon the page within 3 seconds. You can also expect a 1.3% increase in that abandonment for every additional 100ms. For this reason, Google rates page speed quite heavily for SEO, and Google's Search Console provides a report on LCP, which can help website owners understand and improve the loading performance of their pages.

Reasons why page speed needs to be a key KPI:

you want your page to rank well in organic searches
you want your ads to perform
you don’t want users abandoning your page out of frustration

Fortunately, a lot of low-hanging fruit can make a big difference in getting started. Following are some issues that I see a lot and have pretty straightforward ways to address.

Measuring page speed

One of the key metrics used to measure page speed is the Largest Contentful Paint (LCP). The LCP measures the time it takes for the largest content element visible in the viewport to load and render. Therefore, optimizing the hero image can improve LCP and web page speed. Your goal is to have LCP occur as quickly as possible. Google has defined this as within 2.5 seconds or faster measured from the start of page load.

We should always strive to set the hero image src in the initial HTML payload to reduce the length of the critical request chain. Some frameworks will add the src via Javascript or CSS. However, this will always take additional time.

The file size

One way to speed up the hero image is to reduce its file size through compression. You could also use a tool like ImageOptim, or NextJS’s Image Component. Additionally, a next-gen image format like WebP, available for all modern browsers, can significantly reduce the file size without sacrificing quality.

A content delivery network

Another way to improve the LCP is to use a Content Delivery Network (CDN) to serve the hero image. A CDN is a network of servers distributed around the world. It can significantly reduce the time it takes for file delivery by serving it from a geographically closer server.

Specify native height and width

Images should always have both height and width tags to allow the browser to calculate the aspect ratio. These should be the native size of the image while allowing CSS to set the actual rendered size. Adding the height and width allows the browser to hold this space open for the image; therefore, the page will not shift when it loads, allowing the measurement to take place more quickly.

Example of using the height and width:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    alt="Hero Image."
/>

The srcset and sizes attributes

A more responsive image optimization is to use the srcset and sizes attributes. These attributes allow you to provide different versions of an image for different screen sizes and resolutions and can significantly reduce the amount of data on smaller devices or lower-resolution screens.

Example of using the srcset and sizes:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    srcset="
        hero_400px.jpg 400w,
        hero_800px.jpg 800w,
        hero_1600px.jpg 1600w
    " 
    sizes="(max-width: 600px) 100vw, 50vw" 
    alt="Hero Image."
/>

The loading attribute

The loading attribute can prevent or encourage the browser’s loading order. The loading attribute can be set to lazy or eager, depending on the use case. “Lazy” loads the image when it becomes visible in the viewport, while eager loads the image immediately when the page is loaded, whether or not it’s in the viewport.

Example of using the loading attribute:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    loading="eager"
    alt="Hero Image."
/>

You can add the loading attribute with a value of “lazy” to other images on your page when they should not load early. Slowing these items down helps speed up the rest of the assets. Lazy images are requested immediately if they are within the viewport. Outside the viewport, they are delayed and only fetched when approaching it.

The link tag with preload

A link tag with the preload attribute tells the browser about critical resources before encountering them in HTML. So, for example, you can use preload to increase the download priority of late-discovered Hero images, especially if they load via Javascript or CSS.

Example of using the link tag:

<link rel="preload" as="image" href="hero-image.jpg" />

If you are already using the srcset in your hero’s image tag, you can also use that here in the link tag and ensure that the correct size image is selected.

Example of using the link tag with a responsive image:

<link
    rel="preload"
    as="image"
    href="hero-image.jpg"
    imagesrcset="
        hero_400px.jpg 400w,
        hero_800px.jpg 800w,
        hero_1600px.jpg 1600w
    " 
    imagesizes="(max-width: 600px) 100vw, 50vw"
/>

The fetchpriority attribute

You can use a fetchpriority attribute to do the same thing as a link preload, although you will have to wait for the processor to discover the image tag. A priority hint can adjust the loading order of assets such as images, CSS, iframes, scripts, and fonts. So the Hero can be requested before other lower-priority assets.

Example of using the fetchpriority attribute:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    fetchpriority="high"
    alt="Hero Image."
/>

Putting it all together

Using all the resources we have learned, we can apply them all to receive an optimal loading path.

Example of using all the tools:

<head>
    <link
        rel="preload"
        as="image"
        href="hero-image.jpg"
        imagesrcset="
            hero_400px.jpg 400w,
            hero_800px.jpg 800w,
            hero_1600px.jpg 1600w
        " 
        imagesizes="(max-width: 600px) 100vw, 50vw"
    />
</head>
<body>
    <img
        src="hero-image.jpg"
        height=”400”
        width=”400”
        srcset="
            hero_400px.jpg 400w,
            hero_800px.jpg 800w,
            hero_1600px.jpg 1600w
        " 
        sizes="(max-width: 600px) 100vw, 50vw" 
        alt="Hero Image."
        loading="eager"
        fetchpriority="high"
    />
</body>

Optimizing the hero image is essential in improving the LCP and web page speed. Applying the above techniques can get your site dramatically closer to that 2.5 seconds goal!

Head tags organized

Richard Dillman — Thu, 14 Jan 2021 20:41:48 +0000

Order (still) matters

A minimal number of tags are allowed within the HEAD of HTML documents. Those tags are title, style, base, link, meta, script, and noscript. Oddly enough, these elements’ order can drastically alter the loading of your document and its dependencies. Here are some things I have discovered trying to scratch out better performance within the sites I work on.

1: Character Encodings

The meta tag for the charset declaration should fit entirely within the first 1024 bytes of the file. If the charset is included later in the code, the HTML will be re-parsed once encountered, wasting precious time before rendering anything. So always put it first. The same reasoning applies to the viewport and other meta tags that describe how a page should render.

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">

2: Title Tag

The title tag’s purpose is to declare the name of the document. It will replace the URL within the browser's tab, so it is good to place it as early as possible to avoid confusion if the user notices when the tab name updates.

<title>Page Title</title>

3: Preconnected Links

Here we are focused on third-party domains that we know for sure will be requested. Preconnect will handle the DNS lookup, navigate the connection, and any redirects necessary to reach the targets. It will not download any content. Requesting these connections is particularly helpful on slow connections to establish the route as early as possible. However, this can be costly for mobile devices as multiple connections can consume unnecessary bandwidth. Only preconnect to servers you are certain will be needed, such as analytics, your CDN, or your static asset site.

<link rel="preconnect" href="https://www.google-analytics.com" />

4: Synchronous Scripts

Synchronous scripts include any JavaScript that must run before the page renders, such as populating the dataLayer. Here we include script blocks and external scripts but not deferred or async ones. No matter where it is, any script in the head will block applying CSS, even after the CSS. The browser must process anything that might modify the DOM before processing your styles. So you should add those synchronous scripts before your style sheet.

<script>...</script>
<script src="app.js"></script>

5: Synchronous CSS

This includes inline style blocks and style sheets that are used for rendering. Consider using media queries and breaking your styles into multiple files. The media attribute will let the browser know if this CSS is going to be render-blocking or not.

Inline styles are parsed first. It is important that we remember that styles are parsed as they are encountered.

<style>...</style>

External files are requested and parsed next.

<link href="style.css" rel="stylesheet">

Next to be requested and parsed are the styles with media queries. If they match your current breakpoint, orientation, or pixel density.

<link href="other.css" rel="stylesheet" media="(min-width:768px)">

Next up for request and parsing are the print style sheets.

<link href="print.css" rel="stylesheet" media="print">

Stylesheets with media queries that do not match the current environment will not be requested.

<link href="other.css" rel="stylesheet" media="(min-width:1024px)">

Knowing this, you can also trick the browser into loading non-critical CSS a bit later with the onLoad method. By pretending this is a print sheet, it will load after all other CSS but before any containing media queries. Once its load event fires, the media changes to all. With this being async, that will happen after the DOM has been parsed and images begin loading.

<link rel="stylesheet" href="lazy.css" media="print" onload="this.media='all'">

6: Preloaded Links

We should preload as few files as possible. These should be visual elements that are required for above the fold rendering. This includes items like fonts, hero images, or icons. As for fonts, you most likely only need the woff2 version. Also, consider loading the fonts from your own server.

<link rel="preload" as="font" href="font.woff2" type="font/woff2" />

7: Asynchronous or deferred Scripts

All other scripts[?] requested, such as those that add interaction handlers, go here. We should put these at the bottom of the body to allow for quicker parsing of the DOM. But if you must put them in the head due to CMS or framework restrictions, place them here, and set them to either async or defer depending on your need.

<script src="foo.js" async></script>
<script src="bar.js" defer></script>

8: Prefetched Links

These are assets that you know for sure you will need later within this page's render cycle. This includes things that you want in place before they are needed. This could include logos in the footer, Twitter feeds, or videos.

<link rel="prefetch" href="jwpplayer.js" />

9: Prerendered Links

Entire content pages that you are reasonably certain that your user will visit next. You can download the assets for that page before it is even requested. I would render things like login, search, cart, or the next page in a series.

<link rel="prerender" href="/search/" />

10: Non-rendering assets

This includes meta tags and scripts that do not affect rendering in any way, such as OpenGraph, manifests, structured data. These tags are for bots and sharing in social media but are not necessary to render the page. To include a script in this spot it must be inline as this content will be inspected in the first pass through the document.

<link rel="shortcut icon" href="icon.png" />
<link rel="apple-touch-icon-precomposed" href="icon.png" />
<meta name="apple-mobile-web-app-title" content="Company Name" />
<link rel="canonical" href="https://companyname.com" />
<meta name="twitter:card" content="summary">
<meta name="twitter:image" content="icon.png">
<meta name="twitter:description" content="">
<script type="application/ld+json">
{
  "@context": "https://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

Those are the most common tags that could be in your head. Do you wonder about any not listed here? Bring them up in the comments, and let’s discuss!

Creating readable names

Richard Dillman — Thu, 14 Jan 2021 20:41:22 +0000

I have seen a proliferation of easy meaningless words that look like documentation but explain very little. Naming is one of our most challenging problems. The importance of meaningful names cannot be overstated and should not be an afterthought. Attention to naming increases code readability and trust. Well-named methods and variables are more likely to be reused, and creating reusable code is the purpose of creating shared libraries.

Combining words

Camel: (camelCase)
Kebab: (kebab-case)
Pascal: (PascalCase)
Snake: (snake_case)
Screaming Snake: (SCREAMING_SNAKE_CASE)

Each language has its preferred cases for various things. Always follow the lining standards for your language. I use JavaScript and Python so here are those.

Javascript

Camel: variables, methods, and functions
Pascal: types, classes, and constructors
Screaming Snake Case: global immutable constants

Python

Snake Case: variables, methods, and functions
Pascal: types, classes, and constructors
Screaming Snake Case: global immutable constants

Meaningless words:

Never use the following words. They add no meaning to the name and can always be replaced with a better, more specific term.

code
data
meta
mutate
parse
payload
transform
util

Consider the difference between two methods called getArticle and getArticleData. As an outsider reading that API, if there is nothing else known about those methods, it would be very difficult to know which one to use in each situation. The word data is adding no information.

One could say that people should just read the documentation if they want to know the method details. getArticleData becomes tough to understand when nested within other functions.

For example:

function getAuthors(id) {
  const data = service.getArticleData(id);
  const article = service.getArticle(id);
  return article.getAuthors(data);
}

Although we can see this method is supposed to get the authors of an article, the internal logic is difficult to read because it is unclear what the internal methods do. The word Data doesn't add enough meaning to warrant, adding it to the name.

Consider the difference between the three methods mutate, transform, and parse. Having not read the implementation of those methods, you can not know the convention for what these words mean within the context of the project. It is challenging to see the purpose of those methods or the order in which they should be used.

For example:

function getArticle(uri) {
  return Article.fetch(uri)
    .then(mutateAuthors)
    .then(parseAuthors) // bug: authors should have been parsed before being mutated
    .then(transform);
}

Although it is evident that this method gets an article (of some unknown state and type), finding bugs with the ordering or functionality of this method is impossible without resorting to debugger statements or console logs. It is forcing the developer to run the code to understand the expected values between each step.

Obfuscation

When the purpose of the function or variable name is to hide or limit understanding (i.e., black boxes, facades, moderators), then obviously this does not apply. The words referred to here as having low informational value may be useful in those cases where we're deliberately trying to hide.

For example:

return getArticle()
  .then(applyTransformations(options));

In this case, we're deliberately hiding what the transformations are behind a layer of obfuscation or abstraction. There are many reasons this is valuable, including preserving the right to change the contents of the functionality in the future dramatically.

Acronyms, Initialism, Abbreviations, and Disemvoweling

Shortened words are a constant source of confusion. It is generally better to enter the full name and not the abbreviation, but there are cases where it would be redundant to do so, as in the case of well-known acronyms like AMP or HTML. In this case, stick to the camel case and only capitalize the first letter of the acronym, especially when the initialism is beginning.

Single Characters

Single-character names should be avoided, even within a loop where the temptation to use an “I” for the iterator. Think of the group you are looping over. Doesn’t the following make a lot more sense?

for (const dog in dogs) {
  console.log(`${dog}: ${dogs[dog]}`);
}

Better Verbs:

get: Retrieve some state.
set: Change some state.
reset: Reset some state to its default value.
add: Add new content to some state.
remove: Delete some existing state.
apply: In-memory replacements
compose: Create a new dataset from existing information.
fetch: Retrieve some state from an external data store.
handle: Deal with an action. Often used in callbacks.
is/has: A pre-verb to denote a boolean.
$: A pre-verb to indicate a JQuery reference.

Duplication

Any named item that is a child should not duplicate its parent name, nor should it repeat any synonym of that patents name. In the following example, we see breakpoints. We know that breakpoints refer to widths, and as our project is mobile-first, we know they are all minimum widths.

BAD

$breakpoints = {
  minWidthLg: “1440px”,
  minWidthMd: “1200px”,
  minWidthSm: “992px”,
  minWidthXs: “768px”,
  minWidthXxs: “500px”
};

GOOD

$breakpoints = {
    xl: “1440px”,
    lg: “1200px”,
    md: “992px”,
    sm: “768px”,
    xs: “500px”
};

Classes

Classes must be named with an appropriate proper singular noun in PascalCase, and tell us that this variable contains a type with properties and methods.

class Animal { }
class Dog extends Animal { }
class Dachshunds extends Dog { }

Class Methods and properties

Class methods and properties use the verb + noun convention, but the methods can get away with omitting the noun in some cases. In this case, the noun is the parent class. User.get() assumes you are getting the user User.name assumes a user name.

Dog.getName()
Dog.setColor()
Dog.wagTail()

Numbers, Strings, and Objects

Name all Numbers, strings, and objects with the most appropriate singular noun.

Booleans

The names for booleans are in the form of a question, asking what it is or has or can be. So our verbs are: is, has, can, or will.

Arrays

Name arrays with a plural noun, allowing us to address each child as a singular noun. If need be, you can replace plural with a collection name birds becomes flockOfBirds.

Functions

Functions are always actions. So we start with a verb then add a noun. Verb + Noun results in a command for a thing.

getBirds();
goHome()

Some languages have their own rules around specific types of things (TypeScript prefers interfaces begin with a capital I). I am mostly interested in language-agnostic naming. Do you have any preferences around naming? Bring them up in the comments, and let’s discuss!

Operation Code at The Muse

Richard Dillman — Fri, 25 Sep 2020 15:58:21 +0000

This spring we were honored to connect with Operation Code to host their April Meetup. Operation Code is a non-profit organization serving America’s veterans and their families to help them to sort out their next steps after their service - or sometimes, while they’re still serving. Helping people to find their passions and turn them into fulfilling careers is exactly what we do at The Muse, and we were delighted to pitch in. This being Operation Code, Engineering and Product were particularly excited to get involved.

How do you transition into the civilian workforce as a developer? Senior Application Engineer Richard Dillman moderated a panel of Musers to explain how to master the technical job search, and how to maintain that success once hired. Director of Talent and Acquisition Lillian Landrum shared how candidates can stand out in the selection process. Manager of Client Project Management Danielle Incontrera discussed how people on the technical side can more effectively communicate with product about goals and timelines. Account Manager Christina Giordano explained how engineers help in both sales and client acquisition at The Muse.
Director of Engineering Peenak Inamdar fielded questions on what skills developers need to have on his team and how we at The Muse determine if a candidate’s skills meet those needs.

Following Peenak’s remarks, Associate Product Manager James Mayr gave a presentation on Google Tools for Product and Engineering, an overview of how developers can use Google tools such as Optimize, Analytics, Tag Manager, Lighthouse and Google Search Console to monitor site performance, dynamically add or modify content, and develop approaches to increase speed and reliability. We spent quite a bit of time on accessibility and usability too.

Afterwards there was more pizza and more networking amongst all, with the most popular topic being breaking into the developer role as a fresh code camp graduate. Our conversation carried well past our 9PM target with some of us not leaving until well past 10.

Meetups and Operation Code are both great ways to meet people you otherwise might not, learn new skills, and possibly make a connection for a new career.

Check out the full video of the event

How to write a readable commit message.

Richard Dillman — Sun, 09 Aug 2020 05:43:19 +0000

Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier.

Subject

The subject should be around 50 characters or less. You want it to fit in an email subject line. If you need to explain why you made some decisions or tradeoffs, those comments should be in the code.

An adequately worded commit should fit grammatically into the sentence below:
- If applied, this commit will [Subject]
Use an imperative mood. These changes will not be applied right away
Capitalize the first letter
No punctuation at the end
Consider using a conventional commits prefix like karma:
- feat: a new feature for the user, not a new feature for a build script
- fix: bug fix for the user, not a fix to a build script
- docs: changes to the documentation
- style: formatting, missing semicolons, etc.; no production code change
- refactor: refactoring production code, e.g., renaming a variable
- test: adding missing criteria, refactoring tests; no production code change
- chore: updating grunt tasks etc.; no production code change
A scope or section of the codebase can optionally follow the prefix

Instead of writing down everything you did, think of each commit as a command. These are instructions to your future self. Git will apply your commits to the codebase, not you, and only once the PR is approved and merged.

git commit -m "feat(login): Add a google OAuth endpoint"

Body

If you need to offer more information within your commit (code examples, external references, documentation, explain complexity), you could do it here. But most times, this information belongs either in the code or the final pull request. Please keep this as short as possible. It is not a blog post. Focus on the following:

Give the reasons why you made this change
Explain the way things worked before this change (and what was wrong with that)
Describe why you decided to solve it the way you did
Describe how the code works differently now than it did before

git commit -m "feat(login): Add a google OAuth endpoint" -m "This includes the handler, routes, and templates."