DEV Community: Luke Brannagan

Learning in 2025: How I Stopped Consuming and Started Understanding

Luke Brannagan — Sun, 26 Oct 2025 09:53:54 +0000

In a world where you have access to all the content imaginable, I feel that some people have forgotten the appropriate way to learn. Content, be that a tutorial, a YouTube short, or a blog post like this, can promise you the world with an outcome, but conveniently leaves out the part about the hard work required to learn anything.

Being stuck in tutorial hell can feel like pushing a rock up a hill. It’s ambiguous whether you’re actually learning anything. I remember spending weeks following a React tutorial only to realize I couldn’t build a single component without looking back at the video. That was the moment I realised I was consuming content, not learning.

I’m going to share my approach to learning, specifically coding topics, but this could easily apply to other subjects too.

The Risk of Modern Learning

It’s worth mentioning that learning, in my opinion, is the most dangerous it has ever been. With the introduction of AI, it now takes mere seconds to create a LinkedIn post and shovel out whatever comes from your prompt into the post box and press publish.

There is no watchman for the AI. Sometimes it gets things right, but it can also easily get things wrong, and you, the student on said topic, are none the wiser. I’m not saying avoid AI at all costs; it’s a useful tool, but that’s all it is—a tool. You should be validating its output by reading relevant documentation to ensure it’s correct.

The allure of speed is intoxicating, but that speed comes at a cost, and that cost is understanding. When used wisely, AI can actually help you learn faster, but only if you stay in control of the process.

Why I Dislike “Build X From Scratch” Videos

It’s an abstraction. Someone has done all the hard work, read the docs, built prototypes, and created a project. Now it’s time to monetise and cash in on the thousands of people who think that loosely watching a video at 1.5x speed teaches them anything more than a surface-level understanding.

These videos are purely monkey see, monkey do, and reward you with a nice GitHub repo without the real reward: understanding the rendering techniques of Next.js, for example.

My Process for Learning Anything

To start, I’d like to foreword that this is nothing new. It should be used less as a guide and more as a reminder of how to actually learn, rather than watching fruit dance on a YouTube short and expecting to know how to grow fruit.

Remember that your time is money. Quite literally in today’s world, I could make a short that gives you 30 percent of a concept, so you watch it 15 times to fully understand it, only to forget it a week later and watch again another 15 times.

Learning something is hard. Expect to put in the hours to fully understand a concept. Prepare yourself and accept that you might not learn it, if it’s a large one, in a day, a week, or even a month.

First, I start with my note-taking tool. Personally, I use Obsidian because I like to own my data. However, any note-taking app or combination of writing tools, like a pen or pencil and some thin horizontal tree skin, will work.

I start by writing a summary of what I’m going to learn and the questions I should be able to answer by the end of my learning session. If you want to get fancy, you can also add any linked topics that might branch off from this one.

Next, I find resources that I trust: official documentation, MDN, or Wikipedia. We’re not in school—it’s normally accurate enough. I read, take notes, and if I get stuck, I’ll post that section into my LLM of choice, giving it the context of my notes rather than letting it just guess.

From here, I have an understanding, not a complete or deep one yet, but a loose, untested understanding of the concept I’m learning. Now it’s time to put it into practice. Prototype on Stackblitz, build a portfolio piece, apply your theory, and try explaining the concept to someone. Keep it short—it also looks good on a CV.

How to Know You’re Actually Learning

There are a few simple signs that tell me when something has clicked.

You can explain the concept to someone else without looking at your notes.
You can build a smaller version of what you learned without copying code.
You can connect what you just learned to something you already know.

When those things start to happen, that’s when you know you’re truly learning.

Final Thoughts

I’ve applied this pattern to almost all my learning over the past seven years and have been able to stay consistent with tech. I like to think I’m quite knowledgeable in the specialism I’ve chosen. It’s freeing to know that you can learn literally anything with enough hard work.

True learning isn’t about speed. It’s about depth, patience, and curiosity.

🫖 Thinking in patterns not features

Luke Brannagan — Sat, 25 Oct 2025 14:23:44 +0000

Patterns stand the test of time because they describe how something should work, not exactly how it’s built. The challenge comes when we design at too granular of a level.

Building something that’s overly specific to a single feature quickly becomes hard to maintain, and documenting it, well is even harder.

Think about the simple act of boiling water.

The pattern looks like this:

Heat up the water
Wait until it boils
Congratulations, you’ve boiled water

The implementation might look like this:

Pour water into a kettle
Plug the kettle in
Press the switch
Wait for it to boil
Congratulations, you’ve boiled water

The pattern doesn’t change, only the method does. You could use a kettle, a campfire, or any other heat source however, the underlying logic stays the same.

