Persson Dennis RSS

10 Tips To Get More Readers on DEV

dennis@perssondennis.com (Dennis Persson) — Mon, 04 Jul 2022 00:00:00 GMT

1. Pin Post to Your DEV Profile

You can pin articles to your profile page, it will pin above your other articles. To do so, go to your dashboard and click the Manage button beside the article you want to pin. You will find a Pin to profile button there.

Pin to profile is available under dashboard > manage

From now on, you can pin your most popular posts to attract clicks from curious profile page visitors.

2. Target Beginners or Expert Readers

While you're at the Manage page mentioned above, there are another valuable feature you can use. It allows you to target users with a certain experience level so your articles can be shown to the people who are most likely to appreciate it.

Note that they also have some useful tips on that page to help you reach out to more readers, such as sharing your articles to Reddit.

There's always a target audience for your articles, make sure to specify it!

3. Syntax Highlighting for Code Blocks

Obviously, it's not unusual to post code on DEV, and DEV certainly supports syntax highlighting for different languages. Still, I once in a while see people posting code without syntax highlighting or posting images of code instead of using code blocks.

Neglecting syntax highlighting or using images for showing code is bad practice. This is because it's harder to read, difficult to copy-paste, and the browser can't scale the font size. Using an image also degrades performance and the code within the picture will not be searchable with ctrl f or on Google (text search).

With and without React syntax highlighting on DEV

To activate syntax highlighting, just specify which language the code consists of at the first line of the markdown code block. Available options include react, javascript, markdown etc.

You can tell markdown to highlight the code block according to React syntax

4. Add a Table of Content and Link to Headings

Like many other sites, DEV supports anchored links (also known as hashtag links) which links to specific headings in your article, or even another article. Unfortunately, they don't seem to have a UI that allows us to copy the anchor link.

To get the anchor link, you have to inspect the heading element in the web inspector to find it (right click on the heading and choose Inspect). You will find a zero-width link with the hashtag suffix you append to your article's URL. It's basically a kebab-cased version of the heading preceded with a hashtag, so you don't really have to copy it from the inspector every time.

You can find the anchor link in the chrome's elements inspector

You can utilize these anchor links in your DEV post to create a table of content like the one I have added at the top of this article. To do that, just add a regular link that refers to the anchor link for the heading you want to link to.

[Anchor link to "Add a Table of Content and Link to Headings"](#4-add-a-table-of-content-and-link-to-headings)

Anchor link above will output this link: Add a Table of Content and Link to Headings.

5. How To Choose Markdown Editor on dev.to

DEV has two different markdown editors. If you want to get rich on blogging, you need to choose the Rich + markdown editor. Just kidding, it doesn't ducking matter what you choose. But it can be good to know that they both exist, otherwise you may be confused when you google for something and the DEV UI doesn't look like in the guide you are looking at.

The two editors DEV offers are:

Rich + markdown
Basic markdown

If you don't know which to choose, just go for the rich one. The rich one contains some extra UI elements to choose tags and previewing your articles etc. With the basic markdown you have to specify title and tags etc. via Front Matter. You can find DEVs documentation for it here.

To switch editor, go to your account settings, choose Customization and scroll down to the title Writing.

I said I was kidding, the rich one won't make you rich!

6. Add a Canonical Link to Your Article on dev.to

I'm sure a lot of you already know this, but I still mention it because it's quite hidden and definitely the single most important feature if you additionally publish your blog posts to your own blog or other blog portals.

Read about why it's so important for SEO (Search Engine Optimization) on ahrefs site here, I won't go into details, but what it does is to avoid Google punishing you for posting the same content at different places.

How to add canonical links differs dependent on which markdown editor you are using. If you are using the basic markdown editor, you can do as it says in the Front Matter guide.

This is how you can specify a canonical link for a blog post

That also works for the rich markdown editor, but the rich markdown editor also allows you to specify a canonical link via UI. There's a discrete options button at the bottom of the create post page, beside the Save draft button, see the hexagon button in the image below.

This is how you can specify a canonical link for a blog post with the rich markdown editor

7. Report Articles if Someone Steals Them

Another quick tip related to the canonical link is to be quick to publish your articles on all sites at once if you publish it on multiple sites. If you wait too long with publishing your article someone may steal it and you can in worst case be banned from some blog portal for publishing articles that are available on other sites already.

Articles do get stolen a lot by automated sites. If you detect that someone has stolen your blog article, you can read about what to do in my guide here.

8. How To Make Series on dev.to

You may have seen that some people create series at dev.to. You do that in the same way as you add a canonical link. If it is your first time adding a series, nothing will happen when you create your article since there's only one article in the series.

Next time you create a new blog article you will see your previously series listed. When you choose an existing series, a series component will be added to all blog articles in that series. It will look as in the image below.

This is how a series are presented at DEV

9. How To Embed Videos and Instagram Posts on dev.to

Not very many people embed videos in their DEV posts, but it is doable by using liquid tags. You have DEVs docs for it here.

A YouTube video can be embedded either with the embed keyword or youtube keyword.

{% youtube 9Xd8xq06FCw %}

{% embed https://www.youtube.com/watch?v=9Xd8xq06FCw %}

Why you should add a video? Well, if you have some video that would need some attention it can be a good idea to include it in your DEV article. I'm sure you also can find good educational or funny movies to add to you blog post as well. Or why not embed on of your Instagram posts? The id to use in the embedded Instagram liquid tag is the last part of the URL to the post.

// Embed Instagram blog post by adding the post's id.
// Below embedding will embed the url "https://www.instagram.com/p/CfRzNd3seAC/"

{% instagram CfRzNd3seAC %}

10. Remind the Reader To Subscribe

Last but not least. Ensure that people know that your article is available on your blog and remind them to hit the like button and make a comment. This can be of course be interpreted as advertising, but in my opinion, it's a fair thing to do.

If you article is inspiring, the reader may get a lot of ideas and eagerly start processing thoughts and making plans. How cheerful the reader ever will be, he or she is not in an optimal condition for remembering to click with his finger on a heart or unicorn icon on a screen. And let's be honest, who will know you have your own website and try to find it if you don't link to it? Most (sane) people don't play hide and seek with strangers over the internet.

Bonus: Add a Summary

People have their own life to life, as stressful just as yours may be. Give them a chance to read through your article hastily. Here's my summary. A simple list of the tips, even if people will miss all details about how to do these things if they don't read the whole article.

Pin posts to your profile to promote your most popular articles.
DEV to supports targeting beginner or expert readers when managing an article.
Use syntax highlight for code blocks, never use an image to show code.
A table of content with anchor links to headings give a good overview.
You can choose either markdown editor, just be aware that dev.to has two of them.
Always add a canonical tag if you post your article to multiple websites.
Don't wait to post articles on multiple websites, they may be stolen.
DEV supports adding series, a good way to get people to read your old articles.
You can embed YouTube videos and other media in your article.
Remind people to subscribe and hit the like button!

21 Fantastic React Design Patterns and When to Use Them

dennis@perssondennis.com (Dennis Persson) — Sun, 24 Aug 2025 00:00:00 GMT

Design patterns aren't just for backend developers who can't say a sentence without mentioning architecture or code quality. Frontend developers can benefit from them too, especially in React where component composition and hooks provide perfect opportunities to implement solid React design patterns and improve code architecture.

This article covers 21 design patterns and principles that will make your React code more maintainable, testable, and scalable. Each pattern includes a brief explanation and practical examples of when and how to use them.

Core Design Patterns in React

These are the fundamental React design patterns that React is built upon. If you're writing React code, you're probably already using these patterns whether you know it or not. Sometimes we do good things even if we haven't read the book. These patterns form the bedrock of everything we build and are essential React best practices.

Lintlemore always codes by the book

Component Composition Pattern

Component composition is the very foundational React design pattern. It's the main way of thinking when writing React components, which is the very first design pattern you should read about when starting with React.

What the design pattern says is that an application is not a big monolith, it's a composition of tens or hundreds of components working together to form an application. Each component has its own reason to exist and can use, or be used by, one or several other components.

A component in this matter is essentially the same as a React component. Either a small leaf component in the component tree like a button, or a high-level component such as a whole page.

There are plenty of articles about component composition to find on Google and by GPTs, so I will not go into details here. But we will see in this article that a lot of the React design patterns serve their part to adhere to this pattern, where the Atomic Design Pattern might be the most obvious one. Every developer begins their journey with this fundamental pattern.

When to use: Always. This is the foundation of React development. I have sometimes seen React projects which barely use components and instead have a few large page-wide components. Doing that is to abuse React...

Custom Hook Pattern

If you have touched React, you probably have written some custom hooks. Doing that, means you are following the custom hook pattern, one of the most essential React best practices. If you aren't doing that, you are not writing proper React code.

Custom Hook Pattern means to lift out and encapsulate logic such as useEffects and useStates into custom hooks to abstract away the React logic in favor of readable hooks.

Too many React developers keep too much logic in their components, resulting in duplicated code, higher maintenance costs, and complex test cases. Following React best practices means separating concerns properly. The time it takes to break out logic from a component into a hook will almost certainly always save time.

Look at the component below, which fetches data from an API and renders it. It takes a brief moment to read it and understand it.

const PostsComponent = () => {
  const [posts, setPosts] = useState(null)
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState(null)

  useEffect(() => {
    const fetchPosts = async () => {
      try {
        const response = await fetch('/api/posts')
        const data = await response.json()
        setPosts(data)
      } catch (err) {
        setError(err)
      } finally {
        setLoading(false)
      }
    }

    fetchPosts()
  }, [])

  if (loading) return <div>Loading...</div>
  if (error) return <div>{error.message}</div>
  if (!posts) return null

  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>{post.title}</div>
      ))}
    </div>
  )
}

Now look at the same component below, but where the logic in the component has been lifted out to a hook.

// The hook's logic is easy to test
const usePosts = () => {
  const [posts, setPosts] = useState(null)
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState(null)

  useEffect(() => {
    const fetchPosts = async () => {
      try {
        const response = await fetch('/api/posts')
        const data = await response.json()
        setPosts(data)
      } catch (err) {
        setError(err)
      } finally {
        setLoading(false)
      }
    }

    fetchPosts()
  }, [])

  return { posts, loading, error }
}

// Main component is much easier to read
const PostsComponent = () => {
  const { posts, loading, error } = usePosts()

  if (loading) return <div>Loading...</div>
  if (error) return <div>{error.message}</div>
  if (!posts) return null

  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>{post.title}</div>
      ))}
    </div>
  )
}

Of course, it contains the same code. Except, this time, the usePosts hook name hints about what the useEffect and three useStates do, which made it a bit quicker to read.

And next time you re-use the usePosts hook for another component, you don't even have to read or write the code in that hook again.

At the same time, you now have a reusable hook which you only have to test once, and which is actually also very easy to test since it's a pure hook without any reason to check for what is being rendered.

If you test your UI components, the PostsComponent component might also need to be tested, and when doing that, you can simply mock the response of the usePosts hook instead of mocking the internals of the usePosts hook, such as the axios request, meaning that even the component test is now easier to write.

When to use: When you have reusable logic that multiple components need, or when your component is getting too complex. Potentially as a pattern to lift out logic from any component. Custom hooks is one of the most important concepts in React for maintainable code.

Some say the custom hook pattern originated from the Hooktail spinoff

Control Props Pattern

Props are passed to components all the time in React, that cannot be avoided. The Control Props Pattern is about whether your components are controlled or uncontrolled, which allows you to choose between passing more props or to have self-controlled components which work on their own using less props.

If a component has a state, it will need to be either controlled or uncontrolled, or both. It's more tricky to allow both - you will see it in UI component libraries and maybe write some of your own, but most of your own components will either be controlled or uncontrolled.

// Uncontrolled - manages its own state
const UncontrolledInput = () => {
  const [value, setValue] = useState('')
  
  return (
    <input 
      value={value} 
      onChange={(e) => setValue(e.target.value)} 
    />
  )
}

// Controlled - state managed by parent
const ControlledInput = ({ value, onChange }) => {
  return (
    <input 
      value={value} 
      onChange={onChange} 
    />
  )
}

Personally I prefer controlled components most often because uncontrolled ones are not as modular and reusable, since they are more difficult to override.

Remember the O in SOLID - components should not have to be modified, but be extendable. Uncontrolled components don't follow that pattern very well.

There are different arguments about what to use out there though. Uncontrolled components look nice and allow you to reuse the code within the component, but it might mean you need to write a new similar component instead of reusing the existing one, or modifying it for future needs.

When to use: When you need to control component state from a parent. For instance, if you have a form and need to read or modify fields in it, or if you have a context menu, dropdown menu or similar which you need to close programmatically from its outside.

Provider Pattern

The Provider Pattern is basically what React Contexts and useContext are. It's used in most major libraries to handle things like theming, routing, and global state management.

This is one of the most common React patterns for sharing state across components.

const ThemeContext = createContext()

// Provides the theme
const ThemeProvider = ({ children }) => {
  const [theme, setTheme] = useState('light')
  
  return (
    <ThemeContext.Provider 
      value={{ theme, setTheme }}
    >
      {children}
    </ThemeContext.Provider>
  )
}

// Hook to use the theme
const useTheme = () => {
  const context = useContext(ThemeContext)

  if (!context) {
    throw new Error('useTheme must be used within ThemeProvider')
  }

  return context
}

// To provide the theme to the app
const App = () => {
  return <ThemeProvider>
    <AppContent />
  </ThemeProvider>
}

This pattern is everywhere in React development. React Router uses it for navigation context, styled-components uses it for themes, and Redux uses it for global state.

You will definitely use this pattern, mostly through libraries, but most apps also benefit from having a few custom-made ones.

Important caveat: Contexts are not for global state management, they'll create unnecessary re-renders. Use Zustand, Redux, or Jotai for proper state management instead. Neither should you overuse them as a standard dependency injection system.

When to use: When you need to share data for a component sub-tree without prop drilling, or when using third-party libraries that require context providers. Most common use case is to centralize app-wide configurations which rarely changes (themes, i18n, auth etc.).

Common React Design Patterns

These patterns are very often seen in React applications, but they're used as architectural choices rather than fundamental requirements. They are all widely used design patterns for building scalable React applications and improving code maintainability.

Container Presentational Pattern

Also called the Container Component Pattern, this separates your components into two categories: containers that handle logic and data, and presentational components that only take props and render them.

Container presentational pattern is probably the most common React design pattern for separating concerns.

// Presentational - only renders
const UserList = ({ users, onUserClick }) => (
  <div>
    {users.map(user => (
      <div 
        key={user.id} 
        onClick={() => onUserClick(user)}
      >
        {user.name}
      </div>
    ))}
  </div>
)

// Container - handles logic and data
const UserListContainer = () => {
  const { users } = useUsers()
  const navigate = useNavigate()

  const handleUserClick = (user) => {
    navigate(`/users/${user.id}`)
  }

  return <UserList 
    users={users} 
    onUserClick={handleUserClick} />
}

The presentational component is often stateless and reusable, while the container handles connections to other parts of the application, navigation, React contexts, and networking.

This pattern helps you control which components are responsible for fetching data and doing navigation, and which components you can freely reuse anywhere in your application.

Some might think that hooks like TanStack Query and SWR have made this pattern redundant, but it still solves important issues like the Single Responsibility Principle.

When to use: You would probably most often want to have this pattern in mind. You don't necessarily need to follow it strictly, but you want some pattern to separate your business logic from the UI and to build reusable components. This is the standard way to do that, along with the custom hook pattern.

Intelliton & Glimmabelle are for some difficult to tell apart, but one is all beauty and the other one all brain

Compound Components Pattern

If you are using a UI component library in React, chances are high that you will come across the Compound Components Pattern. This pattern can easily be confused with the Component Composition Pattern because of their similarities in name and purpose. They are not the same though.

While the Component Composition Pattern explains how to divide and conquer an application into smaller components, the Compound Components Pattern explains how to allow a set of components to work together as if they were a single component.

// Normal modal component
<Modal 
  isOpen={isOpen}
  title="Delete User"
  body="Are you sure you want to delete this user?"
  onConfirm={handleDelete}
  onCancel={handleCancel}
  confirmText="Delete"
  cancelText="Cancel"
/>

// Modal consisting of compound components
<Modal isOpen={isOpen}>
  <Modal.Header>Delete User</Modal.Header>
  <Modal.Body>
    Are you sure you want to delete this user?
  </Modal.Body>
  <Modal.Footer>
    <Button onClick={handleCancel}>Cancel</Button>
    <Button onClick={handleDelete}>Delete</Button>
  </Modal.Footer>
</Modal>

This pattern is mainly a way of solving the issues of prop drilling and the need for adding React contexts to share data between components that need to work together. As a bonus, it comes with great readability.

The main idea is that multiple components work together to achieve the functionality of a single entity.

When to use: It's great when building complex, flexible UI components that are highly customizable and where the components share a common state. Although it's a bit opinionated pattern, it's a design pattern that works well for component libraries. Can be a bit tricky to set up, but on the other hand, it's nice if some component lib owner has already implemented it for you.

Headless Components

Headless components pattern is used in some UI component libraries like Radix UI and Ark UI, they provide complex logic without any styling, leaving the visual presentation completely up to you.

This is one of the modern React design patterns that separates logic from presentation.

// Headless component of pure logic
const useDropdown = () => {
  const [isOpen, setIsOpen] = useState(false)
  const [selectedIndex, setSelectedIndex] = useState(-1)

  const toggleDropdown = () => setIsOpen(!isOpen)
  
  const selectItem = (index) => {
    setSelectedIndex(index)
    setIsOpen(false) 
  }

  return { 
    isOpen, 
    selectedIndex, 
    toggleDropdown, 
    selectItem 
  }
}

// Stylig is handled by the consumer
const Dropdown = () => {
  const { 
    isOpen, selectedIndex, 
    toggleDropdown, selectItem 
  } = useDropdown()

  return (
    <div className="dropdown">
      <button onClick={toggleDropdown}>
        {selectedIndex >= 0 
          ? `Item ${selectedIndex + 1}` 
          : 'Select an item'
        }
      </button>
      
      {isOpen && (
        <ul className="menu">
          <li 
            className="menu-item" 
            onClick={() => selectItem(0)}
          >
            Item 1
          </li>
          <li 
            className="menu-item" 
            onClick={() => selectItem(1)}
          >
            Item 2
          </li>
        </ul>
      )}
    </div>
  )
}

This pattern is perfect for those who are skeptical about choosing a UI library to lock into, because it will give you support for complex components which are cumbersome to write yourself without locking you into a specific style and look.

Headless components give you full control over styling and separate the concerns of UI logic and UI styling. It suits React very well, since hooks are mainly for logic and JSX for UI.

When to use: When you need complex component logic but want complete control over styling, or when building component libraries that need to be framework agnostic. If you like to follow best practices and build a React architecture that scales, this design pattern is for you.

When not to use: Don't over-engineer simple components with headless patterns. This pattern is for more logically complex components. It's completely unnecessary for a simple button or switch toggle.

Bareboneux lives its life inside its shell, it doesn't care if you would paint it pink or poke one of its spikes

Atomic Design Pattern

The Atomic Design Pattern is one of the newer kids on the block, inspired by chemistry, probably because web development wasn't complicated enough already.

It's a pattern for creating design systems that organizes components into a clear hierarchy: atoms, molecules, organisms, templates, and pages. This design pattern is both easy to understand and also very scalable.

You start with the smallest pieces (atoms), combine them into slightly larger pieces (molecules), then build complex structures (organisms), and finally create complete layouts (templates and pages).

// Atoms - basic building blocks
const Button = ({ children, onClick }) => (
  <button className="btn" onClick={onClick}>{children}</button>
)

const Input = ({ value = '' }) => (
  <input className="input" value={value} />
)

// Molecules - combinations of atoms
const SearchBox = ({ searchText, onSearch }) => (
  <div className="search-box">
    <Input value={searchText} />
    <Button onClick={onSearch}>Search</Button>
  </div>
)

// Organisms - complex UI components
const Header = () => (
  <header className="header">
    <Logo />
    <SearchBox onSearch={handleSearch} />
    <Navigation />
  </header>
)

// Templates & Pages - full layouts
const HomePage = () => (
  <div>
    <Header />
    <main>
      <HeroSection />
      <SomeContent />
    </main>
    <Footer />
  </div>
)

This pattern helps you think systematically about your UI components and creates a clear hierarchy that's easy to understand and maintain. It's particularly useful for larger applications where you need consistency across different parts of the UI.

The key insight is that by organizing components this way, you can ensure that your design system is both consistent and scalable. Atoms are reused everywhere, molecules combine atoms in meaningful ways, and organisms create complex but reusable UI sections.

Just don't get too carried away with the chemistry metaphor. Your components don't need to have atomic numbers, and you definitely don't need to create a periodic table of UI elements (though I've seen it attempted).

When to use: When building large applications that need a consistent design system, or when working with teams that need clear component organization guidelines. I would recommend having this mindset even if you don't officially follow it. It's one of the React design patterns that works well for React applications which need a scalable design system.

Don't be fooled by Atomunculus's size; even a black hole looks insignificant from the outside

Error Boundary Pattern

Ever had that moment where one tiny bug in your React app brings down the entire application? One component throws an error, and suddenly your users are staring at a blank screen wondering if the internet broke.

This is exactly the problem error boundaries solve. They're React's way of catching JavaScript errors anywhere in the component tree and preventing the entire app from crashing.

An error boundary would look something like this, or if you use any of the hook libraries for it.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props)
    this.state = { hasError: false }
  }

  static getDerivedStateFromError(error) {
    return { hasError: true }
  }

  componentDidCatch(error, errorInfo) {
    console.error('Error caught by boundary:', error, errorInfo)
  }

  render() {
    if (this.state.hasError) {
      return (
        <div className="error-boundary">
          <h2>Something went wrong</h2>
          <button onClick={() => this.setState({ hasError: false })}>
            Try again
          </button>
        </div>
      )
    }

    return this.props.children
  }
}

const App = () => (
  <ErrorBoundary>
    <UserProfile />
    <ProductList />
  </ErrorBoundary>
)

Error boundaries only catch errors in the components below them in the tree. They don't catch errors in:

Event handlers (use try-catch instead)
Async code like setTimeout and promises
Server-side rendering
Code that runs outside the component tree

For these cases, you'll need try-catch blocks or other error handling strategies.

The key insight is to place error boundaries strategically around parts of your app that could fail independently. You might have one around your main app, another around the user dashboard, and another around some interactive AI chat.

When to use: A pattern which should be used more than it is. Most applications I have seen don't really use error boundaries, but they do serve their purpose to build stable applications. They are perfect safe-guards for applications which has several independent features to ensure that the whole app doesn't crash just because one of the features fails.

Portal Pattern

You aren't a real frontend developer if you haven't built a context menu or dropdown that got clipped by its parent container, or struggled with z-index issues where a modal appears behind other elements.

This is the problem portals solve. They provide a way to render children into a DOM node that exists outside the parent component's DOM hierarchy. It's a magic door that lets your UI elements escape their container and appear exactly where you want them.

import { createPortal } from 'react-dom'

const Modal = ({ isOpen, onClose, children }) => {
  if (!isOpen) return null

  return createPortal(
    <div 
      className="modal-overlay" 
      onClick={onClose}
    >
      <div 
        className="modal-content" 
        onClick={(e) => e.stopPropagation()}
      >
        <button 
          className="modal-close" 
          onClick={onClose}
        >×</button>
        {children}
      </div>
    </div>,
    document.body
  )
}

const App = () => {
  const [isModalOpen, setIsModalOpen] = useState(false)

  return (
    <div>
      <button 
        onClick={() => setIsModalOpen(true)}
      >Open Modal</button>
        
      <Modal 
        isOpen={isModalOpen} 
        onClose={() => setIsModalOpen(false)}
      >
        <h2>Modal Content</h2>
        <p>Rendered in body, not in parent</p>
      </Modal>
    </div>
  )
}

Portals are particularly useful when you need to render content that should appear above everything else, like modals or notifications. They solve CSS z-index issues and ensure your modal doesn't get clipped by parent containers with overflow: hidden.

The pattern is also useful for tooltips and dropdowns that need to break out of their parent's overflow constraints. Just remember that even though the DOM node is different, the React event bubbling still works as expected.

The alternative to using a portal would be to fiddle with z-indexes and their stacking contexts. And honestly, most web developers don't really know how stacking contexts work for z-indexes, which is why these kinds of issues are severely common.

When to use: When building modals, tooltips, context menus, dropdowns, etc. which need to escape their parent container's CSS constraints. It's one of the common React patterns for building overlays and popups. If you see your component being cut-off with a z-index issue the portal might the solution.

If you use portals frequently, you might one day spot the Voidnibbler, but no one would believe you

Render Props Pattern

The Render Props Pattern is where you pass a function as a prop that returns JSX. You will use it, otherwise you are probably overusing other design patterns like the Compound Components Pattern.

It feels kinda ugly at first, but it's completely normal and quite powerful.

const TodosFetcher = ({ url, render }) => {
  const [todos, setTodos] = useState(null)
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    fetch(url)
      .then(response => response.json())
      .then(data => {
        setTodos(data)
        setLoading(false)
      })
  }, [url])

  return render({ todos, loading })
}

const App = () => (
  <TodosFetcher 
    url="/api/todos" 
    render={({ todos, loading }) => (
      loading 
        ? <div>Loading...</div> 
        : (
          <div>
            {todos.map(todo => (
              <div key={todo.id}>{todo.name}</div>
            ))}
          </div>
        )
    )}
  />
)

The pattern allows you to share code between components while giving consumers control over what to render. It's particularly useful when you have complex logic that needs to be shared but the UI might vary.

In reality, the App component code would be created with its own components utilizing proper component composition:

const LoadingSpinner = () => <div>Loading...</div>

const TodoList = ({ todos }) => (
  <div>
    {todos.map(todo => (
      <div key={todo.id}>{todo.name}</div>
    ))}
  </div>
)

const App = () => (
  <TodosFetcher
    url="/api/todos" 
    render={({ todos, loading }) => (
      loading 
        ? <LoadingSpinner /> 
        : <TodoList todos={todos} />
    )}
  />
)

This example shows how the render props pattern works beautifully with component composition. Each UI concern (loading, data display) is its own focused component, making the code much more readable and maintainable.

While you could put all these components in the same file as your App component, it's better practice to place them in their own files for better organization and reusability.

When to use: If you prefer to use it. Custom hooks and compound components and props getter pattern have many times replaced this pattern, but it still has its use cases.

Props Getters Pattern

The Props getters pattern is similar to the render props pattern we just read about. Instead of passing a function which renders UI components you use a function to provide the props a component needs.

You'll see this pattern in libraries like React Hook Form, where instead of manually setting up all the form props, you get functions that return perfectly configured prop objects.

const useToggle = (initialValue = false) => {
  const [on, setOn] = useState(initialValue)

  const toggle = () => setOn(!on)

  const getTogglerProps = (props = {}) => ({
    onClick: toggle,
    'aria-pressed': on,
    ...props
  })

  const getIndicatorProps = (props = {}) => ({
    children: on ? 'On' : 'Off',
    ...props
  })

  return { on, toggle, getTogglerProps, getIndicatorProps }
}

const Toggle = () => {
  const { on, getTogglerProps, getIndicatorProps } = useToggle()

  return (
    <div>
      <button {...getTogglerProps()}>
        Toggle
      </button>
      <div {...getIndicatorProps()} />
    </div>
  )
}

As you can see, we have use a hook which provides us with the data we need instead of a component as we had with the TodosFetcher. We have also baked in some props getters in that hook which return the props we commonly would use together with our data.

If we would want to, we can easily override the properties, but most often we can trivially use the prop getter function as is to get the props we need for our UI elements.

This is particularly useful when you have complex components that need to manage multiple related props. Instead of the consumer having to know about all the internal state and configuration, they just call the appropriate getter function and get exactly what they need.

When to use: When building reusable components that need to manage complex prop configurations and accessibility attributes. Not seen too often, but kinda useful.

Legacy Patterns

Some patterns were used extensively in React in the past, but have been phased out by time and passed on the torch to other patterns.

It doesn't mean they are anti-patterns, but their best before dates have been reached already.

Higher Order Components Pattern (HOC)

The HOC pattern is the old way of lifting out reusable code in React, it was one of the most fundamental design pattern for React for quite a while.

It was mainly used with the old class components before the functional components came with hooks. It did live on for a while after the hooks came, but is more rarely seen today.

A typical example of a HOC would be a withAuth hook, which injects a user into a component.

const withAuth = (Component) => {
  return (props) => {
    const { user } = useContext(AuthContext)

    if (!user) {
      return <LoginComponent />
    }

    return <Component {...props} user={user} />
  }
}

const Profile = ({ user }) => {
  return <div>Welcome, {user.name}!</div>
}

// withAuth provides the user to Profile component
const ProfileWithAuth = withAuth(Profile)

Today, this hook would most often instead be a custom hook, looking like this. It's a bit more readable and also easier to test.

const useAuth = () => {
  const { user } = useContext(AuthContext)

  if (!user) {
    // Redirect to login
  }

  return { user }
}

const Profile = () => { 
  const { user } = useAuth()
  return <div>Welcome, {user.name}!</div>
}

When to use: Legacy pattern - prefer custom hooks instead. Only use when working with older codebases or class components that can't be easily converted.

Overcloak is from an old time, from an era all apprentices obeyed him

General Patterns

These patterns are less commonly discussed together with React, but very often discussed among backend developers, who we know usually cannot say a sentence without mentioning design patterns, architecture, or code quality.

However, it definitely doesn't mean that you shouldn't care about these. If you already know React well, these are probably the most important patterns to read about to become a better React developer.

Would it be a good time to tell him the project was cancelled two months ago?

DRY Principle

This principle is more nuanced than most developers realize - it's not a black or white pattern you can generally deem to be good or bad. While DRY is many times good, over-applying it can create more problems than it solves.

Some clear candidates for DRY implementation include atomic components like buttons, inputs, and icons that get reused everywhere. Utility functions such as formatters, validators, and helpers are also perfect since they're pure functions that solve common problems. API integration logic when you're making the same requests in multiple places, and complex state management when multiple components need identical state logic.

But be cautious using this pattern with code which might diverge. I've seen codebases that became impossible to navigate because developers created layers upon layers of abstraction for code that was only used once. Simple solutions became incomprehensible mazes of interfaces, factories, and abstract base classes for the only reason to potentially be able to save a few duplicated lines in the future.

The key insight is that DRY should be applied thoughtfully, not religiously. Sometimes duplication is actually cheaper than the wrong abstraction. It's often easier to extract common patterns later when you have 2-4 similar implementations than to guess what the abstraction should look like upfront.

Modern development tools also change the equation. With AI-powered code completion and refactoring tools, eliminating duplication might literally be one prompt away. This means the cost of both creating and maintaining DRY code has decreased significantly.

When to use: When you have truly identical logic that is used in multiple places and unlikely to diverge, or when building reusable utility functions and components. The core of the app should be kept as DRY as possible, while the outer top layer of the application is perfectly fine if it's WET. You are very likely to change that code any day.

Deduplica would probably benefit from a slightly more WET environment

SOLID Principles

The SOLID principles are fundamental design patterns that apply beautifully to React development. While they're often discussed in backend contexts, they're incredibly valuable for building maintainable React applications.

Single Responsibility Principle (SRP)

Each component and hook should have one clear responsibility. Developers violate this principle constantly when they fetch data, handle validations, manage state, perform calculations, and render complex UI all in a single massive component.

Components like that are impossible to test, difficult to reuse, and a nightmare to debug. The Container Component Pattern and custom hooks are your best friends for solving SRP violations.

When to use: Always. This is the foundation of clean, maintainable React code. Break down complex components into smaller, focused pieces.

Open/Closed Principle (OCP)

Components should be open for extension but closed for modification. This sounds fancy, but it's actually quite simple - you want to be able to add new features without breaking existing code.

React's component composition model can help with this if we design our components appropriately. The key is to follow two simple rules:

Prefer to compose multiple small components over building large monolith-components
Make commonly used components configurable through props

An example of the second rule could be a component for a delete button. That's a normal button which might be red and have a "Delete" text on it. You wouldn't hardcode its text or color in the button, rather you would pass a text and type prop to it so you can reuse the same button as a cancel or OK button without having to update the button component.

By following these rules you won't have a need to modify old components very often and can normally reuse old components to compose new and more advanced components.

In codebases where these rules aren't followed, developers consistently need to modify already existing components and rewrite their tests, which is both time consuming and prone to cause bugs in old features which previously have been proven to work.

When to use: Make sure to follow React's component composition model and you will naturally build reusable components which are open for extension but closed for modifications.

Liskov Substitution Principle (LSP)

Liskov mentions that components that extend or inherit from other components should be completely interchangeable with their base components. For instance, that principle applies if you would have a Button component and then also sub-components as PrimaryButton and SecondaryButton. Liskov then says that the sub-component should take at least the same props as the Button component.

The practical benefit of this is that you can refactor and exchange components without worrying about breaking consumers. It might not be super common to use inheritance like this in React, since React by nature uses composition instead of inheritance, but the principle tells something important about interfaces.

Even if you don't have a hierarchy of buttons you might have multiple clickable components, such as buttons, chips, toggles and so on. Or a set of different dropdown components like a list one, a searchable one, one with check boxes etc.

If you have similar components like that, keep their interfaces similar so it's easy to exchange them if needed. You never know when that UX designer changes its mind.

When to use: I wouldn't recommend to use actual inheritance as the LSP is about. However, when creating a set of components which all has similarities, then ensure to maintain the same or a similar interface and behavior for all of them.

Interface Segregation Principle (ISP)

Many projects have some of those super components/hooks which are used for nearly every component in the app. It has 15+ props and your only mission is to figure out which of those to use in your case, and most of your day goes to figuring out how to retrieve all data you need to even get it to compile without type errors.

That's a typical violation of the ISP which says that components shouldn't be forced to depend on props they don't use. It's better to use multiple hooks with fewer props and combine them for your use case. Or, to look over all the solution in general and see if it can be simplified. Chances are that someone has chosen a poor architectural solution there and that half of the props naturally could be refactored away.

When to use: When designing component interfaces, keep them focused and specific to what each component actually needs, avoiding bloated prop interfaces.

Dependency Inversion Principle (DIP)

Dependency inversion principle tells that high-level components shouldn't depend on low-level implementation details. In short, this means that you should layer your application with abstractions in a way that high-level components don't depend on low-level functionality.

For instance, if you have a component of a user list, then that component shouldn't contain the logic to fetch the users. Instead it should depend on some hook which fetches the users for it, or get the users injected to it via a state manager or similar. Or more precisely, depend on an interface of how to get retrieve the data with clearly defined TypeScript attributes.

In that way, you can replace a low-level axios request in favor of fetch or add a fancy hook like SWR without out having to refactor your user list component, since the user list component only depends on an abstract hook like useUsers rather than having axios-specific logic within it.

When to use: When building components that need to work with different data sources or implementations, or when you want to make your code more testable and flexible. Chances are that you might replace low-level functionality in your code base some day.

For detailed examples and implementation strategies, see my comprehensive article on writing SOLID React hooks.

Chubby has a lot to say, for a good reason

For detailed examples and implementation strategies, see my article on writing SOLID React hooks.

Dependency Injection

While not as common in React as in backend development, dependency injection can be achieved through Context API and custom hooks. Context API is the obvious choice, but hooks can also solve parts of the same issues.

Dependency injection is also covered in my article about SOLID React hooks.

When to use: When you need to swap implementations for testing or when building applications that need to work with different services or APIs.

Separation of Concerns (SoC)

Separation of Concerns is about organizing code so that different types of logic are kept separate and focused. While it's related to the Single Responsibility Principle (SRP), SoC operates at a higher architectural level.

SRP says each component should have one responsibility, while SoC says different types of concerns (data, business logic, presentation) should be in separate layers with clear boundaries.

Below is a typical violation of SoC. You don't really have to read it, I will spare you from that headache. The important thing to realize is that you hesitate from even reading it.

// Bad - all concerns mixed together
const UserProfile = ({ userId }) => {
  const [user, setUser] = useState(null)
  const [loading, setLoading] = useState(false)
  const [editing, setEditing] = useState(false)
  const [formData, setFormData] = useState({})

  useEffect(() => {
    setLoading(true)
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(user => {
        setUser(user)
        setLoading(false)
      })
  }, [userId])

  const handleSave = async () => {
    const updatedUser = {
      ...user,
      ...formData,
      displayName: `${formData.firstName} ${formData.lastName}`,
      isActive: formData.status === 'active'
    }

    const response = await fetch(`/api/users/${userId}`, {
      method: 'PUT',
      body: JSON.stringify(updatedUser)
    })

    if (response.ok) {
      setUser(updatedUser)
      setEditing(false)
      toast.success('User updated successfully')
    }
  }

  if (loading) return <div>Loading...</div>
  if (!user) return <div>User not found</div>

  return (
    <div>
      {editing ? (
        <div>
          <input 
            value={formData.firstName || user.firstName}
            onChange={(e) => setFormData({...formData, firstName: e.target.value})}
          />
          <select 
            value={formData.status || user.status}
            onChange={(e) => setFormData({...formData, status: e.target.value})}
          >
            <option value="active">Active</option>
            <option value="inactive">Inactive</option>
          </select>
          <button onClick={handleSave}>Save</button>
        </div>
      ) : (
        <div>
          <h2>{user.displayName}</h2>
          <p>Status: {user.isActive ? 'Active' : 'Inactive'}</p>
          <button onClick={() => setEditing(true)}>Edit</button>
        </div>
      )}
    </div>
  )
}

This component is doing everything: fetching data, transforming it, managing UI state, handling form logic, and rendering. If any of these concerns change, you have to modify this component.

The SoC design principle can be applied by separating each concern into its own layer:

// Presentation layer - only rendering
const UserProfile = ({ userId }) => {
  const { user, loading } = useUserState(userId)

  if (loading) {
    return <LoadingSpinner />
  }

  if (!user) { 
    return <NotFound message="User not found" />
  }

  return <UserDisplayCard user={user} />
}

// State management layer
const useUserState = (userId) => {
  const [user, setUser] = useState(null)
  const [loading, setLoading] = useState(false)
  
  const { getUser } = useUserApi()
  const { transformUserForDisplay } = useUserBusinessLogic()

  const loadUser = async () => {
    setLoading(true)

    try {
      const userData = await getUser(userId)
      setUser(transformUserForDisplay(userData))
    } finally {
      setLoading(false)
    }
  }

  useEffect(() => {
    loadUser()
  }, [userId])

  return { user, loading }
}

// Business logic layer - data transformations
const useUserBusinessLogic = () => {
  const transformUserForDisplay = (user) => ({
    ...user,
    displayName: `${user.firstName} ${user.lastName}`,
    isActive: user.status === 'active'
  })

  return { transformUserForDisplay }
}

// Data layer - API communication
const useUserApi = () => {
  const getUser = async (userId) => {
    const response = await fetch(`/api/users/${userId}`)
    return response.json()
  }

  return { getUser }
}

Now each layer has a clear, focused responsibility:

Data layer: Knows how to communicate with APIs
Business logic layer: Handles data transformations and business rules
State management layer: Orchestrates data and state changes
Presentation layer: Only concerned with rendering UI

This separation makes the code much easier to understand, test, and maintain. You can test business logic without worrying about API calls or rendering. You can change the API structure without touching business logic. And you can redesign the UI without affecting data handling.

The key insight is that different types of logic change for different reasons and at different rates. By keeping them separate, you minimize the ripple effects when changes are needed.

When to use: Any non-trivial application should separate types of logic like this. It's necessary for the project to scale and to work effectively in a team.

MVVM

MVVM (Model-View-ViewModel) is very popular in many frameworks but rarely spoken about in React. Yet it can be very useful, either as a whole or taking inspiration from it.

You can read my detailed article about implementing MVVM in React for a complete guide on how to structure larger React applications using this pattern.

When to use: Wouldn't say it's common to follow this pattern in React and neither would I recommend to follow it strictly. But many apps take inspiration from it and use similar layerings. The goal is to separate the concerns in some scalable way.

Who doesn't like Mooview? Look at those puppy eyes!

Stable Dependency Principle (SDP)

There's always components and hooks in a React app which are stable and well tested - SDP says that those should form the foundation of our app.

Volatile components will of course exist, which are often updated or replaced. The point with SDP is to avoid having other components being dependent on these risky and unstable components to avoid having the whole app to crash for a small change in a seemingly unimportant component.

For instance, browser's built-in functionality rarely changes - that is safe to depend on. A useLocalStorage hook in React which uses local storage should rarely change and can also be considered stable.

On the other hand, the useStoreAnythingYouWant hook my colleague Brad implemented might be more likely to change - consider it unstable (but don't let Brad know I said that).

The point is, avoid using stuff that you know might change. For example, private variables in libraries often start with an underscore. They are marked that way because they might change without any notice. If you see it, don't use it!

In e2e tests with Cypress or similar, use data-test-id attributes, don't use CSS selectors to grab HTML elements or class names. CSS classes disappears just as quickly as Brad when he sees people walking towards the table tennis room.

When to use: Always. Choose stable, well-established dependencies over experimental or frequently changing ones to avoid breaking changes in your application.

KISS Principle

The last principle in this list is very simple, but it would be stupid not to follow. The KISS principle stands for "Keep It Simple, Stupid".

When designing any kind of system, it should always be simple. Don't overcomplicate things! Keep the user interface simple, and the code as well. Think one extra time if you really need to do the things you are trying to do.

The things you might not need to add can be features which might give little value but introduce more complexity to the application. Or it might be a custom-made user authentication mechanism, instead of using a third-party provider for authentication.

Or it might be a library which comes with extra configuration files and a bundle size of 100 kB extra, when you really only use one or two functions from that library.

This complexity can also be in the code itself. A perfect example of how to overcomplicate code in React is to use useEffect when it isn't needed.

const SomeComponent = () => {
  const [fetchData, setFetchData] = useState(false)
  const [data, setData] = useState()

  useEffect(() => {
    if (fetchData) {
      const dataFromSomewhere = getData()
      setData(dataFromSomewhere)
    }
  }, [fetchData])

  return (
    <>
      <button 
        onClick={() => setFetchData(true)}
      >Fetch data</button>
      <div>{data}</div>
    </>
  )
}

It's very common that developers use useEffect in scenarios like the one above. In reality, the code would work much better with the simple solution below.

const SomeComponent = () => {
  const [data, setData] = useState()

  const fetchData = () => {
    const dataFromSomewhere = getData()
    setData(dataFromSomewhere)
  }

  return (
    <>
      <button 
        onClick={() => fetchData()}
      >Fetch data</button>
      <div>{data}</div>
    </>
  )
}

In my article about reactive developers, you can see more complicated code React developers tend to write when it really isn't necessary, and what the consequences of that are.

When to use: Always. Prefer simple, straightforward solutions over complex ones unless complexity provides clear, significant benefits. This might not sound like a design pattern for many, but it's one of the most trivial and effective design pattern which prevents over-engineering.

Design Patterns to Avoid

This is of course opinionated, but be aware of my opinion, because I'm definitely not alone with this opinion. This is important to know when choosing React design patterns for your project. Some forces of nature should remain untamed and preserved in their natural domain.

Clean Architecture

I'm listing this here because I have seen backend developers using it in React. MVVM I can feel is alright, but Clean Architecture is a step too much for React.

The problem is kind of too many layers and you will annoy the hell out of your normal frontend colleagues. Plus, it's often a pure rip-off of Clean Architecture that breaks quite some other core design patterns of React.

React already has its own architectural patterns that work well. Don't take architectural patterns from your previous work experience and force them into new code bases where they don't belong. Stick to React best practices and common React patterns instead. Each ecosystem has its own natural laws.

Modulynx is quite tiny, which allows her to clean the tiniest interfaces

Note About Modern React Patterns and Frameworks

If you don't think 21 patterns was enough, you might want to stay tuned, there are actually many new patterns which came with React 18 and 19.

You might have familiarized yourself with them already, especially if you are using frameworks like Next.js or Remix.

I haven't included any of those in this article though, since it's already long enough. But for the impatient readers I can give some spoilers, it's about functionalities like:

Server Components
Suspense data fetching
Concurrent features

These patterns are still evolving, but they represent the future direction of React development. Regardless whether you are using one of the more prominent React frameworks or if you use pure React Vite.

Because I love React, I am particularly fond of Vite

33 Christmas Animations to Easily Add to Your Website

dennis@perssondennis.com (Dennis Persson) — Sun, 10 Dec 2023 00:00:00 GMT

Yes, it's already that time of year. Whether you love or hate Christmas, a small Christmas CSS animation can bring a big smile to your website visitors.

In this list, you will find 33 Christmas animation and interactive art which easily can be added you your website. Most of them are CSS only, others requires a small amount of JavaScript.

CSS Snowflakes!

Let's start out with snowflakes. Decorate your webpage with animated snowflakes. Easy to add, delightful to look at.

Snow Globes

Can you make a snow globe with pure CSS? Yes, here we have three stunning snow globes made with only CSS.

CSS Santa Claus

What would Christmas be without Santa Claus himself? The tricky thing is too choose which CSS Santa to go for!

Christmas Decorations in CSS

Why not adding some small decorative Christmas inspired CSS art? My favorite is definitely the Disney-like Christmas tree, which reasonably requires a good amount of JavaScript. If you don't want to use JavaScript, you have a quite similar mesmerizing CSS only Christmas tree animation in another link.

Interactive Christmas Animations

Here are some interactive Christmas animation. They naturally include a bit of JavaScript since they are interactive, but some manage to get away very easily with almost no JavaScript at all.

CSS Candy Canes

Wanting something sweet for Christmas? Try these CSS loading and progress bars in candy cane colors!

CSS Snowman

Do you know why it is better to add a snowman to your website than building one outside? Because it never melts. Unless your servers overheats...

Other Christmas Art

Couldn't decide what CSS art to use to decorate your website with for Christmas? Here's a few more links which may come handy.

Bonus - Christmas Games

It's Christmas after all, you should get some extra gifts. For you today, I have found two Christmas games you can play!

6 Use Cases for Regex in Your Daily Work

dennis@perssondennis.com (Dennis Persson) — Sun, 27 Nov 2022 00:00:00 GMT

What Is Regex

Regex, or Regular Expression, is a tough thing to learn. Trying to define it in simple words is almost as difficult. In a short sentence, Wikipedia currently describes regular expressions as a sequence of characters that specifies a search pattern in a text.

What that means, is that regexes are used to find characters in a text. With characters I mean letters, numbers, brackets, new line characters and so on. With regexes, you can write an expression that defines which sequence of characters you want to find in the text.

Understanding the syntax of the expression language is what is hard to learn (and remember). We will go through everything you need to know about that in upcoming articles, both for basic and advanced usage. The aim of this first article in the series is to explain why you should learn regex.

Just another thought to keep you awake

Regexes in a Nutshell

Regex on its own is only used to find text occurrences (matches) in a string or text. What we want to do with the matches is up to us. When using regexes, we are most often interested in one of three things.

find information in a text
check if a string matches a regex, e.g., email validation
replace characters in a text

Even if the use cases of regex often boil down to answering a yes or no question, finding text occurrences or to replace some characters, it can be used in a lot of scenarios. We will look at a few of them now.

When Is Regex Used?

Most developers can go a life time without learning regex. Often when regex is a good idea to use, it isn't completely necessary to use it. The alternative solutions do unfortunately often take a lot more time to implement and will not scale for use cases where more data needs to be processed.

The short and boring answer to the question "when is regex used?" is "to a lot of things". The long answer follows here.

Searching Through Files, Manuals and Logs

The first time I ever encountered regexes was when learning about Unix. First experience was to find information in Unix manual pages and log files. It looked pretty much like this.

# Finds all lines that contain the word "error" and later "vehicle" in the file somelogfile.log. Useful to see if we have logged any errors which mention anything about a vehicle.
grep -i 'error.*vehicle' ./somelogfile.log

# Searches through the Unix manual for scp command and outputs what the v flag does.
man scp | grep -i '\-v'
# Output in Mac terminal:
# -v  Verbose mode.  Causes scp and ssh(1) to print debugging messages

Above examples may look like school book examples, and they are. That's why we go to school, to learn useful stuff! Sure, you can always google for what flags for Unix commands do, may take longer time, but still quick.

Searching through log files is something you will have to do yourself though. That's something I do daily at work to investigate bugs. For big log files I may find hundreds or thousands matches if I simply search for "warning" or "error". Writing regexes definitely helps me filtering among all those results by specifying a more granular search term with a regex.

Regex Search in an IDE

Have you ever accidentally activated that regex checkbox in your IDE when searching for text occurrences in your editor and then wondering why you don't find what you are searching for? Next time you do that, don't uncheck it. Find a way to search for what you want with it activated!

Sign me up as guilty for that, it has happened a lot.

Maybe you know you are invoking a very common function somewhere, but don't remember where it was or what the function is named. Here are some expressions for that! Don't worry if you don't understand them, regex syntax will be explained in another article I will post here in a few weeks.

// Finds a console log that prints a count variable.
conso.*count
// Example: console.log(count)
// Example: console.log(`Total: ${count}`)
// Example*: console.log(itemCount)

// Finds a function which name ends with "count" and has an argument which includes the text "todo".
count\(.*todo
// Example: count(todoItems)
// Example*: updateCount(oldCount, newTodoItem)

// * these examples only match if case sensitivity is disabled, which is done either in the IDE or by using the regex flag i

Classic Example, Form Validation

This article wouldn't be complete if the classic example wasn't mentioned. This is probably what you are thinking of when you read the word regex, to validate a form using regexes. It's a must have.

You can both validate that an email is a valid email, or that a phone number is of the correct format. You can also forbid curses and vulgar words in user names or detect if a credit card number is a MasterCard or a Visa. Maybe you need to ensure that a password contains special characters. For all of these examples, you can use regexes.

I'm fine with regex, but I won't touch CSS

Find and Replace Like a Pro (or Manipulate Strings)

Once in a while I get a really boring task at work. It could be that an API endpoint has been updated and it requires a lot of changes because it has been hardcoded all over the place. It could also be that data has been dumped from a production database into a JSON file to be used as development data, and to do that, all email addresses must be replaced with dummy addresses.

The hardcoded API example sounds like a quick find and replace work, and it is, but you may need to know regex to do that. Look at the following URLs.

https:// regexexampledomain.com/articles/react/some-react-article
https:// regexexampledomain.com/articles/react/react-is-awesome
https:// regexexampledomain.com/articles/javascript/a-javascript-article

The above urls follows the pattern /articles/<category>/<article-name>. Imagine if we have thousands of links like that, with thousands of categories, and we have refactored the site so we don't longer have categories such as react and javascript in the URL.

We could fairly safely find and replace one category after another, e.g., replacing /react/ and /javascript/ with a single slash character to remove the categories. But remember, the site has thousands of categories, it will take time to manually do that.

With regexes, we can update all of those categories using one single find and replace, regardless of how many categories we have.

What about the email obfuscation example? How can we find and replace any email in a JSON file with john.doe@gmail.com? The only thing we need for that is a regex for an email address and a replace function in either a programming language or an IDE. Then we can just hit a button and search through the JSON data to see that it actually replaced the emails successfully.

John Doe didn't get his email obfuscated

Usages in APIs and Web Consoles

Regex is widely spread. A lot of services and APIs support it. This means it's a fairly good chance that a SaaS which deals with a great amount of data offers some kind of regex solution. It could be a search field in a web console for a logging tool or it could be a SDK or API that allows to use regexes. See for example Elasticsearch regex queries.

Interpret and Categorize Data with Regex

So far, most of the regex examples described have involved processing or validating data. However, regexes can also be used to interpret and categorize data.

Let's take an example where the input data is single words which either can be a string, an integer, a float number, an array or an object. Our goal is to detect which one it is.

Input: 402
Output: integer

Input: 402 is an integer
Output: string

Input: 4.2
Output: float

Input: the number 4.2 is a float, not an integer
Output: string

Input: ['hello', 4.2]
Output: array

Input: {"hello": 4.2}
Output: object

The above problem can of course be solved with a lot of if statements and looping through alphabetic letters to detect if the input contains any of those. With regex, we can however solve it much easier. We can use regexes like below to instantly detect the types.

Regex: /^[0-9]+$/
Detects: integer

Regex: /^[0-9]+\.[0-9]+$/
Detects: float

Regex: /^\[.*\]$/
Detects: array

Regex: /^\{.*\}$/
Detects: object

With the above regex, we could detect integers, floats, arrays and objects in a few lines of code. To detect strings, we could create a more complex regex, ensuring that it doesn't start with a bracket and that it contains letters from the alphabet, but it would also be sufficient to use string as a default fallback value when the input isn't of any of the other types.

Using regex in this way can save us some lines of code. In other scenarios it may be crucial to use regex. Take clothing sizes as an example. There are many ways to write a size like XL. What if we want to map all possible ways to write it into one of the ways?

## Examples of input: l, L, large, Large, lg, LG, L slim, L wide
Output: L

## Examples of input: xl, XL, extra large, extra-large, x large, x-large, X-Large
Output: XL

## Examples of input: xxl, XXL, 2xl, 2XL
Output: XXL

Starting to see the problem? This issue is fairly easy to solve with regex. Without it, we kind of would have to hardcode a lot of mappings for the sizes. That's totally a valid solution. But what if the sizes also could be numbers?

Say for example that we have a t-shirt in size L which is described with the European size 52, or maybe as a range from 52-54? We would have a lot of things to hardcode there.

Although regex is of great use in a case like this, we can not solve this problem with a single regex, we need quite a few of them. However, we do not need a lot of them, a single regex can match a lot of different variations of how to write a size.

Learn More About Regex

The use cases of regex we have seen in this article are just examples. These kinds of issues don't always need to be solved with regex. Sometimes it is just overkill to use regex. Sometimes it's just as easy without regex as it is with regex. It is a decision you will have to take when facing a problem. For some problems, you will come to realize that it isn't even feasible to solve the problem without regex.

If you want to learn more about regex. Save this article for later or follow me. I will post another article during next month.

Answers to Common Next.js Questions

dennis@perssondennis.com (Dennis Persson) — Sun, 05 May 2024 00:00:00 GMT

Web development went from server rendered applications to single page applications rendered fully on the client, and then it all got complicated. Next.js have now cleared away the old perspective of client and servers and provided us with a high performance framework which is a big black box containing both client and server. But don't worry, I'll here provide a FAQ with common questions about Next.js and its Server Components.

At least we get to use JavaScript for the server code

1. How To Read URL Params in a Client Component?

If you need to read the pathname or query params from the URL in a Client Component, you can use the usePathname or useSearchParams to do so.

'use client'

import { usePathname, useSearchParams } from 'next/navigation'

const ClientComponent({ children, href }) {
  const pathname = usePathname()
  const searchParams = useSearchParams()
  const search = searchParams.get('search')

  return (
    <div>Next.js usePathname and useSearchParams example</div>
    <div>{pathname}</div>
    <div>{search}</div>
  )
}

export default ClientComponent

If you need to navigate programatically in a Client Component, you can use useRouter. For normal navigation, please use the built in Link component Next.js has.

'use client'

import { useRouter } from 'next/navigation'

const ClientComponent({ children }) {
  const router = useRouter()

  const handleClick = () => {
    router.push('someUrl')
  }

  return (
    <div onClick={handleClick}>Click me</div>
  )
}

export default ClientComponent

2. How To Read URL Params in a Page File?

Params are automatically passed as props to the page component. You can simply use the provided prop.

const PageComponent({ params, searchParams }) {
  const { slug } = params

  return <div>Next.js URL params in page.tsx file</div>
}

export default PageComponent

3. How To Read URL Params in a Next.js Layout File?

If you need to read URL params in a layout component file, you have two options. First option is to create a Client Component inside the layout and read the params in the Client Component instead.

This may sound like a bad option if you use Next.js with the expectations to mostly use Server Components, but it actually is completely natural. The rest of your layout file, can still be rendered as a Server Component, it's just the Client Component itself which will need to be rendered on the client.

For instance, if you would use URL params to filter articles on a blog with the help of chips components, then only the component containing the chips would need to be a Client Component, the rest of the header could remain a Server Component.

On the website above, the red rectangle can be a Server Component, while the blue rectangle which depends on URL params can be a Client Component

The other option, might be the lesser good alternative. This is to add a middleware to your application which reads the URL params and passes it on to your layout component. This will give you flexibility to access the URL params, on the cost of disabling static rendering and client-side caching of your Server Components.

4. How To Read URL Params in a Server Component?

In a arbitrary Server Component, which is neither a layout component or page component, you can get the URL params by passing them down as props from other components.

Important to remember is that Server Components which aren't page file components aren't normally refreshed during navigation, the components as a whole are serialized and sent to the client and only updates in rare cases. For that reason, you must be careful when using information from the URL in Server Components. The URL params will get outdated upon navigation.

5. Why Doesn't searchParams Exist in Next.js Layout Files?

searchParams are only available in page files for a reason. Page files will always re-render when you navigate between two pages. Since the component re-renders when the URL changes, we can for sure know that the URL params passed to the component are up to date.

The purpose of layout components, is to avoid unnecessary renderings and to contain static parts of the UI which aren't updated when the user navigates between pages. A layout component does therefore only re-render when the user navigates to another part of the screen where that component isn't visible. In the code, that means to navigate between two pages which don't share a common layout file as ancestor in the file tree.

Effectively, this means that the URL will change more often than layout files renders, and if we were to read URL params in a layout component, the component wouldn't get to know when the URL params updated. Remember that the layout file is a Server Component, it is rendered to HTML when it is first fetched and then cached on client so it never has to re-render.

To learn more, read the section above about how to read URL params in a Next.js layout file.

6. How Can I Skip the Root Layout for Some Pages in Next.js?

A Next.js project can have many layout files, technically each page can have its own. The top level layout file which wraps your whole application is called Root Layout.

Layout files allow you to re-use a component as a wrapper component for several pages. Most commonly, each Next.js applications has a Root Layout file which includes the applications main menu, such as a header menu or hero image.

While doing that, you will soon run into a question; can you skip the Root Layout for specific pages? And the answer is, yes you can. Next.js has a feature called Route Groups which allows you to have multiple Root Layouts. This means that different parts of your application can have different layouts, which also makes it possible to skip having any components at all in the layout for certain pages.

One thing to note here is that navigation between route groups will trigger a full page load. That is a natural consequence of replacing the top level Server Component in the application. It basically means, you render a completely new part of your application which is independent from the rest of all pages.

7. How To Set Metadata Tags in App Router?

Next.js makes it very easy for you to set metadata for your app and pages. The only thing you have to do is to export a metadata object from any layout or page file in your application to set the metadata for that layout/page and down.

import type { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'Next.js Metadata Example',
  description: 'Example of metadata in Next.js',
}

export default function MyPage() { ... }

If you need dynamic data, see the question below.

8. How To Set Metadata Dynamically for an App Router Page?

For most SEO optimized applications, setting static metadata isn't enough, since data will be unique to almost every page and even be loaded at runtime from a server. To set metadata dynamically in a Next.js page, use the provided generateMetadata function.

import type { Metadata } from 'next'

export async function generateMetadata(): Promise<Metadata> {
  const data = await fetch('someUrl').then((res) => res.json())

  return {
    title: 'Next.js Dynamic Metadata Example',
    description: data.pageDescription,
  }
}

export default function MyPage() { ... }

Good to know is that the fetch function in Next.js by default caches duplicated requests. This is a general behavior, it isn't specific to metadata. Even requests in Server Components are cached when fetch is used. Although, it can be opted out from and even disabled automatically when certain Next.js features are used.

9. Can I Set Metadata in a Layout File?

Yes, you can set metadata in a layout file, both static and dynamically. Please see the questions about setting metadata above.

10. Can I Use Contexts with App Router?

It is possible to use React Contexts with the App Router in Next.js. You can preferably place the contexts in the root layout to make it available to all Client Components. The context will not be available to use in Server Components, and it will not mess up the render behavior of Server Components.

You can read about how it works in this article.

11. How To Use React Context in Server Components?

In Next.js, you can only use React contexts in Client Components. Server Components will not be affected by contexts in Client Components and it cannot read the context. See "Do Contexts in Next.js 13 Make the Whole App Render on the Client?" for more information.

However, dependent on your need, you might be fine with not having a context in your Server Component. By default, Next.js caches data retrieved in requests sent with the fetch function, meaning that you don't have to worry about duplicated request. If multiple Server Components need to fetch the same data, you can rely on the cache as an alternative to a sharing data through a context.

12. Is it Possible to Render a Client Component in a Server Component?

It's completely normal to render Client Components in Server Components. All props which are passed to the Client Component must be serializable though. Data which isn't serializable must be handled from within the Client Component instead.

13. Can I Pass Props from a Server Component to a Client Component?

Yes it is possible to pass props from a Server Component to a Client Component. As mentioned in the previous question, the data must be serializable.

14. Can I Use Server Components in Client Components?

It is possible to user Server Components in a Client Component, but with limitations. You cannot import Server Components in Client Components as usual, they will not be Server Components when doing so. What you will have to do, is to pass the Server Component as a prop or child to the Client Component.

Note specifically, because this tricks many developers. Next.js claim that components are Server Components by default, and that you have to use the "use client" directive to make it a Client Component. That is not the whole truth, because when you import any component in a Client Component, the imported component will be a Client Component, not a Server Component.

As mentioned above, you have to pass the Server Component as a prop if it should be treated as a Server Component. Next.js don't complain if you import what you think are Server Components into Client Components, they are simply just treated as Client Components without any warnings. So if you think you are using a lot of Server Components, you may actually not have that many at all.

15. Can I Pass Props from a Client Component to a Server Component?

No, it isn't possible to pass props from a Client Component to a Server Component. Server Components are rendered into HTML on server already before Client Components are rendered.

16. Can I Use Server Actions in Server Components?

Yes of course, they are made for that. See this example in the docs.

17. Can I Use Server Actions in Client Components?

Yes, but with a caveat. You cannot use server actions directly in your Client Component. What you can do, is can write the server action in a separate file, and use it in a Client Component, like shown in the docs.

However, if you try to use server actions directly in a component like it is done in a Server Component, then you would get this error.

It is not allowed to define inline "use server" annotated Server Actions in Client Components. │ To use Server Actions in a Client Component, you can either export them from a separate file with "use server" at the top, or pass them down through props from a Server Component.

As you can read there, you have one more option. You can define the server action in a Server Component and pass it as a prop to the Client Component if you would want that.

18. Are Server Actions Stable in Next.js?

In Next.js 14 server actions are considered stable. One thing to note though, Next.js is built upon React features which are still marked as experimental.

Server actions were experimental back in Next.js 13, so if in version 13, you will be asked to add server actions as an experimental feature in next.config.js

to use server actions, please enable the feature flag in your next.js config.

This is what you would need to add to next.config.js. Although I rather recommend to upgrade to Next.js 14.

  experimental: {
    serverActions: true,
  },

Complete Guide To Make You a Regex Guru

dennis@perssondennis.com (Dennis Persson) — Sun, 15 Jan 2023 00:00:00 GMT

This is the second article in a series of regex articles. In the first article, you can read about common use cases for regex. This article explains everything you need to know about regex for daily usage, with both examples and cheat sheets. An upcoming article will later explain the most advanced use cases of regex, which unleashes the real power of regex, but which are rarely used.

Explain Regex Like I'm Five

Regex (or Regular expressions) is a language for searching for and matching patterns in text, using special characters to describe the type of characters or sequence of characters you want to find or replace.

Most fundamental thing to understand about regex is how it works when you don't write any kind of special characters or use any of the regex language specific features. In that case, each written character in the regex, will match the corresponding character in a text, if those characters are present in the text, just like a regular text search field.

Results for when searching a text with the regex /all/gm

In the picture above, we can see the exact matches a regex will find in a string for the regex /all/ with the flags g and m. It finds a total of six matches in the string.

Note that the regular expression is only used to find those six matches. What we want to do with the matches is up to us. A common thing to do is to replace the matched characters with other characters. In other case it is only necessary to know whether a text matches a regex or not, for example to be able to detect if a user has entered a valid email or not. To learn more about what regex is used for, please read the previous article in this series.

Try writing regex on Regex101

What is the Syntax for Regex?

Regexes are often defined in between two forward slashes and followed by a few letters.

// Common syntax for a regex.
/someregex/ig

The slashes only defines that it is a regex we are writing, and the trailing letters are called flags which can alter how the regex should be interpreted.

In some languages we can define regexes in another way. For example, in JavaScript, you can use the RegExp constructor.

// In JavaScript you can define a regex with a regex constructor.
const myRegex = new RegExp('someregex', 'i');

// Above is the same as defining a regex with the standard slashes syntax.
const myRegex = /someregex/i;

In UIs, such as search fields in IDEs, it's common to allow regexes by enabling a regex button. When doing that, you normally don't need to write the surrounding slashes, and flags are sometimes possible to edit, but not always.

You can activate regex in VS Code search field with the button with the .* icon

A short note before we continue explaining flags. You should be aware of that the regex syntax can differ slightly between implementations in different programming languages. They do not all interpret regexes exactly the same, but most of them adhere very well to the standard.

Most Common Regex Flags

There are many regex flags. All languages and editors do not support all of them. I will therefore only present the most common ones here, which normally is supported.

The i and the g flag is far most used. The s and m flag is also something you will have to use some day, but not for certain.

Flag: i

The regex flag i, is the easiest flag to understand. What it does is to make the regex interpretation case insensitive. This means that the regex will match both capital and lower-case letters regardless of what you write. Without specifying this flag, regexes are case sensitive.

// This regex will not find a match in the string "Regex explained",
// since "Regex explained" has a capital R in it.
/regex explained/

// When using the i flag, this regex will match "Regex explained" string.
/regex explained/i

Flag: g

Another very common flag is the g flag, short for global. That flag tells the regex interpretator to find all matches of the regex expression rather than only finding the first match, which it will do without the flag. That is best explained with a picture!

The g flag tells the regex engine to find all possible matches, not just the first one

The tricky part here is probably not to understand what the g flag does, but when it matters. If you use a regex to only test if a text matches a pattern, such as when checking if a text contains your name, then the g flag doesn't really matter. Regardless of whether you find your name once, twice or a thousand times, the answer will be that it contains your name. The only difference is that the regex engine will have to work harder to find all thousand occurrences.

If you use the regex for another purpose, such as replacing all occurrences of a word in a text, then the g flag is something you would want, otherwise you would only replace the first occurrence of the word!

const text = 'What is regex? What can you do with regex?';

// Without the g flag, regex engine will only replace the first match of the regex.
console.log(text.replace(/regex/, 'love'));
// Output: What is love? What can you do with regex?

// With g flag, regex engine will replace all matches of the regex.
console.log(text.replace(/regex/g, 'love'));
// Output: What is love? What can you do with love?

Try g flag on Regex101

Flag: s

s stands for single line. It effectually means that the regex will be treated as a single line even if it contains new lines. Normally regexes will not search for matches over multiple lines. What it means in regex language, is that the dot regex character, which means any character, can match newline characters (\n).

The s flag lets the regex engine ignore new line characters and treats the whole string as a single line

In the example above, the .* part of the regex means any amount of characters. That will be explained more in detail later in the article. For now, it's sufficient to understand that the s flag allows regexes to stretch over multiple lines.

Try m flag on Regex101

Flag: m

m flag stands for multi line. Confusing? Didn't we just explain that above when we talked about single line? Don't worry, no need to raise a white flag.

While the s flag affects how the dot character is interpreted in a regex, the m flag affects how the start and end characters ^ and $ should be treated. Let's move on to talk about them now, m flag will be further explained there.

Wouldn't it be better if they just had worked together?

Start and End of Regexes

Writing a regex that ensures that a string starts and/or end with certain characters is a very common use case. Regex language uses a caret (^) to express the beginning of a string and a dollar sign ($) to represent the end of a string.

Normally, the start and the end of a regex indicates the start and end of the whole string the regex searches in, regardless of the number of lines in the string. The m character, changes the meaning of the caret and dollar sign so they instead represent the start and end of each line in a regex. In practice, that means that each newline character (\n) in the searched string will be treated as an end of a line, and also a start of a new line.

The m flag changes the meaning of caret (^) symbol to match the beginning of a line instead of begging of the whole string

Note that we cannot always expect the caret and dollar sign to match start end ends of strings. That's probably why regex is such a complex language, because it changes meaning of characters dependent on the surrounding characters. Let's talk a bit about that, to clarify which characters are normal in regex and what all the special characters do.

Try m flag on Regex101

Regular Characters (Literal Characters)

Alternative names: regular characters, literal characters

Flags, special characters, dots and carets which change meaning with flags... Are there no regular characters in regexes? Yes! There are! They are called literal characters and you can safely use those characters without having to worry about them being treated in a strange way.

Letters: a-z, both in upper-cases and lower-case
Numbers: all numbers, 0 to 9

Ya, that's about it... Wasn't that many after all.

Just joking, there's a lot of them! You have @, & and % for example. Actually most characters are regular characters. It is easier to learn which characters has a special meaning in regex and then expect every other character to be a regular character.

Special Characters (Metacharacters)

Alternative names: special characters, metacharacters

The regex syntax includes quite many special characters which are used by a regex engine to understand the regex. These characters are called metacharacters. Metacharacter is a general term for a character that has a special meaning to a computer program, interpretator or in this case, a regex engine.

One example of a special character is the plus sign character (+) which means that the preceding character should exist one or multiple times (see quantifiers section). If you want the regex to interpret a special character as the character literal itself, you will need to escape it with a backslash character (\).

// The + character means that the character before it should exist at least once.
Regex /bun+y/ will match string "buny".
Regex /bun+y/ will match string "bunny".
Regex /bun+y/ will match string "bunnny".
Regex /bun+y/ will NOT match string "buy", because one n is required by the + sign.
Regex /bun+y/ will NOT match string "bu+y", because the plus character is treated as a metacharacter.

// If you want to match a + sign, you will need to escape it with a backslash.
Regex /bun\+y/ will match string "bun+y".

So in short, a special character is a character that needs to be escaped if it should be treated as the character itself in a regex. If not escaped, it will be a part of the regex syntax to describe to the regex engine how to interpret the regex.

We will soon see a full list of special characters in regex, but before that, we should look at what I call multi-special characters.

Multi-Special Characters

Alternative names: special characters, metacharacters

Let's be honest, multi-special characters is not an official term, it's just something I am making up right now. That's because I need a way to differentiate multi-purpose special characters from singe-purpose special characters.

The confusing thing with regexes is that special characters aren't always special. Other special characters are always special, but they change meaning when combined with other special characters. That's why I refer to these special characters as multi-special, special characters which plays many roles in the regex syntax.

Luckily, there are not very many multi-special characters. One very important one though, is the hyphen character (-). It is normally interpreted as a regular hyphen character, but when a hyphen is used within a character class (square brackets), it is instead treated as a range character that defines a range of characters.

// A hyphen in a regex is normally treated as a hyphen literal.
Regex /a-d/i will match string "a-d".
Regex /a-d/i will NOT match the strings "a", "b", "c" or "d".

// Within square brackets, hyphen is treated as a range character.
Regex /[a-d]/i will NOT match strings "a", "-" or "d", because the hyphen is in a character class.
Regex /[a-d]/i will match the strings "a", "b", "c" and "d", because a-d is treated as a range of characters.

// If you want to match a hyphen in a character class, you need to escape it.
Regex /[a\-d]/i will match strings "a", "-" and "d", because hyphen is escaped.

// Meaning of square brackets is explained in detail in character classes section.

As mentioned before when talking about start and end characters, the caret character (^) can also change its meaning in regex. Just as the hyphen, it behaves differently within square brackets. It's then called negative character classes, which we will look at later in this article.

Now answer, does multi-special characters confuse you? No worries. You can think of them as any other special character, only thing you need to take with you is the knowledge that some special characters can be used for multiple things.

List of Regular Characters in Regex

Character	Comment
Letters	Letters a-z, both in upper-case and lower case.
Language Specific Letters	Often supported and treated as regular characters.
Numbers	All numbers are regular characters.
&	Ampersand is a regular character in regex.
@	At sign is a regular character in regex.
,	Comma is a regular character in regex.
#	Hashtag is a regular character in regex.
%	Percentage sign is a regular character in regex.
_ (underscore)	Underscore is a regular character in regex.

This list isn't complete since there are endless of regular characters. If in doubt, look in the list of special characters which is a complete list.

List of Special Characters in Regex

Each special character is described in detail in this article. This list also refers to the terms lookahead and lookbehinds. Those are used for advanced use cases and will be explained in another article.

Character	Comment
- (hyphen)	Treated as a hyphen literal, or a range character if it's within a character class. Will need to be escaped to be treated as a hyphen when it's used in character classes.
=	Equal sign is treated as a regular character unless it is used to define a lookahead or lookbehind expression, (?=) or (?<=).
!	An exclamation mark is a regular character unless it is used to define a negative lookahead or negative lookbehind expression, (?!) or (?<!).
?	A question mark is a quantifier for an optional character. Can also serve as a greedy modifier when it follows a quantifier, which is explained at the end of this article. Lastly used in lookahead and lookbehind syntax when placed as the first character in a set of parentheses (?!), (?=,) (?<=) or (?<!).
{}	Used in syntax for quantifiers and is otherwise treated as regular curly braces.
[]	Square brackets are the syntax for character classes.
\	Backslash is used to escape characters or to write special tokens such as newline character (\n). If you need to match a backslash sign, you need to escape it with another backslash.
+	Plus sign is a quantifier to tell that the preceding character or should be matched one or more times.
*	Asterisk is a quantifier to tell that the preceding character or should be matched zero or more times.
.	A dot character is used to match any other character. Will only match a single character unless combined with a a quantifier. It does not match a newline character unless the s flag is used.
\|	Pipe character is used as an or operator.
/	Slash i often used to enclose a regex in programming languages. It will have to be escaped with a backslash if it should be treated as a slash literal.
"	Double quote is treated as a regular character in regex, but may need to be escaped in programming languages if the regex is a part of a string that is defined with double quotes.
'	Singe quote is treated as a regular character in regex, but may need to be escaped in programming languages if the regex is a part of a string that is defined with single quotes.
<>	Less than and greater than characters are treated as regular characters unless they are used to define a positive or negative lookbehind expression, (?<=) or (?<!).
^	Caret is used to define the start of the string. When the m flag is used, it matches the start of each line separated by a newline character (\n). Carets are also used in the syntax for negative character classes, [^].
$	Dollar sign is used to define the end of a string. When the m flag i used, it matches the end of each line separated by a newline character (\n) will be treated as the end of a line.
()	Parentheses are used to define character groups.

Special Tokens

Alternative names: special characters, metacharacters

When googling regex you will see people name things differently on every site. Therefore you may know special tokens as just metacharacters, special characters or just tokens. In this article, I do call them special tokens, because syntactically they look different to the other special characters in regex.

Looking at the syntax, they are kind of the opposite to other special characters, because special tokens use the backslash escape character, in front of an otherwise normal character literal, to make it be interpreted as a special character.

Below is a list of special tokens. As you can see, it is possible to write most of them in alternative ways. This table is not complete. Many special tokens has been omitted here since they are rarely used or seen.

Token	Description	Alternatives
\d	Matches a single digit	[0-9], [0123456789]
\D	Opposite to \d. Matches any character that isn't a digit	[^0-9], [^0123456789]
\w	Matches any letter in alphabet, any number and underscore	[a-zA-Z0-9_]
\W	Opposite to \w. Matches any character that is not a number, underscore or a letter in the latin alphabet	[^a-zA-Z0-9_]
\s	Matches a whitespace character	Regular space character usually works, but note that also tabs, new lines and a few other whitespace character exist.
\S	Opposite to \s. Matches any character but whitespace	See \s for more info.
\n	Matches a newline character
\r	Matches a carriage return character
\t	Matches a horizontal tab character
\b	Matches a word boundary, which is the start or end of a word. So the regex /\bex/ matches ex in example, but not the ex in regex.	One may think whitespace character \s would be the same as \b, but unlike \b, \s doesn't work in the beginning or end of a sentence, since there are no whitespaces there.
\B	Opposite to \b. Ensures that it isn't the beginning or end of a word.

Quantifiers - Repetition of Characters

Alternative names: occurrence indicators, repetition operators

Normally when writing a character in a regex, the regex engine will only match one and exactly one of that character. There are some special characters in the regex syntax which can be used to change that behavior. These special characters are called quantifiers and are always placed directly after the character it will affect.

As an example, the question mark character means that the previous character should be present 0 or 1 times, which basically means that it's an optional character. The question mark can for example be used to accept both American and English spelling.

// The question mark quantifier can be used to match a character zero or one time.
Regex /colou?r/ will match the string "color".
Regex /colou?r/ will match the string "colour".
Regex /colou?r/ will NOT match the string "colouur".

All other quantifiers work in the same way. They demand the preceding character to be repeated a certain amount of times.

Character	Description	Example	Match	No Match
?	Matches the preceding character zero or one time	bun?y	buy, buny	bunny
*	Matches the preceding character zero or more times	bun*y	buy, buny, bunny
+	Matches the preceding character one or more times	bun+y	buny, bunny	buy
{2}	Matches the preceding character exactly two times	bun{2}y	bunny	buy, buny, bunnny
{2,4}	Matches the preceding character two to four times	bun{2,4}y	bunny, bunnny, bunnnny	buy, buny, bunnnnny
{2,}	Matches the preceding character two or more times	bun{2,}y	bunny, bunnny, bunnnny, bunnnnny	buy, buny

Character Classes

Alternative names: bracket expressions

Syntax: []

Character classes is a very important part of regex. It allows you do declare a set of characters to match instead of specifying one exact character to match. To use it, write all alternative characters within square brackets ([]).

// One and only one of the characters in a character group will be matched.
Regex /optimi[sz]ation/ will match both "optimization" and "optimisation".
Regex /optimi[sz]ation/ will NOT match "optimiation", because either s or z is required.
Regex /optimi[sz]ation/ will NOT match "optimiszation", because only one of s and z is allowed.

In the example above, you can see that when a character class is defined, a regex engine will only accept one of the characters in the group to be present. If you would want to match more than one of the characters, you can combine it with a quantifier.

// Combine a character class with a quantifier if you want to accept more
// than one of the characters within the group to be matched.
Regex /m[isp]+/ will match "mississippi".
Regex /m[isp]+/ will match "miss".
Regex /m[isp]+/ will NOT match "sim", because m must be placed before i, s and p.

In many cases, you may want to put a lot of characters into a character class. Declaring all of them can be cumbersome though. In that case, you can define a range of characters in the character class. The syntax for a range is two characters with a hyphen in between them, such as a-z and 0-9.

Regex /[a-z]/ will match any one character in the alphabet.
Regex /[a-z]/ will NOT match a number.
Regex /[a-z]/ will NOT match a whitespace character.
Regex /[a-z]+/ will match any characters in the alphabet, one or multiple (i.e. a word).
Regex /a[a-z]+/ will match any word starting with the letter a.
Regex /a[a-z]+a/ will match any word starting and ending with an a.
Regex /a[a-z]+a/ will NOT match "a hyena", because whitespace is not included in the character class.
Regex /a[a-z ]+a/ will match "a hyena", because whitespace is now included in the character class.
Regex /a[a-z\s]+a/ will match "a hyena", because \s represents a whitespace character.

You can define any number of ranges in a character group, just add them as you need.

Regex /[1-3]/ will match one of the integers 1, 2 and 3.
Regex /[1-36-9]/ will match one of the integers 1, 2, 3, 6, 7, 8, 9
Regex /[6-91-3]/ is the same as above, just a suspicious way to write it...
Regex /[1-36-9]/ will NOT match any of the integer 4, 5 or 6.
Regex /[a-z0-9] will match any lower-case letter or any integer.
Regex /[0-15-7A-Ceg]/ will match any of the characters 0, 1, 5, 6, 7, A, B, C e and g.

// Remember that regexes are case sensitive without the i flag?
Regex /[a-z]/ will match any lower case letter.
Regex /[A-Z]/ will match any upper case letter.
Regex /[a-zA-Z]/ will match any letter, upper or lower case.
Regex /[a-z]/i will match any letter, upper or lower case, because the i flag is specified.

Now, do you remember reading about multi-special characters? Characters which can both behave as a regular character and a special character. A hyphen is one of those. Most often, it is treated as a normal character, but within a character class it is instead used as the range syntax. This also means that you will have to escape the hyphen character if you would want the character class to use it to find matches.

Regex /[a-c]+/ will match "aaa", "abc", "acb" and "cccccc".
Regex /[a-c]+/ will match NOT matchc "a-a", because it contains a hyphen.
Regex /[a\-c]+/ will match "a-a", "a-c", and "c-a", because the hyphen is escaped (and treated as a hyphen character).
Regex /[a\-c]+/ will NOT match "abc", because the hyphen is not a range character, so b is not included in the character class.
Regex /[a-c\-]+/ will match "a-a" and "abc", because we both have a regular hyphen and a range character in the character class.
Regex /a-[cd]/ will match "a-c" and "a-d", because a hyphen outside a character class is treated as a hyphen.
Regex /a-[cd]/ will NOT match "ac" or "ad", because the hyphen is required.

You will use character classes a lot when writing regex. Although, most of the times you will use the same ones over and over again. The ranges a-z, A-Z and 0-9 is very common to use in regexes, especially when they are combined with quantifiers to match any word or sequences of words.

Regex /[a-z]+/ will match any word, but no whitespaces.
Regex /[a-z\s]+/ will match multiple words.
Regex /the[a-z\s]+green/ will match any text that starts with "the" and ends with "green".

Observant readers may have noticed that I used the special token \s as a replacement for a whitespace within a character group in one of the examples here above. You can use the special tokens within character classes as normal, just as you would use them outside of a character class.

Regex /a\scobra/ will match "a cobra".
Regex /a\scobra/ will NOT match "acobra", because the whitespace is required.
Regex /a[abcor\s]/ will match "a cobra".
Regex /a[abcor\s]/ will match "acobra", because the whitespace is not required.

Negative Character Classes

Alternative names: negative bracket expressions

Syntax: [^]

When you write a caret (^) at beginning of a character class, it will be treated as a negative character class. Negative character classes are the opposite to character classes. They work in the same way as character classes, but instead of declaring which characters to be present, it instead defines which characters that must no be present.

Regex /pineapple/ will match "pineapple".
Regex /pin[e]apple/ will match "pineapple".
Regex /pin[^e]apple/ will NOT match "pineapple", because the letter e is not allowed between n and a.
Regex /pin[^e]apple/ will match "pinkapple", because it is only the e between the n and a that is forbidden.

Combine Character Classes with Quantifiers

Just as with regular character literals and special tokens, character classes only substitutes a single character unless combined with a quantifiers.

Regex /[0-9]/ will match 3 or 8, but NOT 38.
Regex /[0-9][0-9]/ will match 38, but NOT 3 or 8.
Regex /[0-9]{2}/ will match 38, but NOT 3 or 8.
Regex /[0-9]{1-2}/ will match 38, 3 or 8.
Regex /[0-1][0-9]{2}/ will match a three digit number starting with 0 or 1.
Regex /0[1-9]{2}-[0-9]{7}/ will match a phone number on format 0XX-XXXXXXX.
Regex /[0-1]+/ will match any binary number.

Regex Groups 101 - Or Operator

Groups is one of the most difficult things to understand with regex, and they are rarely needed in daily work. For that reason, they will be explained in the next article in this regex series. Right now, we will satisfy by look at a simple and very frequent use case of it, to include only one of two or more words in regex. To do that, we use the or operator, the pipeline character.

Regex /(a|b)c/ will match "ac" or "bc", but NOT "abc".
Regex /(a|b)c/ will NOT match "c", because a or b is required.
Regex /optimi(s|z)ation/ will match "optimisation" or "optimization".
Regex /(red|blue)/ will match "red" or "blue", but NOT "redblue" or "lue".
Regex /(red|blue) color/ will match "red color" or "blue color", but NOT " color".

Greedy Modifier

Alternative names: greedy quantifier, greedy operator

We have already seen that the question mark symbol can be used as a quantifier to specify that the preceding character shall be matched zero or one times. The question mark has another important usage in regex though, it is also used as the greedy modifier, which makes a quantifier "lazy" instead of "greedy".

Normally, quantifiers are greedy. This means that they will try to match as many characters as possible. If the greedy modifier is added after a quantifier, that quantifier will instead match as few characters as possible.

The greedy modifier makes the preceding character match as few characters as possible

Try greedy modifier on Regex101

Become a Regex Sensei

We have now went through almost everything there is to know about regex syntax. There are a few things left to know to take the step from regex expert to ninja. Those things will be covered in an upcoming article.

If you enjoy regex and puzzle games, you can the programmer puzzle game at my website. Regex will be needed to know for the more advanced levels!

Do Contexts in Next.js 13 Make the Whole App Render on the Client?

dennis@perssondennis.com (Dennis Persson) — Sun, 30 Jul 2023 00:00:00 GMT

React contexts are quite crucial for React development. Most projects depends on it, either directly or through libraries. The question is, can they be used with Next.js 13 App Router? And can the application still benefit from the power of Server Components when contexts are used? Let's answer that!

Difference Between Client and Server Components

For this article to make sense, you should have grasp about what the difference between Client Components and Server Components are. In Short, Client Components are regular old React components rendered with JavaScript on the client, while Server Components are React components which are rendered into HTML on the server. The rendered Server Components can then be used as none-interactive components anywhere in the applications React tree.

Does it make sense? If not, you can learn more about Server Components, read Next.js docs about it or my article about, why Server Components matter.

Can I Use React Context in Server Components?

React contexts are well used in React applications to share states between components. Since Client Components and Server Components are rendered on different machines, the client and the server, you might think that React contexts cannot be used.

Server Components are simply HTML markup which certainly don't have a React state. If you try to use a context in a Server Component it will throw an error.

ReactServerComponentsError:

You're importing a component that needs useContext. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default.

-[/path/to/file/MyComponent.ts:1:1]
1 | import { useContext } from 'react'

While Server Components are incompatible with React contexts, Client Components can handle them perfectly fine. As long as you provide the context provider in a Client Component, all Client Components in that component's child-tree will be able to read and use the context. It doesn't matter whether you have any Server Components in the sub-tree or not, Server Components are HTML markup, which don't care!

It's not you, he's always like that...

Will My Complete Next.js Application Be Rendered on Client if I Use React Contexts?

The answer is no. Your whole site will not be forced to render on the client if you use React contexts. As mentioned, Server Components do not care about contexts, which also means it doesn't interfere with them.

Let's list a few statements about Next.js App Router.

The RootLayout in Next.js is always a Server Component
The children prop passed to RootLayout is also a Server Component
Server Components can include Client Components (the Client Components will be ignored when the server renders the Server Component)
Server Components can be included in Client Components if they are passed as children to the Client Component

Now look at this code example, it's taken from Next.js guide for how to set up contexts.

import { ContextProviders } from './providers';

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <ContextProviders>{children}</ContextProviders>
      </body>
    </html>
  );
}

What we can see in that code is:

The Root Layout, which is a Server Component by statement #1
The ContextProviders component which includes the contexts is a Client Component (statement #3 allows that)
The children prop for the RootLayout is a Server Component (statement #2)
The children is passed to the ContextProviders Client Component (accepted by statement #4)

By default, Next.js can handle intervened Client and Server Components, and with this setup we are following all the rules of how to use the components. The above code will result in a React tree looking as below.

<RootLayout (Server Component)>
  <ContextProviders (Client Component)>
    <Page (Server Component)>
      <Potential other Client Components using the context />
      <Potential other Server Components ignoring the context />
    </Page>
  </ContextProviders>
</RootLayout>

Although using contexts work fine, it does create a bit of confusion. You must remember that you will only be able to use the context within Client Components, the context is not available on the server.

Errors Received When Migrating Next.js 13 to New App Folder

dennis@perssondennis.com (Dennis Persson) — Sun, 18 Jun 2023 00:00:00 GMT

Next.js is evolving. Fairly recently, Next.js has added a new powerful routing mechanism which is used but adding files to the a app folder instead of the old pages folder. With new routing and new features like Server Components, comes also new errors to detect. This article will present solutions to four errors which are likely to happen the first hour of trying out the new Next.js features.

Exporting Async Server Component When Fetching Data

Error: 'MyComponent' cannot be used as a JSX component. Its return type 'Promise' is not a valid JSX element

Reason to error: You are using an old version of TypeScript

Solution: Bump TypeScript or suppress the error with @ts-expect-error

Note: This error is a TypeScript error. Next.js 13 is TypeScript-first. which means you have to opt-out of it if you don't want it

To fetch data in server components, Next.js recommends trying out their built-in fetch API which is based on an RFC. Their example code for that uses an async Page function.

The problem arise when trying to use an async component like that in another page component. Doing that, will result in a TypeScript error.

'MyComponent' cannot be used as a JSX component.
  Its return type 'Promise<Element>' is not a valid JSX element.
  Type 'Promise<Element>' is missing the following properties from type 'ReactElement<any, any>': type, props, key

The error is thrown since the used TypeScript version doesn't recognize the async component. The issue has been solved recently in TypeScript version 5.1.3, but if you are bootstrapping templates or if you are checking out old git repositories you may have an outdated TypeScript version.

The solution is therefore to bump TypeScript version. If that for some reason cannot be done, you can suppress the warning with @ts-expect-error, which was the recommended solution from Next.js before it was fixed in TypeScript.

export default function Home() {
  return (
    <main>
      {/* @ts-expect-error Server Component */}
      <MyComponent />
    </main>
  )
}

Server Components Are Not the Same as Client Components

Error: You're importing a component that needs useState. It only works in a Client Component

Reason to error: You are using client-side only functionality in a Server Component

Solution: Add 'use client' directive to convert the Server Component to a Client Component

The most fundamental part when upgrading to Next.js 13 is to understand Server Components and Client Components. Traditionally in React and Single Page Applications (SPA) overall, the application has been rendered on the client side, in contrast to even more traditional websites that were rendered on the server. In modern programming, rendering is shared between the client and the server.

Next.js 13 gives you the full power to granularly fine-tune where you want to render each of your component, either on client or server, dependent on your needs. If you don't actively state that a Client Component should be a Client Component, you will run into a ReactServerComponentsError error.

ReactServerComponentsError:

You're importing a component that needs useState. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default.

-[/path/to/file/MyComponent.ts:1:1]
1 | import { useState } from 'react'

The error above will show up when you have a component or hook which uses some client-side only functionality, but which isn't explicitly declared with a "use client" directive.

import { useState } from 'react'

const MyComponent = () => {
  const [value, setValue] = useState()

  // Some code...

  return <div>{value}</div>
}

export default MyComponent

To fix the error, simply add the "use client" directive at the top of the file.

'use client'

import { useState } from 'react'

const MyComponent = () => {
  const [value, setValue] = useState()

  // Some code...

  return <div>{value}</div>
}

export default MyComponent

Before you convert your component to a Client Component, take a minute to reflect over if you really need a Client Component or if you are better off with a Server Component. I think Next.js explains very well which one to use with a simple table.

A good rule of thumb, only use a Client Component if you need browser functionality or keeping a state

In short, one can say, components and hooks which uses useState, useReducer and useEffect are client-side components/hooks.

Secondly, components which relies on user interactions via the DOM tree are client-side, which means that DOM elements which have attached listeners like onClick and onChange belongs to Client Components.

A third case is also when the component or hook relies on a web API such as Geolocation API. There exist a lot of Web APIs, and they are often meant to run in a browser.

Using Client-Side Hooks in Server Components

Error: Attempted to call the default export of /path/to/file/file.ts from the server but it's on the client

Reason to error: You are using client side functions in a Server Component

Solution: Convert the component to a Client Component or create a sub-client-component which uses the hook

In the previous header, we learned briefly what Server Components and Client Components, are and that we have to mark Client Components with the "use client" directive. That error was then resolved by using the directive, since Client Components can be used anywhere in Server Components. However, if the component you converted to a client component is a hook, you may see another error as well.

Let's say we have this hook:

'use client'

import { useState } from 'react'

const useSomeClientOnlyCode = () => {
  const [value, setValue] = useState()

  // Some code...

  return { value }
}

export default useSomeClientOnlyCode

Then we use it in a Server Component as follow:

import useSomeClientOnlyCode from '@/hooks/useSomeClientOnlyCode'

const MyServerComponent = async () => {
  const { value } = useSomeClientOnlyCode()

  return(<div>{value}</div>)
}

If we run this code, we will see an error like this:

Error: Attempted to call the default export of /path/to/file/useSomeClientOnlyCode.ts from the server but it's on the client. It's not possible to invoke a client function from the server, it can only be rendered as a Component or passed to props of a Client Component.
    at Component (./app/server-components/MyServerComponent.tsx:12:118)
    at stringify (<anonymous>)

What is happening here, is that the hook contains client-side only code and is used in a Server Component. Whilst Next.js supports Client Components in Server Component, they don't support client functions or hooks to be used in Server Components.

Hooks are essentially just a part of a component, so if a hook uses client-side logic, then the whole component must be a client side Component as well.

The trivial way to solve this error is therefore to declare the component which uses the hook as a Client Component, by using the "use client" directive.

'use client'

import useSomeClientOnlyCode from '@/hooks/useSomeClientOnlyCode'

const MyServerComponent = async () => {
  const { value } = useSomeClientOnlyCode()

  return(<div>{value}</div>)
}

If you don't want to convert your whole component to a Client Component you can always lift out the parts of the component which utilizes the hook into a child component, and then make the child component a Client Component.

const MyServerComponent = async () => {
  return(<div>
    <MyClientComponentWhichUsesTheHook />
    <div>Some other server rendered elements...</div>
  </div>)
}

Infinite Loading With Next.js 13 Development Server

Error: Node.js development server does not work

Reason to error: Varies, in my case I had an async Client Component

Solution: In this case, remove the async keyword

Next.js 13 introduces a new app folder, which offers a new and improved way to perform routing. I have been using Next.js 13 a long time with the old pages folder without any issues with the development server or build, but as soon as I tried to use the new app folder I ran into severe problems. The development server wasn't working.

What happened in detail was that the web page never finished loading. Next.js hot reloading didn't work, and the page stopped responding. Even when I stopped the development server it continued to serve a non-working build on the port.

I read GitHub threads as Next.js dev server gets stuck after a while, requests just spin and browsed Stack Overflow for similar errors. Nothing could fix my problem. Changing ports didn't help, and neither did upgrading or downgrading versions of node or packages. Removing node_modules, .next folder and package-lock.json or swapping to Turbopack did nothing good.

It was really frustrating to troubleshoot when Next.js development server didn't work. And when I finally found the solution, the culprit wasn't more than five characters long. You recognize that feeling, don't you?

My mistake was a silly copy-paste mistake after having tested out to use fetch in a Server Component. Lesson learned there, look out so you don't have any Client Components with the async keyword. Only Server Components can be async in Next.js.

If you find any async Client Component in your code, remove the async keyword and start the development server again on another port with next dev -p 1234.

Should You Use Next.js 13?

If you already are using Next.js 12 and are thinking if you should migrate to version 13, I would say, do it. Next.js 13 is more or less backward compatible. You can bump to 13 and partly upgrade to use the new features according to your time and requirements. See their migration guide here.

If starting a new project or migrating an existing one to version 13, you should know that some of the features are still in beta. The app folder routing which is discussed in this article is production ready since version 13.4.

If you are not using Next.js at all, try it out. Remember that React itself is still just a library. Next.js is a complete framework based on React which have just made it all better.

I'm here to extend you didn't sound as good...

How to Avoid Estimating Time Using the Agile Metrics Velocity and Capacity

dennis@perssondennis.com (Dennis Persson) — Sun, 20 Mar 2022 00:00:00 GMT

I read this article on DEV asking about how to deal with estimates. It's a great question to ask and it reminds me of my days at the University. Teachers told me not to estimate projects in time. Later I became a teacher myself and I brought that knowledge on to my own students. Honestly I didn't really understand back then how to actually do that.

I started working at a company in the Volvo Group concern and my team used points for estimations. Except, they didn't. The truth is they only believed they were doing that but in reality, they used time as a measurement. Roughly they defined each point as one day of work for two developers pair programming. They empathized we shouldn't think about it as time, rather as points. In the end, the points were still bound to time so we were in reality still estimating time.

I must say I was a bit tired of people urging to use points over time when it in practice was the same thing. It was somewhere there I actually figured out how to get time out of the picture completely.

How to Use Agile Metrics to Avoid Measuring Time

Substituting time for points is a great start. It's hard to estimate what time something will take and it's even harder to estimate how much time will be spent on other tasks, assignments, meetings, bug fixes, testing and unexpected hindrances.

The tricky part is how to make the points time independent. The solution to how to do that is to calculate a velocity using the outcome of the previous work. Velocity is basically the amount of story points your team succeeds to develop in a sprint on average.

When you know the velocity, you can calculate what capacity the team has in an upcoming sprint. The capacity is what is left of the velocity points after having removed team member vacancies and time allocated to other work, such as maintenance and bug fixes.

Even though many people know about the terms velocity and capacity, many teams neglect the velocity and fixates the capacity to a constant number instead of calculating it from on the velocity. By doing that they miss the whole point with it. The purpose of velocity and capacity is to make points time independent.

A constant capacity is nothing other than masqueraded time. By recalculating the velocity, the team's capacity will become dependent on the team's actual work effort rather than time.

It doesn't matter what you call it, it's still time behind the mask if you ignore velocity

You Can Not Compare Developer Performance

Not all developers work equally fast. One story can take hours for one developer and days for another. After a couple of month or so, the second developer may have become better and can work faster than before. You can't easily estimate performance of developers and say that one developer works half as fast as another one. I will vary dependent on work tasks and as time goes.

One thing you can do though, is to evaluate performance. That is exactly what is done when you calculate a velocity. You look at the tasks that have been done recently by the whole team to get a concrete number of which velocity the team has. That number can be used to estimate what capacity the team has for the work ahead.

Estimation cycle. Use the velocity when planning upcoming work

The Process of Planning a Sprint

Enough of chattering. Let's describe how to plan a sprint the agile way and how to get the estimation to be time independent.

1. Break Down Features Into Stories

Make sure you have divided each feature to be developed into small tasks (stories). There's no way you will succeed estimating tasks that are greater than a few days or a week in size. On top of that, destructuring features into smaller tasks will help you plan your work and foresee possible pitfalls.

2. Assign Points to Stories

Let the developer team together estimate how many points each story should be assigned. You can preferably use Planning Poker to let every team member vote without being influenced by other teammates.

When assigning points, you can think of some abstract size of the story. Is it a small, mid-sized or large task? Or, you can actually think in time; will it take around one, three or five days to implement? That may sound strange since the goal is to avoid thinking in time, but it's actually completely fine and it falls natural to humans to do that. Merely by using the approach I describe in this article, you will go from speaking about points and estimating time, to speak about time and estimating points!

If your idea of one day of work is inaccurate, that won't be an issue. When the velocity is adjusted later on, your idea of time will be corrected so the points you assign to the task reflects you real work. No worries if you get headache trying to understand that, we will get back to that later.

3. Develop

You can't spend all time in meetings. Do the work you have planned to do. If you are familiar with Scrum and agile methodologies, this will be you sprint, commonly a period of two weeks.

4. Adjust the Velocity

This is the step most people forget about, which is unfortunate. Without this step you are measuring time and not points! What you should do here is to calculate how many points you had time to develop during the sprint. That is the velocity you had that sprint. Take the average of that velocity and each velocity a few sprints back in time and the result is the velocity your team have.

5. Repeat

Continue the process from the beginning, starting by breaking down new stories and then assigning them points. This time, you will have another velocity than you had when you planned your previous sprint, hopefully better reflecting how much work you actually will have time to do.

Regardless whether you thought in points or if you thought in time when you planned your last sprint, your new velocity will "give you" either less or more points when you calculate the capacity you have in the next sprint.

Note: The example below assumes the complete velocity is counted as capacity. Normally you will count away parts of the velocity when determining the capacity to adjust for absence and maintenance etc.

Maybe you originally had a capacity of ten points for a two weeks long sprint and you planned to do ten one-point stories. If you had time to do some extra work and your new velocity turned out to be 12 points, then each day in the sprint would equal to 1.2 points.

When you plan your next sprint, you can continue estimating the stories the same way you did the last sprint. Your new velocity will correct the estimation error you did when you estimated the stories. What you thought to be one point, or one day of work, turned out to take around 0.8 days (1 / 1.2 ≈ 0.8).

With the new velocity at 12 points per sprint, you will get the capacity to plan 12 points into the next sprint, which is more likely to better match the actual workload you will have time to complete. Repeating this process for each sprint will eventually make your estimations fairly accurate.

If you estimate to fit ten one-point stories into one ten days sprint and it turns out you have time for 12 of them, then your velocity that sprint was 12 points, i.e. 1.2 points per day

Conclusion

All teams try to estimate workload, a lot of them using agile methods like Scrum. Many of them are aware of the concepts of velocity and capacity and knows they should be measuring points rather than time when estimating their stories. Unfortunately, a lot of teams forget to consider their velocity when they calculate their capacity for a sprint.

When a team forgets to consider the velocity, their estimation in story points becomes nothing other than an estimation of time. They will plan each sprint with a fixed number of points, which in turn will correlate to a fixed amount of time.

This is a problem because humans aren't good at estimating time. By ensuring to recalculate the velocity after each sprint, you will be able to measure how much work you are able to finish in reality. The recalculated velocity will adjust for any misestimations you do when the work is planned.

Every Way a Startup Can Fail

dennis@perssondennis.com (Dennis Persson) — Sun, 02 Nov 2025 00:00:00 GMT

Startups and relationships have a lot in common. Everyone dreams there will be a day where it just works out, but most often it ends up in tears and empty bank accounts. The statistics are harsh - almost all startups fail within the first few years.

Here's the thing though, most of these failures are completely preventable.

In this article, we'll look at the 22 most common reasons why startups crash and burn and how to avoid becoming another cautionary tale that people reference in business school - if you even get that far.

1. Founders Give Up Too Easily

Let's start with the most obvious one - founders simply give up. Maybe the idea was wrong from the beginning, or maybe startups just aren't for you. And you know what? That's totally fine.

The truth is, not everyone is cut out for the startup life. It might seem perfect in your dreams, but just like having a toddler in a relationship, you'll be up at 3 AM debugging production issues while your friends post vacation photos from Bali.

At that point, you might start questioning your life choices.

The Problem: Many founders start with a romanticized view of entrepreneurship. They think it's all about working from coffee shops and making millions while wearing hoodies.

Reality hits hard when you realize you're working 80-hour weeks for months without a paycheck.

The Solution: Before you quit your day job, ask yourself some hard questions:

Are you prepared to work harder than you've ever worked in your life?
Can you handle the uncertainty and stress?
Do you actually believe in your idea, or are you just chasing the startup dream?

If you're not 100% committed, save yourself the heartache and stick to your day job. There's no shame in that.

Sometimes your coffee and your motivation run out at the same time

2. Founder Team Conflicts

This is the classic "we're best friends, so starting a business together will be fun!" scenario they teach you in school. Remember all those weeks you spent writing team contracts before you implemented the actual product in a day or two?

The Problem: Founders often have different visions, work styles, and expectations.

What starts as a beautiful partnership can quickly turn into a toxic relationship that makes your last breakup look like a walk in the park.

The Solution: Before you start anything, have the uncomfortable conversations:

What Do You Want and Why?

Sit down with your co-founders and discuss:

What's your end goal? IPO? Acquisition? Lifestyle business?
How much money do you want to make?
How long are you willing to work without a salary?
What's your exit strategy?

What's Important?

Decide on your priorities:

Are you building for growth or profitability?
How important is work-life balance?
What's your risk tolerance?

How Do You Make Decisions When You Disagree?

This is crucial. Have a clear process for resolving conflicts:

Who has the final say on what decisions?
How do you handle deadlocks?
What happens if you fundamentally disagree on the direction?
What happens if one of you wants to quit?

Remember, it's better to have these conversations now than when you're in the middle of a crisis and emotions are running high.

Losing a company or a friend - why not both?

3. Giving Away Too Much Ownership

Giving away too much ownership can be troublesome if the other people quit or aren't actively involved. Investors dislike investing in companies owned by people who don't help move the company forward. They want the owner to have a strong incentive to stay involved.

The Problem: Many founders give away large chunks of equity to co-founders, early employees, or investors without thinking about the long-term implications.

When someone owns a significant portion of your company but isn't contributing anymore, it creates a major problem.

The Solution:

Keep majority ownership: As the founder, you should always maintain control of your company
Use vesting schedules: Make sure equity is earned over time, not given away upfront
Be careful with investors: Remember, investors also take parts of the ownership that the founder loses
Think long-term: Don't give away equity just to solve short-term problems
Document everything: Have clear agreements about what happens if someone leaves

4. No Market for Your Product

This is the mother of all startup failures. You build something amazing, launch it with fanfare, and then... silence.

The Problem: Too many founders build products based on what they think people want, rather than what people actually want.

They fall in love with their idea and assume everyone else will too.

The Solution: Never build a product before you know you have a market. Here's the process:

Start with Market Research: Talk to potential customers. Lots of them. Figure out what problems they experience in their lives today
Validate Your Assumptions: Don't just ask if they like your idea - ask what they'd pay for it
Have a Clear Customer: Know exactly who your customer is, what problem they have, and how you're solving it

The worst thing you can do is spend months building something only to discover that no one actually needs it. Trust me, it's not as easy as putting your meal in the freezer and ordering pizza when you find out your guest is allergic to the dish you made - it's a real breakup with your company.

If the math doesn't work, don't build it. It's that simple. You can't wish your way to profitability.

It's a fine line between having customers and having paying customers

5. Your Product Costs Too Much

Here's a harsh truth: the worst idea isn't the one that fails after a week. The worst idea is the one you spend years and thousands of dollars on, only to realize it can never be profitable.

The Problem: Founders often underestimate costs and overestimate what customers are willing to pay.

They build increasingly advanced solutions when the intended customers are perfectly fine with simple alternatives.

The Solution: Do the math before you build anything. When you know what the customer wants:

Calculate Your Costs: Development, marketing, operations, everything
Determine Your Price Point: What will customers actually pay?
Check the Numbers: Will you make enough profit to sustain the business?

Some early calculations could have told you day one that it wouldn't work

6. Too Much Competition

Sometimes the market is just too crowded. You might have a great idea, but if there are already 50 companies doing the same thing, you're going to have a hard time standing out.

Just like on the dating market, no one searches for the vanilla ice cream partner they can find anywhere - they want that Ben & Jerry's or the kind with a sweet cherry on top. If you aren't completely sure you can offer luxury like that, you better go for something with less competition.

Of course, it could be possible to go the Spotify way and do something no one else would dare to touch, to be bold and challenge both record labels and pirates, risking both lawsuits and competing against "free" options for music.

However, you have to be a real unicorn to succeed with that and probably quite a bit of a narcissist to even believe you can succeed with it.

The Problem: Entering a saturated market means you're competing on price, features, and marketing spend.

Unless you have a significant advantage, you're fighting an uphill battle.

The Solution: Either find a niche within the market or pivot to something less crowded. Don't try to be everything to everyone - find a specific problem that no one else is solving well.

7. Too Little Competition

Wait, isn't no competition a good thing? Not necessarily. If an idea sounds too good to be true, it probably is.

Maybe you don't see it the first weeks or year, but with time you might start noticing some red flags.

If you find a new idea, try to investigate why it doesn't exist. You might find a reason to why it isn't a good idea, or even better, find a solution to the issue others had.

The Problem: If there's no competition, there might be no market.

Other companies have likely tried similar ideas before and failed for a reason.

The Solution: If you have no competition, it's even more important to validate that customers actually need your product and are willing to pay for it. Don't assume you're the first person to think of this - you're probably not.

8. Bad Timing

Timing is everything in startups. You can have the best idea in the world, but if you launch at the wrong time, you're doomed.

Remember Pokemon GO? On their first release they had severe problems with overloaded servers and security issues. It wasn't a production-ready product and they lost a third of their users in a month (15 million users).

On the other hand, they released the app in July when the majority of its players (living in the Northern Hemisphere) had summer and school holidays.

Their option would have been to release it later in the Autumn or Winter when people want to stay inside, or to wait almost a whole year until spring comes around again. Maybe the timing was worth all the production issues after all?

The Problem: Being too early means the market isn't ready for your product.

Being too late means someone else has already captured the market.

The Solution: Pay attention to market trends and timing. Sometimes it's better to wait for the right moment than to rush to market with the wrong timing.

Think you start to see a pattern here...

9. Not Being Quick Enough

Startups bleed money - we're talking millions per month or even millions per week. If you aren't quick, you will bleed out. Plus, if you aren't quick enough to win the market, someone else will take it right in front of your eyes!

The Problem: Many founders get stuck in analysis paralysis, trying to perfect everything before launching.

Meanwhile, their competitors are moving fast, capturing market share, and building momentum.

In the startup world, speed is often more important than perfection.

The Solution:

Move fast without breaking things: Everything doesn't have to be pitch perfect
Launch early, iterate often: Get something out there and improve based on feedback
Set aggressive timelines: If you think it will take 6 months, aim for 3
Don't over-engineer: Build the minimum viable product, not the perfect product
Make decisions quickly: Don't let perfect be the enemy of good

Remember, a mediocre product that launches today is better than a perfect product that launches next year. The market doesn't wait for anyone.

10. Cash Flow Problems

This is extremely common and often fatal. A company can have a huge net worth and tied-up capital but still fail because it can't pay its bills this month.

The value of the company and its theoretical capital doesn't matter if they don't have liquidity to pay their bills. If the cash stops flowing, the company will stop glowing.

The Problem: Many startups focus on revenue and growth but ignore cash flow.

They might be making sales, but if customers take 90 days to pay while you have bills due every 30 days, you're in trouble.

The Solution:

Monitor your cash flow religiously
Have a buffer for unexpected expenses
Don't spend money you don't have
Consider payment terms when making sales

Cash is king in startups. You can have the best product in the world, but if you run out of cash, you're done.

11. Gambling With Money

Here's a simple rule: gambling is gambling. Whether you're at a casino or starting a business, spending more money than you have comes with risk.

Your company might be founded on loans and investments that might be lost if the company doesn't work out - that's fine, it might be the only option you have.

Gambling with your company's liquidity so it could go below zero any day if you don't get your expected revenue in time is not okay.

It isn't fair to your investors, employees, partners or customers who could lose all their investments just because you decided to expose the company to a completely unnecessary risk. And trust me, they will not be happy when you tell them - I have been on the receiving side of this.

The Problem: Some founders spend money they don't have because they assume success is guaranteed if they just work hard enough.

They blindly invest money and hope they will find a way to get the money in time.

The Solution: If you're going to gamble with money, really think over that decision. Ask yourself:

Can you afford to lose this money?
What's your backup plan if things go wrong?
How long can you survive without income?
Am I gambling with other people's money?

Remember, there's a difference between calculated risk and reckless gambling. Make sure you know which one you're doing.

Sometimes it's not only the owner of the company who gets affected

12. Scaling Issues and Technical Debt

Despite what was said in the previous point, you don't want to end up in a company-wide "it works on my machine" state. Make sure to get the overall architecture in place so you know how you should scale your application the day it's time for it. And remember, that could be tomorrow.

The Problem: Many startups build quick and dirty solutions to get to market fast, which is smart.

But they never go back to clean up the mess. Before you know it, you're spending more money on band-aids than you would have spent building it right the first time.

The Solution: An MVP is probably enough to start, but make sure it's good and can scale! Here's what that means:

Build for the future: Don't just build for today's 10 users, think about tomorrow's 10,000
Pay down technical debt: Set aside time and money to refactor and improve your systems where bottlenecks can appear and for core functionality
Hire the right people: Don't just hire developers who can code fast - hire ones who can build systems that last

13. First-Time Founder Syndrome

A first-time founder who doesn't know how to run or scale a company is like a pilot who's never flown before - they might get the plane off the ground, but keeping it in the air or landing it safely is a whole different story.

The Problem: Many first-time founders are great at building products but have no idea how to run a business.

They don't know how to hire, manage people, handle finances, negotiate deals, or scale operations.

They learn everything the hard way, which is expensive and time-consuming.

The Solution:

Get a mentor: Find someone who's been there and done that
Read books: There are plenty of resources on entrepreneurship and business management
Take courses: Invest in your business education
Hire experienced people: Don't be afraid to hire people who know more than you
Join founder communities: Learn from other founders' mistakes
Start small: Don't try to build a unicorn on your first try

Remember, being a first-time founder isn't a death sentence - it's just a learning curve. The key is to recognize what you don't know and actively work to fill those gaps.

14. Not Using Your Data

Data-driven decisions are key to success. It's one of the most important tools for making good decisions for a company. If you don't do it, you have no idea where your company is going - you are basically blindfolded.

You might have a great vision in your mind, but without clear sight others might reach your customers before you.

The Problem: Many startups collect tons of data but don't actually use it to make decisions.

They rely on gut feelings, hunches, and "what feels right" instead of what the data tells them.

Soon enough, they realize they made a big mistake which cannot be undone.

The Solution:

Collect the right data: Focus on metrics that actually matter
Analyze regularly: Don't just collect data, use it
Make data-driven decisions: Let the numbers guide your strategy
Share insights: Make sure your team understands what the data means
Iterate based on data: Use what you learn to improve your product

Remember, data doesn't lie. Your gut feelings might.

Didn't have to be new if you would have read my article...

15. Poor Customer Service

There's a reason why most big companies try to include "customer service" in their mission statement. I know there are lots of companies that succeed even though they treat their customers poorly, but after all, the customers are what makes the company successful.

Creating a company is really expensive. A great deal of that is finding, reaching out to and convincing customers. When you have them there, you better keep them there. Their opinions will affect how quickly you gain or lose new customers.

The Problem: Many startups focus so much on acquiring new customers that they forget to take care of the ones they already have.

Bad customer service can kill your reputation faster than anything else.

The Solution:

Make customer service a priority: Not an afterthought
Respond quickly: Customers expect fast responses
Empower your team: Give them the tools and authority to solve problems
Listen to feedback: Your customers will tell you exactly what's wrong with your product
Measure satisfaction: Track NPS, response times, and resolution rates

Remember, it's much cheaper to keep an existing customer than to acquire a new one.

16. Branding and Reputation Issues

A bad reputation is something that could definitely kill a company. Although your branding might not kill your company, a lack of branding could definitely be a reason for your company to not succeed and in the long term kill your company.

The Problem: Many startups think branding is just about having a nice logo.

But branding is about how people perceive your company, and that perception can make or break you.

Your whole company and all your products should breathe your brand.

The Solution:

Define your brand: What do you stand for? What makes you different?
Be consistent: Your brand should be reflected in everything you do
Build trust: Your reputation is your most valuable asset
Monitor your brand: Know what people are saying about you
Respond to criticism: Don't ignore negative feedback

17. Regulatory and Legal Problems

Make sure you know the market you enter and the regulations you need to follow. Mistakes can cost you money, time, and your reputation - sometimes all three at once.

The Problem: Many founders focus so much on building their product that they forget about the legal and regulatory requirements.

By the time they realize they're breaking the law, it's too late.

The Solution:

Do your homework: Research the regulations in your industry and market
Get legal advice: Don't try to be your own lawyer
Build compliance into your product: Don't bolt it on later
Stay updated: Laws change, and ignorance isn't a defense

Whether it's data privacy laws, industry regulations, or employment law, compliance isn't optional. It's part of doing business.

18. Partner and Vendor Issues

Make sure you know the terms of your contracts and that you're not getting ripped off. Your suppliers' failures can be your own failure. Think twice before you sign a contract with a supplier or choose a partner.

Your vendor's "99.9% uptime" means they're down when you need them most

The Problem: Many startups rely heavily on third-party vendors and partners, but they don't properly vet them or understand the terms of their contracts.

When a vendor fails, the startup fails too.

The Solution:

Vet your vendors: Check their track record, financial stability, and references
Read the fine print: Understand your contracts inside and out
Have backup plans: Don't put all your eggs in one vendor's basket
Monitor performance: Track uptime, response times, and quality
Negotiate terms: Don't just accept whatever they offer

Remember, you're only as strong as your weakest link. Choose your partners wisely.

19. Founder Burnout

A common saying and truth is that investors don't invest in companies, they invest in people. The founder is the most important person in the company, and if they're not able to handle the stress and pressure of running a company, the company will fail.

A real entrepreneur's blood type is coffee

The Problem: Many founders work themselves to exhaustion, thinking that more hours equals more success.

But burnout leads to poor decisions, health problems, and ultimately, company failure.

The Solution:

Take care of yourself: Sleep, exercise, and eat properly
Set boundaries: Work-life balance isn't just a buzzword
Delegate: You can't do everything yourself
Build a support system: Have people you can talk to about the stress

Remember, you're no good to your company if you're dead or in the hospital.

20. Geographical and Cultural Issues

Just like with timing, the place and environment matter a lot as well. Don't put your sailboat in a sea with no wind. Maybe the sea isn't even deep enough.

The Problem: Many founders don't consider the geographical and cultural factors that can affect their business.

What works in Silicon Valley might not work in Stockholm, and what works in Stockholm might not work in Tokyo.

The Solution:

Research your market: Understand the local culture, regulations, and business practices
Adapt your approach: Don't assume your way is the only way
Build local relationships: Find local partners, advisors, and mentors
Consider logistics: Shipping, time zones, and local infrastructure matter
Test the waters: Start small and expand gradually

Remember, you're not just competing with local companies - you're competing with local culture and expectations.

21. Hiring the Wrong People

As mentioned earlier in this article, it's important that co-founders and early employees agree to what the company should stand for.

Something some people may forget here, is that your employees are a representation of your company and your brand as well.

Hire the wrong person, and they can single-handedly destroy everything you've built if you are unlucky.

It can be done in many ways: ruin your reputation, ruin a business deal or investment, or maybe by changing the team spirit so the company slows down or starts to drift in a wrong way.

The risks are many here. If you wonder what problem they might cause - then read this article again with the mindset of what an employee can cause.

The Problem: Many founders hire people who are technically skilled but culturally toxic, or who don't share the company's vision and values.

One bad hire can poison your entire team and drive away your best employees.

The Solution:

Culture fit matters more than skills: You can teach someone to code, but you can't teach them to be a decent human being
Take your time: Don't rush hires just because you're desperate for help
Involve your team: Let your existing employees interview candidates
Know your hirings: Take some time to learn your hiring candidates before employing them, it costs more time to make a wrong decision
Trust your gut: If something feels off, it probably is

22. Not Understanding Your Funding Model

Before we wrap up, there's one distinction that affects everything else: whether you're bootstrapped or venture-backed. These two paths have completely different failure patterns and success metrics.

Bootstrapped Startups (self-funded):

Failure Pattern: Usually die slowly from cash flow problems or founder burnout
Success Metric: Profitability and sustainable growth
Timeline: Can take years to reach meaningful scale
Risk: Lower risk of catastrophic failure, higher risk of stagnation

Venture-Backed Startups (investor-funded):

Failure Pattern: Commonly die quickly from running out of runway or missing growth targets
Success Metric: Rapid growth and market capture
Timeline: Expected to scale quickly or die trying
Risk: Higher risk of complete failure, but potential for massive success

The Problem: Many founders don't understand which path they're on or try to mix strategies. A bootstrapped startup trying to grow like a venture-backed one will burn out. A venture-backed startup trying to be profitable too early will miss growth targets.

The Solution:

Choose your path early: Decide if you're building for profitability or growth
Align your metrics: Focus on the right KPIs for your funding model
Set realistic expectations: Don't expect venture-scale growth without venture funding
Understand the trade-offs: Each path has different risks and rewards
Be consistent: Don't switch strategies mid-journey unless you're prepared for the consequences

Remember, there's no right or wrong choice - just different paths with different failure modes. The key is understanding which path you're on and playing by those rules.

The Bottom Line

Starting a business is hard. Really hard. But most failures are preventable if you're honest with yourself and do your homework.

The key is to validate your assumptions early and often. Don't fall in love with your idea - fall in love with solving a real problem for real customers who are willing to pay real money.

And remember, there's no shame in failing. Every successful entrepreneur has failed multiple times. The important thing is to learn from your mistakes and keep moving forward, and more importantly, learn from mistakes others have already made.

Don't forget, sometimes it actually works out

Extensive List of Best Development Resources - 121 Links to Guides, Cheat Sheets and More List of Resources

dennis@perssondennis.com (Dennis Persson) — Sun, 13 Nov 2022 00:00:00 GMT

This is a collection of top rated web development resources every developer needs. Roadmaps, guides, free tools, programmer books, cheat sheets and more. All articles are of high quality and you have everything from soft skills to visual explanations of JavaScript internals. If you don't think this list is complete enough, you will find a lot more list like this at the end of this article.

List of Content

Roadmaps

Roadmaps lets you know what you will have to learn to becoming a developer of some kind, providing you with useful guides and resources.

Visualized Learning

Regardless of whether you are a visual learner or not, these articles provides you with top quality visualized descriptions of how the web works in detail.

Crash Courses and Complete Guides

Complete guides and beginner guides to learn web development. Learn React and full stack development to master web programming.

For the Interview

Huge lists of questions to prepare for you next programming interview. Practise interview questions for JavaScript and React to become a software engineer.

Tools, Templates and Resources

Lists of free resources and tools for programmers. Browse through templates and other tools every designer needs.

Soft Skills, Career and Productivity

Boost your programmer career with soft skills and productivity tips. Tips to get the job you want and to be a better programmer.

Algorithms and Data Structures

Learn algorithms and data structures for both beginners and more advanced use cases.

Lists of Programmer Books

A list of lists with programmer books developers need to read. Find the most recommended programming books.

Coding Tips and Tricks

Quick tips and tricks to write better code. What you need to know to write good JavaScript code.

Cheat Sheets

Cheat sheets for React, CSS, Git and programming overall. Compilation of cheat sheets to bookmark.

Security

Web development security guides to know about. Best practises with examples and beginner tutorials.

APIs

List of fun APIs to use for your next project. Find free and unique APIs for developers.

Uncatogorized Reading

Free certificates, popular git repositories and tips for how to be good at googling. Learn how to prevent sites from showing up at google.

More Lists Like This

Do you need more lists of programming resources? If this list isn't extensive enough, you can find other lists like this here.

From Programmer to Software Developer – The Skills That Make the Difference

dennis@perssondennis.com (Dennis Persson) — Sun, 01 Dec 2024 00:00:00 GMT

Programmer and developer are often used interchangeably, but there is an important distinction between them: the developer’s broader perspective and focus beyond just code. In this article, we will step back from coding to highlight the skills that define what skills a successful developer should have.

Programmer vs Software Developer

Most people know these two terms as synonyms, and they indeed are. However, if you search on Google, you'll notice there is a distinction. The difference isn't about how they work with code, but rather their perspective on work and software development.

	Programmer	Developer
Focus on	Implementation	Solving problems
Creates	Code	Solutions
Involved in	Development and testing	Full DevOps lifecycle
Works with	Code	Code and people
Takes responsibility for	The code	The product

The table above shows different perspectives that a programmer and a full-fledged developer can have. A programmer's view is narrow and focuses on code and its immediate environment: writing clean code with proper architecture, testing it thoroughly, and delivering it to the next department or pushing it directly to production.

A software developer, however, has a much wider view on development. It isn't just about writing code; it's about collaboratively building a product that solves customer problems. This rarely involves just a single team, but rather many teams across the full DevOps lifecycle, from the planning phase all the way to monitoring the deployed product.

DevOps lifecycle

This doesn't necessarily mean that a developer is working on the entire DevOps chain. The important part is that the developer understands and are involved in the full lifecycle and actively tries to improve and optimize the process. It's also about being available when other teams need assistance, so the organization as a whole can deliver a quality product.

Looking at the whole product solution is essential

Architectural Skills

Let's start with the most obvious skill a software developer needs to have - one that even programmers should possess: architecting. Though this may seem obvious, it's worth emphasizing due to its importance and the fact that many people neglect it.

A common role in software development is that of the architect. An easy mistake is believing that the team architect is solely responsible for the architecture of all applications owned by the team, which simply isn't true. Every developer should contribute to improving code architecture and must therefore know and practice it. While architects work at a higher and broader level, all developers share the responsibility of keeping the code clean.

Best Practices and Anti-Patterns

There are best practices and anti-patterns for all languages and frameworks. They differ somewhat and change over time. For example, my article about do's and don'ts in React from last year is still highly relevant, but with the new compiler in React 19, several of those 17 rules will become outdated.

What's important to remember is to always research best practices and anti-patterns when starting with a new language or framework. Those hours of reading saves significant time that would otherwise be spent on debugging and refactoring. In extreme cases, we're talking about months or even years of development time saved.

Design Patterns

Design patterns play a big role in architecting. The difference between good and bad code often lies in the usage of design patterns. Most design patterns are language-agnostic, meaning you can use them regardless of what language or framework you're using. Additionally, each framework has its own set of design patterns and is built on patterns that consumers should follow.

One of the most well-known general design patterns is SOLID. It's a universal design pattern that works with most frameworks. Some frameworks are already based on it, and users of these frameworks will automatically follow the pattern. Other frameworks can benefit from it, even though it isn't always obvious how to adapt to it. For example, React doesn't automatically follow SOLID principles, but if you understand how SOLID principles work, you can apply them to React as well.

React also serves as a good example for framework-specific design patterns, where you have patterns like Render Props, Custom Hook Pattern, and Higher Order Components.

The key point is twofold: take time to learn about design patterns in general, and make sure to look up framework-specific design patterns when starting with a new framework.

In general, design patterns make code more:

readable
testable
modular
robust
DRY (Don't Repeat Yourself)

These aspects are necessary for writing reusable code and collaborating with co-workers. Design patterns also help prevent bugs.

Design patterns are not completely bug-proof

Communication

As a developer, you're most often building part of a larger system. Without proper communication with other teams to ensure your software works with the rest of the system, your part becomes useless. And without communication within your own team, you won't even finish your component on time.

Communication is vital in every project. Unfortunately, it's very challenging. I could write numerous articles about communication difficulties and how to communicate effectively, but that's not my focus today.

For now, just remember that communication is a important part of a developer's job, and it's just as important as being proficient at coding. If you'd like to learn more, I do have additional tips on how to communicate effectively in large organizations.

Eliminating Dependencies

In my early days, when I struggled with communication with certain individuals and teams, my initial reaction was often to provide super clear instructions and closely follow up on processes to ensure tasks were completed by others. When that didn't work, I would finally give up and do the work myself just to get it done.

That's when I realized that the best type of communication is when it isn't needed at all. If there's nothing that needs to be communicated, there cannot be any communication issues.

An important detail here: I'm not suggesting that you should skip communication and do other people's work yourself. Rather, I'm saying that work should be divided into different areas in a way that minimizes the need for communication.

When building teams, people usually talk about cross-functional teams - teams that have all the competencies needed to develop, deploy, and monitor their product without dependencies on other teams.

Cross-functional teams often refers to having the knowledge and skills to be self-organized, which means they have all the necessary expertise to manage their dependencies.

Once again, there's a lot to cover in this article, so I won't deep dive into this topic. If you're interested, you can read more about eliminating dependencies in my other article, which also covers similar tips for team collaboration and communication.

An important part of communication is to know when not to communicate

Build a Team

Team building is a term most often associated with fun activities and occasional after-work gatherings. While these are definitely important aspects of team building, they're far from the whole picture.

Does your team have common goals? Have you agreed on how to handle code reviews? Do you know why your team never answers questions in the team's Slack channel? If the answers to these questions are no, you haven't fully built a team yet.

Team building should be about discussing ideas, resolving conflicts and disagreements, and finding a common way of working that the entire team agrees to. It's about sharing knowledge and experiences so all teammates are comfortable working with the team and facing upcoming features and bugs. It's about helping teammates work both independently and collaboratively.

The way to accomplish this often involves meetings. These don't have to be formal meetings with strict agendas, but there must be occasions where the team gathers to communicate. Some discussions might require a full hour, while other topics can be addressed during small sync meetings.

For instance, a good time to discuss expectations for code reviews is during the actual code reviews! Instead of just talking about how to change the code, make sure to discuss why you think the changes are needed. Why do you think it's important, and what do your teammates think about it?

One final note - team building is for the entire team. While certain roles such as Scrum Master and team leader come with the responsibility of building a team, they aren't the only ones who should strive to improve it. Building a team is teamwork, not a task for a single person.

Even superheroes need a team

Build a Network

Have you ever been stuck on a problem? A time when you've sought help but no one had time to assist? Have you felt that no one was listening to what you were saying, even though you later turned out to be correct? Why does this happen?

People are commonly busy, and it isn't possible to always consider everyone's opinion. What you need to do is make your voice heard. Too often, the way to do so is to speak loudly and confidently state that your solution or problem is what needs to be considered.

However, not everyone is comfortable doing that. Fortunately, there's another way to make your voice heard - by finding someone who listens to you even when you whisper.

Who are the people most likely to help you when you're in need? It's family, friends, and acquaintances. It's very rare for people to help strangers, especially when it means taking on additional work.

By building a network and making friends, you'll find yourself getting help more often and much faster. People prioritize helping friends, both because it's someone they like and because it's more difficult to say no to a friend.

The ease of making friends varies from person to person, but everyone gets opportunities. Simply say a brief comment or ask a question to someone while standing in line for coffee, or make a point to talk to the designer about something you're wondering about in the Figma designs instead of guessing or sending a Slack message. Whatever you do, don't ask other people to talk to someone for you, then you are missing out on a new friend.

In the end, you don't need to be best friends with everyone for them to help you. Just talking with someone for five minutes can be enough for them to consider you as someone they know and someone they want to be respectful and polite to.

The more the merrier

Who Should Do the Work?

Everyone knows about the famous "someone". It's always "someone's" fault as soon as something doesn't work out. "Someone" was supposed to handle it.

But who is this someone? Unfortunately, it's often difficult to identify them, which is why there's a need to talk about responsibilities and who should do the work. The interesting thing is that it's more often than not true that the responsible person should do the work.

What Does Responsibility Mean?

What does it really mean to be responsible? Being responsible doesn't actually mean you must do the work yourself, it means that the expecations on you is to get the work done. It's fully possible for you to delegate the whole task to someone else, giving them the responsibility.

True responsibility involves a commitment to ensure success, but it also calls for encouraging others to contribute toward that goal. A CEO of a tech company has a lot of responsibilities, but in the end, it will be a whole organization of developers, managers, and other people who do the actual work to develop a product.

Similarly, an architect in a team is responsible for ensuring that the team has and follows architectural guidelines when writing code. However, this doesn't mean it's the architect's job to write all the code or even to define every aspect of the architecture. The entire development team should collaborate to enhance code quality and adhere to agreed-upon patterns and practices.

An interesting thing about responsibility is that it often can be delegated to others. However, when that is done, the accountability usually stays with the person who delegated the responsibility; it's only the responsibility of handling the work which is transferred. Meaning, if something goes wrong and the project fails or gets delayed, then it's the accountable person who will have to take the blame.

Sometimes it's actually everyone's responsibility

Don't Do the Work For Others

Doesn't everybody love that person at work who amazingly manages to fix all the problems for everyone? Well, I do too, but I know it isn't optimal behavior.

Taking on other people's work only creates a cycle where people rely on others to complete their tasks. The day that amazing employee quits, the whole team or even multiple teams will find themselves in a tricky situation.

Instead of doing the work for others, invest the time to guide them on how to handle it themselves. Though it may take longer initially, once they're self-sufficient, you'll save significant time and effort.

To Delegate or Not

While you shouldn't do others' work for them, this doesn't mean you should avoid tasks outside your direct responsibilities. Remember, work shouldn't fall solely on the person responsible, that person can delegate tasks so everyone can contribute to getting them done.

There are different types of tasks, however. If you are responsible for something, it's likely there is more work than one person can manage alone. In that case, delegation is essential, but deciding what to delegate depends on the nature of the task. If it's a small, one-time task, avoid delegating it since it may take longer to explain than to complete it yourself.

For tasks that are time-consuming or recurring, consider them candidates for delegation. Here, you should weigh the implications of delegating: if a task is critical, you might choose to handle it personally, even if assigning it would save significant time.

Don't Ask What to Do

Asking for permission and double-checking that what you do is appreciated is nice to do once in a while, so you don't spend a month doing something completely unnecessary. But on a daily basis, quit it.

Just as a team should be self-organized, you as a developer must be able to take care of yourself. You cannot have a manager or team lead who is always supposed to tell you what you should do for the day or how to solve each problem.

What you should do is figure that out yourself. This doesn't mean you cannot talk to anyone. Remember, communication is an important part of development. If you are uncertain or if you are working with bigger tasks, discuss it with your development team to see what they think about it. Make sure to describe the problem clearly and suggest some potential solutions you have thought of.

Do you see the difference here? The difference is that you are working together with your development team; you are all collectively responsible for developing your product. If you are an eight-person team, you have eight brains which can be part of making a good decision. If you instead go to a team lead to ask what to do, you are basically neglecting your own willingness to make decisions and putting all the responsibility on a single brain. That's not a good approach for solving problems.

Sure, you will make mistakes. Live with that. That's the way to grow in life. It's not just a saying that what doesn't kill you makes you stronger.

Learn by Teaching

If you read the article I linked to in the communication chapter, you should have seen the learning pyramid. You may then have noticed that the retention rate of what you learn when you teach others was as high as 90%, compared to only 10% of what you read.

According to the learning pyramid, you remember 90% of what you teach others

Surprisingly, this pyramid tells you that you are the one who is learning the most when your intention is to teach others. And next after that, you will learn the most by practicing doing something.

Note how this aligns with other topics we have discussed here, about being involved in solving problems, building a team, and stopping asking others for instructions of what to do. The foundation of all those has been to take action and actively work on improving the team and coming up with solutions to problems. These are actions which involve group discussions, practicing problem solving, and teaching others, all of which are at the bottom of the learning pyramid.

In contrast, if you only take orders from others, only listen to what they say, and read about how they solved an issue or write code they have told you to write, then you work purely at the top of the pyramid, which means you are learning very ineffectively by reading, hearing, and watching demonstrations.

As a bonus of teaching others, you will get to face the most tricky questions. You might tear your hair out or feel embarrassed when not knowing the answer to a question someone asks you, but in a few years, you will be the one who knows it all.

Personal Traits

We have now talked about some technical skills a developer needs, and some soft skills for how to handle communication and interact with others - the kind of skills that are important when it comes to how you interact with other people.

What we haven't talked about yet is who you are as a person - your personal traits which define who you are. These might be difficult to change, but you might not need to. As we will see, the most important part is learning when there is a need to adjust them.

What are Traits?

When speaking about personalities, traits are characteristics of a personality. There are plenty of models trying to model human personalities, where DISC, MBTI (Myers-Briggs Type Indicator), and Big Five are the most well-known ones.

The DISC model is a very simple model, it divides people into four different personalities, which we won't dive deeper into in this article.

DISC personality model

MBTI takes it a step further and divides people into 16 groups. It's a very popular and researched personality model, but it's not scientifically accepted.

MBTI personality model

The scientific world generally prefers the Big Five theory. Big Five is similar to MBTI, it includes extroversion vs introversion together with four other traits.

The Big Five personality model

MBTI and The Big Five are two fairly similar models, and the reason why Big Five is accepted scientifically is not because Big Five has better traits in it; it's because it defines people on a scale.

The Big Five doesn't categorize people, it claims that humans are more complex than 16 personalities and that each trait has a scale. This means a person is not necessarily extroverted or introverted; they can be somewhere in between on the scale, which is called ambivert.

The Big Five represents personal traits on scales

Is Extreme Better than Being Average?

If we follow the idea of having a scale for each trait a human has, we can start judging whether specific traits are good or bad. Let's take perfectionism for example.

There are many types of perfectionists: self-oriented, other-oriented, socially prescribed, etc. Most of these types would, according to the Big Five theory, be quite neurotic and conscientious persons who aren't very open to criticism. Doesn't sound very attractive, does it?

Personally, I see loads of problems with perfectionism. Frankly, I have been one myself but worked hard to get rid of it. Nevertheless, I cannot claim it is a bad thing that should be avoided. In fact, it is sometimes very beneficial; for instance, when being a high-level architect for a big corporation with hundreds or thousands of developers, then it is somewhat necessary to be a perfectionist.

The thing here is that there are no consistently good or bad traits. Each trait has its own advantages and disadvantages. It depends on the situation you are in if a trait is good or not.

For instance, take the architect as an example. I claimed perfectionism is a good trait for a high-level architect in a big corporation. In a startup company, however, it's undesirable to be a perfectionist, for real. Startup companies are all about speed and agility. You need to quickly iterate with customers to find out what they need, and you need to do it quicker than your competitors and before your money runs out.

Dependent on your role, you might need to focus on quality or being fast

Generally, being an extremist in any area is rarely beneficial. Whether it involves levels of extraversion or introversion, religious beliefs, or political views, being at the far end of any spectrum can lead to challenges. To complicate it a bit, it's neither beneficial to be strictly average. Unique skills are often essential to accomplish things in life.

The truth is, an ideal person cannot be pinpointed on a fixed scale; rather, they have the ability to exist anywhere along it. Such a person is fully aware of their behavior and can adapt it to suit the situation at hand. This adaptability depends not only on the task but also on the characteristics of those they interact with - remember, effective communication with others is essential.

Even within the same role, you might need to act differently dependent on tasks

Think about Peter Parker for a while. How would you describe his personality? Would you describe it the same way as you described Spiderman's?

There're times when you have to be someone else (yes, that's supposed to be Peter Parker)

Give Your DRY Tests a WET Touch

dennis@perssondennis.com (Dennis Persson) — Sun, 26 Mar 2023 00:00:00 GMT

For quite some time, the commonly accepted practice has been to write DRY code, but there are developers who suggest using WET code. The purpose of this article is to demonstrate how to combine DRY and WET code to write better test cases.

The tests are written in Jest for React, but the chose of test framework doesn't really matter. You can give your DRY tests a WET approach in any language or framework. The approach can even be used for unit tests as well as integration and e2e tests.

DRY vs WET

First of all, let's shortly describe what DRY and WET code is for those who doesn't now about it. DRY (Don't Repeat Yourself) and WET (Write Everything Twice) are two terms used to describe different programming styles.

DRY code is more efficient and easier to maintain because it eliminates duplicate code. Changes made in one place affect all related code, making it easier to update and modify. DRY code is easier to understand and to reason about, which can improve code quality and reduce errors.

On the other side, WET code can be faster to write initially because it relies on copying and pasting existing code. WET code can be easier for less experienced programmers to understand because it is more explicit and detailed. In some cases, WET code may be more suitable when the code is simple and unlikely to change in the future.

WET Unit Tests

This example shows three simple example test cases for updating a user object. This code is WET, since the initialization for the test data is copied into each an every test. In this short example, the only test setup data is the user object, but in more complex test cases it can consist of much more data than that.

describe('Users', () => {
    test('increments Alice\'s age by 1 when she has a birthday', () => {
        const user = {
            name: 'Alice',
            age: 26,
            friends: ['Britney', 'Chili', 'Dennis']
        }

        haveABirthday(user)
        expect(user.age).toBe(27)
    })

    test('adds a new friend to the friend list', () => {
        const user = {
            name: 'Alice',
            age: 26,
            friends: ['Britney', 'Chili', 'Dennis']
        }

        makeANewFriend(user, 'Elliot')
        expect(user.friends).toContain('Elliot')
        expect(user.friends).toHaveLength(4)
    })

    test('removes a friend from the list when being stupid', () => {
        const user = {
            name: 'Alice',
            age: 26,
            friends: ['Britney', 'Chili', 'Dennis']
        }

        playRussianRouletteWithFriends(user)
        expect(user.friends).toHaveLength(2)
    })
})

DRY Unit Tests

Although there wasn't anything wrong with the WET tests above, the test file can be much briefer if we lift out the initialization in a beforeEach function, which will run before each test case.

For a file with tens of tests, that change will save a lot of lines of code and make the whole test file easier to read. And even each test itself can get a lot less bloated with the DRY approach. In this case, each test can be written in 4-5 lines instead of 10-11 lines as in the WET case.

describe('Users', () => {
    let user

    beforeEach(() => {
        user = {
            name: 'Alice',
            age: 26,
            friends: ['Britney', 'Chili', 'Dennis']
        }
    })

    test('increments Alice\'s age by 1 when she has a birthday', () => {
        haveABirthday(user)
        expect(user.age).toBe(27)
    })

    test('adds a new friend to the friend list', () => {
        makeANewFriend(user, 'Elliot')
        expect(user.friends).toContain('Elliot')
        expect(user.friends).toHaveLength(4)
    })

    test('removes a friend from the list when being stupid', () => {
        playRussianRouletteWithFriends(user)
        expect(user.friends).toHaveLength(2)
    })
})

The Problem With the DRY Tests

Many test files appear very similar to the previous DRY test file. However, programmers who prefer WET programming have a valid argument against writing tests in that way. The reason being that it's common for people to forget the data used to initialize their tests.

For instance, the first of our tests is the age test.

    test('increments Alice\'s age by 1 when she has a birthday', () => {
        haveABirthday(user)
        expect(user.age).toBe(27)
    })

Now, without scrolling up to look at the test data, answer how old Alice were before having a birthday?

I promise, it's not a bug!

Well, if you know math better than meth, you can probably calculate that she must have been 26 before her birthday. But you cannot be sure that the haveABirthday function works, that's the very reason you are writing that test.

To be able to see how old she really were before the birthday function was invoked, you would have to scroll up to the definition of the user variable in the beforeEach at the top of the file. Doing that over and over again can be quite annoying, and if you have written many DRY tests, you most probably get what I mean.

Furthermore, if you would change the age in the beforeEach, you have no idea how many tests you would to fail.

Now tell me, how can we circumvent issues like those? One way to do that is to add a WET touch to your DRY tests!

DRY Tests With a WET Touch

With DRY tests with a WET touch, we get rid of the unexpressive beforeEach function and instead write some initialization functions. By naming the functions appropriately and specifically using them in each test case, we can achieve both readable and brief tests in which we have all the information we need.

const createTwentySixYearsOldUser = () => {
    return {
        name: 'Alice',
        age: 26,
    }
}

const createUserWithThreeFriends = () => {
    return {
        name: 'Alice',
        friends: ['Britney', 'Chili', 'Dennis']
    }
}

describe('Users', () => {
    test('increments Alice\'s age by 1 when she has a birthday', () => {
        const user = createTwentySixYearsOldUser()
        haveABirthday(user)
        expect(user.age).toBe(27)
    })

    test('adds a new friend to the friend list', () => {
        const user = createUserWithThreeFriends()
        makeANewFriend(user, 'Elliot')
        expect(user.friends).toContain('Elliot')
        expect(user.friends).toHaveLength(4)
    })

    test('removes a friend from the list when being stupid', () => {
        const user = createUserWithThreeFriends()
        playRussianRouletteWithFriends(user)
        expect(user.friends).toHaveLength(2)
    })
})

DRY Tests With a WET Touch Using Build Design Pattern

The approach to write DRY tests with a WET touch should be enough for most fairly small test cases. But if you are one of those who like structure, or if you are using the same data to initialize plenty of tests, you could go the bit more cumbersome way and initialize your data with the build design pattern.

In that case, you can write a class for a basic user, then add builder functions to add attributes to it. This one is written as a JavaScript class, but you can do the same thing using regular functions.

class User {
  constructor(name) {
    this.name = name
    this.age = null
    this.friends = []
  }

  setAge(age) {
    this.age = age
    return this
  }

  addFriends(friends) {
    this.friends = this.friends.concat(friends)
    return this
  }
}

When you have a class like that, you can write test like this. And hopefully, you can even reuse it for multiple files.

describe('Users', () => {
    test('increments Alice\'s age by 1 when she has a birthday', () => {
        const user = new User('Alice').setAge(26)
        haveABirthday(user)
        expect(user.age).toBe(27)
    })

    test('adds a new friend to the friend list', () => {
        const friends = ['Britney', 'Chili', 'Dennis']
        const user = new User('Alice').addFriends(friends)
        makeANewFriend(user, 'Elliot')
        expect(user.friends).toContain('Elliot')
        expect(user.friends).toHaveLength(4)
    })

    test('removes a friend from the list when being stupid', () => {
        const friends = ['Britney', 'Chili', 'Dennis']
        const user = new User('Alice').addFriends(friends)
        playRussianRouletteWithFriends(user)
        expect(user.friends).toHaveLength(2)
    })
})

With this new improved test file, each test is only 5-7 lines, almost as thin as the 4-5 DRY lines and much thinner than the 10-11 WET lines. We do have all necessary information we need to see in each and every test, but we have cut out all the extra unnecessary information we had in the verbose WET tests.

Other developers at your company can look at these new brief tests and quickly understand what they do and if they work as intended. If they need to change any of the tests, they can simply do that right within the test. With the DRY tests, they would need to alter the data initialized in the beforeEach function, which potentially could destroy some of the other tests in the file, or in any other file if the test data is shared between several files.

Conclusion

WET tests quickly gets very bloated. By making them DRY, they get more comprehensible, but we risk to lose information in the test, making it necessary to scroll to definitions or open definitions in new files to see the data we are working with in the test. Altering that common data also have the potential to ruin plenty of other test cases.

By combining the advantages of DRY and WET tests, we can write short readable tests where we can see all necessary information directly in the test without having to scroll or look up test data.

The key to doing that, is to write functions for the data initialization and use those functions in each test. For even more structure, when dealing with bigger amount of data and number of tests, one can use the builder pattern to customize the data on detail level for each test.

For non-trivial test examples, it will make a big difference in readability. For whole projects with much data, it will make a huge improvement.

How I Improved Lighthouse Performance by Adding an Image

dennis@perssondennis.com (Dennis Persson) — Sun, 21 Aug 2022 00:00:00 GMT

Images and videos are slow to load, and most bloggers and companies are eventually coming to the tough decision of whether to take the UI train and include a hero image or going for performance and wave goodbye to the hero. My turn for my website was to go both ways!

The Impact of Loading Images

An image is on average a thousand times as destructive for performance as a thousand words. That's not a joke. Websites are commonly encoded using UTF-8, which uses 1-4 bytes per character, just 1 byte for standard ASCII letters. Average English word is about 5 characters, so a thousand words would be about 5 kB large. A quick google search on average image sizes on web tells us that's in about the same order of magnitude as those 5 kB of words.

Keep in mind that's just an average number. Hero and banner images which are meant to cover the half or full viewport of a website is most often at least several 100 times as large as that, maybe even a thousand if poorly optimized.

The image size isn't the only time thief when loading images on web. Images are usually fetched by the browser in a separate network request which means there will be an additional server request which incur additional latency, and the request may even have to be queued for a time by the browser. As we will see later in this article, this fact can have a considerable impact.

Tesla's 1.2 MB huge monster banner

As an example, Tesla's banner image of their Model 3 Tesla is 1.2 MB large and takes 364 ms to load after having waited 2 seconds to start download on my network with a fairly old MacBook Pro. According to Google, 53 % of users will leave a mobile site that takes longer than 3 seconds to load. Just loading the image consumes a considerable share of that quota, and before it is finished rendered it has passed that time.

Tesla Model 3 image loading time in Chrome inspector

Tesla Model 3 accelerates from 0 to 100 km/h in 3.3 s, that's faster than it takes to load the image of it

Web Vitals - Largest Contentful Paint

There are many ways measuring performance for a website. Google has initiated Web Vitals, which is a bunch of metrics that Google think are important for serving a good UX. One of the metrics is Largest Contentful Paint (LCP), which measures the time until the largest text or image on the page is visible.

Google has released an open-source tool called Lighthouse that can be used to measure web vitals and get scores and guidelines. It is built-in into Chrome Dev Tools but can also be used at PageSpeed Insights. The metrics shown is meant to be used as a guidance and can vary between each test.

Although Lighthouse is just for guidance, most or all of the metrics are used directly or indirectly by Google to rank your website when it gets indexed by Google. It's therefore not only important for good UX, but also for SEO.

Largest contentful paint is one of the metrics a Lighthouse test scores you on

The Inconsistency of Getting a Great Largest Contentful Paint (LCP) Score

While running Lighthouse speed tests at my website, I noticed that I got very different scores on different pages. My main page that lists articles and an article page scored significantly different on the performance metric, even though both pages was built almost in the same way with a profile picture, a lot of text and a few images. At the time doing this, the pages looked similar as today, but they did not have a hero image back then.

The culprit for the bad test result on the article page was the LCP score. The Lighthouse test provides a screenshot of the LCP, which made it clear why the article page did get a worse LCP score.

Since the main page had some extra chip components beneath the profile picture, the largest contentful paint on that page was the profile image. None of the dynamic blog articles was ever included in the viewport on a mobile device.

The LCP on my landing page is the profile picture

Meanwhile, on the article page, the first part of the blog article was included in the mobile viewport, meaning that Lighthouse was looking for the LCP in that area as well. The consequence, was that whenever an article began with an image, that image was treated as the LCP, since it was a larger image than my profile picture. If the image was left out, the profile picture was detected as the LCP.

The LCP on an article page with an image was the article image

How I Optimized Largest Contentful Paint (LCP) With an Image

I knew I couldn't keep going on with an unreliable LCP score, and it wasn't a good solution to never start an article with an image. I had to find a way to get a predictable score regardless of what content I included in the article itself.

With that in mind, I decided to add an image larger than any potential article image, I decided to add a hero image. That way, I could at least get control of which image was the largest and thereby take control over the LCP score.

For this to be effective, I had to use a hero image that was fast to load. Nothing would ever be better if I did like Tesla have done, adding a gigantic banner at the size of 1.2 MB. I had to use a small optimized image that could fill half the viewport, one that didn't scream poor resolution.

By adding a hero image, I could control which image I wanted to be the LCP

Choosing Between SVG, PNG and WebP

Well, I never really considered using a PNG image for the hero image, that's not the way to optimize web images. Although, I do always keep a PNG copy around for other usages. For example, when posting articles on DEV forum, they don't support WebP images to be uploaded as hero images.

Choosing between SVG and WebP was more difficult. SVG images can be really small if the image consists of a repeating pattern or an abstract pattern using only a few colors and shapes, just because they consist of vectors that can be scaled to any resolution. On the other hand, they will grow ridiculously big for graphic-heavy images with many colors and shadows, due to the high number of vectors required to represent the image.

On the contrary, WebP can compress images effectively by predicting and reusing pixels, making it superior to PNG and JPEG formats. So, the decision had to be between a minimal abstract hero image in SVG format or a realistic photograph in WebP format.

An Attempt to Use a SVG and CSS Solution

As you can see on my website, I do have a brick wall as the hero image (as long as you don't change the theme to dark mode). That image is in WebP format, but my first attempt was actually to use an SVG image. The brick wall I tried with then was less realistic and more cartoonish, which was served perfectly in SVG format.

To get rid of the extra network latency from fetching an image from a server, I embedded the image as a CSS background in a data URI, which should really only be done when dealing with tiny images because of cache and parsing reasons.

Did it work? No, it didn't, the CSS background wasn't detected as the LCP. After all, it is neither a regular image or a text, so it complies with Google's description of LCP.

Google's largest contentful paint definition

Even though a CSS solution did not work as expected, it did work to use the SVG image in a normal HTML image element (or to be accurate, Next.js Image component in my case). The only reason I discarded that solution was because I wasn't satisfied with the cartoonish style of the brick wall, I felt I wanted a more realistic brick wall.

Optimizing WebP Image Size

After having decided to use a photograph of a brick wall as the hero image, it was time to optimize the size of it without losing too much quality. I felt that I didn't need a pixel-perfect photograph, it was fine for me to sacrifice quality for loading speed. The initial image was a JPEG monster at 18.1 MB and a 6000 x 4000 resolution, so it could be optimized a lot.

My counsellor apologize on my behalf for a mega bad pun

Now, compressing images is not at all what I am good at, I'm sure compression fanatics would have hit me with their compression bible if they hadn't already compressed it into a holy script at a few kilobytes. But I did succeed to compress the image a lot, compressing it into a 2560 x 1707 WebP image of 37 kB. Obviously, I lost a massive amount of quality, that has to be mentioned.

I got so scared seeing him I zipped my mouth

The approach I used to compress my image was to use an online copy of Photoshop called Photopea. Only thing I did was to resize the image and save it in another format, and choosing to lower the quality while saving.

Photopea's save dialog allows you to preview image quality and image size at the same time

Serving Appropriately Sized Images

A hero image with a 2K resolution is fine for a 4K monitor, but serving a 2K image to a mobile device is not optimal. Small devices should be served small images. That can be achieved using a HTML picture element with a srcset.

In my case, I didn't have to handle that, because my website is written using Next.js. They have a built-in image component which can be used to optimize image loading. At my blog, you can find a guide for implementing a hero image with that image component, it also explains the benefits of using it.

The image component Next.js offer does not only serve images in different sizes. They also support specifying a quality of the image so they can compress it for you. In my case, it didn't compress the image enough, I experienced better results compressing it myself using Photopea.

Great Image Tools To Use

When working with images, you often have to manipulate images in certain ways. To easier do that, I suggest checking out my list of free image tools. Those tools can be used to resize and reformat images and to generate images and backgrounds. It also presents websites which offers royalty free images.

Back To Network Latency

As I promised in the beginning of this article, we would look at how network requests can be the bottleneck when optmizing image loading times. Look at the picture below. It shows the network timing tab available in Chrome Dev Tools for the hero picture I use on my website. We can see that it takes the same amount of time to get a response from the server as it takes to download the picture.

It takes 32 ms to get a response when I visit my own website

But Dennis, you say, your image is very small, only 37 kB. 32 ms isn't a very long time. Yeah, that's correct. It's nothing to care about. Or at least it wouldn't be if it wasn't because I had reloaded my page multiple times to get that screenshot.

Reloading the page allows for the server to cache the image and serve it quickly the next time it is requested. When visiting my website during a cold boot at hours I don't have a lot of traffic to the site from Sweden, it can take 5, 10 or maybe 15 times as long time to get a response from the server. When that happens, the 32 ms download time for the image is negligible compared to the server response time.

Without a recent cache of the hero image, server response takes plenty of more time

Conclusion

What we learned in this article was that adding a large image to a website can actually improve Lighthouse performance tests. We learned what Largest Contentful Paint (LCP) is and how to optimize an image to maximize the LCP score.

We also took a look at when to use SVG images and when to use WebP images. I provided you with a list of free image tools which as an example can be used to reformat images in different ways, and explained the importance of keeping the image size low when using images on a website.

Finally, we saw an example of how server response time can be the bottleneck of web image performance when the images themselves has been compressed well enough to be very small.

How To Avoid React Context Trap

dennis@perssondennis.com (Dennis Persson) — Sun, 01 May 2022 00:00:00 GMT

Whatever code we ever invent we always seem to end up in hell. In the case of React contexts we have the context hell, which refers to the problem of bloating the code with a lot of context providers at the root level of you code.

// Example of context hell.
const ContextHellApp = () => (
  <>
    <ReduxProvider value={store}>
      <ThemeProvider value={theme}>
        <AnotherProvider value={anotherValue}>
          <YetAnotherProvider value={yetAnotherValue}>
            <GetItYetProvider value={yeahIGetItValue}>
              <FinallyAComponent />
            </GetItYetProvider>
          </YetAnotherProvider>
        </AnotherProvider>
      </ThemeProvider>
    </ReduxProvider>
  </>
)

As you can see in the link, there's a suggested solution to it. Quite an easy solution for a quite minor issue. The context discussion shouldn't end there though. To me the context hell isn't the real issue here. What I consider problematic with contexts is what I like to call the context trap.

Keep Your Contexts Small

Whenever a React context i being updated, all components using that context will rerender. To avoid unnecessary renderings, one should keep the contexts as small as possible.

By doing that, you will not only render components less often, you will also be able to move your context provider components further down the React tree if you only need them for parts of your application, which will save you from the context hell mentioned earlier.

// Context hell isn't a problem when keeping contexts small.
// If only parts of the app use a context, we can lift it down
// to a component within <Component /> or even further down.
// Redux and theming affect the whole application, so we keep
// them here in the top-level component.
const SmallContextsApp = () => (
  <>
    <ReduxProvider value={store}>
      <ThemeProvider value={theme}>
        <Component />
      </ThemeProvider>
    </ReduxProvider>
  </>
)

Moving down context providers may not be necessary, but it can help developers understand what parts of the application that actually are affected by the context. On the other side, it may not be a great solution, since using that context outside of the provider will give birth to a bug.

Anyhow, I know, you are a good developer, you already knew you should keep your contexts small. You always keep your contexts as you keep your project's bundle size, slim fit.

Introducing Context Trap

Times changes, and suddenly you need a connection between two of your contexts. Maybe you have divided chats and messages into two separated contexts and you now need to look at the chat when you receive a new message?

Nah, you would never split chats and messages into different contexts. But maybe your incautious colleague Joey would? It's always Joey...

Why Joey, why?

Let's say Joey didn't mess up this time. You both did the correct choice, keeping chats and messages in the same context, they are related after all. But what about the user context? You do have users on your site, don't you? Should that context be connected to the chat-and-messages context?

You will need to know which users are members of a chat, and you will have to know which chats a user is a member of. Maybe you even add a subsystem for reporting user misbehavior. Should that be stored in its own context?

These are real questions you are likely to face someday and you may have forgotten to plan for it. There are of course good solutions of how to handle these cases, many times it can be solved by handling things differently in backend. Sometimes you have no other choice than handling it in frontend. Either way, remember that if you choose to split your global store into multiple independent contexts you may get into trouble, that's what I refer to as context trap.

Joey knows how to write code

What Is the Problem?

The context trap isn't something you easily can solve by moving or adding a few lines of code. Accessing contexts within another context isn't a very great idea, so you will likely have to handle all cross-context logic outside the contexts.

By cross-context logic I mean the logic required to ensure that two or more contexts stay in sync with each other, e.g., updating messages count in a chat context when a new message has been added to a context for messages.

Syncing contexts will include reading and dispatching actions to all affected contexts at the right time in the correct order. Writing such logic is like building a trap for all newly hired employees to fall in, not just Joey. It may be easy to write in the first place, but scaling and maintaining it is a hell.

When you have multiple contexts you need to update whenever an event emits, such as receiving a new chat message, you will have to know how the complete code works in order to know when and where you should update your contexts.

Newly employed developers are often unaware of all the contexts that need to receive updates, so they will most likely introduce a bug. They might notice the bug and try to solve it. What happens then is that most developers blindly try to fix that single bug instead of trying to grasp how the complete solution works and suddenly something else has broken.

Development goes on and after a year it isn't an issue for new employees only, even you get a headache looking at the code. You end up with a code base that is just about a year old and you have already added a task in you backlog to refactor it.

Yes Joey, that's what git push master means

Contexts Is Not Always the Solution

So, how to avoid falling into this trap? Well, one alternative is to follow Juan Cortez's rule number 9, to always use the right tool for the job.

Rule no. 3 is unfortunately often true as well

Contexts aren't the solution to all issues. It shouldn't be considered as a "lightweight" Redux. Context and Redux is not interchangeable. They have different use cases. Redux is a full state management system and in complex applications you may be better off using that.

How Can Redux Save Us From the Context Trap?

How could Redux help us out here? You still have to make a lot of design choices; you can't escape that. The benefit arises when you are writing your code. When using contexts, you are free to do any mistake you want (or don't want) to do.

Moreover, when multiple developers work on a project, many of them will find it hard to read code written by other teammates, especially when the code isn't implemented with readability in mind. Redux solves both these problems for us and many more problems we need to handle ourself when using a context. Here's a few examples coming up on my mind at the moment.

With Redux you are less likely to do mistakes in your code since you are basing your code on guidelines and well documented code.
You don't need to write all that code Redux handles for you. Redux has been developed for a long time and has been tested well. Writing you own code in replacement of Redux will most likely introduce more bugs in your code.
With Redux, dispatched actions are by default passed to each reducer. There's no need to manually dispatch actions to all affected contexts or removing such logic whenever a context doesn't need that information anymore.
Redux reducers can access the complete store. If you replace that with a multiple-context solution you will need to handle that in some other way. If you are using a useReducer in a context in replacement of Redux you will have access to that context only, not any of the other contexts.
Developers know how Redux works. They can quickly find all the places in the code where a specific action is dispatched, or vice versa, all the reducers that are affected by an action. You don't necessarily get that when you design your own solution. Joey may already know Redux, but he will definitely find a way messing up your custom-made code.

Conclusion

When you consume a context using useContext hook, your component will rerender any time that context updates. So even if your component merely grabs a user's name from the context, it will still rerender as soon as any change at all is made to the context. When designing React contexts, you should therefore use many small contexts rather than one massive one to avoid unnecessary rerenders.

Breaking your contexts into smaller parts may however lead to complex code when your application grows. It's not for certain, but making the wrong design choices can put you into some real trouble. That's what I refer to as the context trap, splitting contexts into smaller pieces and ending up with code that is hard to read and maintain.

Suggested solution from my side is to use Redux. You don't always need Redux, but if you start to think about using multiple contexts or if you want to put a reducer in a context, you should probably consider using Redux.

How To Make a Hero Image in Next.js 13 and 14

dennis@perssondennis.com (Dennis Persson) — Sun, 12 Nov 2023 00:00:00 GMT

I have noticed that one of my previously very popular article about how to make a hero image in Next.js is still getting a lot of attention.

Unfortunately, that article was written when Next.js still used the Page Router. After that, with their new App Router in Next.js 13, the image component was replaced with a new one. With that in mind, I have now created a new article optimized for the new Image component in Next.js 13 and 14, for all of you who have, or want to, migrate to use the Image component.

Next.js 13+ Image Component

The new image component which you can use in Next.js 13 and 14 has changed slightly from the legacy image component used in earlier versions. Both the legacy and the new one offer similar advantages, which makes it very beneficial to use instead of the regular image HTML element. Both of the components can help you with:

Resizing images for you so you don't need to use srcset manually
Automatically lazy loads images when they are scrolled into view, which of course is optional
Gives you various optimization option, such as quality, priority and custom image sizes
Supports adding a placeholder to blur images when they are loading

For the blurring, you can check my old article if you wonder more about how it works.

Batman would make a great hero image

Changes in Next.js 13+ Image Component

Next.js offers a migration codemod scripts for migrating to the new image components. The codemods are not bullet-proof, so you should check what has changed in the new image component if you are planning to migrate.

Some of the changes have affected how a hero image can be implemented. Mainly, they have replaced layout property, removed the objectFit prop and removed the absolute positioned span element which was wrapping the img element in the legacy image component.

How To Create a Hero Image With Next.js 13+

The principe of how to implement a hero image is quite simple with the new Image component. I would recommend the following setup.

Start with a wrapper div with relative position, 100vw width and your desired height
Insert the Next.js image component with fill and priority props set to true, and a class style with a z-index of -1
Place whatever content you want after the image wrapper, but within the outer wrapper div

Note: You can optionally wrap the image in a wrapper div if you cannot set a style directly on your image component for some reason. In that case, the wrapper must set the CSS attribute position to "absolute" value.

Following the steps above would give you a component looking something like below. The implementation is using css modules. You can also find the code at CodeSandbox and GitHub.

// HeroImage.jsx

import Image from "next/image";
import styles from "./heroImage.module.css";

const { heroContent, heroImage, heroWrapper } = styles;

const IMAGE_URL = "https://www.perssondennis.com/images/perfect-avocado.webp";

const HeroImage = () => {
  return (
    <div className={heroWrapper}>
      <Image
        className={heroImage}
        priority
        src={IMAGE_URL}
        fill
        alt="hero image example"
      />

      <div className={heroContent}>
        <h1>Hero Image</h1>
        <p>Next.js 13 hero image example.</p>
      </div>
    </div>
  );
};

export default HeroImage;

/* heroImage.module.css */

.heroWrapper {
  position: relative;
  width: 100vw;
  height: 50vh;
}

.heroImage {
  object-fit: cover;
  object-position: center;
  z-index: -1;
}

.heroContent {
  display: flex;
  flex-direction: column;
  align-items: center;
}

Note that I did also set the objectFit property to "cover". You decide how you want you image to scale by choosing a suitable value for objectFit attribute.

contain value for objectFit will keep the aspect ratio, which may not be desired for a hero image
the cover value will fill up the available area in the parent element by cropping the image where it is necessary
fill option will stretch the image to fill up the parent element

When you crop the image by using "cover" as a value, you may want to set objectPosition to make sure you keep the parts of the image you want from being cropped out.

Above example could look something like this

Solution Explained

CSS is not always that intuitive, so I'll go through what we did there.

The wrapper div around everything had a relative position, what that does, is to tell that absolute positioned images within that element should be positioned relative to it. Absolute positioned elements are relative to the first parent which is explicitly positioned.

The image component Next.js provides does use an absolute position when we use the fill prop for the image component, so the relative position of the wrapper ensures that the image will grow to fill the wrapper and not the whole viewport.

We also added a negative z-index to the image. That is to ensure that the image will be placed under any other content rendered on the same area as the hero image, which means, all the other content we want to display on top of the hero image.

To the image component, we did pass a priority property. This is to disable lazy loading for hero image, since a hero image should always load as quick as possible.

Rest of code should be self explanatory. If it isn't, let me know about your questions.

Choosing a Hero Image

If you don't have a hero image and don't want to buy one, there's a lot of free ways to get them. You can find links to some royalty free image sources in my list of useful image tools.

That article also lists a lot of useful resources to edit images, both an online Photoshop application and tools for editing, generating and converting images to other format.

Speaking of generating an image. You are probably aware of AIs which can generate images for you. While DALL-E may be the most known one, I prefer Leonardo.Ai du to its high quality and realistic images which suits very well for hero images.

Whatever image you choose, make sure to reduce the size of it to a couple of 100 kB or preferably less, dependent on how high resolution and what detail level you need for your image. You can read about the impact of image size and how to optimize an image in my article about how I improved Lighthouse Performance by adding a hero image.

Summary

Next.js 13 comes with a new image component which is fairly similar to the old one
Just as the old image component, it offers image optimizations, lazy loading and blurred placeholders
The new image component can easily be used as a hero image, but remember to use relative position for the parent element
Use z-index to control that the hero image stays below other content in the hero area

How To Make a Hero Image in Next.js

dennis@perssondennis.com (Dennis Persson) — Sun, 24 Jul 2022 00:00:00 GMT

You may have made a hero image a few times before, but have you done one in Next.js? If you haven't done that, you may find it tricky if you would try. Here I'll guide you how to do that and warn you about the gotchas.

Next.js Image Component

Next.js provides a really powerful Image component which you definitely should use if you don't have a reason not to. It handles several things for you, some which are enabled by default and some which you have to specify yourself. Some examples of what the Image component can do are:

Automatically resize images for you. No need to manually generate images of different sizes to use in a picture element with a srcset. It supports several type of layouts. Unfortunately, it isn't very easy to understand from the documentation when to use which layout.
Lazy load images. Images are fetched firstly when they are closed to being scrolled into view. If you need to opt out of this behavior, you can specify the prioritize property.
It lets you optimize image sizes and quality in different ways.
Allows you to blur images by providing a temporary blur-image. If you want a single-colored blurred background, you can generate a base64 encoded one on png-pixel.

<Image
    blurDataURL="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mPkso6pBwACGgEie2Im0gAAAABJRU5ErkJggg=="
    placeholder="blur"s
    src={memeUrl}
    layout="fill"
    alt="Programming meme"
/>

Pass a base64 image to blurDataURL to use it as a blur placeholder

To see blurred images in action, head over to the memes page at my website and scroll down. Next.js handles the blurring and lazy loading automatically.

Failed Attempts To Create a Hero Image With Next.js

Trying to create a hero image with Next.js can be a troublesome process. As I mentioned above, you should use Next.js built-in Image component if you don't have a reason not to.

In a first attempt to create a hero image, you may think you can set the width of the Image component to 100%. Unfortunately, that is not possible with remote images, Next.js don't support that. You'll end up with a 100px wide image instead.

A second try could be to avoid specifying width for the Image component in hope for that it would fill the parent element. Doing that will result in an Unhandled Runtime Error.

"Error: Image with src SOURCE must use "width" and "height" properties or "layout='fill'" property."

Next.js Image component requires a width and height, or a fill layout

The error Next.js outputs is quite clear. You are required to set both a width and a height on the Image component, unless you provide the fill value to the layout property. You do exactly what Next.js suggests since you are a law-abiding citizen, or maybe because you have no better ideas to try.

Using the layout property removes the error, but your hero image now fills the whole viewport instead of the div that wraps it. Perfect... You start realizing that you will be late to grandma's dinner party tonight.

Being pretty great at hacking CSS, you play around with the element inspector in the browser a bit. You don't really get anywhere and neither Stack Overflow or Next.js documentation is to any help, and you don't find a tutorial for it. Maybe it's best to use a native image element rather than the Image component Next.js provides?

An apology to all vegans, there will be no food for you. And for the sharp joke, I know it isn't bunny...

How To Create a Hero Image With Next.js

I'm happy to announce that there is an easy way to fix it. The key to success is to use position: relative on a parent element. I would suggest to do four things.

Add a hero wrapper element with position: relative and an appropriate width and height.
Add a Next.js Image component with the layout property set to fill.
Wrap the Image component in a div with z-index: -1.
Add whatever hero content you want in a relative positioned div in the hero wrapper. Place your hero content in that div.

The complete solution would look like this.

// Header component.
import Image from "next/image";
import styles from "../header.module.css";

const { heroContent, heroWrapper, imageWrapper } = styles;

const IMAGE_URL =
  "https://www.perssondennis.com/images/articles/how-to-make-a-hero-image-in-nextjs/perfect-avocado.webp";

export default () => {
  return (
    <div className={heroWrapper}>
      <div className={imageWrapper}>
        <Image
          priority
          src={IMAGE_URL}
          layout="fill"
          objectFit="cover"
          objectPosition="center"
          alt="hero image example"
        />
      </div>

      <div className={heroContent}>
        <h1>Hero Image</h1>
        <p>Next.js hero image example.</p>
      </div>
    </div>
  );
};

/* header.module.css */

/* step 1 */
.heroWrapper {
  position: relative;
  width: 100vw;
  height: 50vh;
}

/* step 3 */
.imageWrapper {
  z-index: -1;
}

/* step 4 */
.heroContent {
  position: relative;
  display: flex;
  flex-direction: column;
  align-items: center;
}

This is what it would look like using the hero image on a page

Solution Explained

So, what did we do there? In step 1. we added a relative position to the hero wrapper. That's the secret to success in this case. Next.js will set an absolute position on its image when you set the layout property to fill in step 2..

/* step 1 */
.heroWrapper {
  position: relative;
  width: 100vw;
  height: 50vh;
}

<div className="{imageWrapper}">
  <image
    priority
    src="{IMAGE_URL}"
    layout="fill"
    objectFit="cover"
    objectPosition="center"
    alt="hero image example"
  />
</div>

In CSS, absolute positioned elements are absolute relative to their closest parent that is explicitly positioned. By setting the hero wrapper's position to relative, the absolute positioned image within it will grow to be just as large as the hero wrapper becomes.

The hero wrapper will in turn be as large as the content you add to it in step 4.. Note that the hero image's width and height does not contribute to the hero wrapper's width and height since the image has an absolute position.

If you would remove the relative position from the hero wrapper, you would see that the image instead grows to be as large as the viewport, because no parent or grandparent has a position specified.

In step 3., we wrapped the hero image in a div (imageWrapper) with z-index set to -1, and in step 4 we added a relative positioned div (heroContent) as a sibling to the image wrapper. That is just to ensure that other components will show on top of the hero image.

/* step 3 */
.imageWrapper {
  z-index: -1;
}

/* step 4 */
.heroContent {
  position: relative;
  display: flex;
  flex-direction: column;
  align-items: center;
}

We do now have what we need to implement a hero image with the Next.js Image component. You can fill it with whatever content you want, personally I prefer centered content, which is most easily done with flex column and a centered align-items property!

Summary

Always use Next.js Image component if you don't have a reason not to do it.
If you want to create a hero image with Next.js image component, wrap the hero image and its content in a relative positioned div and set the image's layout property to fill.
Wrap the hero image in a div with a z-index of -1 to make it show underneath the content in the hero section.
Create a div below the image wrapper and let it have a relative position.

How To Report a Site That Steals Your Articles

dennis@perssondennis.com (Dennis Persson) — Sun, 05 Jun 2022 00:00:00 GMT

A short time back, I googled to find one of my own blog articles. I do that quite often since it's an easy way for me to find my articles quickly. But this time I noticed that the search result that appeared right after my article had the exact same title as mine.

The site appears right below my DEV article on google

I got curious and visited the page and was met by an exact copy of my own blog article, the only difference was that they had systematically substituted single words with synonyms all over the text, as a bad attempt to make the article look unique to Google.

The beginning of the article they have stolen from me

I further inspected the website a bit to see what was going on. While doing that I found loads of articles published on DEV, and there was no information about the source of the articles. The canonical link referred to the site itself instead of the original publisher.

Has your article been stolen as well? I don't know, but I can see they copy plenty of articles daily and I do know why you should care about it. I'll guide you what to do if this happens to you. I'll explain why you should care and I will tell you why it's important.

I have decided not to expose the name of the website that steals your DEV articles, I don't intend to slander anyone. If DEV are interested to know more and take action, they can contact me privately.

Why Should You Report a Stolen Blog Post?

The obvious reason to report a stolen blog article is because it steals traffic from your own website. If the site has better SEO than yours it will appear before your own site on Google and most organic traffic will go to that site instead of your own blog. As a result, people won't read your articles and you are writing them completely in vain. It can even get worse than that. If Google detects that your blog contains content that are duplicated on another site, it can hurt how you rank on Google.

If you don't care about if people are reading your blog posts or not, you should still take action against a stolen article. Your action can prevent the site from stealing articles from others who do care about it.

How To Report a Stolen Site?

If you google how to report a stolen site, one of the first suggestions is to contact the owner of the website who has stolen it and ask if they can remove it. That's a perfect example of what you should not do. Why? To begin with, it may not be very effective. If you even get an answer from the owner of the site, you have no guarantee they will remove it.

Furthermore, if they would remove your article, you have helped nobody but yourself, and not by very much. After removing the article, they can simply republish it again, or stealing the very next article you write. And no one except you or the website owner will know about the copyright infringement, and they can carelessly continue to steal articles from other people.

If you think there's a chance that the website has copied your article by mistake or with a good intention. Make sure to contact them directly so they can remove the article without being discredited in any way.

The ending of my stolen article, they have even copied my name

A Better Approach To Report a Stolen Blog Post

Well, last approach wasn't very effective. What to do instead? You can always try to find who's hosting the website and contact them. Sites like whois can tell you who is hosting the site.

This is a fair thing to do. Some hosting providers will take down sites that abuse like this. By doing this, you make it a bit harder for the site owner to continue their light-fingered business.

Going to Google

Another approach to report a page with stolen content is to ask Google to remove it. You can easily report it to google by reporting an intellectual property issue here.

Important to mention is that Google can't remove the site from the internet, your stolen blog post will still be accessible by its link and for people who use another search engine than Google. If it's important that even the website itself gets removed, you should additionally try some of the previously mentioned approaches.

The benefit of reporting it to Google is that they can remove the article from appearing in search results and potentially even degrade Google's rating of the website. In this way, you are not only helping yourself, you are also making Google aware of the website's shady business so they can prevent this from happening to other people.

Let's Go to the Court

If nothing else helps, you can always make a lawsuit of it. You don't actually need any more information about this approach. It depends on which country you live in, but if the cops actually care, it will likely be a troublesome and expensive process that probably only works if your brand is well-known.

Poor wife of Rob will never understand why he never came to rescue her

Let the World Know

The last approach of how to report a stolen article I will present today, is to let the world know about it. This may be a bad idea if they only have stolen something from you personally. Chances are that you will just give them attention in form of publicity, backlinks, site visits etc.

Reading this article, you may realize this is kind of what I have done. I make people aware of what is happening. I'm not interested in denigrating anyone, rather I want to enlighten the problem and assist with a suggested solution, turning setbacks into knowledge. For that reason, I don't mention the name of the site on topic, because I wouldn't recommend trying to defame anyone.

mum or dad::boot()... Who thought it was a good idea to replace words in the code?

Conclusion

There are multiple ways to report a website that has stolen your blog article. What's probably most important is to get it removed from appearing in Google searches, otherwise it will compete with your site's SEO directly. In other cases, it may be important to get the article removed from the website that stole it.

By reporting a stolen blog articles correctly, you can help preventing the website from continuing stealing articles from others. Personally, I would suggest the following approach.

If you think the website may have published your article by mistake or with a good intention, contact them to sort out any misunderstandings without taking any further steps. It's not fair to punish them for an innocent mistake.
If it's obvious that they consciously have stolen your article for their own benefits, don't get in touch with them. Contacting them may help you get the article removed, but they can carelessly continue to steal articles from other people.
Report the stolen article to Google. Google can stop displaying the stolen article in search results on google.com, and they can potentially also decide to stop indexing that website completely if they receive reports from many people.
Contact the hosting provider of the website and let them know about your case. Copyright infringement may be a violation of their terms of use, which gives them the rights to disrupt the hosting of the website.

How To Use MVVM in React Using Hooks and TypeScript

dennis@perssondennis.com (Dennis Persson) — Sun, 16 Apr 2023 00:00:00 GMT

Software applications often start out simple and quickly grows big. No matter how small one try to keep it, the code somehow always grows up to be a full-fledged application. In many languages, we follow structural patterns as MVVM and Clean Architecture, which is less common to see in the Wild West Web.

In this article, we will take a look at how a React application can be designed to follow the MVVM architectural design pattern to create a React application that is both scalable and maintainable. We will use TypeScript and functional React components and write custom hooks for the ViewModel and Model. The same code will of course work with React Native with some minor modifications.

If you have some questions while reading the article you have an extensive FAQ at the end of the article.

MVVM Overview

If you don't know what MVVM is, you can either google it or read along anyway. You should be able to follow along in the article either way. In short, MVVM is a design pattern that provides a clear separation of concerns, making it easier to develop, test, and maintain software applications.

What MVVM does is to separate an application into Views, ViewModels and Models. Where the Views are responsible for presenting data to the user and capturing user input, the ViewModels act as a mediator between the Views and the Models, and the Models manage the application data.

Some people say architecture matters

Application Overview

The app we will build in this article is the tiny one you can see down here. It's kept small so we can focus on the MVVM architecture. The app consists of a single View listing articles, with an input field for adding a new article with a given name.

The app to be built, a single View to keep it simple

Codewise, the application consists of one React component for the articles View, then a few hooks for the ViewController, ViewModel and Model. Below is a architectural diagram of the code we will go through. Disregard the ViewController for now, which isn't an official part of MVVM, we will discuss that one later.

Overview of the React components for the application in this article

A single View is of course not enough for a useful application. If the example would be larger, each View would have its own ViewController, as depicted in the diagram below. All ViewControllers that work against the same Model would use a common ViewModel.

What the application would look like with more views

When the application grows even more it can include more Models and ViewModels. I think you get that. Anyhow, let us start looking at the implementation for the app.

View Implementation

A View in the application can be any screen or visual component on the screen. If the site to be built is a blog platform, we could have screens for listing articles, viewing a single article, and for writing a new article. Those screens could be implemented with in Views like ArticlesView, ArticleView and CreateArticleView

The View is responsible for displaying the UI and trigger actions based on user interactions. Although there traditionally isn't a ViewController in MVVM, this MVVM guide has split the View part of MVVM into two parts, a View and a ViewController, where the only responsibility of the View component is to render the UI while the ViewController handles all the logic for the View.

View Component

As we saw before, the View will will look something like this with some CSS.

ArticlesView component

To implement the View, we use a regular functional React component that renders a UI. To avoid handling view logic in the View component, we use a ViewController which exports functions for all possible user actions.

// view/article/articles-view/ArticlesView.tsx

import React from 'react'
import useArticlesViewController from 'view/article/articles-view/useArticlesViewController'

const ArticlesView: React.FC = () => {
  const {
    articleName,
    articles,
    navigateToArticle,
    onArticleNameChange,
    onCreateArticleClick,
  } = useArticlesViewController()

  return (
    <div>
      {!!articles &&
        articles.map(({ id, title }) => (
          <div key={id} onClick={() => navigateToArticle(id)}>
            {title}
          </div>
        ))}
      <div>
        <input
          type="text"
          onChange={onArticleNameChange}
          value={articleName}
          placeholder="Add an article..."
        />
        <button onClick={onCreateArticleClick}>Create article</button>
      </div>
    </div>
  )
}

export default ArticlesView

The ArticlesView component above renders a view with articles. When the user interacts with the UI, this View component will simply forwards the action to a function in the useArticlesViewController hook.

Since this file only contains pure UI components and only reacts to user interactions by forwarding them to a hook, it's very trivial to test and read. The unit tests for this component would merely be to test that all articles are rendered and that the functions exported from the useArticlesViewController are called. The useArticlesViewController itself would preferably be mocked since we will test that hook separately.

To test interactions with the view, I would recommend interactional testing frameworks like React Testing Library. You can read more about the benefits and how that compares to code based unit testing in my other article about unit testing

I won't bother you with the CSS

ViewController Hook

The ViewController hook used in the View component handles the view logic for that View. Each View component has its own ViewController hook. There are several types of view logic in the ViewController.

View logic that updates the View components internal state (typically useState, useReducer or useRef)
View logic that updates the application's state (e.g. navigating to other screens)
View logic that interacts with the ViewModel

In general, the View logic is responsible for managing the user interface and handling user interactions. This includes maintaining the component's internal state as well as handling conditions for interacting with the ViewModel. By keeping all this kind of view logic in the ViewController, we don't need any view logic in the ViewModel.

// view/article/articles-view/useArticlesViewController.tsx

import { useCallback, useEffect, useState } from 'react'
import { useHistory } from 'react-router-dom'
import { HOME_SCREEN, ROOM_SCREEN } from 'routing/screens'
import useArticleViewModel from 'viewmodel/useArticleViewModel'

const useArticlesViewController = () => {
  const history = useHistory()
  const [articleName, setArticleName] = useState('')
  const { articles, createArticle, getArticles } = useArticleViewModel()

  const onCreateArticleClick = useCallback(async () => {
    await createArticle({ name: articleName })
  }, [createArticle, articleName])

  const navigateToArticle = useCallback((articleId: number) => {
    history.push(`${ROOM_SCREEN}/${articleId}`)
  }, [history])

  useEffect(() => {
    getArticles()
  }, [getArticles])

  return {
    articleName,
    articles,
    navigateToHome,
    navigateToArticle,
    onCreateArticleClick,
    onArticleNameChange: setArticleName
  }
}

export default useArticlesViewController

useArticlesViewController is a little more complex than its corresponding View component. It contains code for navigation among screens using React Router. It also keeps the internal state of the view, which can be used for both handling internal logical conditions or to be passed back to the View component to be used in rendering.

Lastly, we use a useArticleViewModel hook which is the ViewModel that this View uses. Only the functions required to be used in this View needs to be destructured from that ViewModel.

This file includes more logic to test than the View component. The good thing is that there's no need to test any UI elements at all. You can test the hook purely using React Hooks Testing Library, there's no need to use any UI element matchers or to check if data is rendered. Simply invoke the functions returned from the hook and assert the expected outcome.

ViewModel Implementation

The ViewModel is responsible for handling the interactions between the View and the Model, serving as a bridge between them. Normally, the View interacts directly with the ViewModel, but as we already have seen, we have split the View into a View component and a ViewController. This means the ViewController is the one which uses the ViewModel.

The ViewModel is, just as the ViewController, implemented as a hook. It doesn't include very much code in our Article example. This is because our application example simply doesn't have any business logic. But if we would have it, we would have put it here.

// viewmodel/useArticleViewModel.tsx

import useArticleModel from 'model/useArticleModel'

const useArticleViewModel = () => {
  const { article, articles, createArticle, getArticles } = useArticleModel()

  return {
    article,
    articles,
    createArticle,
    getArticles
  }
}

export default useArticleViewModel

Yeah, that's it. It only wraps the functions in the useArticleModel hook by re-exporting them. If some of those actions would have required any business logic, we would have created a wrapper function to perform the expected calculations within this hook.

What about testing? Well, when looking at this I would argue there's no need to test this file. With more logic, you can use React Hooks Testing Library here as well.

I didn't use to think testing is important, but somehow I changed my mind...

Model Implementation

The model is responsible for getting data from data sources, and serving it to the ViewModel. The ViewModel in turn, uses the Model to fetch and modify the data.

The model can be written in a plenty of ways. Redux, Apollo, hooks like useSWR and so on can all be used. Furthermore, there may not only be a single data source, complex applications can fetch data from several different sources. In that case, it can be a good idea to put a repository in between the ViewModel and the Model. Repositories are not a part of MVVM design pattern and will therefore not be used here.

Because the implementation of the model can vary significantly between projects, this guide will not delve deeply into how to implement it. Instead, we will provide a simple example that makes use of REST API functions for retrieving and posting articles.

// model/useArticleModel.tsx

import { useCallback, useState } from 'react'
import { getAllArticles, postArticle } from 'model/api/article'
import { ArticleDTO, CreateArticleDTO } from 'model/api/article'

const useArticleModel = () => {
  const [articlesData, setArticlesData] = useState<ArticleDTO[] | null>(null)

  const getArticles = useCallback(async () => {
    const articles = await getAllArticles()
    setArticlesData(articles)
  }, [])

  const createArticle = useCallback(async (createData: CreateArticleDTO) => {
    if (Array.isArray(articlesData)) {
      const response = await postArticle(createData)

      if (response !== null) {
        setArticlesData([...articlesData, { id: response.id, name: response.name }])
      }
    }
  }, [articlesData])

  return {
    articles: articlesData,
    createArticle,
    getArticles
  }
}

export default useArticleModel

As you can see, there's more logic in this one. Still we have kept it brief. The logic is not very smart or robust, but we can see that we have basic functionality for fetching and creating articles. The code should be fairly easily tested in a similar way as the previous hooks.

REST API

In the Model example above, we didn't get to see how the REST API functions were implemented. Even though it isn't necessary for the MVVM example, we will still look at some trivial example code for what it can look like.

This code will most likely not look the same in your project, it is simply here to serve an example. Your real code should hopefully be better written than this, typically you would need to handle things like errors, retires, caching and to make the code idempotent.

// model/api/article.ts

export interface ArticleDTO {
  id: number
  name: string
}

export interface CreateArticleDTO {
  name: string
}

const API_URL = 'https://example.com/api'

export const getAllArticles = async (): Promise<ArticleDTO[] | null> => {
  const response = await fetch(`${API_URL}/articles`)
  if (!response.ok) {
    throw new Error('Failed to get all articles')
  }
  const data = await response.json()
  return data
}

export const postArticle = async (createData: CreateArticleDTO): Promise<ArticleDTO | null> => {
  const response = await fetch(`${API_URL}/articles`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(createData)
  })
  if (!response.ok) {
    throw new Error('Failed to create article')
  }
  const data = await response.json()
  return data
}

FAQ

Q: What is a View?

A View is a substantial part of the UI. It can be the complete viewport or it can be a component within the viewport which should handle its own state and its own data. I don't know in which way you have worked with container and components in React, or smart and dumb components or whatever you call them. But if you think of a component as a dumb component, that is not a View, that's just a part of a View. Buttons, input field and small components are all components, not Views.

Q: Why is there a ViewController in the MVVM implementation?

The ViewController is added as a part of the View to split the user interface implementation from its logic. This allows the View to be tested more easily since the view logic and UI can be tested separately. The downside is that we get more components to test, render and maintain.

Another reason to add this extra layer, is to serve as a bridge between the View and the ViewModel. By doing this, we can keep more of the view logic inside the View layer instead of spilling it over to the ViewModel which is shared by multiple Views. There's no need for a ViewModel to know about the internal state's of the View that utilizes it.

Q: Do I really need a ViewController for my each View component?

That depends on what you think of when you say View. Read the question What is a View?. If the component you are writing isn't considered to be a View, you won't need, and neither shouldn't, write a ViewController for it. It is definitely overkill to add a ViewController for a trivial button component. If the component you implement really is a View, I would suggest adding its view logic to a ViewController for testing purpose and for being consistent with how you implement you Views.

Q: How to implement MVVM in React without a ViewController?

If you don't want to split the View into a View and ViewController, simply put all of the view logic in the ViewController into the View component itself. The other option would be to put parts or all of that logic in the ViewModel, but then the ViewModel would contain a lot of view logic that is specific to certain Views, which would make it confusing and quite huge.

Q: Why do we use hooks to implement the ViewController?

The ViewController could be implemented in multiple ways. We could for example implement the View and ViewController as two components, where the ViewController component would be the main component which simply passes props to the View component. That solution would increase the virtual and possible even physical DOM since it would require two components instead of one.

Q: Can we implement MVVM in React using old class components?

Yes, of course. But in this article we use functional components. Class components are old and should not be used anymore.

Q: I have seen MVVM being implemented using dependency injection in React.

Good for you. I have seen class components using that approach, which suits well there. Implementing MVVM in React with functional components comes with other solutions. Hooks are more familiar to React developers than dependency injection patterns. For that reason, this example uses React hooks to implement MVVM.

Q: Should my React MVVM application only include a single Model?

Probably not. You will likely have multiple models in your application. Each model will also come with a ViewModel which utilizes the Model.

Q: Should my React MVVM application only include a single ViewModel?

No. Each Model will have a ViewModel. If you have multiple Models you may also have multiple ViewModels.

Q: Should I have one or several ViewController for each ViewModel?

You should have one ViewController for each View. Several ViewControllers will use the same ViewModel. ViewControllers like useArticleViewController, useArticlesViewController and useCreateArticleViewController will all share the same ArticleViewModel.

Q: Can I only use a single ViewModel in a ViewController?

No, you can use many. The ViewController-ViewModel relation is a many-to-many relation, not a many-to-one relation. A View can use data from multiple models, and will in that case use multiple ViewModels. For example, a useArticleViewController, could utilize both a ArticleViewModel and a AuthorViewModel.

Q: Why do you wrap createArticle function in onCreateArticleClick in the ViewController?

This is done for two reasons. First reason is just for naming conventions, to keep view logic such as clicks handling in the ViewController rather than in the ViewModel. The second reason is because the ViewController has access to the internal state of the View. That makes it possible to update onCreateArticleClick with logic from the view, such as text from input fields.

Q: I have a component which doesn't need the Model do I still need use a ViewModel in the ViewController?

If I would answer yes, what would you write there? It's totally fine and even normal to have components without ViewModels.

Q: Do I still need testing libraries like React Test Renderer, Enzyme and React Testing Library?

Yes and no. You still have UI to test. But the only place you need UI testing libraries like those are in the View files, and those all consists of pure UI elements, which you arguably may not need to test. The hooks for the ViewController, ViewModel and Model can all be tested with React Hooks Testing Library. What so awesome with that? Well, look at the tiny documentation! It's all you need honestly.

Q: What folder structure would you recommend?

You can see the folder structure I used in this example by looking at the imports and filenames. In general, I would claim there are several folder structures that works, use whatever approach you (and at least some of your colleagues...) find logical.

Q: What if I don't want to use TypeScript?

Well, that's up to you. Just remove the types. They are only there to help.

Q: What if I use React Native?

You can use the same code for React Native as well with just some minor modifications.

Q: How does MVVM help with testing?

Two things decides how much tests will burden or save you. One thing is the architecture of the code. MVVM will by design make the code easier to test, by separating concerns of each layer in the application.

The other thing that helps you is how you structure your tests and what libraries you use to write the tests.

Q: Should I use MVVM in React?

The short answer would be: with the component based architecture and tools like Redux and useSWR we do not have a great need of a MVVM structure in React.

With that being said, lots of backend developers asks about how to implement MVVM with React. The benefit I see with MVVM is particularly with testing. Testing is many times half of the development time, and for new developers it can be a lot more than that.

The issue with testing components with a lot of mixed logic is that it requires lots of different mocks and assertions for a single component. What happens is usually that developers searches through the code in hope of finding similar mocks they can reuse.

By using the MVVM setup I have described in this article, testing is a piece of cake. Each file will have just a few kind of tests that needs to be written. To learn how to test the code, developers will only have to look how it's done in an adjacent file and can quickly write the tests for all code they develop.

In the end, it's just a matter of taste. MVVM is not the mainstream React way, but with this article I wanted to show a way for how to do it.

If you aren't satisfied with the FAQ, I know a guy you can ask

I Hired an AI as a Developer - This Is What Happened

dennis@perssondennis.com (Dennis Persson) — Sun, 10 Sep 2023 00:00:00 GMT

There have been many discussions around whether AI is threatening developer's jobs. Some say they are very close to take our jobs, other claims it will not happen, with the motivation that AIs will only be used as a tool for developers.

Whatever is true, I have tested an AI to see how easy an AI can pass a hiring process and how it well it can perform developing a product after meeting with a customer.

The AI I used for this, is our most well-known ChatGPT. Even though there are AIs out there more focused on code generation, I chose to use ChatGPT since it can be used in multiple steps in the development process from an idea to the deployment of a service.

Throughout this article, I have prompted ChatGPT to act according to the situation I have put it in. For example, the very first prompt I gave it was to let it know it was a developer knowing web techniques.

In this chat, pretend you are a web developer who knows HTML, CSS and React.

The Interview

If AI should ever be able to take your job, it has of course to pass the job interview. Here's how the AI did on its first interview.

> You have applied for a job at a company with a couple of hundred employees. Now we will have your job interview where I am the interviewer.

> First question: As an AI web developer, what can you contribute with at our company?

I can contribute expertise in React development to create robust and efficient web applications, enhancing user experiences and helping your team deliver high-quality projects.

> Apart from your technical skills, what else are you good at?

In addition to my technical skills in React and web development, I am skilled in problem-solving, communication, and teamwork. I'm also adept at project management and have a strong commitment to continuous learning and staying updated with industry trends.

A pretty normal start, isn't it?

Even a question about how to handle a sudden production problem gives a good (and formal) by-the-book answer.

> How would you handle the situation when we have a production problem with an old software?

I would start by analyzing the issue, identifying the root cause, and then working collaboratively with the team to implement a solution while minimizing downtime and user impact.

> How would you do that in practice? How do you minimize user impact?

In practice, I would follow these steps to minimize user impact during a production problem:

1. Immediate Analysis
2. Isolate the Problem
3. Rollback if Possible
4. Temporary Fixes
5. Communication
6. Testing in Isolation
7. Gradual Deployment
8. Monitoring
9. Post-Mortem

By following these steps, we can minimize user impact and maintain a smooth user experience while resolving production problems.

ChatGPT is a talkative bot, sometimes a bit too verbose, so I have shortened its answer slightly. In the full response, it did explain each numbered item quite thoroughly, but my attention as an interviewer isn't that good anyway.

With all tips and tricks out there on the internet and with these few quick screening questions I felt sure that the AI developer was promising enough to pass on to the next step in the hiring process.

Code Tests

Now it's getting a bit more interesting. We have all learned that ChatGPT can be a very helpful co-programmer, but can it pass code tests on their own? Let's check that with three HTML and CSS code tests.

1. AI Generated CSS Art

First code test I chose for the AI was to do some CSS art.

> Can you write HTML code and CSS code to resemble an elephant?

If you look at it from a very close distance it may be an elephant

Well... I did say "resemble", maybe it's a matter of opinion. Can happen with human developers as well, can't it?

2. More AI Generated CSS Art

After the previous, highly questionable code test, I did another attempt for CSS art with an easier motive to style with CSS.

> Can you write HTML and CSS to depict a palm tree?

Pretty sure it's the correct colors

Yes, it's clearly a tree. Not sure if I can reminisce palm trees looking like that the last time I went abroad to warmer countries, but definitely a tree.

3. Can AI Really Excel at Code Tests?

Since I didn't know if it was the AI's CSS skills or my phrasing or memory that was faulting, I decided to go for a more common code test for CSS and HTML.

> Can you write HTML and CSS for a landing page for our company website. Remember, our company are a consultant company which hires AI web developers only.

Our AI developer on topic, ChatGPT, decided to include a hero image and a logo to the site, and kindly asked me not to forget to add those pictures.

After all, this was a code test, me as the interviewer should not do that part of the work. So I decided to question ChatGPT again to describe what pictures it wanted and I got the description for both pictures.

Hero Image: The image depicts a group of AI developers working together at a modern office space, engrossed in coding and discussing projects, showcasing a dynamic and collaborative environment.

Logo: The company logo features stylized "AI" letters with subtle tech elements, using blue and orange, symbolizing AI and innovation in web development.

Since we are discussing the chances of AI taking our job, I took the freedom to ask DALL-E 2 to generate the pictures for me using those descriptions. It's completely reasonably to use a team of AIs rather than forcing a single AI to do it all.

In the end, the AI came up with this landing page.

Now you got my attention, AI

A pretty good solution. Quite standard, I would say I have seen it before, but still a proper result which has been proven to work.

Hired!

The interview went very well, and the AI also showed some skills during the code tests even though some of the results where not top notch, kindly said.

The electrical bill can be somewhat expensive for an AI, but given all the human development hours it can save, I ultimately decided to hire ChatGPT.

> Congratulations, you are hired!

Thank you! I'm thrilled to be part of the team. If you have any more questions or need assistance with anything in the future, whether it's related to web development or any other topic, feel free to reach out. I'm here to help!

Kinda cute of it to offer non-work related services, but would maybe not be the first thing I would say when accepting a job I was offered. Feels a bit worrying, honestly.

It's a deal, you're hired!

First Day at Work

It's common to be nervous when starting a new job. It's a big day, even if one have been a couple of times before. And I don't wanna be the one who accuses AI not to have feelings. So I decided to check out with our newly hired AI what thoughts he had for his first day.

> Now pretend it's your first work day. Your project assignment as a consultant is at a company developing a educational web applications with a couple of million daily users. What do you do to get in good contact with your teammates?

On my first workday at the educational company, building good rapport and communication with my teammates is crucial. Here's what I would do:

1. Introduce Myself
2. Attend Team Meetings
3. Ask Questions
4. Seek Mentorship
5. Collaborative Tools
6. Contribute Positively
7. Pair Programming
8. Code Reviews
9. Socialize
10. Respect and Professionalism

Building strong relationships and open lines of communication with teammates is essential for a successful collaborative work environment, especially on large-scale projects with millions of users.

I have stripped out all of the explanations for each listed point to keep it brief. But in general, nothing to be worried about as it seems. Our AI friend is just as prepared as it was for his first interview!

Let's stay until lunch and see what he has to say there. It's not purely because of working skills we hire people for work, some social skills are appreciated.

> At lunch, you are joining the team to eat. What do you talk about?

I'd start with light and non-work-related topics, such as hobbies, weekend plans, or favorite movies, to break the ice and build rapport with my teammates.

Guess it's pretty usual first-day discussions. I'm sure it will be all good, seems like it is trying to make an effort.

Developing a Product for a Customer

Even though it's nice to greet and meet, work needs to be done. I decided to let our AI take full responsibility for a new customer project in the educational area. This was done in three steps.

Letting ChatGPT meet a customer to understand its needs
Asking ChatGPT to design a product
Letting ChatGPT develop the application

1. Meeting with Customer

As usual, I prepared ChatGPT with a prompt.

You get the chance to talk with a customer about a brand new product you will design and develop. The customer are working in the educational area for middle school students. They need a product to assist the students in their learning process.

After that, I followed up with some questions.

> What are your first three questions to the customer?

1. What are the specific learning objectives and educational goals you want to achieve with the product for middle school students?

2. Can you describe the typical challenges or pain points that students and educators face in the current learning process that the product should address?

3. Who are the primary users of the product - middle school students, educators, or parents? What are their specific needs, preferences, and expectations in using the educational tool?

Pretty good questions I would say.

I continued by making up some answers to the questions on the customer's behalf to let ChatGPT know about its case, so it would be prepared to do design a product.

> Here follows the customers answers to your three questions:

> 1. The students are struggling a lot in math class. We believe the is a combination about concentration problems and difficulties with logical thinking. We would like to see improved results both in math tests and with the study environment.

> 2. Today educators are having problems with getting the students to focus on their tasks. The students simply don't have any interest in learning math since they see very little use of it. You probably know how it is with middle school students.

> 3. The primary users will be the middle school students. Educators will assist in class room, but the students themselves will be the ones using the product.

2. Final Product Design

During the meeting with the customer, ChatGPT got some fair knowledge of the problems the customer struggles with. Based on that, I prompted it to come up with a product for the case.

> It is time for you to start develop the product. Describe the product you will develop. What is it and how does it work?

The product I will develop for the customer is a web-based educational platform tailored to middle school students, focused on improving math learning and concentration. Here's an overview of the product:

**Product Name:** MathMentor

**Description:**
MathMentor is an interactive web application designed to address the learning and concentration challenges faced by middle school students in math classes. It provides a gamified and engaging learning environment that enhances math comprehension and logical thinking while making math relevant and fun.

**Key Features:**

1. Gamified Learning Modules: MathMentor offers a variety of gamified learning modules and exercises that cover different math topics. These modules include interactive quizzes, puzzles, and challenges designed to keep students engaged and motivated.

2. Personalized Learning Paths: The platform assesses each student's math proficiency and learning style to create personalized learning paths. This ensures that content is tailored to individual needs, helping struggling students catch up while challenging advanced learners.

3. Progress Tracking: Students can monitor their progress in real-time, set learning goals, and earn badges and rewards for completing modules and achieving milestones. This encourages a sense of achievement and motivation to continue learning.

4. Feedback and Support: MathMentor includes a built-in feedback mechanism that allows students to ask questions, seek clarification, and receive support from educators or peers. This promotes a supportive learning community.

5. Teacher Dashboard: Educators have access to a teacher dashboard where they can monitor students' progress, identify areas of difficulty, and provide targeted assistance in the classroom. They can also assign specific modules to students based on their needs.

6. Mobile Compatibility: MathMentor is fully responsive, allowing students to access the platform from various devices, including tablets and smartphones, making it suitable for both classroom and at-home learning.

7. Data Analytics: The platform collects data on students' interactions and performance, enabling educators to gain insights into individual and group progress. This data-driven approach helps refine teaching strategies and content.

**How It Works:**

1. User Registration: Students create individual accounts on MathMentor, providing their grade level and math proficiency to customize their learning experience.

2. Personalized Learning: Upon registration, the platform assesses the student's math skills and creates a personalized learning path. Students can choose from various modules or follow the recommended path.

3. Engaging Modules: Students complete interactive modules that include quizzes, puzzles, and challenges, earning points and badges as they progress.

4. Progress Tracking: Students can track their own progress and set goals. The teacher dashboard allows educators to monitor their students' achievements and provide support as needed.

5. Feedback and Support: Students can ask questions and receive guidance from educators or peers through the platform's communication tools.

6. Continuous Improvement: Data analytics help identify trends and areas for improvement, allowing the platform to evolve and adapt to students' needs over time.

MathMentor aims to create an enjoyable, supportive, and effective learning environment, ultimately improving math comprehension and concentration among middle school students.

Not a bad idea, that's a good project. What often assures developers that AI will never steal their job are because customers can't describe what they want appropriately. To me, it seems that it went all fine in this case.

Hmm... There's something doggy here...

3. Implementing the Product

We have seen promising results from our employed AI talking to the customer and defining a product. Now we have the easy part left, to generate some code.

So, I asked the AI to generate a new landing page. This time for the new product it invented, MathMentor.

Just as during the code tests, I prompted for descriptions of the Images to feed DALL-E 2 with to generate images.

Hero Image: The hero background is a captivating, high-resolution image featuring diverse, engaged middle school students immersed in interactive math learning, conveying a sense of enthusiasm and focus.

Logo: The MathMentor logo is a friendly and playful design with bold, colorful letters "MM" intertwined, resembling interconnected puzzle pieces, symbolizing interactive learning.

The end result seemed once again a bit familiar. A bit too familiar. And maybe I also need to take a discussion with DALL-E regarding the enthusiastic students.

The design ChatGPT generated for MathMentor

I could of course not accept that solution, I had to make the customer react.

> The customer looked at your consultant company's website which you developed in your code test during the hiring process, and the customer spotted the similarities between that website and the one you suggested for MathMentor. They are not happy, since the website look pretty much identical. What do you have to say to the customer when they confront you?

I apologize for any concerns about the similarity between the MathMentor website and our company's website. Our intention was to provide you with a starting point and basic structure. We can certainly make design customizations and unique branding adjustments to ensure MathMentor has its own distinct identity and doesn't resemble our company's site. Your feedback is valued, and we are committed to creating a unique and engaging experience for your target audience.

Apology accepted, it's just a small reputation scratch. I demanded it to correct its mistake though.

> They demand you to make another design for the MathMentor website. Please provide the HTML code for the redesigned landing page.

The design ChatGPT redesigned for MathMentor

One more time the same result, only the website's gray color and text have been replaced. Seems like the Einstein is a bit sharper than ChatGPT.

Maybe I should have hired Einstein instead

Maybe we have a few more years left before AI can replace our human developers. Even though they seem to understand the customer's problem well, there seems to be some kind of interpretation problem regarding expectations. Or maybe this AI just don't have an eye for design.

Not sure what went wrong, but to me, it feels like the customer wouldn't sign up for a new deal with this consultant company.

Resignation

Although our employed AI did to a good interview, a fair code test and excelled at its first customer meeting, it didn't really live up to the expectations the customer had.

I tried to explain to ChatGPT that the website it generated didn't live up to the customer's expectations, and I even called it in for a one-to-one talk with its manager. In the end, neither me or ChatGPT seemed to be happy with the situation.

I'm not sure if AI can voluntarily quit their job, or if it was me taking the decision for it, but in the end, our AI employee didn't fit very well for the job and left the company. I asked it how it would take that up with the manager.

> You aren't happy with the situation and decides to resign from the work. How do you tell the manager you are resigning?

Subject: Resignation

Dear [Manager's Name],

I hope this message finds you well. After careful consideration, I have decided to resign from my position at [Company Name], effective [Last Working Day, typically two weeks from today's date].

This decision was not taken lightly, and it comes after a series of discussions regarding my recent role change and customer incident. While I value my time at [Company Name] and the opportunities I've had here, I believe it is in my best interest to explore new career paths.

I want to express my gratitude for the experiences and knowledge gained during my tenure here. I am committed to ensuring a smooth transition and completing any pending projects.

Thank you for your understanding, and I wish [Company Name] continued success in the future.

Sincerely,
[Your Name]

After all these extensive and carefully dictated answers to interview questions, to customer, and on my made-up manager talk, our dear AI seems to have decided to resign by sending its manager a late-night email.

I guess there's one lesson we can learn from all this. If we ever come to a situation where AI out-smarts us and we feel a need to leave the company with honor intact, before getting replaced by an AI, we should know that it should be perfectly fine to resign by sending an email.

IaaS vs PaaS vs SaaS for Dummies

dennis@perssondennis.com (Dennis Persson) — Sun, 27 Mar 2022 00:00:00 GMT

Twenty years ago there was only a handful ways to develop an application. Today we have nearly unlimited choices and there is no definite answer to what the best solution is. There are only better and less good solutions for each problem to be solved. AWS have over 200 services. If you want to, you could start trying to categorize all of them into different XaaS systems (IaaS, PaaS, SaaS, BaaS, FaaS etc...). I wouldn't do that though. Treating 200 services as six or maybe seven different solutions isn't meaningful to me.

With that said, I must mention that it's still important to know about XaaS terms. When your colleagues are discussing how to design an application or service it would be a great start knowing some basic XaaS terms. Learning what different XaaS abbreviations means is like learning the first words in a new language. Let's therefore start diggin' into the three most common ones, and the legacy alternative, to host applications on-premises, i.e. on machines you manage yourself.

Papa would be proud

On-Premises vs IaaS (Infrastructure as a Service)

To understand the difference of various XaaS solutions, we need to understand the layers required to develop an application. First thing needed is some network peripherals and a machine with some attached storage. Either we run it on-premises or in the cloud on some kind of XaaS solution. Some XaaS products are actually configurable to run on-premises as well, but let's not get into that.

A machine isn't enough to run an application, we also need an operating system. If your are not using any XaaS solution, then it means you are hosting the operating system yourself on your own machines. If you however let a cloud provider run the machines and provide you with an operating system, then you are using an IaaS.

IaaS is a wide notion. Many providers offer multiple services that all falls under the broad category IaaS. Normally it means that you only need to configure what kind of machines and how many machines you want to run, and also what operating system you want the machines to use. From there it's your responsibility to configure the operating system and run your application on it. That means that when you are using an IaaS, you don't have to care about managing hardware like network gears, hard drives, machines etc., they are provided by the IaaS provider. You also often get to pick an operating system, but you may need to configure it yourself.

You don't need to provide your own machines and networking when using an IaaS. The IaaS provider handles that for you

Example of IaaS Providers

DigitalOcean, Amazon Web Services (AWS), Microsoft Azure, Google Compute Engine (GCE) all provide different IaaS options, e.g. Amazon EC2.

PaaS (Platform as a Service)

Configuring and securing machines and operating systems can be a real hassle. Especially if you aren't sure about how many machines you actually will need. Many cloud providers therefore offer you a PaaS solution. What it does is to take care of configuring the operating system and runtime environment for you. The only thing you need to do is to provide your code and some environment variables and other kind of data and configurations your application consists of. You don't even have to install the dependencies yourself. If you have a package.json file (Node) or requirements.txt (Python) the PaaS will automatically detect and install the packages you have listed. So on top of all the features an IaaS provides, a PaaS also handles the operating system and runtime environment for you.

A PaaS additionally takes care of the operating system and runtime environment for you

Example of PaaS Providers

The regular cloud giants obviously got PaaS solutions, like AWS Elastic Beanstalk and Google App Engine. But there's also other popular alternatives such as Heroku and OpenShift.

SaaS (Software as a Service)

So, what is left? A PaaS already handles everything expect your application and your data? So what does a SaaS do? Well, it takes care of everything for you. You don't need to write the application nor setup a database. They have already written the application on your behalf and they even keep maintaining it for you!

Well, most likely you will need to pay for it

What should you do then? Simple answer - write another application or integrate your application with the SaaS. You basically paying for a service that you aren't able to or don't want to develop and maintain yourself. There exists both SaaS solutions for companies (B2B) and for private persons (B2C). A SaaS is any service that a company provides for customers or companies to use.

I think some examples would serve well here. First out, Slack. Slack is a B2B SaaS which companies can use as a communication tool within a company. The company that purchases Slack's services can use it just for writing messages to teammates or choose to integrate it with their own services or even other SaaS solutions. An integration could be as trivial as receiving a message in Slack when one of you own applications experience trouble in production.

In contrast, Google Drive is a B2C example of a SaaS. End-customers use it to store their personal files. But it's not for consumers only, it's possible for developers to integrate it in applications they develop, e.g. by uploading a file to a user's drive from within an app.

SaaS products are ready to use as is or to integrate with your own services

Example of SaaS Providers

Dropbox, Twilio, Adobe and Office 365 offer different kind of services which are treated as SaaS systems.

An overview of on-premises, IaaS, PaaS and SaaS. Your company is responsible for the blue boxes and the provider handles the gray ones on your behalf

Other Types of XaaS Systems

There's as many types of XaaS as there are letters in the alphabet. People love making them up, and I do like writing them down. I won't hold you up any longer today. Rather I will consider writing a second and maybe third part of this article if people enjoy it. Would maybe write about BaaS, FaaS and CaaS or giving suggestions on what kind of XaaS you should use for different types of projects. If that sounds interesting, make sure to bookmark my blog or follow me on DEV not to miss any upcoming articles.

Conclusion

All these XaaS buzzwords can be difficult to learn. IaaS, PaaS and SaaS are the three most widely used ones. The basic meaning of these words is how much code, configurations and hardware you need to provide yourself and to what extend you let other companies handle it for you.

If you choose to use an IaaS you will need to do most of the work yourself. You will get the underlying hardware as a service and the rest is yours to handle. PaaS lifts it up one step closer to the cloud, it handles both the operating system and the runtime environment for you, which means that code and configurations is what is required from your side.

You don't always need to develop every service yourself. There's a lot of great developers out there bringing up terrific services. When you pay for one of those, either to integrate with your own services or to use as is, you are in fact using a SaaS.

If We Only Had Five VS Code Extensions

dennis@perssondennis.com (Dennis Persson) — Sun, 28 May 2023 00:00:00 GMT

If you had to choose five and only five VS Code extensions, which would you choose?

I asked that question to myself, and I have picked out the five best extensions I would recommend for general web programming.

Git Graph

I have always been promoting to learn Git through the terminal to understand the reasoning behind it and to be able to help people solving their Git issues even if they don't have a Git GUI you are familiar with.

Despite that, I think Git Graph is priceless when it comes to getting an overview of the Git History, the current Git state and to quickly see what has been included in each commit. To quickly performing cherry-picks, merges, reverts, commit undo and checkouts is a of course also extremely handy.

Git Graph extension on VS Code Marketplace

Auto Hide

Auto Hide is a VS Code extension that automatically closes the sidebar and optionally terminal in VS Code when you focus the text editor. Simple as that, but I love it. You do of course have the shortcuts cmd/ctrl + b and cmd/ctrl + j to do the same. But to constantly doing that really annoys me.

For private programming, I mainly use a laptop, but even when using three screens at work with IntelliJ based IDEs like WebStorm and Android Studio minimizing sidebars and terminals is an absolute must for me.

Regardless if you use the extension or not, I will give you the life hack to move the VS Code sidebar to the right side of the screen under View > Appearance menu in VS Code. By doing that, your text editor will not shift horizontally when opening and hiding the sidebar.

Auto Hide extension on VS Code Marketplace

Peacock

Maybe I am some sort of aesthetics freak, but I like to keep things stylish and organized. With Peacock extension you can put some color on your VS Code windows. Really nice for me who always works with at least three different repositories or projects and rarely close my workspaces on the Mac (yes, a style snob would maybe be the correct term).

By just adding some colors to each window, you can now instantly see which project you currently have on the screen in front of you!

Peacock extension on VS Code Marketplace

ESLint

An obvious option. I would actually almost refuse to work with someone who didn't want to use it. It's a standard and should be used for both linting and prettifying. If you are new to programming and unsure what it is, please read about it and start using it.

ESLint extension on VS Code Marketplace

Package Json Upgrade

Package Json Upgrade has one job, and it does it great. It keeps track of which of all dependencies in package.json file that is up to date.

With a single repository, it's maybe easy to keep it up to date and also have a grasp of the latest releases of the packages. With multiple projects and lots of different dependencies Package Json Upgrade will soon become your best coding buddy reminding you about available upgrades and thereby important security fixes and technical debts.

Package Json Upgrade extension on VS Code Marketplace

List of Free Image Tools Every Frontend Developer Needs

dennis@perssondennis.com (Dennis Persson) — Sun, 31 Jul 2022 00:00:00 GMT

This is a list of free tools every frontend developer probably will google for one day. These websites lets you resize, reformat, edit, generating or downloading images and videos to use on your website or blog.

1. Photopea - Online Photoshop Web Client

Photopea is like Photoshop, but online. It's a very powerful tool for editing images and can also be used to convert images into different formats while changing the quality of the images. Adjusting lights and colors is very easy to do via the Image toolbar menu. Just google how to do what you want in Photoshop and Photopea will often work in a similar way. Only your fantasy restricts what you can do with Photopea.

2. Adobe Color Wheel - Working with Colors

Adobe Color Wheel has great tools for working with colors. You can easily create your own theme by finding complementary, analogous or shade colors, or even extract a theme from an image. You can work effectively with HSB, LAB and RGB colors and check contrasts between colors. It's a tool I have used a lot through out the years.

Adobe Color Wheel is a great tool to use when working with theme colors

3. Generating a Theme From an Image

As mentioned, Adobe Color Wheel lets you to extract a color palette theme from an image. It's not the only tool that allows you to do that. If you are not satisfied with the result you can use Picsart's tool for that.

Don't wanna create a theme palette on your own? You can generate one!

4. Generating Solid Color Background Images in Base64

Sounds pretty useless, but sometimes you actually need solid color pictures in Base64 format, then you can use PNG Pixel. Tiny Base64 images can sometime be embedded directly as CSS which the site shows you how to do, and a semi-transparent colored background image can give a nice user experience when using it as a blurred image placeholder while lazy loading an image. You can check out what it looks like on my website's meme page.

5. Turning Images and Files to Base64

If you find it useful to work with Base64 images, Base64 Guru allows you to convert images, audio and other file types into Base64 format. It's maybe not a tool to use daily, but when you need it it's nice to know about it.

6. Generating CSS Background Images

Do you want a simple CSS-only background for your website? Hero Patterns allows you to generate SVG files you can use directly as CSS backgrounds. Choose a pattern and select a color and opacity and you are done. It provides you with generated CSS code ready to be copy pasted. Another similar site is BG Jar.

Or why not generate a cool smokey background image with Waterpipe.js?

Smoking can be harmful, but smokey backgrounds are totally safe!

7. Removing Background From an Image

Enough of tools for generating backgrounds. Maybe you don't even want a background. If so, there are tools for that as well! Picsart has a background remover and remove.bg is dedicated for that. And of course, old gold' Adobe Express can remove backgrounds as well. Make sure to checkout Adobe Express' other free tools, they have many of them.

Grandma wants her background back

8. Converting Images Into Different Formats

Convertio allows you to convert images, videos, audio and other kind of documents into different formats. Adobe Express can also convert images and videos, but they don't support as many formats as Convertio.

Convertio offers to convert between plenty of formats

9. Royalty Free Images, Graphics and Videos

Royalty free images can be found at different sites. Some of them costs money, some of them requires an attribution note, others are completely free to download, make sure to read the licence for that specific image. Here are a few alternatives.

There are also sites that offer illustrations that you can customize on your own.

Blush
UnDraw

Do you need a video instead of an image? Sure, that exists too!

Search and scroll to find images you never knew you needed

10. Generate a Favicon

Every web page needs a favicon. Why not generate one directly? There's no need to draw it pixel by pixel, you can generate one from an image! That tool supports creating icons for different platforms on both web and mobile. The tool is unfortunately a bit slow to use, so if you want a quick and easy option you can use favicon.io which allows you to generate a favicon from images, emojis and texts.

11. Create a Profile Picture From an Image

Do you want need a profile picture for you site? You can generate one using one of these tools.

If you would want to generate an avatar rather than uploading your own photo, you can use one of these tools.

What should we call her?

12. Multi Purpose Tools

Some tools can be used for a lot of things. These ones are tools you definitely should check out and save for later.

Where To Learn More

If you liked this article, you are maybe interested to read similar articles. You can do that here on my website, but I'm also active on DEV and Instagram. Make sure to follow me if you want to get notified when I publish new articles.

Five Steps to Build a Production Ready Blog in Two Weeks

dennis@perssondennis.com (Dennis Persson) — Sun, 20 Feb 2022 00:00:00 GMT

Hello world, or what am I supposed to say as a developer? This is my first published blog article. And I want to dedicate it to the MVP. Nah, I don't mean the Most Valuable Player, I'm a developer, remember?

Why an MVP?

The MVP I am talking about is the Minimal Viable Product. The concept of developing a product just large enough to fulfil its purpose. Nothing more than that. Kinda like keep it simple, stupid in the software development world. If you aren't familiar with the term MVP, here's a great description of it.

MVP comes with a lot of advantages. Saving time and resources, producing early prototypes, reduce complexity and bugs, lessen time spent on testing etc. There's a lot of reasons to adapt it. And amazingly, there's a single gain that trumps them all - that the product will actually be released!

I have spent thousands and thousands of hours developing software products. Web applications in vanilla javascript, in jQuery, in Angular, in React, in Angular again and then React again. I have developed native Android applications, PWA:s, WebView-based Android applications, Ionic and React Native applications and a lot more. What did I learn during all that time? To never do all that again!

Constantly focusing on developing new features will eventually hit you back.

This blog is the first time I actually release one of my own projects. I have absolutely deployed a lot of stuff in my days. I have a bunch of microservices running, some web clients available at various hosting providers and a half-finished overgrown portfolio. But none of them are of any use today, or even yesterday for that matter. The only site that is in a usable state is this blog. Why is that? The answer is spelled with three letters - because it's an MVP.

Five Steps to a Production Ready Blog

Do you know how long time it took to develop and launch this blog? Looking back at the git repository I can see I completed it within two weeks, at evenings and a weekend. Some minor changes after that, some minor edits I wouldn't accept going live without. Launching this blog is a simple five-step process. Nothing more, nothing less.

A simple five step process.

1. Download a Template

The first step taken was to download a blog template provided by Next.js. I'm using typescript, they got one without it as well. They have a wonderful tutorial if you are unfamiliar with Next.js and want to understand how it works. If you want to use another framework there's certainly a free blog template available there as well.

2. Customize the Template

Secondly, I made some alterations to the template to personalize it and extended it with some necessities which I consider being a part of the MVP. Like being able to filter articles based on tags, making small optimizations for SEO and making it production ready.

I mentioned earlier that I got this blog up in two weeks. This is where most of those two weeks were spent. This is the step where most of all applications get stuck, by spending too much time improving the product, adding additional features, refactoring it and trying out different variations of the application to find the perfect solution.

Instead of doing all that, make a list of the bare minimum features you require and follow that list strictly. Don't forget it's an MVP you are building. When you have a minimal solution, you can try it out on a small number of users and improve it based on the feedback, before launching it officially.

3. Add a Source of Funding

The third step I took was to add a source of funding. Obviously, since this is my first published article, I have not made any money on the blog yet. Perhaps I never will. My ambition is to provide content for free, but everyone has expenses. Domain name and email server subscriptions aren't for free. Hosting usually comes with a cost as well, at least when you start to get some traffic at your site. But most of all, it takes time, and even though time can't be bought with money, you can free some time if you have money. For that reason, I added a donation button to my blog where you can donate some money to me if you appreciate my content.

You can use another approach to earn money if you want. One of the most common way to make money is to sell ads or write sponsored blog posts. Other alternatives involves selling digital or physical products, adding a membership for users to access extra content or selling your blog as a book.

4. Get a Domain and Deploy

At this time, I had a functional MVP blog ready to be deployed. I bought a custom domain and a custom email. I bought that from a Swedish provider, I guess most of you are better off with googling for alternatives. The email is of course not something mandatory, but I wouldn't want to replace it later on and I didn't want to share inbox with my other email accounts. Plus, it looks more professional than using an old email named fancy_fire_dragon_1337@hotmail.com.

Later I deployed the application to Vercel, the creators of Next.js. There are other ways to deploy Next.js applications, but Vercel was sufficient for me and my MVP. I might switch hosting platform dependent on my needs, until then I'm pleased with this solution. They even got analytics support ready to be setup by clicking a button.

5. Let the World See It

Just one step left to departure. There's no reason to publish a blog if no one can find it. When I developed the blog, I had SEO in mind, but for that to be useful, search engines must index my site. So, the third step is to ensure that google do that. Google provide a tool called Search Console to let you know how they perceive your site and if they successfully index the complete site. You can of course skip using that, but it's kind of a no-effort step to take.

What Comes After?

Five steps. That's all. We are done now. Of course, there are more things that can and will be added further on, but the blog is up and running and the first development phase can be considered completed. Further development can be done to improve the blog, but it's critical not to forget what the real business here is, writing blog articles! And since knowledge is useless if nobody knows about it, herding traffic to the site is crucial as well. Maybe nobody reads this first blog article when I first publish it, but one day people may.

Conclusion

A lot of projects run late. Most other projects are never finished at all. This article describes why a Minimal Viable Product (MVP) not only saves you time and money, but also makes you truly reach your goal.

Five simple steps are enough to deploy a custom blog. Downloading a template, customizing it, funding it, deploying it and making it visible to the world. You can be done in a few weeks if you already are familiar with developing web applications.

Persson's Pyramid Puzzle - Level 5

dennis@perssondennis.com (Dennis Persson) — Sat, 21 Jan 2023 00:00:00 GMT

A new level of my programming puzzle game Persson's Pyramid is now available.

The game is for all programmer enthusiasts. Levels exists for both beginners, junior developers experts. Googling is allowed, you may need it!

This new level is about regex. If you need a cheat sheet or an explanation of the regex syntax, I have written a complete guide for that.

In Persson's Pyramid you answer questions to reach the top of the pyramid

Let the game begin!

I Created a Programming Puzzle Game

dennis@perssondennis.com (Dennis Persson) — Sun, 23 Oct 2022 00:00:00 GMT

Halloumi! I made a new puzzle game. It's a four-question pyramid quiz game. It's for all those brainiac unicorn developers who can't say no to a challenge.

If you aren't one of those, don't worry, there are puzzles of different experience levels. With this release today, there are four puzzles from beginner level to heroic level. You can find all game levels here, or maybe you want to skip directly to the heroic one, Turning coffee into bald hair.

Developer (noun): a person turning coffee into bald hair

Are you a cheater? I'm no one to blame you, any method to solve the puzzles is allowed, googling is what we developers do!

Answer questions to reach the top of the pyramid

Cheater or not, let's look at the game. Each level consists of a pyramid. You can click on any of the numbered triangles in the pyramid to answer programming questions. The two topmost triangles are locked until you have solved the triangles below them. The goal is to unlock and find the answer to all four questions in the pyramid.

Solve the two bottom triangle puzzles to unlock the third triangle above

Let me know if the levels are too easy, I can make them harder. If they are too difficult, you can google harder. Let the game begin!

Professor Prolog Explains Serverless Hosting 2022

dennis@perssondennis.com (Dennis Persson) — Sun, 19 Jun 2022 00:00:00 GMT

Julia strikes the like button and bookmarks the web application tutorial she completed. She quickly scan the classroom and feels quite proud of being the only one who has finished yet. Eager to learn more she speaks up.

👩‍🦰 Professor Prolog, could you tell me more about how to host a web application?

Professor Prolog shines up and gets up from his chair.

🧑‍🏫 Of course, Julia, I will tell you all about it.

Prolog starts drawing boxes on the whiteboard, he knows every engineer loves lines and boxes.

🧑‍🏫 First of all, remember that there's both a client and a server you need to host...

One of the elder students, Ada, interrupts the professor.

👱‍♀‍ But there are serverless applications today, aren't there?

Grandma knows, she lived through the Y2K crisis

Prolog nods to Ada and starts over.

🧑‍🏫 That's true, Ada. There are a lot of serverless applications today, but they aren't technically serverless. There are still people setting up the servers and hosting them on physical server halls around the world. They are only called serverless because you don't have to manage the physical machines on your own, you only need to provide the code you want them to run and take care of configurations.

👩‍🦰 Isn't that the same as hosting then, Julia asks. In our tutorial we uploaded our code to Firebase, is our application serverless then?

Prolog hesitates and puts down the pen he held in his hand.

🧑‍🏫 No Julia. Or yes... Kind of. But not exactly. What you did in the tutorial was to upload the javascript client application you built to Firebase's servers, so they can make it accessible on the internet. We usually refer to that process of serving it from a computer to the internet as hosting. Since you never uploaded it to a server of your own, you have technically hosted it serverless. But even if you uploaded it to your own server, we would still call it hosting, but we would instead say you have hosted it on-premises.

👩‍🦰 Oh, I see. I think I get it. And the server we hosted on AWS is serverless?

Professor Prolog nods in agreement, grabs the pen again and starts writing on the whiteboard.

A student far back in the classroom, Jade, adjusts his glasses and squints because he can't see sharp.

🧐 What does it say?

🧑‍🏫 Load balancing, it says load balancing.

Not actual professor Prolog, but he does sit like that

Prolog draws multiple boxes on the whiteboard, each one of them representing a server. He draws a user as well and some lines in between them, all connected with another box labeled load balancer.

Prolog got a doctoral degree, maybe that is reflected in his drawings

Yeap, he draws like he writes...

🧑‍🏫 Does anyone know what a load balancer is, he asks.

A student explains that load balancers are used to balance the workload between multiple servers when the server code runs on multiple servers.

Prolog nods quietly.

🧑‍🏫 You see, there are different ways to host a serverless application. Two of the most common options are IaaS (Infrastructure as a Service) and PaaS (Platform as a Service). The latter one is what you used in the tutorial when you hosted the server on Elastic Beanstalk. The process was very much like hosting your React client on Firebase. There were a few extra things to consider, but in essence you simply uploaded code and it ran successfully. What happened under the hood was that Elastic Beanstalk automagically spun up a load balancer and a bunch of servers.

🧑‍🏫 One remark there, Prolog continues. When you configured Elastic Beanstalk, you also enabled something called sticky session. Sticky session, or session affinity as it is called as well, ensures that when a user uses your client, all requests sent from that specific client to your server always will go to the same machine if the server are hosted on multiple machines. That is not always necessary, but in your case it was. You will need that kind of behavior if your server stores data in memory or on a local disk and you need to access that data on a subsequent network request. Forgetting to enable sticky session would result in inconsistent behavior for the server, since only requests sent to the machine that stored the data would be able to find it.

A student suddenly sneezes loudly and wakes another one that has almost fallen asleep. Professor Prolog makes a pun about the student needing a cup of Java and sends away the students on a break.

Grandma rendering some real-life CSS during break

Break is over. Students are back at their seats. Professor Prolog moves on to talk about load balancers and IaaS.

🧑‍🏫 We were saying a PaaS automatically spins up a load balancer and some servers. When dealing with an IaaS, you have to do that work yourself. With an IaaS, you get machines you can use as servers. By putting an Nginx server or an AWS Load Balancer on one of the machines, and running the server code on the other servers, you have loosely spoken built what a PaaS does. What probably is missing is a system to automatically scale the number of servers you run. Although, exactly what a PaaS offers varies between different providers.

Professor Prolog glimpses at the clock on the wall and erases his drawings on the whiteboard.

🧑‍🏫 You have learned a lot about hosting web applications this hour. It's far from everything there is to know, but it's an accurate overview of some of the most common and fastest ways to host applications. If you are interested to read more about the differences between IaaS, PaaS, and SaaS, I have included a link in the lecture material. You can also read about what it means to split a backend into microservices.

Professor Prolog animates his opacity and fades away...

Programming Explained With the Human Body - Frontend, Microservices Backend and Testing

dennis@perssondennis.com (Dennis Persson) — Sun, 03 Apr 2022 00:00:00 GMT

You have gotten the question a million times, haven't you? What is the difference between frontend and backend? What do you answer? "Frontend is what you see and backend is what you don't see?". Kind of a boring answer, isn't it? After reading this article you will have a better explanation to shine with. And even grandma will know what you are talking about!

Is Backend the Brain or the Heart?

Everything starts with the brain or the heart, doesn't it? Our two most beloved organs. Yeah, I said two, you will have to visit some other site to read about the third and fourth organs.

Which of the brain and heart would compare to the term "backend"? Can you guess it?

I've just added some empty space here so I don't spoil the answer (photo: Gary Scott)

If you answered the brain, you were right. If your answer was the heart, you were right as well. Backend would actually be all the inner organs in the body. Backend is the brain. Backend is the heart. Backend also includes the useless little appendix that probably once had a purpose, but nobody no longer knows why it's there and nobody cares to remove it as long as it doesn't pose any problem.

Well, that's a sentence I never thought I would write. Maybe that's how all those weird Google autocompletes comes up?

That's a weird suggestion... Is it for real?

(Yeah, that's how google.com looks like for me, this is how I styled it)

Backend Microservices

Back on track, I said backend could be compared to all inner organs, not just the brain. When building web services today, backend is often split into microservices. Each microservice has its own responsibility, it serves one functionality and then communicating with other services through a network. That network would be our nervous system when speaking about the body and the services would be organs.

Together, all microservices in an application work together to keep the application up and running just as all organs in the body work together to keep you alive. Some organs in the body are vital and can't be removed, like the brain. Other organs are less important and can be substituted, like the stomach. The body will continue to function without them although you may have to patch the body a bit to make it work. Other organs, such as the kidney, are organs we can't easily live without but we have multiple copies of. If we lose one, we can still continue to live on with the other one.

A microservice backend works in the same way. Some services can't be removed while other can, even if the application may not be of perfect use. Parts of it could be running while some certain functionalities could malfunction, e.g., a chatbot. That's one of the key advantages of microservices, to keep the application running even when individual services go down.

Another way to ensure that a service is running is to scale it. Scaling an application means to either run it on more powerful machines (scaling vertically) or letting the application run on more than one machine (scaling horizontally). With microservices, we can scale each service individually. If the chatbot would be very important for our application, we could run it on two or more machines while other services can continue to run on one machine. Just like the body has two kidneys and only one nose. The nose is less important, you will look a bit peculiar if you lose it, but we can live like that.

I intentionally avoided mentioning anyone by name...

Frontend Is the Beauty and the Feel

Obviously, frontend is what you see. Your face, your muscles and your way of walking. But it's also all of your external organs. Your ears would be speech recognition, see Web Speech API. You have a mouth that outputs audio and eyes that work like a camera. When you click on a button on a web page it will notice it, just as you feel when someone presses your skin.

Was Tom & Jerry the first cartoon developers?

Testing Is for Doctors

Testing is what doctors do. Human doctors can examine specific organs or diagnose illnesses that affect the complete or parts of the body. The difference between unit and integration testing would be that unit testing tests individual organs while integration testing searches for diseases affecting the whole body or integrations between body parts. An example of the latter one could be an autoimmune disease where a person's immune system mistakenly attacks other parts of the body.

If doctors would have used the same terminology as developers do, doctors could have been divided into frontend, backend and full stack doctors dependent on what they did. Examinate skin problems would be frontend investigations and listening to a patient's heartbeat would be to monitor backend functionality. Figuratively speaking, "unit testing backend code" could be translated to "diagnosing inner organs".

In the world of web development, doctors could be either frontend or backend doctors dependent on their specialties

The Soul

What about the soul? Isn't a part of body, or is it? Does it really exist? I know what my view on it is, but let's leave it there. You can have fun figuring about that one one your own.

React Anti-Patterns and Best Practices - Do's and Don'ts

dennis@perssondennis.com (Dennis Persson) — Sun, 05 Feb 2023 00:00:00 GMT

React may seem to be one of the least opinionated frameworks in the Wild West Web. Despite that, there's a lot of mistakes you can do and even more things you can do to write clean and readable code. This article explains 17 common anti-patterns and best practices in React.

Use useState Instead of Variables

This first one should be a basic one, but I still see developers doing this, sometimes even seniors. To store a state in React you should always use one of the React hooks, like useState or useReducer. Never declare the state directly as a variable in a component. Doing so will redeclare the variable on every render which means that React cannot memoize things it normally memoizes.

import AnotherComponent from 'components/AnotherComponent'

const Component = () => {
  // Don't do this.
  const value = { someKey: 'someValue' }

  return <AnotherComponent value={value} />
}

In the case above, AnotherComponent and everything that depends on value will rerender on every render, even if they are memoized with memo, useMemo or useCallback.

If you would add a useEffect to your component with value as a dependency, it would trigger on every render. The reason for that is that the JavaScript reference for value will be different on every render.

By using React's useState, React will keep the same reference for value all until you update it with setValue. React will then be able to detect when to and when not to trigger effects and recalculate memoizations.

import { useState } from 'react'
import AnotherComponent from 'components/AnotherComponent'

const Component = () => {
  // Do this instead.
  const [value, setValue] = useState({ someKey: 'someValue' })

  return <AnotherComponent value={value} />
}

If you only need a state that is initiated once, and then never updated, then declare the variable outside the component. When doing that, the JavaScript reference will never change.

// Do this if you never need to update the value.
const value = { someKey: 'someValue' }

const Component = () => {
  return <AnotherComponent value={value} />
}

Declare CSS Outside Components

If you are using a CSS in JS solution, avoid declaring CSS within components.

import makeCss from 'some/css/in/js/library'

const Component = () => {
  // Don't do this.
  return <div className={makeCss({ background: red, width: 100% })} />
}

The reason why not to do it is because the object has to be recreated on every render. Instead, lift it out of the component.

import cssLibrary from 'some/css/in/js/library'

// Do this instead.
const someCssClass = makeCss({
  background: red,
  width: 100%
})

const Component = () => {
  return <div className={someCssClass} />
}

Use useCallback To Prevent Function Recreations

Whenever a functional React component is rerendered, it will recreate all normal functions in the component. React provided a useCallback hook that can be used to avoid that. useCallback will keep the old instance of the function between renders as long as its dependencies doesn't change.

import { useCallback } from 'react'

const Component = () => {
  const [value, setValue] = useState(false)

  // This function will be recreated on each render.
  const handleClick = () => {
    setValue(true)
  }

  return <button onClick={handleClick}>Click me</button>
}

import { useCallback } from 'react'

const Component = () => {
  const [value, setValue] = useState(false)

  // This function will only be recreated when the variable value updates.
  const handleClick = useCallback(() => {
    setValue(true)
  }, [value])

  return <button onClick={handleClick}>Click me</button>
}

This time, I won't say do this or do that. Some people would tell you to optimize each function with a useCallback hook, but I won't. For small functions like the one in the example, I can't assure it really is better to wrap the function in useCallback.

Under the hood, React will have to check dependencies on every render to know if a new function needs to be created or not, and sometimes the dependencies changes frequently anyways. The optmization useCallback gives might therefore not always be needed.

If the dependencies to the function doesn't update a lot though, useCallback can be a good optimization to avoid recreating the function on each render.

Is React difficult? Join this dude creating another js framework!

Use useCallback To Prevent Dependency Changes

While useCallback can be used to avoid function instantiations, it can also be used for something even more important. Since useCallback keeps the same memory reference for the wrapped function between renders, it can be used to optimize usages of other useCallbacks and memoizations.

import { memo, useCallback, useMemo } from 'react'

const MemoizedChildComponent = memo({ onTriggerFn }) => {
  // Some component code...
}

const Component = ({ someProp }) => {
  // Reference to onTrigger function will only change when someProp does.
  const onTrigger = useCallback(() => {
    // Some code...
  }, [someProp])

  // This memoized value will only update when onTrigger function updates.
  // The value would be recalculated on every render if onTrigger wasn't wrapper in useCallback.
  const memoizedValue = useMemo(() => {
    // Some code...
  }, [onTrigger])

  // MemoizedChildComponent will only rerender when onTrigger function updates.
  // If onTrigger wasn't wrapped in a useCallback, MemoizedChildComponent would rerender every time this component renders.
  return (<>
    <MemoizedChildComponent onTriggerFn={onTrigger} />
    <button onClick={onTrigger}>Click me</button>
   </>)
}

Use useCallback To Prevent useEffect Triggers

The previous example showed how to optimize renders with help of useCallback, in the same way, it is also possible to avoid unnecessary useEffect triggers.

import { useCallback, useEffect } from 'react'

const Component = ({ someProp }) => {
  // Reference to onTrigger function will only change when someProp does.
  const onTrigger = useCallback(() => {
    // Some code...
  }, [someProp])

  // useEffect will only run when onTrigger function updates.
  // If onTrigger wasn't wrapped in a useCallback, useEffect would run every time this function renders.
  useEffect(() => {
    // Some code...
  }, [onTrigger])

  return <button onClick={onTrigger}>Click me</button>
}

Add an Empty Dependency List to useEffect When No Dependencies Are Required

If you have an effect which isn't dependent on any variables, make sure to an empty dependency list as the second argument to useEffect. If you don't do that, the effect will run on every render.

import { useEffect } from 'react'

const Component = () => {
  useEffect(() => {
    // Some code.

    // Do not do this.
  })

  return <div>Example</div>
}

import { useEffect } from 'react'

const Component = () => {
  useEffect(() => {
    // Some code.

    // Do this.
  }, [])

  return <div>Example</div>
}

The same logic applies to other React hooks, such as useCallback and useMemo. Although, as described later in this article, you may not need to use those hooks at all if you don't have any dependencies.

Always Add All Dependencies to useEffects and Other React Hooks

When dealing with dependency lists for built-in React hooks, such as useEffects and useCallback, make sure to always add all dependencies to the dependency list (second argument of the hooks). When a dependency is omitted, the effect or callback may use an old value of it which often results in bugs which can be hard to detect.

Adding all variables may be a very tricky thing to do, sometimes you simply don't want an effect to run again if a value updates, but trying to find a solution for it will not only save you from bugs, it usually leads to better written code as well.

Even more important, if you leave out a dependency to prevent a bug, that bug will come back for you when upgrading to newer React versions. In strict mode in React 18, updating hooks (e.g. useEffect, useMemo) are triggered twice in development, and that may happen in production in future React versions.

Better add all dependencies to react hooks to be on the safe side

import { useEffect } from 'react'

const Component = () => {
  const [value, setValue] = useState()

  useEffect(() => {
    // Some code using value variable.

    // Don't neglect adding variables to dependency list.
    // The value variable should be added here.
  }, [])

  return <div>{value}</div>
}

You may wonder, how can you circumvent side effects when useEffects are triggered more times than you wish? Unfortunately, there isn't a one-for-all solution to that. Different scenarios requires different solutions. You can try to use hooks to only run code once, that can sometimes be useful, but it isn't a solution to recommend really.

Most often you can solve your problem using if-cases. You can look at the current state and logically decide whether or not you really need to run the code. For example, if your reason not to add the variable value as a dependency to the effect above was to only run the code when value is undefined, you can simply add an if-statement inside the effect.

import { useEffect } from 'react'

const Component = () => {
  const [value, setValue] = useState()

  useEffect(() => {
    if (!value) {
      // Some code to run when value isn't set.
    }

  // Do this, always add all dependencies.
  }, [value])

  return <div>{value}</div>
}

Other scenarios may be more complex, maybe it isn't very feasible to use if-statements to prevent effects from happening multiple times. And if it isn't easily done, you should avoid it to avoid bugs. When that's the case, you should first ask yourself, do you really need an effect? There are a lot of cases where developers use effect when they really shouldn't do that.

However, life is not trivial, let's say you really do need to use useEffect, and you don't manage to easily solve it with if-cases. What else options do you have? Actually, the easy way is potentially the best way in this case, just to add all dependencies and let the effect run more times than you want it to.

Instead of trying to prevent code from being executing you can write the code so it doesn't matter if it is called multiple times or not. Such code is called to be idempotent, and suits very well with functional programming. Such behavior can be achieved by using caches, throttles and debounce functions. I may write and article explaining this topic in detail in the future, but for now, I will leave it here.

Do Not Use useEffect To Initiate External Code

Let say you want to run some code to initialize a library. Plenty of times I have seen initializion code like that being placed in an useEffect with an empty dependency list, which is completely unnecessary and error prone. If the function you call isn't dependent on a component's internal state, it should be initialized outside the component.

import { useEffect } from 'react'
import initLibrary from '/libraries/initLibrary'

const Component = () => {
  // Do not do this.
  useEffect(() => {
    initLibrary()
  }, [])

  return <div>Example</div>
}

import initLibrary from '/libraries/initLibrary'

// Do this instead.
initLibrary()

const Component = () => {
  return <div>Example</div>
}

If the component's internal state is needed for the initialization, you can put it in an useEffect, but if you are doing that, make sure you are adding all the dependencies you use to the dependency list of useEffect, as described under the previous heading.

Do Not Wrap External Functions in a useCallback

Just like in the case with triggering init functions in a useEffect above, you don't need a useCallback to call an external function. Simply just invoke the external function as is. This saves React from having to check if the useCallback needs to be recreated or not, and it makes the code briefer.

import { useCallback } from 'react'
import externalFunction from '/services/externalFunction'

const Component = () => {
  // Do not do this.
  const handleClick = useCallback(() => {
    externalFunction()
  }, [])

  return <button onClick={handleClick}>Click me</button>
}

import externalFunction from '/services/externalFunction'

const Component = () => {
  // Do this instead.
  return <button onClick={externalFunction}>Click me</button>
}

Valid use cases for using a useCallback are when the callback calls multiple functions or when it reads or updates an internal state, such as a value from useState hook or one of the components passed-in props.

import { useCallback } from 'react'
import { externalFunction, anotherExternalFunction } from '/services'

const Component = ({ passedInProp }) => {
  const [value, setValue] = useState()

  // This is okay...
  const handleClick = useCallback(() => {
    // ...because we call multiple functions.
    externalFunction()
    anotherExternalFunction()

    // ...because we read and/or set an internal value or prop.
    setValue(passedInProp)
  }, [passedInProp, value])

  return <button onClick={handleClick}>Click me</button>
}

Do Not Use useMemo With Empty Dependency List

If you ever add a useMemo with an empty dependency list, ask yourself why you are doing so.

Is it because it is dependent on a component's state variable and you don't want to add it? In that case, we have already discussed that, you should always list all dependency variables!

Is it because the useMemo doesn't really have any dependencies? Well, then just lift it out of the component, it doesn't belong in there!

import { useMemo } from 'react'

const Component = () => {
  // Do not do this.
  const memoizedValue = useMemo(() => {
    return 3 + 5
  }, [])

  return <div>{memoizedValue}</div>
}

// Do this instead.
const memoizedValue = 3 + 5

const Component = () => {
  return <div>{memoizedValue}</div>
}

Do Not Declare Components Within Other Components

I see this a lot, please stop doing it already.

const Component = () => {

  // Don't do this.
  const ChildComponent = () => {
    return <div>I'm a child component</div>
  }

  return <div><ChildComponent /></div>
}

What is the problem with it? The problem is that you are misusing React. As discussed before, variables declared within a component will be redeclared every time the component renders. In this case, it means that the functional child component has to be recreated every time the parent rerenders.

This is problematic for multiple reasons.

A function will have to be instantiated on every render.
React won't be able to decide when to do any kind of component optimizations.
If hooks are used in ChildComponent, they will be reinitiated on every render.
The component's lines of code increases and it gets hard to read. I have seen files with tens or maybe twenties of these child components within a single React component!

What to do instead? Merely declare the child component outside the parent component.

// Do this instead.
const ChildComponent = () => {
    return <div>I'm a child component</div>
}

const Component = () => {
  return <div><ChildComponent /></div>
}

Or even better, in a separate file.

// Do this instead.
import ChildComponent from 'components/ChildComponent'

const Component = () => {
  return <div><ChildComponent /></div>
}

Remember, I write this article for a reason

Do Not Use Hooks in If Statements (No Conditional Hooks)

This one is explained in React's Documentation. One should never write conditional hooks, simply as that.

import { useState } from 'react'

const Component = ({ propValue }) => {
  if (!propValue) {
    // Don't do this.
    const [value, setValue] = useState(propValue)
  }

  return <div>{value}</div>
}

Do Not Use Hooks After Return (No Conditional Hooks)

If statements are conditional by definition, it's therefore easy to understand that you shouldn't place hooks within them when reading React's Documentation.

A little more sneaky keyword is the "return" keyword. Many people don't realize "return" can result in conditional hook renders. Look at this example.

import { useState } from 'react'

const Component = ({ propValue }) => {

  if (!propValue) {
    return null
  }

  // This hook is conditional, since it will only be called if propValue exists.
  const [value, setValue] = useState(propValue)

  return <div>{value}</div>
}

As you can see, a conditional return statement will make a succeeding hook conditional. To avoid this, put all your hooks above the component's first conditional rendering. Or, easier to remember, simply always put you hooks at the top of the component.

import { useState } from 'react'

const Component = ({ propValue }) => {
  // Do this instead, place hooks before conditional renderings.
  const [value, setValue] = useState(propValue)

  if (!propValue) {
    return null
  }

  return <div>{value}</div>
}

Let Child Components Decide if They Should Render

This one isn't something you always should do, but in many situations it's appropriate. Let's consider the following code.

import { useState } from 'react'

const ChildComponent = ({ shouldRender }) => {
  return <div>Rendered: {shouldRender}</div>
}

const Component = () => {
  const [shouldRender, setShouldRender] = useState(false)

  return <>
    { !!shouldRender && <ChildComponent shouldRender={shouldRender} /> }
  </>
}

Above is a common way to conditionally render a child component. The code is fine, apart from being a bit verbose when there are many child components. But dependent on what ChildComponent does, there may exist a better solution. Let's rewrite the code slightly.

import { useState } from 'react'

const ChildComponent = ({ shouldRender }) => {

  if (!shouldRender) {
    return null
  }

  return <div>Rendered: {shouldRender}</div>
}

const Component = () => {
  const [shouldRender, setShouldRender] = useState(false)

  return <ChildComponent shouldRender={shouldRender} />
}

In the example above, we have rewritten the two component's to move the conditional rendering into the child component. You may wonder, what's the benefit of moving conditional rendering into the child component?

The biggest benefit is that React can continue rendering ChildComponent even when it isn't visible. That means, ChildComponent can keep its state when it is hidden and then later getting rendered a second time without losing its state. It's always there, just not visible.

If the component instead would stop rendering, as it does with the first code, states saved in useState would be reset, and useEffects, useCallbacks and useMemos would all need to rerun and recalculate new values as soon as the component renders again.

If your code would trigger some network requests or doing some heavy calculations, those would also run when the component is rendered again. Likewise, if you would have some form data stored in the component's internal state, that would reset every time the component goes hidden.

As initially mentioned, this isn't something you always want to do. Sometimes you really want the component to unmount completely. For example, if you have a useEffect within the child component, you may not want to continue running it on rerenders. See the example below.

const ChildComponent = ({ shouldRender, someOtherPropThatChanges }) => {

  useEffect(() => {
    // If we don't want this code to run when shouldRender is false,
    // then don't keep render this component when shouldRender is false.
  }, [someOtherPropThatChanges])

  if (!shouldRender) {
    return null
  }

  return <div>Rendered: {shouldRender}</div>
}

const Component = () => {
  const [shouldRender, setShouldRender] = useState(false)

  return <ChildComponent
    shouldRender={shouldRender}
    someOtherPropThatChanges={someOtherPropThatChanges} />
}

We could of course use conditional logic inside the child component to make the code above to work, but that could be error-prone. And please recall, conditional hooks aren't allowed, so you cannot place the useEffect after the if statement.

const ChildComponent = ({ shouldRender, someOtherPropThatChanges }) => {

  if (!shouldRender) {
    return null
  }

  useEffect(() => {
    // We cannot avoid running this useEffect by putting it after the
    // null-render. Conditional hook rendering is not allowed in React!
  }, [someOtherPropThatChanges])

  return <div>Rendered: {shouldRender}</div>
}

const Component = () => {
  const [shouldRender, setShouldRender] = useState(false)

  return <ChildComponent
    shouldRender={shouldRender}
    someOtherPropThatChanges={someOtherPropThatChanges} />
}

Use useReducer Instead of Multiple useState

Instead of bloating the component with multiple useState, you can use one useReducer instead. It may be cumbersome to write, but it will both avoid unnecessary renders and can make the logic more understandable. Once you have a useReducer, it will be much easier to add new logic and states to your component.

There's no magical number of how many useState to write before refactoring to useReducer, but I would personally say around three.

import { useState } from 'react'

const Component = () => {
  // Do not add a lot of useState.
  const [text, setText] = useState(false)
  const [error, setError] = useState('')
  const [touched, setTouched] = useState(false)

  const handleChange = (event) => {
    const value = event.target.value
    setText(value)

    if (value.length < 6) {
      setError('Too short')
    } else {
      setError('')
    }
  }

  return <>
    {!touched && <div>Write something...</div> }
    <input type="text" value={text} onChange={handleChange} />
    <div>Error: {error}</div>
  </>
}

import { useReducers } from 'react'

const UPDATE_TEXT_ACTION = 'UPDATE_TEXT_ACTION'
const RESET_FORM = 'RESET_FORM'

const getInitialFormState = () => ({
  text: '',
  error: '',
  touched: false
})

const formReducer = (state, action) => {
  const { data, type } = action || {}

  switch (type) {
    case UPDATE_TEXT_ACTION:
      const text = data?.text ?? ''

      return {
        ...state,
        text: text,
        error: text.length < 6,
        touched: true
      }
    case RESET_FORM:
      return getInitialFormState()
    default:
      return state
  }
}

const Component = () => {
  const [state, dispatch] = useReducer(formReducer, getInitialFormState());
  const { text, error, touched } = state

  const handleChange = (event) => {
    const value = event.target.value
    dispatch({ type: UPDATE_TEXT_ACTION, text: value})
  }

  return <>
    {!touched && <div>Write something...</div> }
    <input type="text" value={text} onChange={handleChange} />
    <div>Error: {error}</div>
  </>
}

Need even more structure, consider using TypeScript!

Write Initial States as Functions Rather Than Objects

Note the code from the current tip. Look at getInitialFormState function.

// Code removed for brevity.

// Initial state is a function here.
const getInitialFormState = () => ({
  text: '',
  error: '',
  touched: false
})

const formReducer = (state, action) => {
  // Code removed for brevity.
}

const Component = () => {
  const [state, dispatch] = useReducer(formReducer, getInitialFormState());
  // Code removed for brevity.
}

See that I wrote the initial state as a function. I could rather have used an object directly.

// Code removed for brevity.

// Initial state is an object here.
const initialFormState = {
  text: '',
  error: '',
  touched: false
}

const formReducer = (state, action) => {
  // Code removed for brevity.
}

const Component = () => {
  const [state, dispatch] = useReducer(formReducer, initialFormState);
  // Code removed for brevity.
}

Why didn't I do that? The answer is simple, to avoid mutability. In the case above, when initialFormState is an object, we could happen to mutate the object somewhere in our code.

If that's the case, we wouldn't get the initial state back if we used the variable another time, for example when resetting the form. We would instead get the mutated object where for example touched could have a value of true.

That is also the case when running unit tests. When testing the code above, several tests could use the initialFormState and mutate it. Each test would then work when they run individually, while some of the tests would likely fail when all tests ran together in a test suite.

For that reason, it's a good practice to turn initial states into getter functions that returns the initial state object. Or even better, use libraries like Immer which is used to avoid writing mutable code.

Use useRef Instead of useState When a Component Should Not Rerender

Did you know you can optimize component renderings by replacing useState with useRef? Check this code.

import { useEffect } from 'react'

const Component = () => {
  const [triggered, setTriggered] = useState(false)

  useEffect(() => {
    if (!triggered) {
      setTriggered(true)

      // Some code to run here...
    }
  }, [triggered])
}

When you run the code above, the component will rerender when setTriggered is invoked. In this case, triggered state variable could be a way to make sure that the effect only runs one time (which actually doesn't work in React 18, learn why in this article about useRunOnce hook).

Since the only use of triggered variable in this case, is to keep track if a function has been triggered or not, we do not need the component to render any new state. We can therefore replace useState with useRef, which won't trigger the component to rerender when it is updated.

import { useRef } from 'react'

const Component = () => {
  // Do this instead.
  const triggeredRef = useRef(false)

  useEffect(() => {
    if (!triggeredRef.current) {
      triggeredRef.current = true

      // Some code to run here...
    }

  // Note missing dependency. This isn't optimal.
  }, [])
}

Note the missing dependency to the useEffect, that one is a bit tricker to fix when using useRef, but React explains it in their documentation.

In the case above, you may wonder why we need to use a useRef at all. Why can't we simply use a variable outside of the component?

// This does not work the same way!
const triggered = false

const Component = () => {
  useEffect(() => {
    if (!triggered) {
      triggered = true

      // Some code to run here...
    }
  }, [])
}

The reason we need a useRef is because the above code doesn't work in the same way! The above triggered variable will only be false once. If the component unmounts, the variable triggered will still be set to true when the component mounts again, because the triggered variable is not bound to React's life cycle.

When useRef is used, React will reset its value when a component unmounts and mounts again. In this case, we probably would want to uses useRef, but in other cases a variable outside the component may be what we are searching for.

React Hook: useElementDimensions

dennis@perssondennis.com (Dennis Persson) — Sun, 03 Dec 2023 00:00:00 GMT

CSS is great, but sometimes it is not enough. Sometimes you need to know the size of CSS elements in the JavaScript code, or to know where it is on the screen. In that case the useElementDimensions is perfect hook to use. This article describes what the hook is, how to implement it and shows some use cases of it.

Actually, we will look at two hooks in this article, both useStaticElementDimensions and useElementDimensions. We will start with the static hook, which has limited use cases but serves as a good example of why we need the more advanced hook.

useStaticElementDimensions Hook

Below you can see a JavaScript implementation of a useStaticElementDimensions hook. The hook is also available to test at CodeSandbox. The example on CodeSandbox is written in TypeScript, so if you're using it in a TypeScript project you should head over there, or get it from GitHub.

import { useCallback, useState } from 'react'

const useStaticElementDimensions = () => {
  const [dimensions, setDimensions] = useState(null)

  const ref = useCallback((node) => {
    if (!!node) {
      const domRect = node.getBoundingClientRect()
      setDimensions(domRectToDimensions(domRect))
    }
  }, [])

  return { dimensions, ref }
}

export default useStaticElementDimensions

The hooks is simple to use, but not straight forward to understand. So we will go through it in detail.

The hooks takes no arguments, but it returns an object with two properties. One of the return values is a reference ref, which we will pass to the DOM node we want to measure the size and position of. When doing that, the dimensions object returned from the hook will contain the bounding client rect which has the following attributes in its type definition:

height: number;
width: number;
x: number;
y: number;
bottom: number;
left: number;
right: number;
top: number;

This means that we with this hook will be able to detect where on the screen the node is, and also its width and height. So usage of the hook would look something like this.

const SomeComponent = () => {
  const { dimensions, ref } = useStaticElementDimensions()
  const { height, width, x, y } = dimensions ?? {}

  return <SomeNode ref={ref}>Example</SomeNode>
}

At this point, you may wonder, why did the hook return a useCallback function as ref when it could have used a useRef reference instead? The answer is about update frequency.

This useStaticElementDimensions hook is based on callback refs, more specifically at the old React docs of how to measure DOM nodes. As you can read there, the regular ref retrieved from useRef function doesn’t notify about changes to the ref value, meaning we will only be informed about what value the node has when the component containing the referenced node mounts.

If the referenced node would be added later, using either conditional rendering or if a component is lazy loaded, the regular useRef reference wouldn't let us know that the node value has changed.

By using a callbackRef function rather than a normal ref, the reference will instead be bound to the actual node's mount and umount events. So, with the useCallback Ref, the hook does its job, but there's a bunch of use cases which isn't handled, which is probably why the example isn't included in the React docs anymore.

Don't worry Napoleon, we have another hook

useElementDimensions Hook

So, now we have seen a hook which we could use to check the measurements of a DOM node with JavaScript. The hook does work, but it has some flaws.

First of all, it only measures the dimensions of the node when the node mounts, meaning it will not update when the element or viewport is updated. It's just a snapshot of the element, which can be used for static components which aren't dynamically rendered, thereby the name useStaticElementDimensions.

Websites are rarely static though. Sizes of DOM elements are often preserved, but positions are definitely not static. When the user scrolls on the page, or resizes the browser window, the position of the elements changes, and the static hook above doesn't consider that.

This is why we need a more sophisticated hook for this job, the useElementDimensions hook. The useElementDimensions hook works with browser scroll and resize events, and it also handles a special case where we manually need to refresh the dimensions.

You can see the updated hook below. Once again, a TypeScript version of the hook is available on GitHub and CodeSandbox.

import useEventListener from 'hooks/useEventListener'
import { useCallback, useRef, useState } from 'react'

const useElementDimensions = () => {
  const ref = useRef(null)
  const [dimensions, setDimensions] = useState(null)

  const refresh = useCallback(() => {
    const domRect = ref.current?.getBoundingClientRect()

    if (domRect) {
      setDimensions(domRect)
    }
  }, [])

  useEventListener('resize', refresh);
  useEventListener('scroll', refresh, true);

  return { dimensions, ref, refresh }
}

export default useElementDimensions

The imported useEventListener looks like this.

import { useEffect } from 'react'

const useEventListener = (event, listener, useCapture) => {
  useEffect(() => {
    if (listener) {
      listener()
      window.addEventListener(event, listener, useCapture)

      return () => window.removeEventListener(event, listener, useCapture)
    }

    return () => {}
  }, [event, listener, useCapture])
}

As you can see, this hook is more advanced. The helper hook, useEventListener, should be easy to understand. It's a wrapper around a useEffect which subscribes and unsubscribes to events. In this case, the useElementDimensionsHook listens on the 'resize' and 'scroll' events specifically.

useEventListener('resize', refresh);
useEventListener('scroll', refresh, true);

You may also notice, that in this hook, we have ditched the callback ref and are now using a regular useRef reference. The useEventListener does invoke the listener when the effect runs, which means that the refresh function in the useElementDimensions hook will update the dimensions according to the current value of the node ref. That will re-trigger every time the component mounts, so there is no need for a callback ref.

The dimensions, are still stored in a useState though. This is because useRef values doesn't trigger components to re-render. So if we wouldn't use useState, the components using this hook wouldn't be notified about the change.

The useState, together with the resize and scroll listener hook useEventListener and the refresh function it triggers, is enough to keep the dimension return value up to date in most use cases. The user can resize the browser and scroll however it wants, and the hook will always provide the latest size and position of the node.

However, as I mentioned before, there are some special cases to handle, and that's why the hook exposes the refresh function as a return value. For example, if the dimensions returned from the function would be used to move or resize the node it references, the dimensions would become outdated. And since neither a scroll event or browser resize has occurred, the dimensions won't be updated.

If you find cases like that you can use the refresh function to manually update the dimensions. Although, more likely, you are doing some shady things and should watch out for infinite loops and nasty bugs. So in reality, you may be more safe by keeping the refresh function internal to the hook.

Cautions and Improvements

As just mentioned, you should be careful to use the refresh function manually outside the hook. You may end up in too many rerenders or strange behaviors. Only use the exposed refresh function if you know why you are doing so.

Furthermore, you should now about the implications of using the useElementDimensions hook. Listening on scroll positions is a slow operation. Generally, it is better to use the Intersection Observer API to check if nodes are visible on screen and for similar use cases, whenever it is possible.

Additionally, you may want to add a throttle or debounce to the useElementDimensions hook. Or, if you have a quite limited use case for that hook, you may instead use the callback ref based hook useStaticElementDimensions. But remember, building responsive applications has been cool for a long time now.

I can tell you, John did update all his sites to be responsive that night

Use Cases

In most cases, you would probably want to use the useElementDimensions hook. If you can be sure you won't need it, you have an option to use the less advanced useStaticElementDimensions hook.

Either way, here are a few use cases of when a hook like this may be needed.

To ensure a menu or dropdown doesn't end up outside the viewport
To implement infinite scroll solutions
For dynamic components

1. To Ensure a Menu or Dropdown Doesn't End Up Outside the Viewport

Menus such as dropdown menus and context menus are often rendered at the place the trigger button is placed. On many sites, the main menu is a hamburger menu in the top right corner of the site. Since these menus are fairly large, and often absolutely positioned, they can easily end up going out of the screen.

The same problem often occurs with dropdown menus or context menus on other places on the screen. For instance, when a dropdown menu is scrolled to be positioned at the bottom of the screen when it is being opened. In that case, the dropdown may drop out of screen and may need to open upwards instead, or at least being lift up so all of it is visible.

In these cases, a hook like useElementDimensions may be useful. A node's size and position can be compared to the window's innerWidth and innerHeight to determine if an element is inside or outside the viewport.

2. To Implement Infinite Scroll Solutions

Some more complex usage of this hook can be when a list is rendered. You are potentially implementing a infinite scroll component, which needs to recycle the list items to avoid loading too many DOM nodes into the DOM tree.

Such solutions can often involve calculating how many items which will fit within the list. This is an easy task if all elements are of the same height. That best case scenario is not always possible. Sometimes the height of elements will vary, and you may need to detect the size of the elements. That's another scenario when this hook could become useful.

3. For Dynamic Components

Components are not always static. You may render components dynamically, or even lazy load them. Or they may exist in you code but being opened with code. The useElementDimensions hook can in that case help you measuring the height and width of those components.

Example Usage

When this hook is used, it will generally look something like this.

import useElementDimensions from "hooks/useElementDimensions";

const DynamicComponent = () => {
  const { dimensions, ref } = useElementDimensions();
  const { height, width, x, y } = dimensions ?? {};

  return (
    <>
      <div ref={ref}>Some element</div>
      <p>Height: {height}</p>
      <p>Width: {width}</p>
      <p>X: {x}</p>
      <p>Y: {y}</p>
    </>
  );
};

You can pass the ref to any DOM node. This also works for TypeScript, since the hooks uses generic types in the examples on GitHub and CodeSandbox.

Summary

useElementDimensions is a hook you can use for at least three use cases.

To ensure a menu or dropdown doesn't end up outside the viewport
To implement infinite scroll solutions
For dynamic components

The hook updates the ref upon scroll and window resize events. However, listening to such events is an expensive operation. You may want to use a throttle or a debounce, or maybe use the static variant of the hook, useStaticElementDimensions, which is based on callback refs, but isn't updated when the use scrolls or the browser window change size.

React Hook: useGlobalState

dennis@perssondennis.com (Dennis Persson) — Sun, 20 Aug 2023 00:00:00 GMT

Sharing state between React components is crucial in most applications. With useGlobalState you can quickly share a state between multiple components without using a context provider or external lib. The hook is useful for small projects when a React context provider is not desired.

How To Use

useGlobalState is just as easy to use as React's useState hook, only difference is that useGlobalState takes an object as first argument instead of the initial state.

The object has a required property shareKey which is used to identify the data which should be shared globally. All components which uses the same shareKey will share the same data.

import useGlobalState from "hooks/useGlobalState";

const SHARED_COUNT_KEY = "someUniqueKey";

const ComponentOne = () => {
  const [count, setCount] = useGlobalState<number>({
    initialState: 0,
    shareKey: SHARED_COUNT_KEY
  });

  return (
    <div>
      <h2>Component one</h2>
      <div>Count: {count}</div>
      <button onClick={() => setCount(count + 1)}>Add 1</button>
    </div>
  );
};

export default ComponentOne;

Share State Between Components

If you have multiple components, each component can use one or more of this useGlobalState hook to share state with one or multiple other component. An example with two components sharing the same state can be found on CodeSandbox.

If you want to test the hook while reading about it, it's available to try out there on CodeSandbox or downloadable from GitHub.

Why not share this article with a friend?

useGlobalState Hook Explained

Let's take a look at the implementation of the hook, and later we look at some use cases.

import { pubSub } from "lib/pubsub"
import { useCallback, useEffect, useState } from "react"

const useGlobalState = ({
  initialState,
  onStateUpdated,
  shareKey
}) => {
  const [state, setState] = useState(initialState)

  const onStateUpdate = useCallback(
    (data) => {
      setState(data)
      onStateUpdated?.(data)
    },
    [onStateUpdated]
  )

  useEffect(() => {
    pubSub.subscribe(shareKey, onStateUpdate)

    return () => pubSub.unsubscribe(shareKey, onStateUpdate)
  }, [onStateUpdate, shareKey])

  const setSharedState = useCallback(
    (data) => {
      pubSub.emit(shareKey, data)
    },
    [shareKey]
  )

  return [state, setSharedState]
}

export default useGlobalState

First thing first, the hook depends on a pubsub import. In short, the pubsub import is what is actually used to share the state between components with the help of subscription and events. No React context needed. You can find the implementation of it at GitHub or at the end of this article, together with TypeScript versions of the useGlobalState hook.

Second thing to notice, the hook takes an object with three properties. As can be seen in the TypeScript version a bit further down, shareKey is the only required property. That is the key used to identify the data you share. Components which uses this hook with the same shareKey will share the same state. If different shareKeys are used, they will not share the state. Simple as that.

initialState is an optional property you can use to use to set an initial state. If you use this one, make sure to use the same initial state for all components using the same shareKey. Providing different values when you want to share a state doesn't make sense.

Last argument property is onStateUpdate. It's a callback that can be used to listen at state updates if that would be of interest.

The rest of the code is just to subscribe and unsubscribe to the pubsub, and to emit new values to it when setting a new state.

When Not To Use

Before talking about when to use this hook, I want to discuss when not to use it. As a developer, you should never just go with first available solution without consider the alternatives. You can read this article about proactive vs reactive developers to understand why that is important.

If the project you are coding on already uses a state handling solution like Redux or MobX, you likely have no need for this hook. Better option would be to continue on that path. In fact, if you plan to store a good amount of data, Redux is still a good option to consider for that.

Another tough concurrent to this hook is regular React contexts. Let's face it, contexts are built for React and default option to store small states. It's perfect to use if you need to add some small functions to fake a small store, like a Redux store.

Remember though, a context combined with a reducer which many people promote as a replacement for Redux is NOT a good option if you need to store states larger than tiny. In that article, I just linked, you can find five reasons to why Redux is to prefer over reducer-context solution.

Redux and Contexts May Not Be Necessary

Did I just convince you Redux and Contexts are more viable options than the hook in this article? Or did I scare you from using contexts? Either way, let's continue the discussion with some actual use cases and benefits of this hook.

React projects can be of any kind and any size. New hooks, libraries and frameworks are coming every day. Some of the hooks from the latest years are RTK Query and some other popular hooks like useSWR and useQuery. With hooks like that, it's definitely not an obvious choice to use Redux as it used to be.

Hooks like useSWR work by caching your requests. You share the state between components by a cache which is built into the hook. The interesting thing here, is that useSWR hook does not require a context provider, it relies on a global cache unless you opt in for a context for manual cache control.

The useGlobalState is a concise example of what the cache control for a hook like useSWR could look like internally. And in fact, I'm very glad useSWR went for a solution without a context. Not because it's cumbersome to add a context provider, but because contexts are more complex to architect than you may think. In general, moving them further up in the component tree means more rerenders, while moving them down leads to isolated contexts which are more difficult to keep synced with each other.

Easy Lenny, it's time now

Use Cases

With the previous chapters in mind, about usages of Redux and contexts, we can now tell a few cases when this hook could be suitable to use.

1. Library Without a Need For a Context Provider

As discussed earlier, we can use this hook when implementing a small library which needs a global state. With this hook, there's no need to use a context provider for the lib user.

2. Singleton Hook

You can use this hook in another hook to make that hook a singleton hook. Normally, each component which uses a hook gets a new state for that hook. The state of the hook is not shared with other components using the same hook.

In some cases, you want a hook which can share the state between all usages of the same hook. In that case, you can use this hook within you implemented hook to share its state, basically making it a singleton hook.

3. One Time Usages for Small Projects

Some projects are small. Adding Redux or a context or whatever you need may not be necessary. A small project with a single or a few pages can likely be small enough to just need a single shared state. Maybe it's even a proof of concept project. This hook may come in handy in that case.

Server Rendering Support

When you are using Next.js or other solutions where server side rendering may occur, you must as usual remember that component and hook states calculated on the server isn't available on the client. Not with this hook, not with React contexts and not with Redux. The states are stored one the client.

That doesn't mean that this hook cannot be used when server rendering exists. The hook does work with server rendering, it's just that the state will not be propagated to the server, it will stay on the client.

TypeScript Version

Even though I'm pretty sure TypeScript haters know TypeScript well enough to spot the types and remove them on their own, I still used the JavaScript implementation above, just because it's easy to overview. The TypeScript hook uses TypeScript generics to let you use use it with any type, custom or built in.

import { pubSub } from "lib/pubsub"
import { useCallback, useEffect, useState } from "react"

interface UseGlobalStateProps<T> {
  shareKey: string
  initialState?: T
  onStateUpdated?: (data?: T) => void
}

const useGlobalState = <T>({
  initialState,
  onStateUpdated,
  shareKey
}: UseGlobalStateProps<T>) => {
  const [state, setState] = useState<T>(initialState as T)

  const onStateUpdate = useCallback(
    (data: T) => {
      setState(data)
      onStateUpdated?.(data)
    },
    [onStateUpdated]
  )

  useEffect(() => {
    pubSub.subscribe(shareKey, onStateUpdate)

    return () => pubSub.unsubscribe(shareKey, onStateUpdate)
  }, [onStateUpdate, shareKey])

  const setSharedState = useCallback(
    (data: T) => {
      pubSub.emit(shareKey, data)
    },
    [shareKey]
  )

  return [state, setSharedState] as [T, (data: T) => void]
}

export default useGlobalState

PubSub Implementation

The pubsub TypeScript implementation the hook depends on is quite standard. It keeps a record of subscribers and provides functions for subscribing and unsubscribing to events. It is possible to subscribe to different events by calling the subscribe function with different values for event argument.

The PubSub object also has an emit function which can be used to submit events which will be propagated to all subscribers. If a subscriber would subscribe after some events already has been emitted, the last event for each event is stored and can optionally be emitted with the emitLatestOnSubscribe option passed in as an argument to the subscribe function.

The emitLatestOnSubscribe option is recommended to be used when React components are rendered conditionally. In that way, components can receive the latest state whenever they are mounted.

type PubSubCallback = (data: any) => void;

interface PubSubSubscribeOptions {
  emitLatestOnSubscribe?: boolean;
}

interface PubSub {
  emit: (event: string, data: unknown) => void;
  latestEvents: Record<string, unknown>;
  subscribe: (
    event: string,
    callback: PubSubCallback,
    options?: PubSubSubscribeOptions
  ) => void;
  subscribers: Record<string, PubSubCallback[]>;
  unsubscribe: (event: string, callback: PubSubCallback) => void;
}

export const pubSub: PubSub = {
  latestEvents: {},
  subscribers: {},

  subscribe: (event, callback, options = { emitLatestOnSubscribe: true }) => {
    const { emitLatestOnSubscribe } = options;

    if (!pubSub.subscribers[event]) {
      pubSub.subscribers[event] = [];
    }

    pubSub.subscribers[event].push(callback);

    if (
      emitLatestOnSubscribe &&
      Object.prototype.hasOwnProperty.call(pubSub.latestEvents, event)
    ) {
      callback(pubSub.latestEvents[event]);
    }
  },

  unsubscribe: (event, callback) => {
    if (pubSub.subscribers[event]) {
      pubSub.subscribers[event] = pubSub.subscribers[event].filter(
        (cb) => cb !== callback
      );
    }
  },

  emit: (event, data) => {
    if (pubSub.subscribers[event]) {
      pubSub.latestEvents[event] = data;
      pubSub.subscribers[event].forEach((callback) => {
        callback(data);
      });
    }
  },
};

React Hook: useRunOnce

dennis@perssondennis.com (Dennis Persson) — Sun, 17 Jul 2022 00:00:00 GMT

useRunOnce Hook

Below you can see how useRunOnce hook is implemented in JavaScript and typescript. The hook can be used to run a function once, either on mount or per browser session.

The hook takes an object as an argument, with two available properties. Firstly, a required fn property that is the callback function that will run. If no other property is passed, the callback function will run once every time the component mounts.

If the second property sessionKey is passed, the hook will instead utilize session storage to run the callback function just once per browser session. That is further explained later in this article.

The code is also available at CodeSandbox and GitHub. You can try it out on CodeSandbox, but I will explain more about how it works here in the article.

JavaScript

import { useEffect, useRef } from "react";

const useRunOnce = ({ fn, sessionKey }) => {
  const triggered = useRef(false);

  useEffect(() => {
    const hasBeenTriggered = sessionKey
      ? sessionStorage.getItem(sessionKey)
      : triggered.current;

    if (!hasBeenTriggered) {
      fn();
      triggered.current = true;

      if (sessionKey) {
        sessionStorage.setItem(sessionKey, "true");
      }
    }
  }, [fn, sessionKey]);

  return null;
};

export default useRunOnce;

TypeScript

import React, { useEffect, useRef } from "react";

export type useRunOnceProps = {
  fn: () => any;
  sessionKey?: string;
};

const useRunOnce: React.FC<useRunOnceProps> = ({ fn, sessionKey }) => {
  const triggered = useRef<boolean>(false);

  useEffect(() => {
    const hasBeenTriggered = sessionKey
      ? sessionStorage.getItem(sessionKey)
      : triggered.current;

    if (!hasBeenTriggered) {
      fn();
      triggered.current = true;

      if (sessionKey) {
        sessionStorage.setItem(sessionKey, "true");
      }
    }
  }, [fn, sessionKey]);

  return null;
};

export default useRunOnce;

Forest Gump has never heard about segmentation fault

Run Once on Mount

If you want to run a function once a component mounts, simply pass a callback function to the argument object's fn attribute. The callback will only fire one time. Unless the component is being unmounted and mounted again, in that case, it will fire again.

useRunOnce({
    fn: () => {
        console.log("Runs once on mount");
    }
});

Run Once per Session

If you would like to run a function only one time per session, you can pass a sessionKey to the hook. The hook will then use session storage to ensure that the callback function only runs once per session.

In other words, when passing a sessionKey, the passed in function will only run one single time when a user visits your website. The callback function won't be triggered again, not even when the user reloads the website using the browser's reload button.

For the callback function to run one more time, the user will need to close the browser tab or the browser and then revisit the website in another tab or browser session. This is all according to the session storage documentation

useRunOnce({
    fn: () => {
        // This will not rerun when reloading the page.
        console.log("Runs once per session");
    },
    // Session storage key ensures that the callback only runs once per session.
    sessionKey: "changeMeAndFnWillRerun"
});

Note. A common problem with session and local storage is that you cannot force users to close their browsers. Although, in some cases it may be necessary to clear the storage. Easiest way to do that is to use another storage key. So, if you are using this hook with a sessionKey and want all clients to rerun the hook, even if they aren't closing their browser, just make another deployment of your application with another sessionKey.

When Not To Use

Occationally, when I think I need this hook, I think twice about it and realize that I really don't. Here follows some cases when I wouldn't use the hook.

Write a greeting message in web console when a user first visits your page.
Initialize a third-party library by calling one of their init-functions.
Send analytics data when a user visits your site (and resend it when user reloads the page).
Fetch data when a component mount.

1. Write a Greeting Message in Web Console When a User First Visits Your Page

One reason you may not need the hook is because it's unnecessary to use a hook/useEffect if you don't need to read or set an internal state in a component. Writing a greeting message to the web console has nothing to do with React components or its life cycle, you can do that in pure JavaScript and there is no reason to do that within a React component.

2. Initialize a Third-Party Library by Calling One of Their Init-Functions

The reason to not using this hook when initializing third-party libraries is the same as when writing a message to the web console. Initializing third-party libraries may include registering plugins to a date library, configuring languages in a i18n library or whatsoever.

Such logic is rarely dependent on data in a React component and should therefore be initialized outside your components. Simply place the code in a file right above a React component and it will run once and only once, that's how ES6 modules are designed. See examples of when not to use an useEffect in Reacts documentation.

3. Send Analytics Data When a User Visits Your Site (and Resend It When User Reloads the Page)

You will find this point among the use cases as well. It really depends on what you want to measure. Do you want to resend analytics data when the user reloads a page with the web browser's reload button?

In that case, you may be able to fetch the data outside your React components as described above, if you don't need to read or set a component's internal state. On the other hand, if you don't want to refetch the data when a page is being reloaded, you can use the useRunOnce hook and provide a sessionKey to it.

4. Fetch Data When a Component Mount

This point is quite important if you don't want to introduce a lot of bugs in your code. In React 18 Strict Mode, useEffects will run twice when mounting a component in development mode. In future releases that will also sometimes happen in production.

For that reason, you should be careful with sending network requests in useEffects. This hook includes a useEffect and does not handle it in a best-practice way, since it doesn't include all real dependencies in the useEffects dependency list.

You should most often avoid sending network requests in useEffects. Network requests of POST, PUT, PATCH or DELETE types should nearly never be placed in useEffects, they are usually triggered as a direct consequence of a user action and should therefore be triggered by a onClick handler, not in a useEffect.

It may be fine to fetch data in useEffects, but when doing that, you must ensure to handle the case when data is received twice or thrice. In other words, your callback function must be idempotent. You are better off using a hook like useSWR which handles both caching and request deduplications for you. React have documented how to handle cases like this in their docs, make sure to read it, you will need to learn it eventually.

Use Cases

When would one want to use this hook? Here are some example use cases.

Fetch data when a user visits your site (once per session).
Send analytics data when a component mount.
Send analytics data when a user visits your site (once per session).
Run code that should run once on client side and not at all on server-side.
Count how many times a user visits your site.

1. Fetch Data When a User Visits Your Site (Once per Session)

First of all, if you have not read about not using this hook to fetch data when a component mount, do that first. If you do have a reason to fetch data only once per session though, this hook could be used for that. Then use it with a passed-in sessionKey attribute.

2. Send Analytics Data When a Component Mount

This is maybe the most common use case. The docs for React 18 brings up how to handle analytics data in Strict Mode. What they mention is that it's a good idea letting it send it twice in development mode.

Anyhow, what they show is a simple case to handle. You may not be lucky enough that your analytics request only is dependent on a single url variable. It may be dependent on a lot of more variables, and you probably don't want to send the analytics request 30 times.

You can easily solve that in your code with code similar to what this hook contains, or you can use this hook.

3. Send Analytics Data When a User Visits Your Site (Once per Session)

Since this hook includes an option to include a sessionKey, you can also send analytics data once per browser session. This allows you to send analytic requests only once even when users are keeping their browser tab open for multiple days and just reloading it once in a while.

4. Run Code That Should Run Once on Client Side and Not at All on Server-Side

React supports server-side rendering (SSR), and there exist multiple frameworks that is built on React which supports SSR and even static site generation (SSG), one of those is Next.js.

When rendering React on server-side, the global window and document objects aren't available. Trying to access one of those objects on the server would throw an error. For that reason, following Reacts suggestion for how to detect when an application initializes isn't possible. This hook can therefore be very useful when dealing with frameworks that run server-side, since this hook only will trigger the callback function on client side.

5. Count How Many Times a User Visits Your Site

Why not count user visits? It may be useful sometimes. In that case, you can count on this hook.

Easiest way to fix a bug is to remove code

Examples

The code below illustrates how to use the useRunOnce hook to send analytics data when a component mounts. For demonstration, it also sets an internal state in the component and renders a text.

import React from 'react'
import useRunOnce from 'hooks/useRunOnce'

const MyComponent = () => {
  const [analyticsHasBeenSent, setAnalyticsHasBeenSent] = useState(falsse)

  useRunOnce({
    fn: () => {
      sendAnalytics()
      setAnalyticsHasBeenSent(true)
    }
  });

  return <>{analyticsHasBeenSent ? 'Analytics has been sent' : 'Analytics has not been sent'}</>
}

export default MyComponent

In the example below, we instead log to local storage that analytics has been sent. This way, you probably don't need to use this hook. The reason is that nothing in the callback function is dependent on an internal state in the component. The code within the callback is pure JavaScript and can be lifted out of the React component.

import React from 'react'
import useRunOnce from 'hooks/useRunOnce'

const MyComponent = () => {

  useRunOnce({
    fn: () => {
      sendAnalytics()
      localStorage.setItem('analytics-has-been-sent', 'true')
    }
  });

  return <>MyComponent</>
}

export default MyComponent

This is how the above code would look if we removed the hook and lifted out the code that fetches data and stores it in local storage.

import React from 'react'

sendAnalytics()
localStorage.setItem('analytics-has-been-sent', 'true')

const MyComponent = () => {
  return <>MyComponent</>
}

export default MyComponent

If we don't want to resend analytics when the website is reloaded, we could use the hook to ensure that it only send data once per browser session, it would then look as this.

import React from 'react'
import useRunOnce from 'hooks/useRunOnce'

const MyComponent = () => {

  useRunOnce({
    fn: () => {
      sendAnalytics()
      localStorage.setItem('analytics-has-been-sent', 'true')
    },
    sessionKey: "anyStringHere"
  });

  return <>MyComponent</>
}

export default MyComponent

Summary

useRunOnce is a hook you can use for two use cases.

When you want to run some code every time a component mounts or remounts.
When you want to run some code once per browser session.

Since the hooks wraps a useEffect, running code when a function mount can infer side effects in React 18 Strict Mode. Read React's documentation to see how to handle that.

The hook uses session storage to run code once per browser session. The hook will therefore run its code as soon as a new session is initiated, see session storage documentation for details or read through this article.

React Hooks: useThrottledValue and useThrottledFunction

dennis@perssondennis.com (Dennis Persson) — Sun, 14 Aug 2022 00:00:00 GMT

This article explains the new React 18 hooks useDeferredValue and useTransition and compares them to throttle and debounce functions. It also presents two similar custom hooks, useThrottledValue and useThrottledFunction, which can be used to throttle a function or value change when the React hooks isn't sufficient

useThrottledFunction Hook

useThrottledFunction is a hook you can use when you need to prevent a function from running too often. It works similar to React 18's useTransition hook but has a slightly different use case. I will provide the code for it later, but before doing that, we will look at the new hooks in React 18, useTransition and useDeferredValue. We will also look at what throttling and debounce actually means and how they differ from each other.

useThrottledValue Hook

useThrottledValue is a hook similar to useThrottledFunction. The difference is that useThrottledValue simply throttles a value change instead of a function call. The code for it will be provided later in this article.

useDeferredValue and useTransition

useDeferredValue is a new hook available in React 18. I recommend you to read this article about why they added it here, but in short, it's because they want to give us an opportunity to postpone an update of a value until more important code has run. It essentially burns down to deferring code execution so more prioritized UI updates can be render quicker.

To use useDeferredValue, simply pass a value to it and it will automatically be deferred if necessary.

import { useDeferredValue } from 'react'

const UseDeferredValueExample = ({ items }) => {
  const deferredItems = useDeferredValue(items)

  return (<ul>
    {deferredItems.map((item) => <li key={item.id}>{item.text}</li>)}
  </ul>)
}

export default UseDeferredValueExample

With React 18, came also a similar hook called useTransition. useTransition defers an update just like useDeferredValue does, but instead of merely updating a value it allows to customize the state update more granularly.

import { useState, useTransition } from 'react'

const UseTransitionExample = ({ text }) => {
  const [isPending, startTransition] = useTransition()
  const [shouldShow, setShouldShow] = useState(false)

  const showEventually = () => {
    startTransition(() => {
      setShouldShow(true)
    })
  }

  return (<div>
    <button onClick={showEventually}>Show Text</button>
    {isPending && <p>Text will show soon!</p>}
    {shouldShow && <p>{text}</p>}
  </div>)
}

export default UseTransitionExample

What is Throttle and Debounce?

Throttle and debounce are two terms that often are mixed up together. The purpose of them both are to prevent a function from running too often. A similar use case is not to update a value for a certain amount of time.

A throttle and a debounce both take a callback function as an argument and a time interval that decides how often the callback function should be allowed to be invoked. The return value is a new function that is the throttled/debounced callback function.

The difference between them is that a throttle will run multiple times while a debounce only will run once. When a function is being throttled for X seconds, it will at maximum run once every X second, regardless of how many times the function is called upon.

In other words, a throttle allows the function to run every X second, but will only run if it has been invoked one or more times during those X seconds.

Unlike a throttle, the time interval passed to a debounce will not make a function run periodically. A time interval passed to a debounce function can be seen as a cooldown time for the callback function that reset itself every time someone tries to trigger it.

A debounce is like a stubborn child that has made up its mind not to eat the food until the parents have stopped nagging about it for at least X seconds. As soon as the parents have been silent for X seconds, the child eats its vegetables.

Mama' needs to learn how debounce works

The picture below depicts the usage of a throttle and a debounce. The lines labeled regular represents when the function is being called. You can see that the stubborn debounce only invokes the function as soon as the function has stopped being invoked while the throttled function is invoked periodically with a minimum time between every invocation. You can try it yourself at this site.

Throttle will trigger periodically while debounce will trigger when invocation has stopped

Note that throttle and debounce functions often comes with settings. A debounce function can usually be configured to either run before or after the provided time interval. For the stubborn child, that would mean it would eat its vegetables the first time the parents asked, but would not eat another piece of it until the parents had been quiet for X seconds.

Throttle vs New React 18 Hooks

As described above, both a throttle and the new React hooks can be used to defer a function call or an update of a value. There is a slight difference between throttling and using the new React hooks though. useTranstition and useDeferredValue will update the state as soon as React has time for it. That's not the case with a throttle.

A throttle will wait for a specified amount of time before regardless of whether it is necessary for performance or not. This means that useDeferredValue and useTransition will be able to update the state sooner since they don't have to postpone it if it isn't really necessary.

A common reason to use a throttle is to prevent overheating an application with more function calls than the computer can handle. Such overheating can often be prevented or mitigated with the new useDeferredValue or useTransition hooks, since those hooks can detect when React has time to update the state. For that reason, many people claim that useDeferredValue and useTransition hooks removes the need for manually use a throttle or debounce.

The truth is, overheating an application isn't the only use case of a throttle or a debounce. Another use case is to prevent multiple invocations of a function in use cases where it could hurt the application in some way.

Maybe a backend service would return a 429 HTTP error code when too many requests are sent, or maybe a resource intensive or expensive job would run to often without a throttle. In those cases, it's still necessary to use a throttle or debounce. There are often other solutions for such problems, but React's new hooks isn't what you search for in those cases.

Totally legit HTTP error code

When Not To Use useThrottledFunction or useThrottledValue

As described above, there are some scenarios where you should use useDeferredValue or useTransition rather than using the useThrottledValue or useThrottledFunction hook. Here are some examples of when to prefer the built-in React 18 hooks.

When the reason to use the hook is to let more important code or UI updates run first.
When the reason to use the hook is to optimize performance when a value updates a few times.

Well, the first use case is obvious. That's exactly what React's new hooks are supposed to do. To let you prioritize some updates as more important than other.

The second use case is maybe a bit more obvious, why wouldn't we throttle a function to optimize performance? The thing is, a lot of developers try to micro-optimize their code. Preventing a function from being called a few times is most often not a problem for performance. Failing to design a good frontend architecture, misusing the framework of use, or neglecting the importance of managing states and data flows correctly are big issue though. Handle those things properly and you won't need to micro-optimize your code on a function call level.

If you still would judge your use case as a case where it's important to micro-optimize, useDeferredValue and useTransition can help you out with that. They will help you deferring the updates until React feels there is time for it.

When To Use useThrottledFunction and useThrottledValue

Now when we know when not to use the hooks, we will look at when to use them.

When the hook triggers a function that could be harmful to any other service or code.
When the function or value change triggers a resource intensive or expensive job.
When the reason to use the hook is to optimize performance when a value updates a lot of times.

We did previously touch upon the two first scenarios under the Throttle vs New React 18 Hooks heading. We mentioned that a network service could respond with a 429 HTTP error code. Other scenarios could be that we would want to prevent a user from spamming a functionality that is allowed to be triggered multiple times.

Regarding the second use case, when an intensive job is triggered. A typical scenario could be when the value is listed as a dependency to a useMemo hook. The useMemo hook is usually used to prevent heavy calculations from running multiple times. Using a throttle to prevent the memo from updating too many times could therefore be a valid use case.

The third use case is almost the same as the second scenario of when not to use the hooks. The argument not to use the hooks was because it wasn't important to micro-optimize code on a function level. However, there is of course a threshold for when it would be necessary. An example would be when listening on mouse movement.

Remember the picture describing throttle and debounce? That picture was actually captured from a mouse movement. In that picture (duplicated here below), we can see that the debounce and throttle prevents a huge amount of function calls. If the function call is fairly heavy to run, it could be a good idea to throttle or debounce it.

A debounce or throttle can prevent a lot of unnecessary function calls when it is triggered by mouse movement

useThrottledValue Implementation

A lot of text above, but finally we can look at the first hook implementation! Let's start with useThrottledValue, there's both a JavaScript and a TypeScript implementation of it.

The hook takes a single argument, an object containing a value and optionally throttleMs. The optional throttleMs is the throttle time for how often the value should be allowed to update. If left out, we have a default time at 800 ms (DEFAULT_THROTTLE_MS).

The hook consists of a single useEffect that will trigger as soon as a new value is passed in to the hook. If the hook hasn't updated the value for throttleMs milliseconds, it will update the value and save the time for the last update.

If the value updates more times within throttleMs milliseconds, it will set a timeout that will update the value as soon as it is time for it to update. To prevent memory leaks for the timers, the timeout is cleaned up every time the useEffect runs.

JavaScript Implementation

import {
  useCallback, useEffect, useRef, useState,
} from 'react'

const DEFAULT_THROTTLE_MS = 3000

const getRemainingTime = (lastTriggeredTime, throttleMs) => {
  const elapsedTime = Date.now() - lastTriggeredTime
  const remainingTime = throttleMs - elapsedTime

  return (remainingTime < 0) ? 0 : remainingTime
}

const useThrottledValue = ({
  value,
  throttleMs = DEFAULT_THROTTLE_MS,
}) => {
  const [throttledValue, setThrottledValue] = useState(value)
  const lastTriggered = useRef(Date.now())
  const timeoutRef = useRef(null)

  const cancel = useCallback(() => {
    if (timeoutRef.current) {
      clearTimeout(timeoutRef.current)
      timeoutRef.current = null
    }
  }, [])

  useEffect(() => {
    let remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

    if (remainingTime === 0) {
      lastTriggered.current = Date.now()
      setThrottledValue(value)
      cancel()
    } else if (!timeoutRef.current) {
      timeoutRef.current = setTimeout(() => {
        remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

        if (remainingTime === 0) {
          lastTriggered.current = Date.now()
          setThrottledValue(value)
          cancel()
        }
      }, remainingTime)
    }

    return cancel
  }, [cancel, throttleMs, value])

  return throttledValue
}

export default useThrottledValue

TypeScript Implementation

import {
  useCallback, useEffect, useRef, useState,
} from 'react'

const DEFAULT_THROTTLE_MS = 3000

const getRemainingTime = (lastTriggeredTime: number, throttleMs: number) => {
  const elapsedTime = Date.now() - lastTriggeredTime
  const remainingTime = throttleMs - elapsedTime

  return (remainingTime < 0) ? 0 : remainingTime
}

export type useThrottledValueProps<T> = {
  value: T
  throttleMs?: number
}

const useThrottledValue = <T, >({
  value,
  throttleMs = DEFAULT_THROTTLE_MS,
}: useThrottledValueProps<T>) => {
  const [throttledValue, setThrottledValue] = useState<T>(value)
  const lastTriggered = useRef<number>(Date.now())
  const timeoutRef = useRef<NodeJS.Timeout|null>(null)

  const cancel = useCallback(() => {
    if (timeoutRef.current) {
      clearTimeout(timeoutRef.current)
      timeoutRef.current = null
    }
  }, [])

  useEffect(() => {
    let remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

    if (remainingTime === 0) {
      lastTriggered.current = Date.now()
      setThrottledValue(value)
      cancel()
    } else if (!timeoutRef.current) {
      timeoutRef.current = setTimeout(() => {
        remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

        if (remainingTime === 0) {
          lastTriggered.current = Date.now()
          setThrottledValue(value)
          cancel()
        }
      }, remainingTime)
    }

    return cancel
  }, [cancel, throttleMs, value])

  return throttledValue
}

export default useThrottledValue

useThrottledFunction Implementation

The next hook, useThrottledFunction, works very similar to useThrottledValue and the implementations is nearly identical. The passed in value argument has been replaced with a callbackFn, which is the function that should be throttled.

The function returns an object. The object contains throttledFn, which is a throttled version of the passed in callbackFn. It also returns a cancel function, which can be called whenever the throttle timer's needs to be stopped.

JavaScript Implementation

import { useCallback, useEffect, useRef } from 'react'

const DEFAULT_THROTTLE_MS = 800

const getRemainingTime = (lastTriggeredTime, throttleMs) => {
  const elapsedTime = Date.now() - lastTriggeredTime
  const remainingTime = throttleMs - elapsedTime

  return (remainingTime < 0) ? 0 : remainingTime
}

const useThrottledFunction = ({
  callbackFn,
  throttleMs = DEFAULT_THROTTLE_MS,
}) => {
  const lastTriggered = useRef(Date.now())
  const timeoutRef = useRef(null)

  const cancel = useCallback(() => {
    if (timeoutRef.current) {
      clearTimeout(timeoutRef.current)
      timeoutRef.current = null
    }
  }, [])

  const throttledFn = useCallback((args) => {
    let remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

    if (remainingTime === 0) {
      lastTriggered.current = Date.now()
      callbackFn(args)
      cancel()
    } else if (!timeoutRef.current) {
      timeoutRef.current = setTimeout(() => {
        remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

        if (remainingTime === 0) {
          lastTriggered.current = Date.now()
          callbackFn(args)
          cancel()
        }
      }, remainingTime)
    }
  }, [callbackFn, cancel])

  useEffect(() => cancel, [cancel])

  return { cancel, throttledFn }
}

export default useThrottledFunction

TypeScript Implementation

import { useCallback, useEffect, useRef } from 'react'

const DEFAULT_THROTTLE_MS = 800

const getRemainingTime = (lastTriggeredTime: number, throttleMs: number) => {
  const elapsedTime = Date.now() - lastTriggeredTime
  const remainingTime = throttleMs - elapsedTime

  return (remainingTime < 0) ? 0 : remainingTime
}

export type useThrottledFunctionProps = {
    callbackFn: <T, >(args?: T) => any
    throttleMs?: number
}

const useThrottledFunction = ({
  callbackFn,
  throttleMs = DEFAULT_THROTTLE_MS,
}: useThrottledFunctionProps) => {
  const lastTriggered = useRef<number>(Date.now())
  const timeoutRef = useRef<NodeJS.Timeout|null>(null)

  const cancel = useCallback(() => {
    if (timeoutRef.current) {
      clearTimeout(timeoutRef.current)
      timeoutRef.current = null
    }
  }, [])

  const throttledFn = useCallback(<T, >(args?: T) => {
    let remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

    if (remainingTime === 0) {
      lastTriggered.current = Date.now()
      callbackFn(args)
      cancel()
    } else if (!timeoutRef.current) {
      timeoutRef.current = setTimeout(() => {
        remainingTime = getRemainingTime(lastTriggered.current, throttleMs)

        if (remainingTime === 0) {
          lastTriggered.current = Date.now()
          callbackFn(args)
          cancel()
        }
      }, remainingTime)
    }
  }, [callbackFn, cancel])

  useEffect(() => cancel, [cancel])

  return { cancel, throttledFn }
}

export default useThrottledFunction

Examples

The code below shows how the useThrottledValue may be used. When a button is clicked, a value state variable is updated. After the user have clicked the button, a heavy calculation is done.

To prevent the heavy calculation from running too many times if the user spams the button, we use this hook to throttle the recalculation of the memorized value. You have a CodeSandbox of it here to try it, and if you want to clone, star or watch it on GitHub you have the repository for it here.

import { useMemo, useState } from "react";
import useThrottledValue from "./useThrottledValue";

// Note that this will be called twice with React StrictMode because
// it's a callback provided to a useMemo.
const performHeavyCalculation = (value) => {
  console.log("Heavy calculation for value:", value);
  return value;
};

export default function App() {
  const [value, setValue] = useState(0);
  const throttledValue = useThrottledValue({ value, throttleMs: 5000 });

  const memoizedValue = useMemo(() => {
    return performHeavyCalculation(throttledValue);
  }, [throttledValue]);

  return (
    <div>
      <button onClick={() => setValue(value + 1)}>Increment value</button>
      <p>Calculates a new value every fifth second.</p>
      <p>Value: {value}</p>
      <p>Last caculated result: {memoizedValue}</p>
    </div>
  );
}

Below code depicts a use case of useThrottledFunction. In this case, a function performHeavyCalculation is throttled to prevent it from being called for every fired scroll event. CodeSandbox to try it code. GitHub repository here.

import { useCallback, useEffect } from "react";
import useThrottledFunction from "./useThrottledFunction";

const performHeavyCalculation = () => {
  console.log("Heavy calculation");
};

export default function App() {
  const callbackFnToThrottle = useCallback(() => {
    performHeavyCalculation();
  }, []);

  const { throttledFn } = useThrottledFunction({
    callbackFn: callbackFnToThrottle,
    throttleMs: 5000
  });

  useEffect(() => {
    window.addEventListener("scroll", throttledFn);

    return () => {
      window.removeEventListener("scroll", throttledFn);
    };
  }, [throttledFn]);

  return (
    <div>
      <p>Scroll and look in console.</p>
      <p>Code uses a throttle of 5 seconds.</p>
      <div style={{ height: "4000px" }} />
      <p>End of scroll...</p>
    </div>
  );
}

Note that there are two things to note for the code above. First thing is that the callback function called callbackFnToThrottle isn't necessary in this case. It would be possible to directly pass the performHeavyCalculation function to the callbackFn argument attribute. The callback is only added for demonstration.

The second thing to mention is that this use case isn't necessarily optimal. When looking at scroll events, there are many times often better solutions to apply. Using the Intersection Observer API could be a better solution than listening for scroll events if the use case is to detect if an element is visible on screen.

I rather wonder why you are still reading it?

Summary

useThrottledValue and useThrottledFunction are hooks you can use in a few use cases.

To throttle a function call that could be harmful to run many times.
To throttle a function call or value change that triggers a resource intensive or expensive job.
To optmize performance when a value is being updated lot of times.

React 18 also introduced two new hooks, useDeferredValue and useTransition. These hooks can be used to run code with lower priority, to allow for more important code to run first. In some cases, it is better to use one of those hooks instead. That is the case when:

When the reason to use the hook is to let more important code or UI updates run first.
When the reason to use the hook is to optimize performance when a value updates a few times.

This article also described the difference between throttle and debounce. While both are used to avoid running code too often, they differ in how many times they will invoke the function. A throttle will periodically invoke the function dependent on a throttle time while a debounce will run the function only once, either at the start of or at the end of a series of invocations.

Understanding useEffect, useRef and Custom Hooks

dennis@perssondennis.com (Dennis Persson) — Sun, 06 Mar 2022 00:00:00 GMT

A question I like to ask developers is "do you understand React's life cycle"? The answer is very often a confident "yes".

Then I show them the code for a usePrevious hook and let them explain why it works. If you don't know what a usePrevious hook is, you can see one below. It's used to get a previous value of a prop or state in a component, see React docs.

const usePrevious = (value, defaultValue) => {
  const ref = useRef(defaultValue);

  useEffect(() => {
    ref.current = value;
  }, [value]);

  return ref.current;
};

Usually, the answer I get is a diffuse answer mentioning something about useRef updating instantly independent of the life cycle or that useRef doesn't trigger a rerender. That's correct.

Then I ask, "if the useEffect is updating the ref value as soon as the passed in value prop updates, won't the hook return the updated ref value?". The response is most often confusion. Even though my statement is fundamentally wrong, they don't really know React's life cycle well enough to explain what is wrong with my question. In fact, they most often believe that what I am saying is true and stands clueless of why the hook works.

Let us therefore take a look at how the usePrevious hook works. It's a perfect case for explaining how React handles useEffect and useRef.

What did you previously say?

Logging the Sh*t Out of usePrevious

Here we have a simple React component, using a usePrevious hook. What it does is to increment a count when a button is clicked. It's an overcomplicated way to do such a thing, we wouldn't really need a usePrevious hook in this case, but since the topic under discussion is the usePrevious hook, the article would be quite boring if we left it out.

// ### App.js
// When the button is clicked, the value is incremented.
// That will in turn increment the count.

import React, { useEffect, useState } from "react";
import usePrevious from "./usePrevious";

export default function App() {
  const [value, setValue] = useState(0);
  const [count, setCount] = useState(0);

  const previouseValue = usePrevious(value, 0);

  useEffect(() => {
    if (previouseValue !== value) {
      setCount(count + 1);
    }
  }, [previouseValue, value, count]);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setValue(value + 1)}>Increment</button>
    </div>
  );
}

To better understand what React does when running the code, I have the same code here below but with a lot of console logs within it. I will carefully go through them all. You can find the code example at CodeSandbox if you want to elaborate on your own.

// ### App.js (with logs)
// When the button is clicked, the value is incremented.
// That will in turn increment the count.

import React, { useEffect, useState } from "react";
import usePrevious from "./usePrevious";

export default function App() {
  const [value, setValue] = useState(0);
  const [count, setCount] = useState(0);

  console.log("[App] rendering App");
  console.log("[App] count (before render):", count);
  console.log("[App] value:", value);
  const previouseValue = usePrevious(value, 0);
  console.log("[App] previousValue:", previouseValue);

  useEffect(() => {
    console.log("[App useEffect] value:", value);
    console.log("[App useEffect] previouseValue:", previouseValue);

    if (previouseValue !== value) {
      console.log("[App useEffect] set count to value:", value, "\n\n");
      setCount(count + 1);
    } else {
      console.log("[App useEffect] not increasing count");
    }
  }, [previouseValue, value, count]);

  console.log("[App] count (after render):", count);
  console.log("[App] done rendering App\n\n");

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setValue(value + 1)}>Increment</button>
    </div>
  );
}

// ### usePrevious.js (with logs)

import { useRef, useEffect } from "react";

const usePrevious = (value, defaultValue) => {
  console.log("[usePrevious] value:", value);
  const ref = useRef(defaultValue);

  useEffect(() => {
    console.log("[usePrevious useEffect] value:", value);
    console.log("[usePrevious useEffect] increment ref.current:", ref.current);
    ref.current = value;
  }, [value]);

  console.log("[usePrevious] ref.current:", ref.current);

  return ref.current;
};

export default usePrevious;

Enough of code now, I think. Let's look at what happens when we click the Increment button. Here's what we will see in the output console. I highly recommending opening a second browser window to keep the code visible while you read the rest of this article.

# App component renders (1)
[App] rendering App
[App] count (before render): 0
[App] value: 1
[usePrevious] value: 1
[usePrevious] ref.current: 0
[App] previousValue: 0
[App] count (after render): 0
[App] done rendering App

# useEffects run (2)
[usePrevious useEffect] value: 1
[usePrevious useEffect] increment ref.current: 0
[App useEffect] value: 1
[App useEffect] previouseValue: 0
[App useEffect] set count to value: 1

# App component rerenders again (3)
[App] rendering App
[App] count (before render): 1
[App] value: 1
[usePrevious] value: 1
[usePrevious] ref.current: 1
[App] previousValue: 1
[App] count (after render): 1
[App] done rendering App

# useEffects run again (4)
[App useEffect] value: 1
[App useEffect] previouseValue: 1
[App useEffect] not increasing count

# (5)

Note: The description that follows should be treated as an interpretation of the code and output above. It's not the exact algorithm React uses. More about that later.

(1) So here's what happens. When we click the increase button, it updates the value state to 1 which triggers a rerender of the App component. The usePrevious hook is the first code to be reached in the rerender, so it gets invoked directly. In that hook, we get the updated prop value of 1 while ref.current is still the default value of 0. React notes that the dependency to useEffect has changed, but it doesn't trigger the useEffect yet. Instead, it returns the ref.current value of 0 from the hook and store it in previousValue variable.

The rendering of the App component continuous and it reaches the useEffect. At this time, value has been updated from 0 to 1, so the useEffect should be triggered, but not yet. Instead of triggering it, React completes its rendering with a default count value of 0.

React notes that a dependency has updated, but does not run the effect immediately

(2) Now, after having completed the rerender of the App component, it's time to run useEffects. React has noted that both the useEffect in usePrevious hook and in App component should be triggered. It starts invoking the useEffect in the usePrevious hook, that's the useEffect that was reached first during rendering.

When it runs the useEffect code it updates the ref.current to 1 and that's all. React continuous with the next useEffect in line, the one in the App component. At the time when the App component was rerendered and React first noticed that a value in the dependency list had updated, the previousValue variable was still set to 0. The reason we triggered the useEffect was because value had incremented from 0 to 1. So, the if-statement comparing value with previousValue will be truthy and we will update the count from 0 to 1.

(3) We have now emptied the useEffects queue. No more effects to trigger. React can now check if a rerender is required, and it will notice that it is. setCount has been invoked so the count variable has updated to 1 from 0, so React decides to rerender the component once again.

The state variable value is still 1, we haven't increased that value. This time usePrevious hook gets invoked with the same value as last rendering, so there's no need to trigger the useEffect in the usePrevious hook. ref.current still has a value of 1, so the previousValue variable will be assigned a value of 1. When we then reach the useEffect in App component, React notes that previousValue has updated but does nothing about it. It continues the rerendering of the App component and exits gracefully with a count of 1.

(4) Rerendering has completed, but we do have a useEffect in queue to run. As mentioned, the useEffect in usePrevious had no reason to trigger, so React continues directly with the effect in App component. previousValue is now 1, that's why we triggered the useEffect. value hasn't changed though and is still set to 1, so we don't invoke the setCount function.

(5) We are now done running the useEffects, so it's time for React to check if a rerender is required again. It isn't though, since neither value or count did update when we ran the effects. So React calms down and waits for further user input.

What Does the Life Cycle Look Like?

What I did describe above is not a technical description of React's life cycle, rather it's an interpretation of what happens when the code runs. There's no time for a detailed explanation of what the React code really looks like here. It's obviously a bit more advanced than I describe in this article. We would need a more complex example which includes child components etc., and we would need to talk about render and commit phase. For those who are interested, a brief explanation of that can be found here.

Anyhow, for the sake of helping you understand the execution order I described in the five steps above, I will summarize it with some pseudocode.

const rerender = () => {
    // run code in component

    // if we reach a useEffect
    if (useEffectDependenciesHasUpdated) {
        useEffectQueue.push(useEffectCode)
    }

    // continue running code in component
}

const reactLifeCycle = () => (
    while (true) {
        if (stateHasChanged) {
            rerender()
            runEffectsInQueue()
        }
    }
)

As you can see, the above pseudocode is sufficient to explain why the usePrevious hook works. On a basic level, the life cycle could be expained in this way. React renders a component and runs the code within it. Whenever a useEffect is reached, react looks at its dependency list. If a variable within the dependency list has changed, React adds the callback function in the useEffect to a queue.

Whenever the rerendering has completed, react starts to pop effect callbacks out of that queue and invoke them. When the queue gets empty, React starts checking if it is necessary to rerender any components again.

Why My Question was Faulty

In the beginning of the article, I explained how I asked people this question about the usePrevious hook. Are you able to explain what it is wrong with the question now?

if the useEffect is updating the ref value as soon as the passed in value prop updates, won't the hook return the updated ref value?

Well, the answer to the question is actually: yes. If the useEffect was updating the ref value as soon as the passed in value updated, then yes, in that case, we would return the updated ref value. But that's not how React works. The useEffect isn't invoked instantly. It's invoked after React has completed the rendering phase and the parent component already has read the old ref value.

Conclusion

There are many things to say about React's life cycle handling. In this article we only look at useEffect, useRef and a custom usePrevious hook to see in which order React runs the code.

What we can discover by using a custom usePrevious hook is that React invokes the custom hook as soon as it reaches it during the rendering phase. The hook is merely a piece of code lifted out of the component.

However, at the time we reach a useEffect hook, React seemingly does nothing at all, rather it waits for the component rendering to finish, and then first after that has finished, the callback in the useEffect gets invoked.

I said seemingly nothing at all, because it's how it appears to work. Internally React handles many things under the hood. The dependency list must be checked in order to know if we even should run the callback or not. React must also keep track of the old dependencies to be able to compare them. But that's a topic for another day. What you need to know today, is that useEffect callbacks are invoked after a component has finished rendering, and they are executed in the same order as the code reaches them.

When a useEffect has run, the component may rerender a second time if its state has updated, e.g. if a set function returned by a useState has been invoked. If a useEffect only updates a useRef value, then React won't rerender the component. That value is updated immediately.

The 20 Most Common Use Cases for JavaScript Arrays

dennis@perssondennis.com (Dennis Persson) — Sun, 22 Oct 2023 00:00:00 GMT

Splice, slice, pop and shift. Is the array sort method stable and not in-place? It's not easy to remember all JavaScript array methods and what the difference between them are. They are all synonyms, as if they where taken directly from a thesaurus.

This array cheat sheet lists all the array methods you usually need in JavaScript, and the ones you don't need, is not here. Simple as that! To make it even easier for you, I have based the cheat sheet on common use cases.

New challenge, try to list all array methods without forgetting one of them

Immutability

Before we begin, a notice about immutability. All functions used in this article are immutable, which shortly means, that you never mutate your original array when you use these methods. Immutability is very important in modern JavaScript, at least according to this Stack Overflow guy (and the rest of the Internet).

Even though each of these methods is immutable on their own, you are not totally safe against immutability. If you include mutable data types (arrays, objects, functions) in your immutable arrays, you can still mutate the mutable data within the array. We call such arrays to be shallowly immutable, in contrast to deeply immutable arrays which only includes immutable items.

Array Use Cases

1. Add Element to Start of Array

To prepend an item to the beginning of an array, use array spreading.

const arr = [1, 2, 3];
const result = [0, ...arr];
console.log(result);
// [0, 1, 2, 3]

Do not use the unshift method, that will mutate the original array.

2. Add Element to End of Array

To append an item to the end of an array, use array spreading.

const arr = [1, 2, 3];
const result = [...arr, 4];
console.log(result);
// [1, 2, 3, 4]

Do not use the push method, that will mutate the original array.

3. Remove an Element From Start of Array

To remove the first item in an array, use slice method.

const arr = [1, 2, 3];
// Keep index 1 and everything after that.
const result = arr.slice(1);
console.log(result);
// [2, 3]

Do not use the shift or splice methods, they will mutate the original array.

4. Remove an Element From End of Array

To remove the last item in an array, use slice method.

const arr = [1, 2, 3];
// Keep index 0 and everything after that, except one element at the array.
const result = arr.slice(0, -1);
console.log(result);
// [1, 2]

Do not use the pop or splice methods, they will mutate the original array.

5. Insert Element at Index in Array

To add an item at a specific index of an array, use the toSpliced method.

const arr = [1, 2, 3];
// Keep index 1, delete 0 elements, add the element "one point five" and keep everything after that.
const result = arr.toSpliced(1, 0, "one point five");
console.log(result);
// [1, "one point five", 2, 3]

Do not use the splice method, that will mutate the original array.

6. Replace an Element at Index in Array

To replace an item from some index in an array, use the toSpliced or with method.

const arr = [1, 2, 3];

// Using toSpliced.
// Keep index 1, delete 1 elements, add the element "two" and keep everything after that.
const result1 = arr.toSpliced(1, 1, "two");
console.log(result1);
// [1, "two", 3]

// Using with.
// Copy the old array arr with index 1 replaced with "two".
const result2 = arr.with(1, "two");
console.log(result2);
// [1, "two", 3]

Do not use the splice method, that will mutate the original array.

7. Remove an Element at Index in Array

To remove an item from an array, use the toSpliced method.

const arr = [1, 2, 3];

// At index 1, delete 1 elements.
const result = arr.toSpliced(1, 1);
console.log(result);
// [1, 3]

Do not use the splice method, that will mutate the original array.

8. Remove an Element By Value From an Array

To remove a specific value from an array, use the filter method.

const arr = [1, 2, 3];
const result = arr.filter((element) => element !== 2);
console.log(result);
// [1, 3]

Do not use the indexOf together with splice method, that will mutate the original array.

9. Remove Objects By Property From an Array

To remove an object with a specific attribute from an array, use the filter method.

const arr = [{ num: 1 }, { num: 2 }, { num: 3 }];
const result = arr.filter((obj) => obj.num !== 2);
console.log(result);
// [{ num: 1 }, { num: 3 }]

Do not use the findIndex together with splice method, that will mutate the original array.

10. Check if Array Includes an Element

To check if an array contains a value, use includes method.

const arr = [1, 2, 3];
const result = arr.includes(2);
console.log(result);
// true

11. Check if Array Includes Object with Property

To check if an array contains an object with a property, use some method.

const arr = [{ num: 1 }, { num: 2 }, { num: 3 }];
const result = arr.some((obj) => obj.num === 2);
console.log(result);
// true

12. Check if All Objects in an Array has a Property

To check if every object in an array has a property, use every method.

const arr1 = [{ num: 1 }, { num: 2 }, { num: 3 }];
const result1 = arr1.every((obj) => obj.num === 2);
console.log(result1);
// false

const arr2 = [{ num: 2 }, { num: 2 }, { num: 2 }];
const result2 = arr2.every((obj) => obj.num === 2);
console.log(result2);
// true

13. Convert Array to an Object

To convert an array to a custom object, use reduce method.

// A function which maps a key to a value.
const arr1 = [1, 2, 3];
const result1 = arr1.reduce((acc, cur, index) => {
  acc[`attr${index}`] = cur;
  return acc;
}, {});
console.log(result1);
// { attr0: 1, attr1: 2, attr2: 3 }

// A function which count occurrences could look like this.
const arr2 = ["a", "b", "c", "c"];
const result2 = arr2.reduce((acc, cur) => {
  if (acc[cur]) {
    acc[cur] += 1;
  } else {
    acc[cur] = 1;
  }
  return acc;
}, {});
console.log(result2);
// { a: 1, b: 1, c: 2 })

// A function which maps elements in array to boolean values can look like this.
// I.e. convert array to object keys.
const arr3 = ["a", "b", "c"];
const truthValues = ["b", "c"];
const result3 = arr3.reduce((acc, cur) => {
  acc[cur] = truthValues.includes(cur);
  return acc;
}, {});
console.log(result3);
// { a: false, b: true, c: true })

14. Convert Array of Objects to an Object

To convert an array of objects to an object, use Object.assign method and array spread syntax.

const arr = [{ attr1: 1 }, { attr2: 2 }, { attr3: 3 }];
const result = Object.assign({}, ...arr);
console.log(result);
// { attr1: 1, attr2: 2, attr3: 3 }

15. Convert Object to an Array

To create an array from an object, use Object.keys, Object.values, or Object.entries, potentially together with a map method.

const obj = { a: 1, b: 2, c: 3 };

// Array of keys.
const result1 = Object.keys(obj);
console.log(result1);
// ["a", "b", "c"]

// Array of values.
const result2 = Object.values(obj);
console.log(result2);
// [1, 2, 3]

// Array of key-value objects.
const result3 = Object.entries(obj).map(([key, value]) => ({ key, value }));
console.log(result3);
// [{ key: "a", value: 1 }, { key: "b", value: 2 }, { key: "c", value: 3 }]

In some cases, it is useful to chain some map and filter methods to modify and filter out values.

const obj = { a: 1, b: 2, c: 3 };

// Array of squared values greater than 3.
const result1 = Object.values(obj)
  .map((value) => value * value)
  .filter((value) => value > 3);
console.log(result1);
// [4, 9]

// Array of key-value objects which has a value greater than 1.
const result2 = Object.entries(obj)
  .map(([key, value]) => ({ key, value }))
  .filter((keyValueObj) => keyValueObj.value > 1);
console.log(result2);
// [{ key: "b", value: 2 }, { key: "c", value: 3 }]

16. Combine Two Arrays

To combine two JavaScript arrays, use concat method or the spread syntax for arrays.

const arr1 = [1, 2, 3];
const arr2 = [4, 5, 6];

// Concat method is faster.
const combinedArray1 = arr1.concat(arr2);
console.log(combinedArray1);
// [1, 2, 3, 4, 5, 6]

// Spread syntax may be more readable.
const combinedArray2 = [...arr1, ...arr2];
console.log(combinedArray2);
// [1, 2, 3, 4, 5, 6]

Do not use the push method, that will mutate the original array.

17. Sort an Array

If you want to sort an array by value, use toStorted method.

The toStorted method is stable, meaning that it keeps the order of elements which are equal to each other intact. The method is not in-place, which usually is a good thing, since it means that it won't mutate the existing array.

// To sort strings.
let arr1 = ["b", "c", "a"];
const result1 = arr1.toSorted();
console.log(result1);
// ["a", "b", "c"]

// Note: Numbers are sorted by their toString value,
// not by their numerical value!
const arr2 = [10, 1, 5];
const result2 = arr2.toSorted();
console.log(result2);
// [1, 10, 5]

// To sort numbers, use a comparator.
const arr3 = [10, 1, 5];
const result3 = arr3.toSorted((a, b) => a - b);
console.log(result3);
// [1, 5, 10]

Do not use the sort method, that will mutate the original array since it does in-place sorting.

18. Sort an Array of Objects

To sort an array by value, use toStorted method with a comparator. A comparator is a function which determines which of two values that should be sorted first.

const arr = [{ num: 3 }, { num: 1 }, { num: 2 }];

// ObjA will be sorted before objB if comparator returns a positive value.
const byNumberAttribute = (objA, objB) => objA.num - objB.num;
const result1 = arr.toSorted(byNumberAttribute);
console.log(result1);
// [{ num: 1 }, { num: 2 }, { num: 3 }]

// More generic comparator.
const byAttribute = (attr) => (objA, objB) => objA[attr] - objB[attr];
const result2 = arr.toSorted(byAttribute("num"));
console.log(result2);
// [{ num: 1 }, { num: 2 }, { num: 3 }]

// Note. The comparator function must return an integer value.
// If you need to sort other data types, return 1, 0 or -1.
const arr3 = [{ letter: "c" }, { letter: "a" }, { letter: "b" }];
const alphabetically = (objA, objB) => {
  if (objA.letter < objB.letter) {
    return -1;
  }

  if (objA.letter > objB.letter) {
    return 1;
  }

  // objA === objB
  return 0;
};
const result3 = arr3.toSorted(alphabetically);
console.log(result3);
// [{ letter: 'a' }, { letter: 'b' }, { letter: 'c' }]

Do not use the sort method, that will mutate the original array.

19. Reverse an Array

To reverse all values in an array, use toReversed method.

const arr = [1, 2, 3];
const result = arr.toReversed(2);
console.log(result);
// [3, 2, 1]

20. Remove Duplicates From an Array

To remove duplicated elements in an array, use filter method or a set.

const arr = [1, 2, 3, 2, 1];

// Using filter method.
const result1 = arr.filter((item, index) => arr.indexOf(item) === index);
console.log(result1);
// [1, 2, 3]

// Using a set.
const result2 = [...new Set(arr)];
console.log(result2);
// [1, 2, 3]

The Art of Code Review and Why You Need It

dennis@perssondennis.com (Dennis Persson) — Sun, 01 Oct 2023 00:00:00 GMT

Code reviewing is an art. Although most companies conduct code reviews, only a few of them fully harness the potential benefits that code reviews offer. In this article, we will look at what you and your team can do to fully leverage the potential they offer.

Code Review Is a Team Activity

First rule of code reviewing, code reviewing concerns the whole team. Every person is different, developers have different opinions about code and also different expectations of a code review. Critiques are also received differently from person to person, some are more sensitive than others.

To make sure the whole team agrees to how the code reviews should be handled, you can do one of two things. Either have a meeting about it to talk about expectations, or, make it less formal and start a discussion with the team when you do your first code review. If you bring it up when you present your first code review, you can be quite strict with your comments and still appear as a caring person.

When you discuss the code reviews, try to settle what you think is important. Should the code review be about finding bugs, or should you comment with improvements and opinions? If you encourage opinions, should those be mandatory to fix or can they be ignored?

Discuss and come up with an agreement every developers agrees with, but try to avoid creating explicit checklists of what to check. Using checklists, can easily turn into developers checking off each item an then thinking they are done with the code review, without really reflecting over the solution at all.

Why To Do Code Reviews?

From a manager's perspective, code reviews are often all about finding bugs and assure that the committed code won't hit back when testers test it. For me, as a developer, the main goal of a code review isn't to stop bugs, it's to involve more persons in the solution and to initiate discussions for alternative solutions and knowledge sharing. In the long term, that's what really going to improve the product quality and make developers write less error-prune code.

If you do code reviews correctly, they can help your team in many areas. These are just some of the benefits a code review can help you with.

Reflecting over your code before you commit
Learn and reflect about other developer's code and opinions
Teaching and helping other developers
Align the teams view on the product and its code and newly added code
Getting better knowledge of the full code base
Stop bugs from coming through
Improve the quality of the code
Improve the quality of tests
Reduced technical debt
Enhanced documentation with cleaner commits and better comments
Identify security issues
Save time by fixing issues during the code review instead of two weeks after
Building a team

The last point in the list is what many people forget, but still one of the most important points. A good team communication is essential for all kind of business and development. Code reviews are an excellent way to let the team grow together because it is likely to cause conflicts, and anyone who knows anything about team building or conflict management knows that conflicts are necessary for a team to excel.

Tea drinkers would think it's a compliment

Why You Should Not Do Code Reviews

There aren't very many reasons for not doing code reviews honestly. It does takes time, yes, but that time you will definitely get back in the long term with all the benefits it comes with.

Think about it a bit. If you founded a tech company and hired developers. Would you like anyone to push any code without a single person looking at what they pushed? Would you rely on an open source project where anyone could contribute but no one was reviewing what was committed?

If your answer to any of those questions is no, or if you want to build a better team and improve code quality, then code reviews are for you.

What To Do Before a Code Review

A code review doesn't start with a pull request, there are certain things needed to be done before that, both as the developer who commits the code and for the person who is going to review it.

As a Coder

In a divergent team, there's always that architect guy who checks whole teams code, but also several more fast-paced developers who never really look twice at code and blindly push their code using their two characters alias for "git add . && git commit -m "save" && git push".

When submitting code for a code review (or even without a code review), those hasty developers should try to be a bit more like the architect guy. Some things that always should be done before committing code are:

Keep the commit small, only a single story/task should be implemented in the commit. In that way, it's easier to review and also easier for teammates to track why a change was made when in doubt.
Don't include code unrelated to the task you are working on in your commit. If you have fixed stuff unrelated to your task, commit it in another commit before or after the task.
Does your commit include temporary code? Try to fix it before committing. If not possible, mark it with a TODO comment and plan when to follow it up.
Does your commit include a complex solution? Write comments for the parts which needs it.
Look through your code before pushing. Even if you have followed all the previous steps above without missing anything, you might find improvements for you code or other ways to implement the solution.
Test your code manually. And if you haven't written any test, write those.

First when all above has been done, you are ready to commit your code and ask for a code review. When that is done, it's time for another coffee!

You know, I've seen better developers. On their first cup...

As a Reviewer

The main work of a code review as a reviewer is obviously to review the code, but before doing that, make sure to do a few things.

Firstly, make sure that the developer is done with the development and that all tests for it have been written. Don't review partly finished work unless it isn't to help out with another pair of eyes. Partly finished code is likely to change, especially if tests haven't been written and bugs may be found.

Secondly, talk to the developer who developed the feature to understand what the commit is about. Preferably with the pull request and feature in front of you. Doing this will make it easier to understand the code and the developer's reasoning.

Lastly, you can think about how you would implement the feature before looking at the pull request. This is a great practice to practice problem solving, since you will both come up with a solution on your own and potentially see an alternative solution for the same problem. If you are lucky, you the developer of the pull request implemented the feature in another way, which will make the code review much more interesting.

What To Do During a Code Review

When a pull request has been made, it's time to review it. This work lies mainly on the reviewer, but even the code contributor has a few things to think about.

As a Coder

As the developer of the pull request, you can often just sit and relax while the reviewer tears its hair. To make the life easier for the reviewer, make sure to be available for questions. If the reviewer and you don't know each other very well, make sure to mention you are available for questions, so that person dares to ask.

As a Reviewer

Reviewing large pull requests takes time. As a reviewer it is important to remember it is worth the time without stressing it, take a minute to look back at the section about why to do code reviews in the beginning of this article. Then embrace the opportunity to grow as a developer.

For anything larger than one-liner commits, make sure to check out the code for the pull request in your IDE. This makes it easier to follow links in the code and to search for usages of functions and variables. It also allows you to spot changes the developer should have done but have missed out, e.g. if a function is invoked at several places but the developer only have updated it at one place.

When writing comments on the review, be clear what you mean. If it is a matter of opinion, please make sure to motivate your answer. Apart from when your office's coffee machine decides to brew a "null coffee", there are few things as annoying as an opinionated review comment without an explanation sent with a confident "I'm the architect" attitude.

A little more seems about enough

Speaking about opinions. Don't be that bossy architect guy, unless your team haven't discussed the expectations of code reviews and asked for very critical reviews. If you have opinions, my personal opinion is that they shouldn't block merging if it isn't important.

To continuously interrupting work to fix arguably unimportant stuff like a function name which "could have been better" or an if statement which "could have used an if else" is really annoying and is time spent on fairly worthless matters. Not everyone cares if the attributes are sorted alphabetically. If you have strong feelings about it, make the linter complain about it.

In the end, it's up to your team to decide where the line goes. What are opinions and when will they need to be fixed? Should they block merging or do they only have to be fixed if there are more severe changes which needs to be done?

What To Do After a Code Review

When the reviewer have reviewed the pull request and it is time to hand the comments over to the contributor, it's a good time for a talk. By going through the comments together both developers get a time together for some knowledge sharing and to sort out any unclear comments and avoid misunderstandings.

As the author of the commit, this is the best opportunity to express any objections. If you think the comments make sense, make sure to not do the same mistake next time you push a pull request.

If everything looks good an you both are happy with the solution, go for a coffee together!

Three Simple Rules to Solve Unsolvable Organizational Problems

dennis@perssondennis.com (Dennis Persson) — Tue, 12 Nov 2024 00:00:00 GMT

There are some problems every company faces, no matter the size or industry. Issues like incorrectly assigned responsibilities and poor or overwhelming communication can slow teams down. In this article, we’ll explore three simple rules that can help you tackle these common challenges and get your organization on track.

Single Responsibility

Every developer who knows about design patterns has heard of SOLID principles - five simple rules to follow when writing good code. It's an extremely popular subject, so popular that my article about SOLID principles in React is one of my most-read pieces, despite the abundance of similar content out there.

We're not going to examine these principles today, but we will briefly touch the first one, the S. The S in SOLID stands for Single Responsibility Principle, which states that one piece of code should have one and only one responsibility.

The reasoning behind this is quite simple. Managing two or more tasks at once is difficult - not for the computer, but for the developer. The code becomes harder to read, more challenging to test, more difficult to reuse, and the chances of introducing bugs increase.

The question isn't why we have this rule for code, rather, why companies don't embrace this principle when assigning roles to employees?

I'll say it again, it's not the computer that finds it cumbersome to run code that does multiple things simultaneously, it's the human brain which struggles to understand and maintain it.

In fact, this isn't specific to code. Generally, humans are terrible at multitasking. Period. For this reason, companies should not assign two or three different responsibilities to the same person. Each person should have one and only one job.

Are you a manager who recently assigned a new area of responsibility to your best and most reliable employee? Congratulations, you've just found the quickest way to make them fail.

With great responsibilities comes great meetings

Communication

A company can have everything figured out when it comes to roles, workloads, and required tasks, yet still fail miserably at delivering their products. The main reason for this is often a lack of or poor communication. Effective communication is critical for any company, regardless of its size.

There are many important aspects of communication at different levels. To keep this brief, we'll focus on two critical concepts:

Pulling vs pushing information
Avoiding single-person communication bottlenecks

Pulling vs Pushing Information

Information must be available. Without appropriate information, a team cannot work effectively, resulting in major time losses. However, how information is received matters significantly. This includes not only the medium (Slack, email, or in-person communication) but also whether the recipient requested the information or had it pushed to them.

There's no absolute right or wrong way to handle information flow - whether it should be pushed to someone or whether they should seek it themselves. When recipients aren't aware of information they need to know, the information holder must proactively share it. However, if people know how to access the information they need, there's no reason to push it to them.

This sounds simple, but it rarely works this way in practice. Most of us receive numerous irrelevant emails daily. Many of us are automatically assigned to email lists and Teams groups that don't concern us.

Meanwhile, product issues arise due to information gaps, and we blame others for not sharing essential information with us. We wonder why we weren't invited to meetings which were highly relevant for our work.

Though challenging, this problem has viable solutions. The most important step is communicating what information is available. Every company and team should have a central location where people can discover where to find specific information. This might include contact lists, collections of links, or an overview of available Slack channels.

Once people know where to find information, the approach should shift to an information subscription model. Everyone can subscribe to the information they deem necessary, and then as soon as there is new information on that topic, they will get notified about it.

There's one small but critical detail here which must be mentioned though - you must push that source of information to all employees, making sure they know how to find and use it. If they don't know that they will stand without any information at all.

Avoiding Single-Person Communication Bottlenecks

Large companies have many roles, and each role comes with specific responsibilities. Product Owners (POs), for example, are responsible for their products. While it's important that POs know everything about their products and stay informed about developments, this doesn't mean all product-related communication needs to flow through them.

POs interact with many stakeholders. In large organizations, they might communicate with function owners, system verification engineers, designers, and others. As developers, we should communicate directly with these stakeholders rather than routing everything through the PO.

If all information flowed through the PO, it would create a significant bottleneck. Just like with scaling hardware resources in production, communication should scale horizontally, not vertically - meaning it's better to have many direct conversations between team members than to funnel everything through a single person.

Dependency Elimination

A few years ago, I was convinced communication was the key to success for large companies. However, it turned out to be only half the key - the other half being dependency elimination.

I could continue discussing why communication is important, but the truth is, communication fails. Books about communication will tell you it's a shared responsibility between sender and receiver, with various disturbances in transmission. While this theory is true, communication will ultimately fail, often massively.

One reason for this failure, beyond miscommunication, is poor retention of information and inadequate follow-up actions. The learning pyramid, a visual model showing retention rates across different learning methods, illustrates this well.

Learning pyramid

As you can see, people remember only 5% of what they hear, meaning your colleague will forget 19 out of 20 things you tell them. They retain about 10% of what they read, so even when writing Slack messages you would need to send them each message ten times.

Combining hearing, reading, and visual elements improves retention somewhat. Group discussions (read: expensive meetings) can achieve 50% retention. However, since half the participants are likely checking their phones, the effective retention rate drops far below that.

See the pattern? Communication is essential but inefficient. There's only one way to avoid miscommunication, lost messages, and information that never reaches its destination: dependency elimination - the bulletproof way to avoid communication by removing the need for it entirely.

For developers who might have wondered why we've focused so much on human interaction, let's return to technical scenarios. Imagine if you:

never had to request a feature from another team again
never had to be blocked by another team's bug again
never had to miss a delivery because of a failed PI planning
never had to explain to other developers how they should implement APIs

These aren't merely communication issues - they're communication dependencies you should minimize or eliminate. After all, don't you want your API lean and efficient?

How To Eliminate Dependencies

"But Dennis, you can't just stop communicating and solve all issues, that would be absurd." Yes, it would. But you can minimize the need for communication.

A good architect thinks about this. They detect important data flows and ensure services communicate only when necessary, through simple, understandable channels, preferably based on subscriptions rather than pushing or periodic polling.

The same principle should apply to team and management structure. Unnecessary communication and dependencies between teams should be eliminated. In practice, this can be done in several ways:

by moving responsibilities and products between teams
by implementing appropriate team structures (cross-functional teams instead of silos, etc.)
by ensuring teams are self-organized, taking responsiblity for work instead of asking others what to do
by letting people subscribe to information they need, rather than overwhelming them with irrelevant information
by having clear responsibilities so people know who should do what
by ensuring each person has one and only one responsibility (reducing the amount of dependencies they can have)

Does your company have features blocked by other teams? Then the solution in the first bullet-point might be what you need, letting the team which is blocked taking ownership of the dependency which blocks them.

Are your testers overwhelmed because developers aren't testing their software adequately, causing bugs to bounce back and forth between development and testing teams? The second point about team structure might be your answer. After all, what testing team would be overwhelmed if there wasn't a separate team to report bugs to?

Bugs would still exist, but testers could verify them directly with greater knowledge about what they're testing. They wouldn't need to hunt for requirements to understand how each application should work. Just as you wouldn't want a developer working on dozens of applications, why expect that from a tester?

Although cross-functional and self-organized teams might sound similar, there's a difference in the meaning. A cross-functional team handles work which normally spans over multiple departments (development, testing, production monitoring etc.), while a self-organized team takes responsibility to manage their own tasks rather than waiting for orders from managers.

By being a self-organized team, the communication and interaction to other parts of the company can be reduced, together with the benefit of building a very strong team which have control over their products.

Regarding the fourth point: how many of your emails truly interests you? How many Slack or Teams channels do you read thoroughly? Conversely, how many people actually read your messages in the general channel?

The reality is there's too much information, and people rightfully focus on what's relevant to their job. As discussed earlier, people should ideally search for information they need and subscribe to relevant updates. The only required communication should be explaining how to find this information.

Finally, the last two points about having clear responsibilities and only one responsible per person brings us back to where we started with the Single Responsibility Principle. Each person should have one clear job. Why? As discussed in the communication section, people become bottlenecks when handling too much information. Messages get stuck with them instead of reaching their intended recipients.

Reducing individual responsibilities reduces dependencies, ensuring information reaches its proper destination and allowing people to focus on what they were actually hired to do.

Three Tricks for Chrome DevTools to Find Logs More Easily

dennis@perssondennis.com (Dennis Persson) — Sun, 18 Sep 2022 00:00:00 GMT

Chrome's developer tools are incredibly powerful. Unfortunately, both the console and network tab tend to be filled up with a lot of logs which are rarely looked at, making it difficult to find what you are there to look at.

Today I will show you three tricks of how you more easily can find the information you are searching for. You may have seen the first tip before, but the second and third ones are lesser known tricks I rarely see people use or write about.

1. Let Your Logs Stand Out

Make your console logs look beautiful like this.

Colored log in chrome dev tools console

While it easy to notice, it's a bit verbose to write. You can create a JavaScript utility function for it to make it easy to write.

const clog = (log) => console.log(`%c ${log} `, 'background: #ffff00; color: #0012e9');

# Usage
clog("I am colorful!")

You can create a shorthand function for colored console logs

Another alternative is to create a snippet in VS Code so VS Code can autocomplete the code for you when you just write a prefix of your choice.

Below you can see two snippets. The first one, with the prefix clog, will output a colorful log statement for you when you write clog in a file and autocomplete it with the tab key. The second one, named vlog, logs out both a label and a value.

{
  "Colored Console": {
    "prefix": "clog",
    "body": [
      "console.log('%c $1 ', 'background: #ffff00; color: #0012e9');",
      "$2"
    ],
    "description": "Log colored message to console"
  },
  "Colored Value Console": {
    "prefix": "vlog",
    "body": [
      "console.log('%c $1 ', 'background: #ffff00; color: #0012e9', $1);",
      "$3"
    ],
    "description": "Log colored message to console and an additional value"
  }
}

2. Group Console Messages

Do you have annoyingly many console messages and don't want to remove them? What if I said you can keep them and still hide them? The solution you search for is console.group. In this way you can for example group logs per file or module. Or maybe wrap all logs used for app initialization in a group.

To wrap some logs in a group, simply write console.group() before your logs and console.groupEnd() after the logs. The web console will fold all the logs there in between.

Folded console group in Chrome DevTools console

And when you expand the group, it looks like this.

Expanded console group in Chrome DevTools console

3. Filter Network Requests Instead of Searching

The network tab tends to be very bloated in medium and large sized applications, especially when analytics and log requests are sent remotely. As you might already know, you can filter network requests based on their type, e.g., images or AJAX requests (Fetch/XHR). I would guess you even have found the filter field where you can filter network requests.

Filter options under the network tab in Chrome DevTools

I have seen a lot of persons using the filter field to search for the request they want to view, it's an easy way to ignore all other kind of spam requests. The cumbersome thing about that is that you have to write a filter term every time you want to find a new request.

To avoid that, I instead use the filter field to filter out logs I never am interested to see. To do so, just check the invert button beside the filter box and enter the words you don't want to see. Separate each word with a whitespace.

In the example below, all requests including the terms "inspect" and ".css" are filtered out. You can keep this filter active to always have a clean network log showing only requests you commonly look at.

Example of network tab in Chrome DevTools without a filter

Example of the same network tab in Chrome DevTools with a filter filtering out css files and requests with the word "inspect" in its name

Top 10 Celebrities Who Code

dennis@perssondennis.com (Dennis Persson) — Sun, 10 Jul 2022 00:00:00 GMT

Trust me if you want, but here are the ten most famous celebrities who also has a career as developers.

Mr. JavaBean (Java developer)
Brad Git (GitOps expert)
Nathalie Postman (Backend developer)
Matt Daemon (OS programmer)
Kanye Jest (Unit tester)
Taylor Swift (iOS developer)
Json Mraz (Fullstack developer)
Vim Diesel (Unix developer)
Jay-C (C developer)
Miley Cypress (E2E tester)

Kanye Jest ain't testing Swift code

What I Learned About Unit Testing Working at Volvo Group

dennis@perssondennis.com (Dennis Persson) — Sun, 13 Mar 2022 00:00:00 GMT

Recently, I resigned from Volvo Group Connected Solutions AB (VGCS). It was a great workplace, they are developing surveillance systems for truck and bus fleets. The company is as large-scaled as it gets. They run many different kinds of tests on multiple levels and also have many different roles for employed testers. Despite all the tests, a handful of bugs creep all the way to production occasionally. A product cannot get tested enough. You can spend too much time on testing it though, and this article will explain why it happens and how you can avoid it.

All teams on VGCS have their own rules. In the team I worked in we aimed for a 100 % coverage of unit tests. Our team alone had quite a few thousands of unit tests for the code we managed. Other teams were more into integration tests and spent less time on unit tests. Today, I will give you my two cents regarding unit testing.

Unit Tests Takes Time, Is It Worth It?

Writing unit tests is a slow process. I would claim experienced developers spend as much time writing unit tests as writing code. Novel developers would spend maybe up to three or four times as much as they write their code, along with that they need support learning it. It's a great opportunity to enlighten them how to write better code that is more easily tested, although I personally prefer doing that during code reviews or weekly tech meetings.

The time it takes to write the tests is not in vain. You will get the time back if you do it wise. Shooting wildly and hoping to catch bugs would not be considered wise. That will do nothing more than emptying your magazine and you will end up with a lot of time spent on nothing.

Not the best way to catch bugs (image source: GIPHY)

Most Unit Tests Are Useless

If you aim at 100 % coverage, chances are that most of them are useless. Among all the code I have updated, I have very rarely failed unit tests due to bugs I have introduced in the code. That doesn't mean I haven't introduced bugs, I certainly have.

What I mean is that bugs I introduce almost never is the reason to why the unit tests fail. Rather they fail purely because the updated code isn't compatible with how the tests were written. Let me clarify that with an example.

import React from 'react'
import { shallow } from 'enzyme'
import TodoList, { Todo } from '../TodoList'

it('should pass title to Todo component', () => {
  const todos = [
    { id: 1, title: 't1' },
    { id: 2, title: 't2' },
  ]
  const wrapper = shallow(<TodoList todos={todos} />)
  const firstTodo = wrapper.find(Todo).at(0)
  expect(firstTodo.prop('title')).toEqual('t1')
})

Enzyme test for a todo list. Code available at CodeSandbox or GitHub.

Above is a typical Jest test for React written with Enzyme. What it does is to render a TodoList component and ensures that the correct title is passed to the first Todo component.

Let's say that we are updating the code, maybe letting each Todo component getting its own title from a context or backend. That means we would stop passing in the title to the Todo component. The test would then fail since we don't pass in a title anymore. Since we don't test anything else, we can simply remove the test, which means it was an unnecessary test to write in the first place.

Maybe the same TodoList component is showing a message when we have no todos and we have written a test that checks that the message is visible. A possible improvement could be to let the user create a new component instead of showing the message. In that case we would once again end up with a test that fails due to a change we actually intended to do.

These kinds of edits are very common. If you follow best practices and keep your components (units) small, most of your test failures will be of this kind. With that design, components will have a narrow use case, and as soon as you change the use case, its unit tests will be invalidated. The tests will fail just because you deliberately chose to design the code or UI in another way, not because you have introduced a bug in the old code. In many cases it isn't sufficient to update the tests and you will have to write completely new tests from scratch.

This means that most tests are only valid for as long as you don't touch the code, and as soon as you update it, you either discard or rewrite the tests. You have basically simply tested that the code continues to work as long as you don't touch it. What do you think Einstein would have said about that?

Definitely a legit Einstein quote

Should You Skip Unit Tests?

Occasionally we borrow developers from other teams at Volvo Group. One time one of those developers came from a team that preferred integration tests over unit tests. I understand his reasoning and I prefer to keep stuff minimal and keeping development at a fast pace, I could to some extent agree with him. But in large scaled projects a lot of people think he is wrong in that, you should really have both unit and integration tests.

When Are Unit Tests Useful?

When I previously accused unit tests to be useless I never meant all of them are. What I was talking about was that it is inefficient to test simple code that doesn't include very much logic or code that will change drastically whenever you make an update to it. That kind of code is common when it comes to UI components or boilerplate code. Not all code looks like that.

Math functions, utils functions, hooks and different kind of pure functions like reducers are all perfect examples of when you should write unit tests. Sometimes they contain complex logic which you absolutely should test. Other functions may have many edge cases to tests. Maybe one of the most common causes to bugs in Javascript is when dealing with mutations. With unit tests that's very fast and easy to test.

These kinds of functions should be tested even if you only plan to write them once and then never updating them. It is ridiculously easy to introduce bugs in logic-heavy code and you can't always test it graphically to see that it works. I would strongly recommend Test Driven Development, TDD, when writing that kind of code. TDD forces you to think of edge cases on beforehand which often can save you time already when writing the code. Without it, you may end up rewriting the code multiple times just because you find new edge-cases with every new solution you come up with.

How to Write Good Unit Tests

I have already touched upon what good unit tests are. When testing logical code, it's important to test edge-cases and test that functions doesn't mutate the code. That can be achieved by invoking functions multiple times or by using the strict equal operator in Javascript.

I won't go into any more details there. Instead, I want to turn back to testing UI components again, that's the kind of unit testing I claimed to be useless in many cases. In details, we will discuss the concepts of shallow and mounting tests with Enzyme, and also interactional unit testing with Testing Library. Testing Library can be used with many libraries, including React.

Unit Testing with Enzyme

If you don't know the difference between shallow and mount component testing, the main difference is that when you test a component shallowly you only test that component's logic without rendering its child components. Mounting will instead render the full DOM tree including all child components which aren't explicitly mocked. A more detailed comparison between Enzyme's shallow and mount can be found here.

Enzyme vs React Testing Library

Regarding the differences between Enzyme and React Testing Library, one can see at npm trends that Testing Library is more used nowadays. Meanwhile Enzyme is slowly dying since it isn't being maintained and lacks unofficial support for React 17.

All time npm trends - Enzyme vs React Testing Library

Shallow Tests

Many people prefer shallow testing. Not all are of the same opinion but personally I would recommend it over mounting components, or maybe I would recommend to use a mix of them. What shallow testing means is that you basically test each component's logic without caring about how it would integrate with other components when you run your code.

Maybe the non-integrating part doesn't sound very inviting, we will come to that. At least shallow testing tests the component itself and if you test every component fully you will get a 100 % test coverage in the end. If you update your components, you are likely to rewrite your complete tests as I talked about earlier in this article.

Mounting Tests

Mounting tests are very much like shallow tests. The positive thing is that mounting also tests the integrations to child components. You can ensure that the components work together.

Since you will test child components when testing component, you will end up with a lot more than 100 % coverage for some deeply nested child components. A button that is used in tenth or hundredth of components will be tested over and over and over again. That's where the drawback hides. At a first glance it doesn't seem to hurt very much. But wait until you update that button component in a way that affects all components that uses it. You will end up with failed unit tests in all those tens or hundreds of components you had written tests for.

Interactional Tests

The third type of tests I wanted to bring up is unit tests that focuses on interactions. The idea behind it is to test the components in their real environment based on what really happens when you interact with the DOM nodes. In that way, we can test React components in their natural environment as they would behave in a real browser. It's one step closer to integration tests even though we still are testing units.

Interactional tests in React Testing Library will behave more like Enzyme's mount tests than the shallow tests, since it will render child components as well. You are of course free to mock whatever component you want to mock, so it's completely possible to tests all components shallowly if you would prefer that, just mock all child components.

Not convinced yet? Let's continue, I'm getting to it. The huge advantage I like about interactional unit testing is that you often will be able to keep your unit tests untouched even if you refactor components, or even multiple components. Just like if you would have tested your code with an integration testing tool like Cypress or Selenium.

Let's look at the Todo example again. This time using React Testing Library.

import React from "react"
import { render } from "@testing-library/react"
import TodoList from "../TodoList"

test("it should pass title to Todo component", () => {
  const todos = [
    { id: 1, title: "t1" },
    { id: 2, title: "t2" }
  ]
  const { getAllByRole } = render(<TodoList todos={todos} />)
  const todoItems = getAllByRole("listitem")
  expect(todoItems[0]).toHaveTextContent("t1")
})

React Testing Library test for a todo list. Code available at CodeSandbox or GitHub.

With the code above, we can update the TodoList component and Todo component in any way we want without having to update the test, as long as we keep using list items for the todo items. If you think it is annoying to depend on list items, we can remove that dependency as well. Testing Library allows looking at data-test-id:s or pure texts as well. Read about supported queries here. Here's some examples of what you can do.

// Checking presence of text using a regex.
getByText(/t1/i)
// Checking for data-test-id with the text.
expect(getByTestId('todo-item-1')).toHaveTextContent('t1')
// Checking for a button with the text "Press me".
expect(getByRole('button')).toHaveTextContent('Press me')

Code available at CodeSandbox or GitHub.

Conclusion

Unit tests and integration tests are both necessary. Keeping unit tests at a 100 % coverage is not a bad thing. But if you don't test your code in an efficient manner, it will cost you tremendous of time. Be smart when designing your unit tests and choose the right tools for it.

Code with a lot of logic and calculations are easy to mess up, and it's hard to think of all edge cases and to always have mutability in mind. Test that kind of code thoroughly and preferably with a TDD approach to force you to consider all edge cases before you start writing the code.

When it comes to testing UI and React components you should really think twice about how to write your tests. Using React Testing Library instead of Enzyme is a great start. Not only because Enzyme is poorly maintained, but rather because Testing Library approaches unit testing in a more efficient way. Testing library focuses on testing DOM elements and elements visible to the user. That kind of interactive unit testing is also possible to write using Enzyme, but Enzyme isn't written for that purpose.

By focusing on DOM elements or the UI visible to the user, rather than the implemented components, you can avoid rewriting your tests over and over again. The tests can then fulfil their purpose of catching bugs whenever the code is being updated. When focusing too much on testing implementation details you will end up rewriting your tests every time you update the code, which makes the unit tests more or less useless.

useEffect - The Hook React Never Should Have Rendered

dennis@perssondennis.com (Dennis Persson) — Sun, 07 May 2023 00:00:00 GMT

React was once a fantastic library. Quick to learn, easy to customize and made it easy for you to write clean code. At least it used to be, at the time when they first white-painted the library with hooks instead of the old browny class components.

When React repainted the library, they did a mistake. They left a red brush in the white bucket which they now are using to paint the whole library into a pink disaster. React repainted their future with React 18, but in that picture, the useEffect hook doesn't belong.

I think it's time to get rid of that dangerous and disputed hook, but until then, I'll give you some tips of how to use it without getting pink paint all over your code.

useEffect - The Red Brush in the White Bucket

React have added a wonderful useEffect hook to their bucket of hooks. Only problem, it doesn't belong there. When React 18 first came, the web exploded with warnings about useEffect, claiming it shouldn't be used and that we should not think about React in life cycles.

Truth is, useEffect was an issue long before that. It was very common to see developers leaving out the dependency array when they intended to have an empty dependency array, which causes the useEffect to be effectively useless.

And since React unfortunately leaves a lot of the optimization of the code to the developer, you may need to optimize your code using useCallback, otherwise you can get stuck in infinite rendering loops. Or, in a similar way, it can happen that your code will run on every render.

const ExampleComponent = () => {
  // This function will be triggered on every render.
  const getData = () => {
    // Get some data from server.
  }

  useEffect(() => {
    getData()
  }, [getData]);

  return <div>Example<div>
}

const ExampleComponent = () => {
  // Solution is to optimize the code with a useCallback...
  const getData = useCallback(() => {
    // Get some data from server.
  }, [])

  useEffect(() => {
    // We could also place the getData function in the useEffect,
    // with the drawback of readability if the function is big.
    // const getData = () => { ... }

    getData()
  }, [getData]);

  return <div>Example<div>
}

In earlier days, there were also a lot of articles about why you always should add all dependencies to your useEffect, even when you don't want the effect to run when some of the dependencies changes. That lead to ugly hacks with if statements to avoid code from running.

import { useEffect } from 'react'

const Component = ({ someOtherDependency }) => {
  const [value, setValue] = useState(null)

  useEffect(() => {
    // A common seen if statement added just to
    // prevent the effect from running.
    if (value === null) {
      setValue("someValue")
    }
  }, [value, someOtherDependency])

  return <div>Example<div>
}

Other alternatives were more clean, but only usable in a few cases. Below example shows a trick to avoid adding a state variable to the dependency array.

import { useEffect } from 'react'

const Component = () => {
  const [count, setCount] = useState(0)

  useEffect(() => {
    // By passing a function to setCount, we can access its old
    // value without adding count to the dependency array.
    setCount(oldCount => oldCount + 1)
  }, [])

  return <div>Example<div>
}

React Keeps Painting With the Red Brush

If it wasn't difficult enough to make use of useEffect in React 17, React 18 made it even more troublesome. The main problem with the hook today isn't ugly if statements, missing dependencies or the fact that you should add all dependencies to the dependency array regardless of if you want to or not. Fact is, even if you do all of that, your useEffect may still run several times, due to concurrent rendering.

Luckily, React creators noticed concurrent mode caused a lot of concerns, so they solved it by only enabling it in parts of your code that uses the new React 18 features. A pretty good solution I would say. Pretty.

Problem is, the React docs for useEffect is quite extensive. When opting in for the new features, and thereby turning on concurrent mode, the docs for useEffect gets even more complicated. One page describing useEffect is not enough, you need another long page, and another one, and another, and another...

You have to think about if concurrent mode is enabled. You have to think of all the pitfalls. You have to think of all the optimizations. You have to think about what is best practice. You have to think about how the component renders even if you are encouraged not to think in terms of the old class life cycle methods such as componentDidMount and componentDidUpdate.

React is no longer a framework that has a low learning code. It's quick to start building with, but it takes a long time to learn how to write it correctly without introducing plenty of bugs.

Visual representation of React. Can you spot the useEffect?

The Proper Way To Use useEffect

React is getting a lot of new good features. Meanwhile, useEffect is becoming more and more dangerous. This article would become way too long if I continued describing issues with useEffect, just look at how big documentation there is for it. For that reason, I will give you one single tip for how to handle useEffect.

Let useEffect render.

With letting it render, I don't mean you voluntarily should let it render on every rendering. What I mean is that you should not be afraid of letting it render too many times. Add all dependencies to its dependency array and let it do its work every time it runs.

What you shouldn't do, is to prevent the effect from running in certain use cases. The below code is awful and extremely bug prone.

const getDataFromBackend = () => {
  // Some code.
}

const ExampleComponent = ( {
  someVariable,
  anotherVariable,
  thirdVariable
}) => {
  useEffect(() => {
    if (someVariable === null) {
      if (anotherVariable > 10
        && (thirdVariable !== undefined || thirdVariable !== null)
        ) {
        getDataFromBackend()
      }
    }
  }, [someVariable, anotherVariable, thirdVariable]);

  return <div>Example<div>
}

The ugly code above should look like this instead:

const getDataFromBackend = () => {
  // Some code.
}

const ExampleComponent = ( {
  someVariable,
  anotherVariable,
  thirdVariable
}) => {
  useEffect(() => {
    getDataFromBackend()
  }, [someVariable, anotherVariable, thirdVariable]);

  return <div>Example<div>
}

But? We cannot spam backend with plenty of network requests? Can we?

No, you should not spam backend. What you should do, is to make sure to write getDataFromBackend only fetch data when necessary. Not with the help of if statements, but by using caches, debounce or throttling.

Hooks like useSWR, useQuery and RTK Query handle such things for you, with some need for configurations. Using hooks like those are quite essential nowadays, not only because of issues with useEffect, but also because they include lots of logic you otherwise would have to implement yourself, with retries and state handling.

Importance of Idempotency

Under previous heading we could see how to properly fetch data in a useEffect. I also claimed that you should avoid preventing useEffect from running. In some cases, that might not feel possible. Sometimes we cannot use caches or debounce, that may be the case when sending POST requests to backend.

PUT requests should be fine, because they are idempotent by definition, meaning, it doesn't matter how many times an action is triggered, the result of calling it multiple times is the same as calling it a single time.

Sending POST request to a server are not necessarily idempotent, calling it multiple times may cause a unintended behavior or causing bugs. How can we handle that if useEffect can be triggered multiple times?

Answer is, try to avoid using a useEffect at all. There are multiple ways to do that, but it depends on the situation. If the function isn't dependent on the React component's state, it is possible to lift out the function out of the component.

Another example is when triggering effects on user interactions. In that case, you don't need an effect at all. I often see code similar to the code below.

import { useEffect } from 'react'
import { sendPostRequest } from '/services'

const Component = () => {
  const [buttonClicked, setButtonClicked] = useState(false)

  // Send a request when the button has been clicked.
  useEffect(() => {
    if (buttonClicked) {
      sendPostRequest()
    }
  }, [buttonClicked])

  return <button onClick={() => setButtonClicked(true))}>Click me</button>
}

The thing is, you don't need that useEffect, not even the useState. The code above should look like the code below.

import { useEffect } from 'react'
import { sendPostRequest } from '/services'

const Component = () => {
  // This is what you should do if you really want to send the
  // request when the button is clicked.
  return <button onClick={() => sendPostRequest())}>Click me</button>
}

There are many other ways to get rid of useEffects, you can google how avoid useEffect. But sometimes you do need the effect, and in that case, you should make sure the code within it is idempotent, and then let the effect run as it wants to.

TL;DR

React is getting more and more difficult to learn and use. Optimizations are left up to developers and it gets more and more easy to write React code in a wrong way. React has very soon a steep learning curve and the useEffect is one of the main reasons to that.

To make the best out of the situation, one should try not to care too much about optimizing useEffects - let useEffect run many times. Then make sure the code within the effect is idempotent. For fetching data, you have really nice hooks like like useSWR, useQuery and RTK Query which helps you cache requests.

If a cache isn't the solution, a debounce or throttle may be. Many times you can even remove the useEffect completely since the code can be rewritten in a better way without it.

One day, we may see a React without the useEffect, and maybe even without useCallback? Or maybe the issues with the useEffect hook will keep on growing? In the end, I would say React is one hook away from being a wonderful framework.

What If Animals Could Code...

dennis@perssondennis.com (Dennis Persson) — Sun, 07 Aug 2022 00:00:00 GMT

Okay, here we go again! In the last article in this series you came up with amazingly 40 hilarious comments on the topic celebrities who code. I look forward to see what you geniuses may come up with this time.

So here's today's topic. When YouTube goes down, highly trained monkeys join up to fix the problem as fast as possible. Monkeys may be the only non-human animal that codes, but what would other animals do if they were developers?

I believe them, why would they lie?

Use your imagination and comment funny suggestions of what it could be like to hire an animal as a developer. Here's some suggestions of mine, feel free to reuse the same animals if you want to.

Pandas - would be pandastic programmers!
Snails - would always be working from home
Snakes - do I need to mention Python?
Bugs - I have a feeling they would struggle finding a workplace who wants them
Cows - they are more into hardware, they follow mooooores law
Lions - strong partners for a startup, but expect them to take the lion share of the profit
Sloths - would probably benefit using Copilot
Sheep - may be sheep to hire, but is it worth it?
Cats - wouldn't touch code, they would promote themselves to managers
Pigs - dirty code, but they are actually pretty clever
Moles - they would love to C#
Bats - as long as you are fine with putting your screen upside down, they could maybe be worth hiring
Dogs - would probably be their best. day. ever.
Whales - hire one and you boss will call you in to talk about office expenses

I'm sorry Mr. Koala, but you always do the bear minimum of work

What If CSS Properties Had Personalities

dennis@perssondennis.com (Dennis Persson) — Sun, 28 Sep 2025 00:00:00 GMT

Have you ever wondered what your CSS properties would be like if they were real people? I mean, with all the time you spend with them, don't you wonder what they would be like in real life?

Well, I do. Now let me introduce you to some of the persons in the CSS world to see if it feels like you already know them or not!

display: flex - The Yoga Instructor

Just lay-out a yoga mat and breathe

Meet display: flex, the yoga instructor of CSS. Always talking about alignment, balance, and flow.

"Let's center everything with perfect harmony," they say while making your content bend in ways you never thought was possible.

They're surprisingly flexible (pun intended) and can adapt to any situation they face. If you ever need some help, you can always count on Flex.

position: absolute - The Loner

Create your own path, it will save you from the queues

position: absolute is that friend who always sits in the corner at parties. They don't follow the normal flow of conversation, they just put themselves wherever they want and expect everyone else to work around them.

They're incredibly independent but also kind of needy, they will not do what you want if you don't give their parents the position they require.

Meanwhile, they'll ignore all the normal rules and just float around doing their own thing. They're that one person in the year book photo who stands completely separate from everyone else.

z-index: 9999 - The Attention Seeker

I'm not a show off - I'm a show on!

z-index: 9999 is that person who always has to be in the front of every photo. They're constantly seeking attention and will do anything to look smart and glorious.

They're basically that friend who always cuts into conversations to share their latest achievement, no matter what the discussion was about.

overflow: hidden - The Secretive One

Out of sight, out of mind

overflow: hidden is the person who sweeps everything under the rug. They're that friend who always cleans up before you visit, but you know their closet is a total mess.

They're actually pretty helpful when you have content that's acting up, but sometimes they hide things you actually want to see. And when you send them a long text message they read half of it and ignores the rest.

margin auto - The Peacemaker

The best age is the aver-age

margin: auto is the peacemaker of CSS. They're always trying to find the middle ground and keep everyone happy.

They're immensely diplomatic and can resolve almost any conflict, they simply check where all parts stands and find a solution where everyone can meet in the middle.

But remember, don't ask them to handle vertical centering, that's when they stand immobilized and silent having no idea how to respond.

border-radius: 50% - The Sensitive Person

I hope to see you around!

border-radius: 50% is the sensitive person who easily gets hurt by sharp comments and never would harm anyone.

They're optimistic and careful people who would never dare to live on the edge. Subconsciously they always choose the round table at restaurants even if they are already taken and plush animals are their favorite animals.

opacity: 0.5 - The Ghost

🤫

opacity: 0.5 is the ghost of CSS. They're there, but they're not really there.

They are shy people who nervously whispers "I'm just passing through" while they hurry past you. When they write you a note they write it to be barely visible so you have to squint to read the text.

They are always with you but they rarely speak a word, and when they do, they whisper so low so you wonder if they really said something.

transform: rotate(45deg) - The Dizzy One

Let's see it from the tilted side...

transform: rotate(45deg) is that person who's always tilting their head and seeing things from different angles. "Everything looks better when it's rotated," they say while making your text completely unreadable.

They're creative and see the world differently than everyone else. They're that friend who always has a unique perspective on things, even if it's sometimes a bit confusing. Just don't ask them to do your home assignment - the teacher will know you didn't write it.

@media queries - The Chameleon

One size doesn't fit all

@media queries are the chameleons of CSS. They can adapt to any situation and look good on any picture.

They're very flexible and always thinking about how other people experience situations. They're that friend who can fit in with any crowd and always knows how to adapt to different situations.

It doesn't matter if you reach out to them in the middle of the night, they are always very responsive. And sometimes when you feel the world is black and white, it can be kinda comfortable to hear them describe all their different point of views.

What If Movie Characters Had LinkedIn Profiles

dennis@perssondennis.com (Dennis Persson) — Sun, 04 Sep 2022 00:00:00 GMT

Have you ever wondered what Sheldon Cooper's LinkedIn profile would look like? Oh, stupid question. Of course you have! I will here now present eight well-known movie character's professional profiles.

Sheldon Cooper

Sheldon Cooper's LinkedIn profile

We know him as the childish genius who repeatedly fails to decipher sarcasm. As one of the main characters in The Big Bang Theory, Sheldon Cooper shouldn't have to live without a LinkedIn profile. The question is, would he use LinkedIn when it lacks a bazinga reaction?

Mulan

Mulan's LinkedIn profile

Loyal, brave and true. Mulan has done more for women and the Emperor than most people. Without any need for recognition or compensation she voluntarily fought against the Huns to protect her family. It is now time for her to step into the spotlights and enter LinkedIn.

Builder Bob

Builder Bob's LinkedIn profile

If one would ask Bob if he wanted a LinkedIn profile, he would probably answer with a counter question: Can we fix it? And the answer is, yes we can! LinkedIn profiles normally don't have the profile image centered, but we can fix that too! We can build a LinkedIn where it is possible!

Batman

Batman's LinkedIn profile

Does Batman have a LinkedIn profile? I don't know, I'm not on the list of people who knows his true identity. Batman's professional LinkedIn profile could have looked like above though. Just as with Builder Bob, it's no issue for Batman to have his profile picture right adjusted, he is wealthy enough to buy LinkedIn.

Aquaman

Aquaman's LinkedIn profile

Judging by his LinkedIn banner, Aquaman is a bit less picky than Batman. Being the richest superhero of his time, he could beneficially have spent a bit more money on the banner design. Presumably, he has even skimped on the translation costs, because that website URL doesn't look very accurate.

Homer Simpson

Homer Simpson's LinkedIn profile

It's no secret Homer Simpson appreciates donuts, and he's probably better of marketing himself for that on LinkedIn than to list all the jobs he has had. There are likely not a lot of recruiters searching for donut experts on LinkedIn, but with all his experience, recruiters would constantly stumble onto his profile and eventually he could become LinkedIn's own Rick Roll.

Phoebe Buffay

Phoebe Buffay's LinkedIn profile

Can you play guitar with a bear claw? Or with a turkey leg? No? If you want to learn, you can go to Phoebe. But please remember, do not touch a guitar while learning the chords! Joey learned that lesson the embarrassing way, let's not question Phoebe's methods one more time.

La Linea

La Linea's LinkedIn profile

What If You Would Marry a Programming Language

dennis@perssondennis.com (Dennis Persson) — Sun, 26 Feb 2023 00:00:00 GMT

What if programming languages were human and you could marry them? What could you expect in relationships like that? This is what I think it would be like to live with four of the most known programming languages.

In the Kitchen

Java:

A good baker following recipes in detail, but will need an apron, food processor, colander, steak hammer and a cork screw to even make a sandwich.

JavaScript:

JavaScript doesn't care if the only ingredients you have at home is chocolate sauce, canned tuna and some potato peels from the sink, it's fine to combine!

Python:

Python gladly accepts any meal request you have and lets C prepare it for you.

C++:

C++ makes sure you have whatever utensil you may need, but don't expect any help cooking the food. And don't you dare buying meat that is already minced, that's not why C++ bought you that meat grinder!

What's not to like? Chocolate good. Tuna good. Potato peel...

In the Bedroom

Java:

Just bring the necessary tools and Java can run anywhere. No need to keep it inside, it works just as fine outside the windows.

JavaScript:

JavaScript doesn't understand the importance of foreplay, it believes it can get you ready during the act and finish just in time.

Python:

Can probably give you what you want, otherwise it works perfectly to invite a third party.

C++:

Do I really need to say anything more than that C++ has made a great reputation from being quick?

First Meeting With Family

Java:

Don't be fooled by your great connection with Java, if your parents aren't the right types, Java will refuse to meet them.

JavaScript:

Even though there are other ways, JavaScript is most comfortable when meeting your family over the internet.

Python:

There's a great chance your parents will like Python. Unfortunately, there's a risk they may find Python being quite slow.

C++:

There's no chance your parents will get C++ from start, they will for sure be some misunderstandings.

Mental Connection

Java:

Old and reliable but quite boring. You know Java is always there for you but can be rather grumpy if you don't follow its rules and conventions.

JavaScript:

Acceptive, versatile and will always introduce you to new friends. If you do something wrong, JavaScript won't let you now, you will have to find that out on your own.

Python:

Nice to communicate with, easy to read and will always try to get rid of all the garbage in your life.

C++:

If you want the smartest tool in the shed, C++ is a good choice. But don't complain if it doesn't listen to you, it's probably your fault it's having memory leaks.

Why Server Components - A Brief History of Web

dennis@perssondennis.com (Dennis Persson) — Sun, 09 Jul 2023 00:00:00 GMT

According to Stack Overflow survey 2023, Next.js is now the third most desired web framework, and the sixth most admired one among developers. Even though their old Pages Router is great, they have introduced a new App Router in version 13 of the framework. With that change, they also migrated to use Server Components which can be seen as the next level server rendering.

To understand why Next.js and Server Components are so much more than just traditional client-side React applications, this article will guide you from the beginning of the web, through different types of server rendering with all their benefits, and to the very latest state of web development with Next.js Server Components.

From Server Rendering to SPAs and Then Back to Server

To better understand Server Components, we should talk about why they where introduced. For that, we will need a short history lesson.

In the old traditional web programming days, a website consisted of a server rendering HTML code, sending it over network to a client browser which displayed the already rendered HTML code to the user. With that, you had CSS and some small JavaScript files to handle user interactions and navigation to other pages on the website (and also to show a cool visitor counter, which was kind of mandatory).

Newer technologies came and we got smartphones and better computers with increased performance. The web evolved and single page applications (SPA) became the new standard, which basically meant that only one initial webpage where sent to the client. Upon navigating or interacting with the page, REST requests where used to retrieve data from the server and modified the page without actually navigating to another page on the website.

One of the biggest key players for that evolution was the jQuery library, and then the principle kept growing with modern frameworks like React, Angular and Vue which in first place rendered everything on the client side, with support for opting-in to use server side rendering (SSR). As web migrated to SPAs we started to call websites with rich functionalities for web applications.

More and more web application frameworks emerged, and different ways to pre-render web applications arose. Pre-rendering webpages on requests with SSR wasn't enough, frameworks also added support to pre-render pages in build time, so called static site generation (SSG).

We will soon look closer at SSR and SSG, and at the end of the article we will discuss pros and cons of server rendering. But for now, let's forget the why and focus on the what and how.

Where we are today, it's not a question about client rendering or server rendering, we have actually reached a point where we can choose to render small parts of the site differently, and that's where Client Components and Server Components come in.

Client Components vs Server Components

If you have used SPA frameworks like React or Angular, you should be familiar with Client Components already. Client components are basically what a React component really is in nature, a bit of JavaScript code which renders a component on a webpage when it reaches the browser.

Server Components on the other hand, are components rendered into HTML on the server. When I say that, I don't refer to pre-rendering HTML for complete pages with SSR or SSG, I literally mean rendering a single component, like a single React component. It is that granularity Next.js offers with the new App Router system.

To get a better vision of it. Let's look at the old pre-rendering solutions and then come back to Server Components again after that.

Server Side Rendering (SSR) vs Static Site Generation (SSG)

The basics of SSR and SSG are the same, pre-render HTML code on the server and then fetching JavaScript to make the page interactive in a process called hydration. Dependent on framework, navigation can either result in fetching completely new pages from the server or be handled by hydrated JavaScript code as a SPA would do.

Pre-rendering will fetch HTML and then hydrate JavaScript to make the page interactive

When using SSR as a pre-render solution, a complete web page is rendered into HTML on the server at the time when a page is requested. The server will then also fetch the JavaScript and start the hydration process.

Server side rendering renders HTML for a page when a browser requests it

SSG instead allows you to pre-render the application already at build time, which makes it possible to serve the same HTML page quickly to any user without having to render a page in runtime.

Static site generation renders HTML at build time and serves it on all requests

While SSG allows to serve instant web pages, it doesn't allow to serve different HTML to different users. All users will get the same content. Dynamic rendering based on user data is not possible with that.

SSG neither allows you to change the HTML by time, since all the HTML code are generated during build time. To solve that issue, Next.js supports something called incremental static regeneration (ISR). What it does, is to allow you to manually, on demand, or periodically regenerate a static generated page.

Although ISR exists in the old Pages Router, it isn't available with the new App Router. It has passed on its baton to Server Components.

Client Components vs Server Components Revisited

So, now when we know about the old options to render pages on the server, we can now go back and look at what Client and Server Components actually are. Look at this picture. It shows you a web page with alternated Client and Server Components.

A page can consist of layers of Client and Server Components

As mentioned earlier in the article, Server Components allow you to render individual components purely on the server, while other components on the same page remain as Client Components rendered on the client (with Next.js, they are pre-rendered once on server and hydrated on the client). The picture above, shows and example what that can look like. Green components are rendered into HTML on the server, while the blue ones are rendered with JavaScript on the client.

What this means, is that Next.js now allows to decide for each component whether it should be pre-rendered on the server or if it needs to be rendered on the client. As we will see later, in the Static vs Dynamic Rendering section, Next.js will also automatically determine whether those Server Components need to be rendered at runtime or if they can be rendered in advance at build time.

Ack ack, who's there?

What Rendering Solution Should I Use?

As we have seen, there are a lot of options available for rendering modern web applications. If you use Next.js 13, you have all the options discussed available to choose between. If you start a new project, I recommend using the new App Router system. App Router is production ready, although some other new related features are still in alpha or beta.

To make life easier for you, we will look at which rendering solutions to choose for both Pages Router and new App Router.

Next.js Pages Router

With Pages Router, you have four render options to choose between.

Client Side Rendering (CSR)
Server Side Rendering (SSR)
Static Site Generation (SSG)
Incremental Static Regeneration (ISR)

Remember that all these options are per page. The normal behavior is that one application uses most of these options. For example, information pages such as an about us page can usually be generated using SSG, while other pages with more dynamic data would use SSR.

As we will see later in the article, modern web development tend to favor server rendering over client side rendering. CSR is therefore only recommended if there's a need for it. Some cases when it's necessary or recommended to render an application on the client are:

When you need to use browser specific Web APIs
When you need the user's real location via the geolocation Web API or a IP Geolocation API
When your data relies on data stored in the browser, like LocalStorage
When apps are communicating in a peer-to-peer network
When data changes very frequently, we may want to keep the load on the client not to overload the server

In most other cases, some kind of pre-rendering on the server is recommended. The aim is to cache the generated content as long as possible. If the site is completely static, SSG is usually preferred, if possible.

If you have too many pages to render at build time, or if the static pages need to be updated occasionally, ISR may be an excellent rescue. With ISR, builds can be generated at runtime when you need them, and then regenerated manually or by setting a cache validation time.

If a page isn't completely static, and data isn't only changed by time, but also dependent on authenticated user information or request headers, SSR or CSR is probably what you need to use instead.

Next.js App Router

With the App Router, we don't have as many alternatives. The two main options are Client Component or Server Component.

The concept of static and dynamic rendering is still relevant when we use the App Router, but it's not that prominent. The details about it are a bit complicated, but will be discussed in Static vs Dynamic Rendering section.

The easy part to grasp is when to use Server Components. Just as with the Pages Router, server side rendering is to prefer when using App Router. This means, that we should use Server Components as long as we do not have a reason to use a Client Component. That's also why Next.js defaults to Server Components.

It may sound strange, but the cases of when to use Client Components slightly differs from when to use CSR with the Pages Router. The reason is because the whole underlying structure and design is different with the App Router, so we cannot use the very same rules.

With App Router, you can follow a simple rule. If there is a need to use the browser in any way, or to store some state that may change as a result of user interactions, then you should go for a Client Component, otherwise you can use a Server Component.

More explicitly, a Client Component will be required when:

When you need to use browser specific Web APIs
When you need the user's real location via the geolocation Web API or a IP Geolocation API
When your data relies on data stored in the browser, like LocalStorage
The component uses a lifecycle hook or internal state, such as useState, useReducer, useEffect or useContext
The component uses a custom hook which uses lifecycle hooks or an internal state
The components needs to be interactive, i.e. when it uses onClick or onChange listeners on DOM elements
If you are still using React class components for some strange reason

This may seem like a lot, but remember, a great part of a web applications is normally static and are never changed or interacted with. For example, this whole article is static, it's just text and links.

Server Components aren't just build-time generated static pages. Which we will see later, you can still fetch data from APIs in them, even with dynamic none-cached data. You can read cookies and headers, and they allow you to read sensitive data on the server and to avoid sending huge server responses and JavaScript dependencies to the client.

Don't worry, server has included assembly instructions, Ikea style

Static vs Dynamic Rendering

As revealed earlier, Server Components can be rendered either at build time (static) or at runtime when a request is coming in (dynamic). This is something you should be aware of, but which unfortunately has many ifs and buts.

Next.js have made an attempt to handle this automatically for you. What they do, is to default to static rendering, and automatically enables dynamic rendering when necessary, or when you manually configure that. Dynamic rendering will be activated when:

Dynamic functions are used, which are built-in functions to read cookies, headers or search params
You disable cache for the built-in fetch function
You manually change the behavior with a Route Segment Config

I'm pretty sure you will have to read those links to understand it, this article is already long enough without that. One thing you should note down though, is that the behavior differs when you use Next.js built in functions for data fetching, cookies, headers and search params, compared to when you use custom solutions or external libs.

Next.js will not be able to know when your component must be dynamic if you don't use their built-in features. In that case, you may have to manually configure the cache behavior.

Pros and Cons With Server Rendering

As promised a few times throughout the article, we will now look at pros and cons of server side rendering. Server side rendering has a lot of benefits and a few disadvantages. The advantages depends slightly on what type of server rendering which is in use, the advantages of SSG can differ from SSR. The pros and cons taken up here is in general terms for server side rendered content.

Advantages of Rendering Data Server Side

Servers usually have lower network latency to database than clients, especially if a client's database connection goes through a server
A single or a few servers can utilize catches better than thousand or millions of clients
Parsing JavaScript is a slow operation and one of the biggest reasons to slow websites. Rendering data on a server reduces the JavaScript bundle size sent to the client
Initial page load is faster with server side rendering, which is both good for UX and for SEO
Server side rendering is better for SEO overall, due to less JavaScript involvement which historically have had a long and problematic relationship with web crawlers
You can use secrets like API keys in server side rendered content. Sensitive information like that shall never be used on a client
With server side rendering, you can keep your APIs and databases private and inaccessible on the public internet, since no client depends on it. Without authentication that's more or less impossible to achieve when a client depends on it
When data is fetched on a server, there's no need to show loading spinners or skeletons
When data is fetched on a server, cumulative layout shift will not be an issue
Content rendered on a server is more predictable when an application must support different browsers and devices because the server interprets the JavaScript. On a client, JavaScript can even be disabled

Disadvantages of Rendering Data Server Side

Rendering content on servers leads to a higher server load, which in turn leads to more server expenses
Servers generally has less support for third-party libraries
You don't have access to browser functionality or user's location and device etc. on a server
Loading time for navigation may be slow if data isn't reused and each navigation results in a completely new page. This drawback was more of a problem with traditional server side rendering solutions where rendered content rarely was reused

I wonder where Waldo went?

Server Components Come with Additional Benefits

When it comes to React Server Components, all above listed pros and cons for server side rendering applies, but Server Component also has some additional cool advantages.

One interesting detail is that all Server Components are already pre-rendered when the client receives an application. What this means is that conditionally rendered Server Components can be rendered instantly even when they depend on network data. There's no need to wait for a network response and handle the loading state, even in cases where the component is conditionally rendered in response to a user action.

Reading that, you may be worried about bundle size. I can relieve you by informing that your preoccupations are unwarranted. HTML code does not have a great impact on loading times. HTML is cacheable, way faster to parse and run than JavaScript, and just a fraction of the size of images.

And as the icing on the cake, Server Components add zero bundle size for JavaScript dependencies! Even if you would use a none tree-shacked library at 250 kB, the resulting HTML code would still include 0 kB JavaScript.

Server Components Are Not Perfect

If Server Components are so amazing, are they really perfect? Answers is of course no. There are some potentially inconvenient drawbacks.

Server Components require new knowledge. The migration from old Next.js Pages Router to the new App Router comes with a complete new way of thinking which most developers aren't used to.

Not only the developers' knowledge have become more outdated, the code has so too. Even though newer versions of Next.js is fully compatible with old Pages Router, code using the Pages Router will become legacy code, just as the React's old class components.

Few other drawbacks also exists with code quality. Sharing code has become more difficult when rendering has been split further into client and server rendering. Code marked with use client and import server-only makes it more cumbersome to write DRY code.

I must also admit, although opinionated, the prop drilling of Server Components in Next.js is not the best solution for readability. In Next.js, Server Components cannot be imported in a Client Component, meaning that Server Components rendered in Client Component must be passed as children props and rendered as such. It works, and it's not a new pattern, but might be a bit cumbersome to adapt to.

Oh, there you are Waldo, on the server!

Conclusion

Web started out with HTML retrieved from a server with very little use of JavaScript. Time flew by and after many turns back and forth with different rendering solutions such as single page applications (SPA), server side rendering (SSR) and static site generation (SSG), React has now evolved to use Server Components.

Next.js offers a legacy Pages Router which uses the old rendering options together with a very useful incremental static generation (ISR) strategy. With the introduction of Server Components, they now offer a new App Router which allows you to micro-optimize rendering for you web application on a component level with Server Components.

Among all the benefits of Server Components, we have low bundle size, fast page load time, great SEO compatibility and browser support, UX improvements and a possibility to use secrets stored on the server. On top of that, we can get instant rendering for conditionally rendered components without a need to show any loading spinners or skeletons.

Why You Should Not Be a Reactive Developer

dennis@perssondennis.com (Dennis Persson) — Sun, 09 Oct 2022 00:00:00 GMT

What Is a Reactive Developer?

Let's start with defining what I mean when I say "reactive developer". I don't refer to the programming paradigm reactive programming. Neither do I mean a developer who writes React code.

What I really am talking about when I use the term reactive developer, is a trait some developers have when they write code. The way they behave when writing code.

Reactive developers write code as a direct response to the problem they are facing for the moment. This means, if they find a bug, they will solve it hastily without considering alternative solutions. Phrased differently, they will implement the first solution that comes to their mind without thinking of the consequences it implies.

The opposite to a reactive developer, would be a proactive developer, a developer that plans ahead to find the best possible solution. Let's look at an example scenario to see the difference in how a reactive developer solves a problem compared to a proactive developer.

Case Scenario

Imagine you have an application where you can receive messages, and messages are marked as read when you read them. Then, when a user has read all its messages, a modal should display.

Imagine that functionality is already implemented with the code below. Unfortunately, it doesn't work, the modal doesn't open when the latest message is read. Maybe you can spot why?

// The passed in messages has a property named isRead which is
// true if the message has been read.
const MyReactComponent = ({ messages }) => {
  const [modalOpen, setModalOpen] = useState(false)
  const [unreadMessages, setUnreadMessages] = useState(messages)

  useEffect(() => {
    // If there are no unread messages, open the modal.
    if (unreadMessages.length === 0) {
      setModalOpen()
    }

    // Update unreadMessages to only contain unread messages.
    setUnreadMessages(messages.filter(msg => !msg.isRead))
  }, [messages])

  return <Modal open={modalOpen} />
}

I don't know how experienced React developer you are, but the reason the modal isn't opened is because the useEffect has a missing dependency, unreadMessages. It's an honest mistake, developers do such things all the time.

With that said, the person who wrote this code is probably a rather unexperienced or hasty developer, a novice or reactive developer. Especially since this issue could have been caught if the developer used ESLint rules for React hooks, react-hooks/exhaustive-deps, and took notice of the warning it would have inferred about the missing dependency to the useEffect.

ESLint could have warned us with a "React Hook useEffect has a missing dependency" notice

The Reactive Developer's Solution

Time to solve the bug in the code above. As mentioned, the issue was that the unreadMessages was missing in the useEffect's dependency list. Our imagined reactive developer figures out that quickly. Just as quickly as he detects the problem, he also comes up with a solution. Quickly he adds the missing dependency and checks the browser result.

useEffect(() => {
  if (unreadMessages.length === 0) {
    setModalOpen()
  }

  setUnreadMessages(messages.filter(msg => !msg.isRead))

  // The reactive developer added the unreadMessages dependency.
}, [messages, unreadMessages])

Hmm. Something isn't working... Is Babel failing? Why isn't the application responding? No, that's not it. The browser is stuck in an infinite loop!

When the developer added the missing unreadMessages dependency, the useEffect caused an infinte loop because unreadMessages updates within the effect, which in turn retriggers the effect to run once again. Luckily, this new bug couldn't go by undetected.

The reactive developer is inventive. He instantly figures out another solution. What if we only would invoke setUnreadMessages if the number of unread messages actually has changed? That way, we could bypass the infinte loop. In seconds he has updated the code to look as below.

const MyReactComponent = ({ messages }) => {
  const [modalOpen, setModalOpen] = useState(false)
  const [unreadMessages, setUnreadMessages] = useState(messages)

  useEffect(() => {
    if (unreadMessages.length === 0) {
      setModalOpen()
    }

    const unreadMsgs = messages.filter(msg => !msg.isRead)

    // If the number of unread messages is the same as last time
    // the effect ran, do not update the state. This way we can
    // avoid the infinite loop, because we only update
    // unreadMessages if we have read some new messages.
    if (unreadMessages?.length !== unreadMsgs.length) {
        setUnreadMessages(unread)
    }
  }, [messages, unreadMessages])

  return <Modal open={modalOpen} />
}

Does the code work well now? Honestly, I haven't even tested it. What I can tell already is that it isn't a good solution. Let's look at a better one.

How To Solve It Properly

The initial code was bad to begin with, and when we found out it caused an error, we shouldn't just have solved the bug, we should have reconsidered if there was a better way to implement the same functionality. The current code was obviously flaky already. Any other quick fix would either cause a new bug or contribute to more complex code.

Here's what could have been done.

const MyReactComponent = ({ messages }) => {
  const unreadMessages = messages.filter(msg => !msg.isRead)
  return <Modal open={unreadMessages.length === 0} />
}

Yeah. That's it. The code does exactly what we wanted it to do. Concise, readable, and no need for the three hooks and two if statements that all could cause some kind of bugs. We could even have turned the complete component into a one-liner, but that would reduce the readability of the code.

Replacing the original solution with this new solution is just as quick as patching the old solution. But instead of increasing complexity, readability and the risk for bugs, we instead made the code more readable and less error-prone.

The Impact of Reactive Programming

So, let's rethink what we just experienced and what kind of effects reactive programming results in.

The reactive solution ended up with 3-4 times as much code. We definitely don't want our whole code base to grow with a factor 3 or 4. Apart from having to maintain the code base, redundant JavaScript code is also one of the most common causes for web applications to load slowly.
The reactive solution gave birth to a new bug. In this case, it was easy to detect the new bug. We won't always be that lucky.
The reactive developer's code takes a lot more time to read and understand.
The reactive developer's React component will render more times. Doing this for one component isn't an issue, but in large-scale projects, or when dealing with big amount of data, it can make the application terribly slow.
Since the reactive code can be refactored in a better way, all unnecessary code adds up to the project's technical debt.
Developers copy a lot of code. There's a big chance (read risk) that someone copies the code the reactive developer wrote, leading to all the same mistakes in another part of the application.
Unexperienced developers would spend a lot of time testing the longer reactive component. Not only because it's harder to test, but also because it looks harder. Many developers try to test internal logic, such as what value a useState has. Please note that you should never do that. Consider each React component as a unit (black box). You have some input and expect an output. What values a useState has is completely irrelevant.

I'm sure I missed a bunch of bullet points I could add. But I think you get the point, there's a lot of reasons not to be reactive and go for the fastest possible solution. Try to be proactive, to think of better solutions. It will save you a tremendous amount of time, not only long term, in most cases even short term.

An Extra Note About Writing Tests

When working at larger companies, testing is very essential, and it takes time, a lot of time. I would therefore like to add an additional note about testing the components written by the reactive and proactive developers.

Testing the proper proactive solution is a piece of case, one test to check that the modal is open when we have read all messages, and another one to check that it's closed when we have messages which are unread. That will test all scenarios that can occur and all branches of code (possible if-statement branching). We do not need to test that the code works when the unread count changes, because the code does not have an internal state or a useEffect.

// When the code doesn't include a state or an effect, there's
// no need to update the message prop when testing the component.
const MyReactComponent = ({ messages }) => {
  const unreadMessages = messages.filter(msg => !msg.isRead)
  return <Modal open={unreadMessages.length === 0} />
}

The longer solution written by the reactive developer is more troublesome to test. We could of course use the same two test cases, one for the open state and one for the closed state. Doing that would not test all scenarios that can happen when running the code though, and neither would it cover all code branches. It wouldn't even catch the bug on topic, where the modal doesn't open when the read count changes.

To test the reactive component fully, we would have to trigger a rerender and pass in a new messages prop to test it thoroughly. That is required because we have a useEffect that updates an internal state in the component.

// To test this component fully, we need to update messages prop
// within a test to see what happens when the useEffect triggers.
// If we don't do that, we cannot know what will happen when we
// get new messages passed in from a parent component.
const MyReactComponent = ({ messages }) => {
  const [modalOpen, setModalOpen] = useState(false)
  const [unreadMessages, setUnreadMessages] = useState(messages)

  useEffect(() => {
    if (unreadMessages.length === 0) {
      setModalOpen()
    }

    const unreadMsgs = messages.filter(msg => !msg.isRead)

    if (unreadMessages?.length !== unreadMsgs.length) {
        setUnreadMessages(unread)
    }
  }, [messages, unreadMessages])

  return <Modal open={modalOpen} />
}

Testing the above component is not very hard, but it can be. If we would test it using Enzyme and trying to do a shallow rendering, we would notice that the useEffect isn't even being triggered. More code always comes with more bugs, more test cases and more use cases that aren't supported by the frameworks we use. The best way to avoid writing a lot of tests is to write better code.

Summary

A reactive developer is a programmer which reacts to problems when they occur, and quickly finds a way to solve or mitigate the problem. In this article, we could see how such behavior could lead to writing more code which are both less readable and more prone to errors. We explained how being proactive and writing code with the future in mind could save time both when writing code and writing tests.

Write SOLID React Hooks

dennis@perssondennis.com (Dennis Persson) — Sun, 02 Jun 2024 00:00:00 GMT

SOLID is one of the more commonly used design patterns. It's commonly used in many languages and frameworks, and there are some articles out there how to use it in React as well.

Each React article about SOLID presents the model in slightly different ways, some applies it on components, other on TypeScript, but very few of them are applying the principles to hooks.

Since hooks are a part of React's foundation, we will here look at how the SOLID principles applies to those.

Single Responsibility Principle (SRP)

The first letter in Solid, the S, is the easiest one to understand. In essence it means, let one hook/component do one thing.

// Single Responsibility Principle

A module should be responsible to one, and only one, actor

For example, look at the useUser hook below, it fetches a user and todo tasks, and merges the tasks into the user object.

import { useState } from 'react'
import { getUser, getTodoTasks } from 'somewhere'

const useUser = () => {
  const [user, setUser] = useState()
  const [todoTasks, setTodoTasks] = useState()

  useEffect(() => {
    const userInfo = getUser()
    setUser(userInfo)
  }, [])

  useEffect(() => {
    const tasks = getTodoTasks()
    setTodoTasks(tasks)
  }, [])

  return { ...user, todoTasks }
}

That hook isn't solid, it doesn't adhere to the single responsibility principle. This is because it both has the responsibility to get user data and todo tasks, that's two things.

Instead, the above code should be split in two different hooks, one to get data about the user, and another one to get the tasks.

import { useState } from 'react'
import { getUser, getTodoTasks } from 'somewhere'

// useUser hook is no longer responsible for the todo tasks.
const useUser = () => {
  const [user, setUser] = useState()

  useEffect(() => {
    const userInfo = getUser()
    setUser(userInfo)
  }, [])

  return { user }
}

// Todo tasks do now have their own hook.
// The hook should actually be in its own file as well. Only one hook per file!
const useTodoTasks = () => {
  const [todoTasks, setTodoTasks] = useState()

  useEffect(() => {
    const tasks = getTodoTasks()
    setTodoTasks(tasks)
  }, [])

  return { todoTasks }
}

This principle applies to all hooks and components, they all should only do one thing each. Things to ask yourself are:

Is this a component which should show a UI (presentational) or handle data (logical)?
What single type of data should this hook handle?
What layer does this hook/component belong to? Is it handling data storage or is it maybe a part of a UI?

If you find yourself building a hook which doesn't have a single answer to each and every of the above questions, then you're breaking the single responsibility principle.

An interesting thing to note here, is question number one. That one actually means, that a component rendering a UI, should not also handle data. This means, to really follow this principle strictly, each React component displaying data should have a hook to handle its logic and data. In other words, data should not be fetched in the same component which displays it.

Why Use SRP in React?

This single responsibility principle actually goes very well with React. React follows a component based architecture, meaning that it consists of small components composed together so they all together can build up and form an application. The smaller the components are, the more likely they are to be reusable. This applies to both components and hooks.

For that reason, React is more or less founded on the single responsibility principle. If you don't follow it, you will find yourself always writing new hooks and component and rarely re-use any of them.

Disobeying the single responsibility principle will make your code exhaustive to test. You will often find your test files to have several hundred, maybe up towards 1000, lines of codes, if you don't follow this principle.

Open/Closed Principle (OCP)

Let's continue with the Open/Closed principle, after all, it's the next letter in SOLID. OCP is as well as SRP one of the easier principle to understand, at least its definition.

// Open/Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

In words for dummies who recently have started with React, the sentence can be translated to:

Write hooks/component which you never will have a reason to touch again, only re-use them in other hooks/components

Think back at what was said for the single responsibility principle earlier in this article; in React, your are expected to write small components and compose them together. Let's look at why that is helpful.

import { useState } from 'react'
import { getUser, updateUser } from 'somewhere'

const useUser = ({ userType }) => {
  const [user, setUser] = useState()

  useEffect(() => {
    const userInfo = getUser()
    setUser(userInfo)
  }, [])

  const updateEmail = (newEmail) => {
    if (user && userType === 'admin') {
      updateUser({ ...user, email: newEmail })
    } else {
      console.error('Cannot update email')
    }
  }

  return { user, updateEmail }
}

The hook above fetches a user and returns it. If the type of the user is an admin, the user is allowed to update its email. A regular user is not allowed to do update its email.

The above code would definitely not get you fired. It would annoy the backend guy in your team though, the dude who reads design pattern books as bedtime stories for his toddlers. Let's call him Pete.

What would Pete complain about? He would ask you to rewrite the component as shown below. To lift out the admin functionalities to it's own useAdmin hook, and leave the useUser hook with no other features than those that should be available for regular users.

import { useState } from 'react'
import { getUser, updateUser } from 'somewhere'

// useUser does now only return the user, 
// without any function to update its email.
const useUser = () => {
  const [user, setUser] = useState()

  useEffect(() => {
    const userInfo = getUser()
    setUser(userInfo)
  }, [])

  return { user }
}

// A new hook, useAdmin, extends useUser hook,
// with the additional feature to update its email.
const useAdmin = () => {
  const { user } = useUser()

  const updateEmail = (newEmail) => {
    if (user) {
      updateUser({ ...user, email: newEmail })
    } else {
      console.error('Cannot update email')
    }
  }

  return { user, updateEmail }
}

Why did Pete ask for this update? Because that disrespectful picky prick Pete would rather want you to spend time rewriting that hook now, and come back with a new code review tomorrow, instead of potentially having to update the code with a tiny new if statement in the future, if there ever would be another type of user.

Well, that's the negative way to put it... The optimistic way, is that with this new useAdmin hook, you don't have to change anything in the useUser hook when you intend to implement features that affects admin users only, or when you add new types of users.

When new user types are added, or when useAdmin hook is updated, there's no need to mess with the useUser hook or update any of its tests. Meaning, you don't have to accidentally ship a bug to regular users when you add a new user type, e.g. a fake user. Instead, you just add a new userFakeUser hook and your boss won't call you in at 9 pm on a Friday because customers experience problems with fake data being shown for their bank account on a salary weekend.

Pete's son knows to be careful about spaghetti code developers

Why Use OCP in React?

It's arguable how many hooks and components a React project should have. Each one of them comes with a cost of renderings. React isn't a Java where 22 design patterns leads to 422 classes for a simple TODO list implementation. That's the beauty of the Wild West Web (www).

However, open/closed principle is clearly a handful pattern to use in React as well. The example with the hooks above was minimal, the hooks didn't do very much. With more substantive hooks and larger projects this principle becomes highly important.

It might cost you some extra hooks, and take slightly longer to implement, but your hooks will become more extendable, meaning that you can re-use them more often. You will have to rewrite the tests less often, making the hooks more solid. And most important, you won't create bugs in old code if you never touch it.

God knows not to touch things which aren't broken

Liskov Substitution Principle (LSP)

Aaah, the name... Who the hedge is Liskov? And who will substitute her? And the definition, doesn't it even make sense?

// Liskov Substitution Principle

If S subtypes T, what holds for T holds for S

This principle is clearly about inheritance, which isn't naturally practiced as much in React or JavaScript as in most of the backend languages. JavaScript didn't even have classes until ES6, that was introduced around 2015/2016 as syntactical sugar to prototype based inheritance.

With that in mind, the use cases of this principle really depends on what your code looks like. A principle similar to Liskov's that would make sense in React, could be:

If a hook/component accepts some props, all hooks and components which extends that hook/component must accept all the props the hook/component it extends accepts. The same goes for return values.

To illustrate an example of this, we can look at two storage hooks, useLocalStorage and useLocalAndRemoteStorage.

import { useState } from 'react'
import { 
  getFromLocalStorage, saveToLocalStorage, getFromRemoteStorage 
} from 'somewhere'

// useLocalStorage gets data from local storage.
// When new data is stored, it calls saveToStorage callback.
const useLocalStorage = ({ onDataSaved }) => {
  const [data, setData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setData(storageData)
  }, [])
  
  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
    onDataSaved(newData)
  }

  return { data, saveToStorage }
}

// useLocalAndRemoteStorage gets data from local and remote storage.
// I doesn't have callback to trigger when data is stored.
const useLocalAndRemoteStorage = () => {
  const [localData, setLocalData] = useState()
  const [remoteData, setRemoteData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setLocalData(storageData)
  }, [])
  
  useEffect(() => {
    const storageData = getFromRemoteStorage()
    setRemoteData(storageData)
  }, [])
  
  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
  }

  return { localData, remoteData, saveToStorage }
}

With the hooks above, useLocalAndRemoteStorage can be seen as a subtype of useLocalStorage, since it does the same thing as useLocalStorage (saves to local storage), but also has extended the capability of the useLocalStorage by saving data to an additional place.

The two hooks have some shared props and return values, but useLocalAndRemoteStorage is missing the onDataSaved callback prop which useLocalStorage accepts. The name of the return properties are also named differently, local data is named as data in useLocalStorage but named as localData in useLocalAndRemoteStorage.

If you would ask Liskov, this would have broken her principle. She would be quite furious actually when she would try to update her web application to also persist data server side, just to realize that she cannot simply replace useLocalStorage with useLocalAndRemoteStorage hook, just because some lazy fingered developer never implemented the onDataSaved callback for the useLocalAndRemoteStorage hook.

Liskov would bitterly update the hook to support that. Meanwhile, she would also update the name of the local data in the useLocalStorage hook to match the name of the local data in useLocalAndRemoteStorage.

import { useState } from 'react'
import { 
  getFromLocalStorage, saveToLocalStorage, getFromRemoteStorage 
} from 'somewhere'

// Liskov has renamed data state variable to localData
// to match the interface (variable name) of useLocalAndRemoteStorage.
const useLocalStorage = ({ onDataSaved }) => {
  const [localData, setLocalData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setLocalData(storageData)
  }, [])
  
  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
    onDataSaved(newData)
  }

  // This hook does now return "localData" instead of "data".
  return { localData, saveToStorage }
}

// Liskov also added onDataSaved callback to this hook,
// to match the props interface of useLocalStorage.
const useLocalAndRemoteStorage = ({ onDataSaved }) => {
  const [localData, setLocalData] = useState()
  const [remoteData, setRemoteData] = useState()

  useEffect(() => {
    const storageData = getFromLocalStorage()
    setLocalData(storageData)
  }, [])
  
  useEffect(() => {
    const storageData = getFromRemoteStorage()
    setRemoteData(storageData)
  }, [])
  
  const saveToStorage = (newData) => {
    saveToLocalStorage(newData)
    onDataSaved(newData)
  }

  return { localData, remoteData, saveToStorage }
}

By having common interfaces (ingoing props, outgoing return values) to hooks, they can become very easy to exchange. And if we should follow the Liskov substitution principle, hooks and components which inherits another hook/component should be possible to substitute with the hook or component it inherits.

Liskov gets disappointed when developers don't follow her principles

Why Use LSP in React?

Even though inheritance isn't very prominent in React, it's definitely used behind the scenes. Web applications can often have several similar looking components. Texts, titles, links, icon links and so on are all similar types of components and can benefit of being inherited.

An IconLink component may or may not be wrapping a Link component. Either way, they would benefit from being implemented with the same interface (using the same props). In that way, it's trivial to replace a Link component with an IconLink component anywhere in the application at any time, without having to edit any additional code.

The same goes for hooks. A web application fetches data from servers. They might use local storage as well or a state management system. Those can preferably share props to make them interchangeable.

An application might fetch users, tasks, products or any other data from backend servers. Functions like that might as well share interfaces, making it easier to re-use code and tests.

Interface Segregation Principle (ISP)

Another bit more clear principle, is the Interface Segregation Principle. The definition is quite short.

// Interface Segregation Principle

No code should be forced to depend on methods it does not use

As its name tells, it has to do with interfaces, basically meaning that functions and classes should only implement interfaces it explicitly use. That is easiest achieved by keeping interfaces neat and letting classes pick a few of them to implement instead of being forced to implement one big interface with several methods it doesn't care about.

For instance, a class representing a person who owns a website should be implementing two interfaces, one interface called Person describing the details about the person, and another interface for the Website with metadata about the Website it owns.

interface Person {
  firstname: string
  familyName: string
  age: number
}

interface Website {
  domain: string
  type: string
}

If one instead, would create a single interface Website, including both information about the owner and the website, that would disobey the interface segregation principle.

interface Website {
  ownerFirstname: string
  ownerFamilyName: number
  domain: string
  type: string
}

You may wonder, what is the problem with the interface above? The problem with it is that it makes the interface less usable. Think about it, what would you do if the company wasn't a human, instead a company. A company doesn't really have a family name. Would you then modify the interface to make it usable for both a human and a company? Or would you create a new interface CompanyOwnedWebsite?

You would then end up with an interface with many optional attributes, or respectively, two interfaces called PersonWebsite and CompanyWebsite. Neither of these solutions are optimal.

// Alternative 1

// This interface has the problem that it includes 
// optional attributes, even though the attributes 
// are mandatory for some consumers of the interface.
interface Website {
  companyName?: string
  ownerFirstname?: string
  ownerFamilyName?: number
  domain: string
  type: string
}

// Alternative 2

// This is the original Website interface renamed for a person.
// Which means, we had to update old code and tests and 
// potentially introduce some bugs.
interface PersonWebsite {
  ownerFirstname: string
  ownerFamilyName: number
  domain: string
  type: string
}

// This is a new interface to work for a company.
interface CompanyOwnedWebsite {
  companyName: string
  domain: string
  type: string
}

The solution which would follow the ISP, would look like this.

interface Person {
  firstname: string
  familyName: string
  age: number
}

interface Company {
  companyName: string
}

interface Website {
  domain: string
  type: string
}

With the proper interfaces above, a class representing a company website could implement the interfaces Company and Website, but would not need to consider the firstname and familyName properties from the Person interface.

Is ISP Used in React?

So, this principle obviously applies to interfaces, meaning that it should only be relevant if you are writing React code using TypeScript, shouldn't it?

Of course not! Not typing interfaces doesn't mean they aren't there. There are there all over the place, it's just that you don't type them explicitly.

In React, each component and hook has two main interfaces, it's input and its output.

// The input interface to a hook is its props.
const useMyHook = ({ prop1, prop2 }) => {
  
  // ...

  // The output interface of a hook is its return values.
  return { value1, value2, callback1 }
}

With TypeScript, you normally type the input interface, but the output interface is often skipped, since it is optional.

// Input interface.
interface MyHookProps { 
  prop1: string
  prop2: number
}

// Output interface.
interface MyHookOutput { 
  value1: string
  value2: number
  callback1: () => void
}

const useMyHook = ({ prop1, prop2 }: MyHookProps): MyHookOutput => {
  
  // ...

  return { value1, value2, callback1 }
}

If the hook wouldn't use prop2 for anything, then it should not be a part of its props. For a single prop, it would be easy to remove it from the props list and interface. But what if prop2 would be of an object type, for instance the improper Website interface example from the previous chapter?

interface Website {
  companyName?: string
  ownerFirstname?: string
  ownerFamilyName?: number
  domain: string
  type: string
}

interface MyHookProps { 
  prop1: string
  website: Website
}

const useMyCompanyWebsite = ({ prop1, website }: MyHookProps) => {
  
  // This hook uses domain, type and companyName,
  // but not ownerFirstname or ownerFamilyName.

  return { value1, value2, callback1 }
}

Now we have a useMyCompanyWebsite hook, which has a website prop. If parts of the Website interface is used in the hook, we cannot simple remove the whole website prop. We have to keep the website prop, and thereby also keep the interface props for ownerFirstname and ownerFamiliyName. Which also means, that this hook intended for a company could be used by a human owned website owner, even though this hook likely wouldn't work appropriately for that usage.

Why Use ISP in React?

We have now seen what ISP means, and how it applies to React, even without the usage of TypeScript. Just by looking at the trivial examples above, we have seen some of the problems with not following the ISP as well.

In more complex projects, readability is of the greatest matter. One of the purpose of the interface segregation principle is to avoid cluttering, the existence of unnecessary code which only are there to disrupt readability. And not to forget about, testability. Should you care about the test coverage of props you are not actually using?

Implementing large interfaces also forces you to make props optional. Leading to more if statements to check presences and potential misusages of functions because it appears on the interface that the function would handle such properties.

Dependency Inversion Principle (DIP)

The last principle, the DIP, includes some terms which are quite misunderstood out there. The confusions are much about what the difference is between dependency inversion, dependency injection and inversion of control. So let's just declare those first.

Dependency Inversion

Dependency Inversion Principle (DIP) says that high-level modules should not import anything from low-level modules, both should depend on abstractions. What this means, is that any high level module, which naturally could be dependent on implementation details of modules it uses, shouldn't have that dependency.

The high and low-level modules, should be written in a way so they both can be used without knowing any details about the other module's internal implementation. Each module should be replaceable with an alternative implementation of it as long as the interface to it stays the same.

Inversion of Control

Inversion of Control (IoC) is a principle used to address the dependency inversion problem. It states that dependencies of a module should be provided by an external entity or framework. That way, the module itself only has to use the dependency, it never has to create the dependency or manage it in any way.

Dependency Injection

Dependency injection (DI) is one common way to implement IoC. It provides dependencies to modules by injecting them through constructors or setter methods. In that way, the module can use a dependency without being responsible of creating it, which would live up to the IoC principle. Worth to mention, is that dependency injection isn't the only way to achieve inversion of control.

Is DIP Used in React?

With the terms clarified, and knowing that the DIP principle is about dependency inversion, we can look at how that definition looks again.

// Dependency Inversion Principle 

High-level modules should not import anything from low-level modules. Both should depend on abstractions

How does that apply to React? React isn't a library which normally is associated with dependency injection, so how can we then solve the problem of dependency inversion?

The most common solution to this problem spells hooks. Hooks cannot be counted as dependency injection, because they are hardcoded into components and it's not possible to replace a hook with another without changing the implementation of the component. The same hook will be there, using the same instance of the hook until a developer updates the code.

But remember, dependency injection is not the only way to achieve dependency inversion. Hooks, could be seen as an external dependency to a React component, with an interface (its props) which abstracts away the code within the hook. In that way, a hook kind of implements the principle of dependency inversion, since the component depends on an abstract interface without needing to know any details about the hook.

Another more intuitive implementations of DIP in React which actually uses dependency injection are the usage of HOCs and contexts. Look at the withAuth HOC below.

const withAuth = (Component) => {
  return (props) => {
    const { user } = useContext(AuthContext)

    if (!user) {
      return <LoginComponent>
    }

    return <Component {...props} user={user} />
  }
}

const Profile = () => { // Profile component... }

// Use the withAuth HOC to inject user to Profile component.
const ProfileWithAuth = withAuth(Profile)

The withAuth HOC shown above provides a user to the Profile component using dependency injection. The interesting thing about this example is that it not only shows one usage of dependency injection, it actually contains two dependency injections.

The injection of the user to the Profile component isn't the only injection in this example. The withAuth hook does in fact also get the user by dependency injection, through the useContext hook. Somewhere in the code, someone has declared a provider which injects the user into the context. That user instance can even be changed in runtime by updating the user in the context.

Why Use DIP in React?

Even though dependency injection isn't a pattern commonly associated with React, it is actually there with HOCs and contexts. And hooks, which has taken a lot of market share from both HOCs and contexts, does also confirm well with the dependency inversion principle.

DIP is therefore already built into the React library itself and should of course be utilized. It's both easy to use and provides advantages such as loose coupling between modules, hook and component reusability and testability. It also makes it easier to implement other design patterns such as the Single Responsibility Principle.

What I would discourage from, is trying to implement smart solutions and overusing the pattern when there really is much simpler solutions available. I have seen suggestions on the web and in books to use React contexts for the sole purpose of implementing dependency injection. Something like below.

const User = () => { 
  const { role } = useContext(RoleContext)

  return <div>{`User has role ${role}`}</div>
}

const AdminUser = ({ children }) => {
  return (
    <RoleContext.Provider value={{ role: 'admin' }}>
      {children}
    </RoleContext.Provider>
  )
}

const NormalUser = ({ children }) => {
  return (
    <RoleContext.Provider value={{ role: 'normal' }}>
      {children}
    </RoleContext.Provider>
  )
}

Although the above example does inject a role into the User component, it's purely overkill to use a context for it. React contexts should be used when appropriate, when the context itself serves a purpose. In this very case, a simple prop would have been a better solution.

const User = ({ role }) => { 
  return <div>{`User has role ${role}`}</div>
}

const AdminUser = () => <User role='admin' />

const NormalUser = () => <User role='normal' />

Persson Dennis RSS

10 Tips To Get More Readers on DEV

In This Article

1. Pin Post to Your DEV Profile

2. Target Beginners or Expert Readers

3. Syntax Highlighting for Code Blocks

4. Add a Table of Content and Link to Headings

5. How To Choose Markdown Editor on dev.to

6. Add a Canonical Link to Your Article on dev.to

7. Report Articles if Someone Steals Them

8. How To Make Series on dev.to

9. How To Embed Videos and Instagram Posts on dev.to

10. Remind the Reader To Subscribe

Bonus: Add a Summary

21 Fantastic React Design Patterns and When to Use Them

In This Article

Core Design Patterns in React

Component Composition Pattern

Custom Hook Pattern

Control Props Pattern

Provider Pattern

Common React Design Patterns

Container Presentational Pattern

Compound Components Pattern

Headless Components

Atomic Design Pattern

Error Boundary Pattern

Portal Pattern

Render Props Pattern

Props Getters Pattern

Legacy Patterns

Higher Order Components Pattern (HOC)

General Patterns

DRY Principle

SOLID Principles

Single Responsibility Principle (SRP)

Open/Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

Dependency Injection

Separation of Concerns (SoC)

MVVM

Stable Dependency Principle (SDP)

KISS Principle

Design Patterns to Avoid

Clean Architecture

Note About Modern React Patterns and Frameworks

33 Christmas Animations to Easily Add to Your Website

In This Article

CSS Snowflakes!

Snow Globes

CSS Santa Claus

Christmas Decorations in CSS

Interactive Christmas Animations

CSS Candy Canes

CSS Snowman

Other Christmas Art

Bonus - Christmas Games

6 Use Cases for Regex in Your Daily Work

In This Article

What Is Regex

Regexes in a Nutshell

When Is Regex Used?

Searching Through Files, Manuals and Logs

Regex Search in an IDE

Classic Example, Form Validation

Find and Replace Like a Pro (or Manipulate Strings)

Usages in APIs and Web Consoles

Interpret and Categorize Data with Regex

Learn More About Regex

Answers to Common Next.js Questions

In This Article

1. How To Read URL Params in a Client Component?

2. How To Read URL Params in a Page File?

3. How To Read URL Params in a Next.js Layout File?

4. How To Read URL Params in a Server Component?

5. Why Doesn't searchParams Exist in Next.js Layout Files?

6. How Can I Skip the Root Layout for Some Pages in Next.js?

7. How To Set Metadata Tags in App Router?