We can apply this same thinking to frontend development. Instead of building a hook that only handles one very specific use case, we can build a more general hook that defines the pattern, then inject the details as dependencies. It’s like choosing whether you use the kettle or the campfire. The steps stay consistent; only the context changes.

This approach helps keep code consistent, easier to maintain, and simpler to explain. By focusing on patterns that represent the essence of what we’re trying to do, we can swap out the details without rewriting the logic every time.

An Example

❌Imperative solution

The imperative solution handles each step manually, tightly coupled to the feature, hard to reuse, document and test.

function useSignupSteps() {
  const [step, setStep] = useState(0);

  const next = () => setStep((s) => s + 1);
  const prev = () => setStep((s) => Math.max(0, s - 1));

  // Steps are hard-coded here
  const steps = [
    { id: "account", label: "Create Account" },
    { id: "profile", label: "Set Up Profile" },
    { id: "confirm", label: "Confirm Details" },
  ];

  const current = steps[step];

  return { steps, step, current, next, prev };
}

// Usage
const { steps, current, next } = useSignupSteps();

🧩 Pattern Version

This version defines a general “steps pattern” and lets you inject the specifics.

import { useState, useCallback } from "react";

type Step<T = any> = {
  id: string;
  label?: string;
  data?: T;
};

type UseStepsOptions<T> = {
  steps: Step<T>[];
  onStepChange?: (step: Step<T>, index: number) => void;
};

export function useSteps<T = any>({ steps, onStepChange }: UseStepsOptions<T>) {
  const [index, setIndex] = useState(0);

  const next = useCallback(() => {
    setIndex((i) => {
      const nextIndex = Math.min(i + 1, steps.length - 1);
      onStepChange?.(steps[nextIndex], nextIndex);
      return nextIndex;
    });
  }, [steps, onStepChange]);

  const prev = useCallback(() => {
    setIndex((i) => {
      const prevIndex = Math.max(i - 1, 0);
      onStepChange?.(steps[prevIndex], prevIndex);
      return prevIndex;
    });
  }, [steps, onStepChange]);

  const goTo = useCallback(
    (id: string) => {
      const idx = steps.findIndex((s) => s.id === id);
      if (idx !== -1) {
        setIndex(idx);
        onStepChange?.(steps[idx], idx);
      }
    },
    [steps, onStepChange]
  );

  return {
    current: steps[index],
    index,
    next,
    prev,
    goTo,
    isFirst: index === 0,
    isLast: index === steps.length - 1,
  };
}

the key take aways from this document should be to design software more with patterns in mind than the imperative solution.

For example, If you need to use localStorage write a hook that handles all implementations of it rather than just thinking about your specific Kettle use case.

Mastering Project Governance: Achieving Codebase Excellence and Consistency (Frontend)

Luke Brannagan — Mon, 26 Jun 2023 17:37:49 +0000

As a frontend developer, I have accumulated several tools over my 4 years of experience that have significantly simplified my projects and improved code quality. In this blog post, I will share these tools with you, emphasising the importance of enforcing code quality standards and consistency across a codebase. Please note that these tools are primarily focused on frontend development using React.

Why should you care about Project Governance?
A Linter
RFC (Request for Comments)
Husky
Plop

Why should you care about Project Governance?

Imagine a scenario where we neglect project governance. In such a situation, several issues start to arise:

Spaghetti code:
- Mixture of single and double quotes for strings.
- Multiple approaches to fetch and handle data.
- Different styling methods: some developers use styled-components, while others prefer Tailwind CSS.
Dependency hell:
- Multiple libraries for fetching data.
- Various date libraries like date-fns and Moment.js.
- Numerous form handlers.
Onboarding difficulties: It becomes challenging to introduce new developers to a repository with 1000 packages serving different purposes and spaghetti code scattered throughout.

These examples only scratch the surface of the potential problems. Now, let's explore some solutions!

A Linter

It goes without saying that using a linter is essential. If you don't have a linter locally installed in your project, your code will lack consistency and become a nightmare to manage. The industry standard combination is ESLint paired with Prettier.

To set up ESLint and Prettier to automatically format your code according to strict yet clean rules upon saving, you can follow this guide for configuring it with most major IDEs: ESLint Configuration Guide.

Here are some recommended rulesets. I personally have been using Wes Bos's config for years and highly recommend it, but I will also list some common alternatives:

For a more comprehensive list of rulesets, you can refer to this awesome-eslint repository.

RFC

RFCs are a fantastic way to gather input from multiple developers before adding something to your repository. This could be a new dependency, a set of hooks to be built and used throughout the app, or even a restructuring of the project's folder structure.

By introducing a small barrier, similar to a pull request, where you need to receive feedback from several individuals before adding a fifth date library to your repository, you can keep the number of dependencies low and encourage thoughtful consideration of each addition.

RFCs can be implemented in various ways. Github supports them, but you can also set up a Slack channel dedicated to pending RFCs or incorporate them as subtasks in your Kanban board to track their status.

Husky

Husky provides pre-commit powers! With Husky, you can run commands like npm run lint --fixAll

just before creating a commit. You can also leverage Husky with TypeScript or testing frameworks to disallow commits with failing tests, adding an extra layer of security and consistency to your application.

Plop

Plop is a tool for creating file templates using handlebars templates. One common problem is the inconsistency with code snippets, as each developer has their own way of quickly creating code from scratch using custom shortcuts. For example, I often use rfac to generate a React component as an arrow function.

Plop allows you to maintain consistent folder structures within your application and enables new developers to quickly onboard by creating components with a single command. You can even alias the command to something like generate. For instance, typing generate test would generate a test file with the necessary imports and snapshot tests already set up, if required. Plop simplifies the process of keeping your application's folder structure clean and consistent.

By incorporating these tools into your frontend development workflow, you can significantly enhance code quality, maintain consistency, and make your life as a developer much easier.

🚀 Feel free to reach out if you have any questions or thoughts. Happy coding!

Getting started with Pact and Consumer Driven Contract Testing

Luke Brannagan — Mon, 26 Jun 2023 10:27:09 +0000

What is Pact?
What are Consumer Driven Contracts?
Setting Up
Summary

What is Pact?

Pact is a family of frameworks that support various languages and offer an easy way to set up Consumer Driven Contract Testing (more on this later). Their website can be found here, which provides comprehensive documentation if you prefer a different writing style.

What are Consumer Driven Contracts?

Let's break it down:

What's a consumer?

A consumer is typically a web app or anything that consumes the provider, which can also be another API.

What's a provider?

Usually, a provider refers to an API.

What's a contract (or pact)?

A contract is a file created by a test to expect a specific content type and body that should be sent to the consumer. For example, if you have a button on a form, clicking it may require passing a body and receiving a "complete" message in response.

How does the testing theory work?

First, we create a test on the consumer side, which generates our contract file. This contract should then be passed to the team handling the provider.

Manually sending contracts to the provider team would be a pain, but that's where a Pact Broker like PactFlow comes in. A Pact Broker easily integrates with your CI/CD system, and other teams can access contracts published on successful builds if desired.

With some CI/CD setup, you can ensure that providers must satisfy the contracts to deploy, eliminating the chance of broken builds for all consumers.

Setting Up

For setting up Pact, I recommend the following resources:

Pact Repo: This repo provides several helpful examples of writing Consumer Driven Contract testing.
React Pact Consumer Contract Example: React developers can check out this repository to learn how to get up and running.

Summary

In summary, Pact is a family of frameworks that enable Consumer Driven Contract Testing. The process involves creating contracts on the consumer side and somehow passing them to the provider for validation. By using Pact, you can ensure reliable and smooth interactions between consumers and providers.

Feel free to reach out if you have any questions or thoughts. Happy coding!

🔥 Hot Take: If you're not using Storybook you're doing FE Development wrong.

Luke Brannagan — Sun, 25 Jun 2023 20:43:57 +0000

Before we get to it, this is a heavily opinionated post so keep that in mind I like Storybook a lot so that should also be noted.

Why
How
So you've heard "Storybook takes me longer to implement components." I'm here to say it does not.
Let's talk about Autodocs because it's too awesome to leave out
Why would I not use Storybook?
Summary

Why

Let's start at the beginning: what is Storybook, and why should I use it?

For those who have not had the chance to use Storybook before, it's incredibly easy to set up and takes little to no time. I won't go into the setup process here, as I'm covering that in a separate post along with some tips and tricks I normally use.

Storybook has recently implemented zero-config support for most CSS solutions, including:

💨 Tailwind
🧶 MaterialUI
💅 Styled Components
👩‍🎤 Emotion

But let's get back to what Storybook actually does and the problems it solves.

This is just a condensed version of the Storybook documentation, which is available here.

Over recent times, complexity with UIs and frontend development has been growing. Starting with responsive design, a typical component now has multiple factors to consider. For example, if you have a button that has 3 variants (with different background colors), you then have to check that variant on each modern browser (4). Additionally, you need to test this component on countless breakpoints. Managing all of this while ensuring no regression issues arise and all components work seamlessly becomes quite a headache.

That's where Storybook bridges the gap. It can help you keep these variations and states in check across all browsers and breakpoints with some help from tools like Chromatic (also made by the Storybook team).

How

In short, before my new blog post comes out, run the following command in the repository where you want to install Storybook:

npx storybook@latest init

And you're off to the races! It will ask some questions about your repository, so answer them correctly, and Storybook will be set up out of the box and ready to go.

For small plugins like the a11y plugin, which injects AXE accessibility tests into your stories, it's rather simple to add as well.

"Storybook takes me longer to implement components" – I'm here to say it does not.

I've heard this complaint a lot. If your components are built in isolation and have data passed to them, you're primed to just copy and paste the same story over and over again. At the very least, with this approach, you get some documentation automatically generated, as well as all the extra bells and whistles that Storybook provides (a11y, testing, etc.).

This takes zero time. I mean, let's be real – the most you would do if you wanted a sleek-looking Storybook is to write your documentation alongside the code, for everyone to enjoy, instead of using Confluence or other external tools.

If you need some templates to steal, take a look at my ecommerce project that I'm building. I'm using Storybook extensively. At the time of writing, I haven't even touched Next.js. Instead, I'm building out each component before adding it to the main site.

Let's talk about Autodocs because it's too awesome to leave out

Autodocs are cool! Here's a link to a video explaining Autodocs. This feature allows you to write extensive documentation with almost zero effort – just copy and paste

Tell me why I'm wrong in the comments below. I'm releasing a new blog post about how I work with Storybook soon, so look out for that.

Why would I not use Storybook?

I'm not quite sure. Storybook has loads of benefits and can help create a robust, clean application. Not using it is pure insanity and inevitably leads to spaghetti code.

Summary

Hopefully, I've helped you see the light, and you'll choose Storybook for your next project. You'll get free documentation, regression testing, a11y testing, and interaction testing built-in with just around 10 minutes of effort for the setup.

🚀 Feel free to reach out if you have any questions or thoughts. Happy coding!

Accessibility - Getting started / Quick wins

Luke Brannagan — Sun, 25 Jun 2023 15:44:35 +0000

Contents:

The reason I'm writing this blog post is due to the current way that accessibility at least in my experience is seen within tech companies. An afterthought or an oops yeah we should've done that at the start.

Accessibility is one of the topics, that for me is as important if not more important than testing (There is no point in testing something if it does not work for people who can only use a keyboard). But opinions aside there is a risk to bad accessibility and that is if whoever you're working for client or business asks we need to meet X standard there is either going to be a lot of refactoring or a complete remake of some components.

A couple of components to look out for are (although this is not a complete list that can be found here).

Tabbed views
Accordions
Fake buttons
Buttons with no text (Icon buttons etc)
Custom selects

Also, if you're looking to learn more semantic HTML learning accessibility in tandem is a really good idea as some semantic elements, for example, the interactive element <dialog></dialog> (we'll get into this in a bit).

In this post, I'm aiming to get you started or at least point you in the right direction when it comes to accessibility, giving you the confidence as well as knowledge to spot common errors before they become large issues causing you to refactor major components within a codebase. Let's get started.

Aria Labels

An aria-label is an attribute for an HTML element that defines a label for the given element. It should be used when there is no visible text associated with an element. Aria labels should only be used on certain elements, don't go labeling everything!

Interactive elements
Landmark elements
Elements that have an explicit widget role
iframe and img elements (I don't think these need an explanation 🙂)

Let's expand on what some of these elements are.

Interactive elements

Interactive elements consist of 4 HTML elements (blog post explaining how to use these coming soon! for now here's a link to some docs!).

<details></details>
<dialog></dialog>
<menu></menu>
<summary></summary>

Landmark elements

Landmark elements are a special kind of element; it could technically be any HTML element with the role set to a valid landmark value. A list of these is:

banner: A region that contains the prime heading or internal title of a page.
complementary: Any section of the document that supports the main content, yet is separate and meaningful on its own.
contentinfo: A region that contains information about the parent document such as copyrights and links to privacy statements.
form: A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.
main: Main content in a document. In almost all cases, a page will have only one role="main".
navigation: A collection of links suitable for use when navigating the document or related documents.
search: The search tool of a Web document.
application: A region declared as a web application, as opposed to a web document.

I apologize for the incomplete response. Here's the continuation of the blog post:

Accessibility - Getting started / Quick wins

Elements with explicit widget role

Some elements have an explicit role that represents a specific widget or interactive component. These elements include:

<button>
<input>
<select>
<textarea>

For these elements, if they don't have visible text, you should provide an aria-label to ensure they are accessible.

Examples of using `aria-label`

Let's take a look at a few examples of how to use aria-label:

Button with an icon:

   <button aria-label="Add item">
     <i class="icon-add"></i>
   </button>

In this example, the button has an icon but no visible text. The aria-label attribute provides an accessible label for screen readers.

Image with no alt text:

   <img src="image.jpg" aria-label="Product image">

When using an image without alt text, you can use the aria-label attribute to provide a description for screen reader users.

Custom select dropdown:

   <div role="combobox" aria-label="Select a country" aria-expanded="false">
     <input type="text" aria-autocomplete="list">
     <ul role="listbox" aria-hidden="true">
       <li role="option">Option 1</li>
       <li role="option">Option 2</li>
       <li role="option">Option 3</li>
     </ul>
   </div>

In this example, we have a custom select dropdown implemented using HTML and CSS. The aria-label attribute on the main container provides a label for the dropdown, and the role attributes on the child elements define their roles for accessibility.

By using aria-label appropriately, you can ensure that elements without visible text are still accessible to screen reader users.

Keyboard Accessibility

Keyboard accessibility is a crucial aspect of web accessibility. Many users rely on keyboards to navigate and interact with websites, especially those with motor disabilities. Here are some key points to consider for keyboard accessibility:

Focus Styles: Ensure that interactive elements, such as links, buttons, and form inputs, have a visible focus indicator when they receive focus. This helps keyboard users understand their current location on the page.
Tab Order: Elements should follow a logical tab order that makes sense for keyboard users. By default, HTML elements are ordered based on their position in the HTML document. However, you can use the tabindex attribute to modify the tab order if needed.
Keyboard Navigation: Test your website using only the keyboard to ensure all interactive elements are reachable and operable. Users should be able to navigate through links, buttons, dropdown menus, and other interactive components using the keyboard alone.
Skip Links: Include a skip link at the beginning of your page to allow users to jump directly to the main content or other important sections. This helps keyboard users avoid repetitive navigation and quickly access the relevant content.
Keyboard Traps: Avoid creating keyboard traps where users get stuck in a particular focus state and cannot navigate away using the keyboard. For example, ensure that modals and overlays can be closed using the keyboard (e.g., pressing the Escape key).

These are just a few considerations for keyboard accessibility. It's important to thoroughly test your website's keyboard interactions and ensure a smooth experience for keyboard-only users.

Semantic HTML

Using semantic HTML is not only good for search engine optimization and code readability but also plays a significant role in accessibility. Semantic HTML

elements convey meaning to assistive technologies and provide context for understanding the structure of a web page. Here are some examples of semantic HTML elements and their usage:

<header>: Represents the introductory content or a group of navigational aids for a page or section.
<nav>: Defines a section containing navigation links.
<main>: Specifies the main content of a document.
<article>: Represents a self-contained composition in a document.
<section>: Defines a standalone section within a document.
<aside>: Represents a section of a document with content related to the main content.
<footer>: Defines the footer of a document or a section.
<figure> and <figcaption>: Used together to encapsulate media content (such as images) and provide a caption.

By utilizing these semantic elements, you provide additional context to assistive technologies and enhance the overall accessibility of your website.

ARIA Landmarks

ARIA landmarks are a set of roles that can be added to specific sections of a web page to help users navigate and understand its structure. Some common ARIA landmarks include:

role="banner": Marks the banner or header section of a page.
role="navigation": Identifies the section containing navigation links.
role="main": Marks the main content of a document.
role="complementary": Identifies a section that supports the main content but is not essential to its understanding.
role="contentinfo": Marks the footer or the end portion of a page, providing additional information about the document.

By using ARIA landmarks, you can enhance the navigation and comprehension of your web pages for screen reader users.

Conclusion

Web accessibility is a vital aspect of building inclusive and user-friendly websites. By following these quick wins, including providing explicit widget roles, using aria-label appropriately, ensuring keyboard accessibility, using semantic HTML, and leveraging ARIA landmarks, you can make significant improvements to the accessibility of your website.

Remember that accessibility is an ongoing process, and it's essential to test your website with real users, including those with disabilities, to gather feedback and make further improvements. By prioritizing accessibility from the start and continuously iterating on your designs and implementations, you can create a web experience that is accessible to all users.

useCallback and useMemo: Understanding Performance Hooks.

Luke Brannagan — Sun, 25 Jun 2023 15:36:45 +0000

Memoization

Before we dive into the hooks, it will be beneficial to understand what memoization is. In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs. It involves storing the results of expensive function calls and returning the cached result when the same inputs occur again.

To put it simply, when we refer to a function as "expensive," it means that the function takes a long time to complete. This could be due to various reasons such as complex computations or waiting for a response from an API.

If you'd like to explore memoization further, I recommend reading this blog post for more information.

useMemo

Now that we understand memoization, you might have an idea of what useMemo can be used for. useMemo, short for memoization, is used for storing the results of expensive function calls and returning the cached result when the same inputs occur again (sound familiar? 👀).

Let's break it down with an example. Consider the following expensive function:

const getPhrase = (phraseType) => {
  let i = 0;
  // Added to simulate an expensive function
  while (i < 1000000000) i++;

  if (phraseType === "greeting") {
    return "hello";
  } else {
    return "goodbye";
  }
};

In this example, I've added a while loop to simulate an expensive function. It could be replaced with any other computationally intensive task, such as making a call to an API that returns a large amount of data.

Now, let's apply this to a React component.

You can find the code here.

When you choose "Preview" in the top-right corner, you can see the component in action.

Try clicking the "Increment" button rapidly. Notice that it's slow to update the counter value. This slowness is caused by the expensive function being called on every re-render of the component. We can address this performance issue using useMemo.

Check out the updated code here.

Now, if you use the "Increment" button, it responds instantly.

Let's analyze what we have learned from memoization and apply it to the useMemo hook.

Here's the key change between the slow and fast examples:

const greeting = useMemo(() => getPhrase(type), [type]);

As we know from memoization, it's an optimization technique that stores the results of expensive function calls and returns the cached result when the same inputs occur again.

useMemo accepts two arguments. The first argument is a function that you want to apply memoization to, and the second argument is a dependency array. The function itself is self-explanatory: in our case, we want to apply useMemo to getPhrase since it's an expensive function.

The dependency array might sound more complex than it actually is. If the values provided in the dependency array change, our expensive function will be executed again. However, if they don't change, React will use the cached result instead of re-running the function to obtain a new result (which explains the performance increase in the above example).

Consider the following example where we have added the counter to the dependency array. Now, as expected, our component becomes slow again because the counter variable changes, causing the component to re-render.

Check out the example here.

That's all for useMemo. By now, you should have a strong understanding of memoization and knowledge of how and where to use the useMemo hook to achieve performance gains.

useCallback

Now that you understand useMemo, let's move on to useCallback. useCallback is similar to useMemo, as it also accepts two arguments: a function and a dependency array.

useCallback(() => someFunction(), [someDependency]);

However, instead of caching the return value of the function, useCallback caches the function instance itself, preserving the same instance until one of the dependencies changes.

Let's break it down with an example. Below is a React component with two click handlers and a counter that tracks the number of new functions created in the component.

Check out the code here.

Each click of the "Increment" button creates two new functions per render. This example demonstrates the behavior without useCallback. Keep in mind that this is just to showcase what useCallback does; it may not necessarily be the best approach in this specific case.

Now, check out the updated code here

after applying useCallback. Click the buttons, and you'll notice that no extra functions are created per render.

In my opinion, the primary use case for useCallback is when you're using a function as a dependency for another hook. Although there are other use cases, I find them to be rare. Take the following code as an example:

function MyApp() {
  const memoizedFoo = useCallback(function foo() {
    // do something with state or props data
  }, [/* related state/props */]);

  useEffect(() => {
    // do something with memoizedFoo
    // maybe fetch data from an API and pass it to memoizedFoo
    memoizedFoo();
  }, [memoizedFoo]);

  return <>...</>;
}

You can find an example here (thanks 🥰).

Without useCallback, this useEffect would execute on every re-render and ignore the dependency of memoizedFoo. As shown in the previous examples, functions are recreated on each re-render, which is NOT desirable. However, useCallback prevents this by using the memorized instance of the memoizedFoo function.

It's worth mentioning that it's not always the best approach to use useCallback for all your functions, although it might be tempting to do so. Kent C Dodds wrote an excellent blog post about when to use and when not to use useMemo and useCallback. You can check it out here.

Microrepos vs. Monorepo: Understanding the Differences 🥷🏻

Luke Brannagan — Sun, 25 Jun 2023 15:29:35 +0000

Welcome to this blog post where we'll explore the differences between Microrepos and Monorepo. As I delve into the topic, I'll solidify my knowledge and share valuable insights with you. So, let's embark on this journey together!

Microrepos

Let's begin by understanding what a Microrepo is. Essentially, a Microrepo refers to a specific service of an application that has been separated from other services. These services work together to create a unified application, rather than existing as standalone repositories.

While examining Microrepos, we uncover some intriguing benefits:

Pros

Clear separation: Each microservice resides in its own repository, ensuring distinct boundaries between services.
Independent deployment: Microservices can be deployed individually, enabling faster release cycles and reducing dependencies between services.
Autonomy: Each team responsible for a microservice has full control over its development, testing, and deployment processes.
Flexibility: Different services can use diverse technologies or programming languages based on their specific requirements.

However, alongside these benefits, some challenges also arise:

Cons

Increased complexity: Managing multiple repositories for each microservice introduces additional complexity in terms of repository organization, version control, and dependency management. It requires careful coordination and may demand a more sophisticated tooling setup.
Communication and coordination overhead: With Microrepos, different development teams may work on separate repositories, potentially leading to communication and coordination challenges. Synchronizing changes and ensuring compatibility between microservices can become intricate, necessitating effective collaboration and communication channels.
Deployment and testing overhead: Deploying and testing multiple microservices individually can be more time-consuming and resource-intensive compared to a monolithic deployment. Ensuring the compatibility and integration of all services during the deployment process may require additional effort and thorough testing procedures.
Dependency duplication: Each microservice typically has its own set of dependencies. With Microrepos, there is a possibility of duplicated dependencies across different repositories. This can result in increased storage requirements and potential difficulties in managing and updating dependencies consistently.

Monorepo

Now, let's shift our focus to Monorepo, which stands in stark contrast to Microrepos. In a Monorepo, the entire code base is stored within a single repository, along with all related dependencies.

Let's explore the advantages of a Monorepo:

Pros

Centralized codebase: All the code for an application is stored in a single repository, making it easier to manage and maintain.
Shared dependencies: Components and libraries can be shared among different parts of the application, promoting code reuse.
Consistent development environment: Developers have a unified view of the entire codebase, facilitating collaboration and enabling consistent testing and debugging.
Simplified refactoring: When making changes that span multiple services, refactoring and maintaining consistency becomes easier within a Monorepo.

However, Monorepos also present some challenges:

Cons

Increased repository size: With a Monorepo, the entire codebase is stored in a single repository, which can lead to a significant increase in its size over time. Large repositories can impact the performance of version control systems and make cloning or updating the repository time-consuming.
Coupling of components: In a Monorepo, all components of an application are tightly coupled within the same repository. Changes made to one component can potentially impact other components, making it essential to exercise caution and thorough testing when modifying shared code or dependencies.
Build and test times: As the codebase grows, the build and test times for the entire Monorepo can increase. Even small changes may trigger full rebuilds and retesting processes for the entire application, leading to longer development cycles and slower feedback loops.
Limited technology flexibility: In a Monorepo, all components of the application

share the same technology stack and dependencies. This can limit the flexibility of choosing different technologies or programming languages for specific components or services, which may be necessary for certain use cases or teams with different expertise.

Collaboration challenges: With a Monorepo, all developers work within the same repository, potentially leading to conflicts and challenges when multiple developers make changes simultaneously. Resolving merge conflicts can be time-consuming and requires effective coordination and communication among team members.
Security risks: In a Monorepo, access controls and permissions need to be carefully managed to ensure that only authorized individuals have access to sensitive parts of the codebase. Misconfigurations or lapses in access control can pose security risks and potentially expose the entire codebase to unauthorized access.

Summary

Clearly, both Microrepos and Monorepo have their pros and cons, and choosing the right approach depends on the specific context of the application you're building.

Opinionated Perspective

As a front-end developer, I personally lean towards favoring the use of Microrepos more often. The flexibility and independent releases offered by Microrepos are powerful advantages compared to the typical Monorepo structure. However, it's important to address concerns related to excessive service splitting, which can be avoided through careful consideration and strong collaboration within the team. Each decision to split services should account for the additional overhead it introduces to the entire application, including testing, releases, and other factors.

❗️ A really good read about over sharding can be found here

with the recent split from amazon prime video going from microservices -> monorepo

Now that we have explored the nuances of Microrepos and Monorepo, you can make an informed decision based on your project requirements and trade-offs.

WTF is HAL (Hypertext Application Language)

Luke Brannagan — Sun, 25 Jun 2023 14:02:31 +0000

So you've found yourself making decisions about an API, and are interested in Hypertext Application Language.

So I'm writing this specific blog post to learn as we go along, so come along for the journey. I hope you enjoy it!

The Background
How do I use HAL

TL;DR: Hypertext Application Language (HAL) is a convention for defining hypermedia links within JSON or XML code. It simplifies API development by making APIs more discoverable and allowing easy interaction using JSON or XML. HAL uses a special media type (application/hal+json or application/xml+json) to indicate its usage. It facilitates linking resources, such as books and authors, by including _links objects. These links can be used to navigate between resources and perform actions. HAL offers a minimal impact approach and enables the creation of general-purpose libraries for APIs.

You can customize the table of contents based on the headings and sections in your document. Simply replace the example headings and section links with your own.

The Background

Let's start off with Wikipedia's definition of what Hypertext Application Language is:

Hypertext Application Language (HAL) is a convention for defining hypermedia such as links to external resources within JSON or XML code. It is documented in an Internet Draft (a "work in progress"), however, the latest version of HAL Internet-Draft expired on November 12, 2016. The standard was initially proposed in June 2012 specifically for use with JSON[1] and has since become available in two variations, JSON and XML. The two associated MIME types are media type: application/hal+xml and media type: application/hal+json.

HAL was created to be simple to use and easily applicable across different domains by avoiding the need to impose any requirements on how the project be structured. Maintaining this minimal impact approach, HAL has enabled developers to create general-purpose libraries which can be easily incorporated on any API that uses HAL.

APIs that adopt HAL simplify the use of open source libraries and make it possible to interact with the API using JSON or XML. The alternative would be having to develop a proprietary format which in turn forces developers to learn how to use yet another foreign format.

source

From this point on, Hypertext Application Language will be referred to as HAL.

So, to unpack that and to make it easier to read, here is my interpretation of this:

HAL is used to handle links across your API and make your API more discoverable.
HAL can be used for both internal routes as well as routes external to your application, despite being only mentioned here as external.
HAL has a special media type application/hal+json or application/xml+json. This should be used to let clients of your API know that you are using HAL.

How do I use HAL?

Let's start with an example of a bookstore.

Endpoint: GET /books/{bookId}

Response:

{
  "id": "1",
  "title": "The Hobbit",
  "genre": "Fantasy",
  "author": {
    "id": "1",
    "name": "J.R.R. Tolkien",
    "_links": {
      "self": {
        "href": "/authors/1"
      }
    }
  },
  "_links": {
    "self": {
      "href": "/books/1"
      }
  }
}

When you send a GET request to retrieve information about a specific book with the ID 1, the API responds with the book's details, including its title, genre, and the author associated with it. The response follows the HAL format. The book resource includes a link to the author's resource using the _links object, where the self link points to the URL for the author resource.

Endpoint: GET /authors/{authorId}

Response:

{
  "id": "1",
  "name": "J.R.R. Tolkien",
  "books": [
    {
      "id": "1",
      "title": "The Hobbit",
      "_links": {
        "self": {
          "href": "/books/1"
        }
      }
    },
    {
      "id": "2",
      "title": "The Lord of the Rings",
      "_links": {
        "self": {
          "href": "/books/2"
        }
      }
    }


  ],
  "_links": {
    "self": {
      "href": "/authors/1"
    }
  }
}

When you send a GET request to retrieve information about a specific author with the ID 1, the API responds with the author's details, including their name and the books they have written. The response follows the HAL format. The author resource includes a list of books, each represented as a separate object with its own _links object. These links point to the URLs for the respective book resources.

`_links`

The _links key can include a wide array of keys. In the book example, we could add a "next" key to show the next book in the series or even a "prev" to show the previous book in the series.

It's also a great place to link together actions. For example, editing a book would now include:

{
  "id": "1",
  "title": "The Hobbit",
  "_links": {
    "self": {
      "href": "/books/1"
    },
    "next": {
      "href": "/books/2"
    },
    "edit": {
      "href": "/books/2/edit"
    }
  }
}

DEV Community: Luke Brannagan

Learning in 2025: How I Stopped Consuming and Started Understanding

The Risk of Modern Learning

Why I Dislike “Build X From Scratch” Videos

My Process for Learning Anything

How to Know You’re Actually Learning

Final Thoughts

🫖 Thinking in patterns not features

An Example

❌Imperative solution

🧩 Pattern Version

Mastering Project Governance: Achieving Codebase Excellence and Consistency (Frontend)

Table of Contents

Why should you care about Project Governance?

A Linter

RFC

Husky

Plop

Getting started with Pact and Consumer Driven Contract Testing

Table of Contents

What is Pact?

What are Consumer Driven Contracts?

What's a consumer?

What's a provider?

What's a contract (or pact)?

How does the testing theory work?

Setting Up

Summary

🔥 Hot Take: If you're not using Storybook you're doing FE Development wrong.

Why

How

"Storybook takes me longer to implement components" – I'm here to say it does not.

Let's talk about Autodocs because it's too awesome to leave out

Why would I not use Storybook?

Summary

Accessibility - Getting started / Quick wins

Aria Labels

Interactive elements

Landmark elements

Elements with explicit widget role

Examples of using aria-label

Keyboard Accessibility

Semantic HTML

ARIA Landmarks

Conclusion

useCallback and useMemo: Understanding Performance Hooks.

Memoization

useMemo

useCallback

Microrepos vs. Monorepo: Understanding the Differences 🥷🏻

Microrepos

Monorepo

Summary

WTF is HAL (Hypertext Application Language)

Table of Contents

The Background

How do I use HAL?

_links

Examples of using `aria-label`

`_links`