DEV Community: Adrian Knapp

How a Real-World Problem Led Me to Become an Open Source Contributor to the World's Most Popular HTTP Client

Adrian Knapp — Tue, 03 Jun 2025 01:12:52 +0000

Introduction

Sometimes, a real-world problem at work can lead you to unexpected places. In my case, it started with a limitation in Axios and Next.js, led to the creation of a new HTTP client (Traxios), and ended with me becoming an official open-source contributor to Axios—the world's most popular HTTP client.

The Origin: Traxios and a Real-World Problem

When Next.js 13 introduced new capabilities to the native fetch API, it broke the way we used Axios at Tractian. Axios didn't support the new fetch options like cache and next, which are essential for advanced caching and revalidation in Next.js.

To keep our developer experience and productivity high, I built Traxios from scratch—a lightweight HTTP client with an Axios-like API, but powered by the native fetch API and fully compatible with Next.js features.

Want to know more about this journey? Check out my article on building Traxios.

The Axios Update: A Partial Solution

Months after Traxios was born, Axios released an update that introduced the fetchOptions property (commit a3ff99b). This allowed developers to pass native fetch options directly to Axios requests, finally making it possible to use features like cache and revalidate with Next.js.

Problem solved? Not quite.

The new fetchOptions property was typed as Record<string, any>. This meant you could pass any value, but you lost all the benefits of TypeScript: autocomplete, type safety, and documentation. For teams that rely on TypeScript and care about developer experience, this was a significant gap.

My Contribution

As a TypeScript enthusiast, I knew this could be improved. I wanted developers to have the same great experience with fetchOptions as they do with the rest of Axios.

So, I opened a pull request to the official Axios repository, updating the type of fetchOptions to use the native RequestInit interface (omitting properties Axios already handles):

fetchOptions?: Omit<RequestInit, 'body' | 'headers' | 'method' | 'signal'> | Record<string, any>;

This small change made a big difference:

Autocomplete in your IDE
Type safety and documentation
A smoother experience for anyone using Axios with Next.js or fetch

Here's a before/after of the developer experience:

Before:

No autocomplete, no type safety.

After:

Full autocomplete and type safety for all native fetch options.

Conclusion

Sometimes, the best open source contributions come from real-world needs. If you spot something that can be improved, don't hesitate to contribute—you might end up helping a lot more people than you think.

Curious about how this all started? Read my article on building Traxios from scratch.

How Next.js 13 Made Me Rethink Axios and Build Traxios: Creating an HTTP Client from Scratch for Tractian

Adrian Knapp — Mon, 02 Jun 2025 22:52:20 +0000

Introduction

When Next.js 13 introduced new capabilities to the native fetch API, it broke the way we used Axios in our web projects at Tractian. This is the story of how I identified the problem, led the creation of a new HTTP client—Traxios—and how this decision positively impacted our team and delivery.

Situation

At Tractian, our web team relied heavily on Axios for all HTTP requests. Axios provided a familiar, ergonomic API, interceptors, and instance management, making it a staple in our codebase. However, with the release of Next.js 13, the native fetch API was extended with new options like cache and next, enabling advanced caching and revalidation strategies crucial for modern SSR/SSG applications.

Unfortunately, Axios did not support these Next.js-specific fetch options. Using Axios meant losing out on powerful Next.js features, while switching to the native fetch API would require significant refactoring and loss of developer productivity due to its less friendly interface.

Task

The challenge was clear:
How could we keep the developer experience and productivity of Axios, while leveraging the new fetch capabilities introduced by Next.js 13?

I needed to provide a solution that:

Preserved the familiar Axios-like API for the team.
Allowed full use of Next.js's fetch enhancements (e.g., cache, revalidate).
Minimized disruption and learning curve for ongoing and future projects.
Centralized and standardized HTTP logic for maintainability and scalability.

Action

After discussing the problem with stakeholders and the team, I proposed building a new HTTP client from scratch—Traxios—inspired by Axios but powered by the native fetch API.

Key Steps:

Designing the API:
I modeled Traxios's API to closely resemble Axios, including support for instances, interceptors, and typed responses, so the team could transition with minimal friction.
Leveraging TypeScript:
The client was built with TypeScript from the ground up, ensuring type safety and a great developer experience.
Supporting Next.js Features:
Traxios passes all configuration options directly to fetch, including Next.js-specific options like cache and next, unlocking the full power of the framework.
Maintaining Familiar Patterns:
I implemented request/response interceptors and instance creation, so existing patterns and middleware could be reused.
Documentation and Onboarding:
I wrote clear documentation and migration guides, and provided support to the team during the transition.

Example Usage

import { traxios } from 'traxios'

// Creating an instance with Next.js-specific options
const api = traxios.create({
  baseUrl: 'https://api.example.com',
  cache: 'force-cache',
  next: { revalidate: 3600 }
})

// Making a GET request
api.get('/data').then(response => {
  console.log(response.data)
})

Result

The introduction of Traxios had a significant positive impact on our team and projects:

Seamless Migration:
The team was able to migrate from Axios to Traxios with minimal code changes, thanks to the familiar API.
Full Next.js Compatibility:
We could now leverage all the advanced fetch features in Next.js 13+, improving our caching strategies and overall app performance.
Increased Productivity:
Developers continued to use interceptors, instances, and other patterns they were used to, without having to learn the quirks of the native fetch API.
Centralized HTTP Logic:
All HTTP requests were standardized, making the codebase easier to maintain, test, and evolve.
Faster Feature Delivery:
With the right tools in place, our team delivered new features and improvements faster, without being blocked by technical limitations.

Conclusion

Building Traxios was not just a technical solution—it was a strategic move that empowered our team to keep moving fast, adopt new platform features, and maintain high code quality.

Note: Traxios is a private, proprietary solution developed for Tractian, and the code is not publicly available.

And you, how did you handle this challenge with the latest versions of Next.js?
Share your experience or thoughts in the comments!

Managing Application State with Custom Events in React: A Simple Yet Powerful Approach

Adrian Knapp — Fri, 31 Jan 2025 22:35:21 +0000

When building React applications, managing state across components can become challenging. While solutions like Context API, Redux, or Zustand are popular choices, there's a simpler native browser feature we can leverage: Custom Events.

What are Custom Events?

Custom Events are part of the native Browser Event API that allows you to create and dispatch custom events throughout your application. They provide a lightweight, decoupled way to communicate between components without prop drilling or complex state management libraries.

Why Use Custom Events?

Native Browser API - No additional dependencies are required.
Decoupled Communication - Components can communicate without direct relationships.
Simple Implementation - Easy to set up and maintain.
Performance - Lightweight alternative to global state management.
Type Safety - Can be fully typed with TypeScript.

Implementation Example

Let's look at a practical example of implementing a modal system using Custom Events.

1. Define Your Custom Events
First, create an interface to define your custom events:

export interface CustomEvents {
  'modal-event': {
    action: 'open' | 'close'
  }
}

2. Create a Trigger Function
Create a helper function to dispatch custom events:

export const triggerCustomEvent = <EventName extends keyof CustomEvents>(
  eventName: EventName,
  data: CustomEvents[EventName]
) => {
  const event = new CustomEvent(eventName, { detail: data })
  document.dispatchEvent(event)
}

3. Create a Custom Hook
Create a hook to listen for custom events:

export function useEventListener<T extends keyof CustomEvents>(
  eventName: T,
  handler: (detail: CustomEvents[T]) => void
) {
  useEffect(() => {
    const eventHandler = (event: CustomEvent<CustomEvents[T]>) => {
      handler(event.detail)
    }

    document.addEventListener(eventName, eventHandler as EventListener)
    return () => {
      document.removeEventListener(eventName, eventHandler as EventListener)
    }
  }, [eventName, handler])
}

Usage Example

Here's how to implement a modal system using Custom Events:

Triggering the Modal:

const handleOpenModal = () => {
  triggerCustomEvent('modal-event', { action: 'open' })
}

Modal Component:

export const FeedbackModal: React.FC = () => {
  const [isOpen, setIsOpen] = useState(false)

  useEventListener('modal-event', ({ action }) => {
    switch (action) {
      case 'open':
        setIsOpen(true)
        break
      case 'close':
        setIsOpen(false)
        break
    }
  })

Real-World Benefits

Let's examine a practical scenario where Custom Events shine. In our example application, we have three separate components (Header, Content, and Footer) that all need to trigger the same modal:

export default function Home() {
  return (
    <div>
      <Header />
      <Content />
      <Footer />
      <FeedbackModal />
    </div>
  )
}

Instead of:

Lifting state up to a common parent
Using Context API
Implementing a state management library
Prop drilling

We simply:

Define our custom event
Trigger it from anywhere
Listen for it where needed

Best Practices

Type Safety: Always define your custom event interfaces
Event Naming: Use clear, descriptive event names
Cleanup: Always remove event listeners in useEffect cleanup
Payload Structure: Keep event payloads simple and well-defined

When to Use Custom Events

Custom Events are particularly useful when:

Components need to communicate across different parts of the application
You want to avoid prop drilling
You need a lightweight alternative to global state management
Components need to react to actions without direct relationships

When Not to Use Custom Events

Consider alternatives when:

You need persistent state
You require state synchronization across multiple tabs
You need to handle complex state logic
You need to track state history

Conclusion

Custom Events provides a simple, powerful way to handle component communication in React applications. While they might not replace full-state management libraries for complex applications, they offer a lightweight solution for many common scenarios.

The beauty of this approach lies in its simplicity and use of native browser features. It's a reminder that sometimes the best solutions are the ones built into the platform itself.

This implementation demonstrates how we can leverage browser APIs to create clean, maintainable code without unnecessary dependencies. The full example code is available in the provided repository, showing how Custom Events can elegantly solve cross-component communication challenges.

Repo: https://github.com/AdrianKnapp/custom-events
Try it out: https://custom-events-iota.vercel.app/

The best artificial intelligence for developers

Adrian Knapp — Sun, 21 Apr 2024 17:45:46 +0000

Artificial intelligence (AI) has revolutionized many sectors, and software development is no exception. With the ability to automate complex tasks and offer deep insights, AI is becoming an indispensable tool for developers around the world. As technology advances, integrating AI solutions into programmers' daily lives not only optimizes workflow, but also opens up new possibilities for innovation and efficiency. In this context, exploring and choosing the most suitable AI tool becomes crucial to maximizing the benefits of this transformative technology. For a few weeks, I spent time each day testing and experimenting with different options that are currently on the rise in the market, and in this article, I bring you the results of that study, in order to decide which tool adds the most value to a developer's day-to-day life.

The tools chosen were: Perplexity AI, Cursor.sh and Phind. Based on the following criteria:

Internet connection and real-time articles;
Specific use for programming and code generation;
Possible integration with IDEs;

Here is a brief summary of each of the tools:

Phind:

Phind stands out as a search engine integrated with AI, created especially for developers. This tool offers advanced support for coding, debugging and understanding programming concepts, integrating effectively with the Internet and users' code bases to ensure contextual relevance.

Perplexity AI:

Perplexity AI is an AI-chatbot based search and conversation engine that answers queries using predictive text in natural language. It generates answers using web sources and cites links in the text response. It is designed to provide accurate and comprehensive answers, which makes it suitable for research-oriented tasks.

Cursor.sh:

Cursor.sh is a tool that integrates AI into the coding environment, designed specifically to improve the coding workflow. It is a fork of VSCode, with built-in AI, which makes it familiar to VSCode users.

So, each offers its own benefits, strengths and trade-offs, let's understand these better:

Phind:

Strengths

Developer-centric: tailored specifically for developers, providing precise solutions and insights into coding problems.
Generative AI navigation: offers code snippets and technical solutions, increasing productivity in software development.
Customizable search modes: allows users to refine their search to obtain more efficient information.
Free tool: accessible without the need to create an account, which makes it easy for developers to start using it straight away.

Trade-offs

Coding-focused: Designed primarily for coding-related queries, which may limit its usefulness for broader search tasks
Limited to programming languages: its effectiveness is limited to the programming domain and may not help with general productivity tasks outside of software development.

Perplexity AI

Strengths

Precise answers: provides comprehensive answers to complex queries, extracted from a vast set of data in various domains.
Context awareness: provides relevant and informative answers by understanding the context of queries.
Versatility: Assists various professionals, including programmers, in tasks such as answering questions, generating texts and summarizing texts.
Free version available: provides basic search functionality and all search modes free of charge, making it accessible to casual users.

Trade-offs

Limited to research and information gathering: While excellent for research, it may not directly help with code generation or debugging.
Dependence on web sources: Depends on web sources for information, which may not always be up to date with the latest programming practices or solutions.

Cursor

Strengths

Seamless integration with VSCode: Offers a familiar environment for developers already using VSCode, with additional AI features.
Coding assistance with AI technology: Offers features such as code generation, debugging assistance and much more, directly in the coding environment.

Trade-offs

Limited information available: There is less detailed public information about the full features and specific characteristics of Cursor.sh compared to Perplexity AI and Phind.
Requires familiarity with VSCode: best suited to users already familiar with VSCode, which can present a learning curve for others.

Since each tool has its own peculiarities, I kept the same level of testing between them and came to the following conclusion:
Perplexity AI: excellent for everyday tasks, creation of creative material. It replaces Google very well in terms of search. In addition to the more humanized interface, it is possible to formulate different types of interactions through questions and answers.
Phind: works very well when it comes to code. The memory of Phind-70B, Phind's artificial intelligence, is excellent and stands out compared to the other options. In addition, its "chat" option offers more human contact with the technology, and its extension, which can be easily integrated with VSCode, adds much more value to the tool, offering real-time debugging and agility in development.
Cursor.sh: despite its simplicity, its Copilot++ is excellent and offers extremely useful suggestions that save a lot of time with chrono-jobs and repetitive tasks. However, its integrated chat with GPT-4, although it works very well with the context of all the code, isn't that useful and doesn't add that much value. Phind, for example, already offers this through its extension.

In conclusion, by understanding the purpose of each tool, it can be seen that each one has its advantages and works best according to the demand offered. However, for the day-to-day work of a software developer, Phind becomes the most efficient alternative, since its way of dealing with codebases and sources on the web is more efficient when it comes to suggesting code snippets and debugging, making it the most cost-effective tool on the market today. In other words, if you have to choose one option, Phind is the alternative that stands out the most.

In addition, as a personal recommendation, Perplexity AI is extremely effective for day-to-day use when the subject is not directly code and programming, such as basic searches that would be done on Google, for example. Therefore, I see the Perplexity AI + Phind combo as an excellent combination when the intention is to increase productivity and achieve better results.

And you, which tool do you use most on a day-to-day basis and do you recommend we try out? And if you've already used any of the tools mentioned in this article, what's your opinion? Share it with us in the comments.

React: O que é, e como funciona um Compound Component?

Adrian Knapp — Sun, 26 Feb 2023 22:57:35 +0000

Recentemente encontrei um desafio no trabalho: A ideia seria criar um componente Stepper, onde os métodos do componente precisavam ser compartilhados, e acessados de forma externa. A questão é como, e qual a forma mais efetiva? É aí que os Compound Components entram (mas eu só fui saber disso após tentar algumas outras coisas).

A ideia é ter um ou mais componentes que trabalham juntos para atingir um objetivo. Normalmente, um componente é o pai, e os outros são os filhos. Com o intuito de prover uma API mais flexível e expressiva.

Algo como o <select> e <option>:

<select>
  <option value="option1">label1</option>
  <option value="option2">label2</option>
  <option value="option3">label3</option>
</select>

Caso você tente usar um sem o outro, não irá funcionar. Agora vamos imaginar caso não tivéssemos uma API de compound components para trabalhar. (E lembre, isso é apenas HTML, não JSX).

<select options="option1:label1;option2:label2;option3:label3"></select>

Claro que há algumas outras formas de imaginar isso, mas enfim. E como você expressaria o atributo disabled em uma API como essa? As coisas complicam.

Já os compound components, disponibilizam uma boa forma de conectar e interagir entre componentes.

Outro ponto importante sobre esse conceito de "estado implícito": O <select>, implicitamente armazena o estado da opção selecionada e compartilha isso com seus childrens, sendo renderizado da forma correta dependendo desse estado. Mas isso está implícito e não conseguimos ter acesso em nosso HTML.

Em minhas tentativas de tentar criar o componente Stepper, minha primeira abordagem foi através de Render Props, onde o componente <Stepper>, disponibiliza propriedades para o children, permitindo manipular os steps.

const Stepper = ({ children, initial = 0 }) => {
  const [active, setActive] = useState(initial);

  const nextStep = () => {
    if (active < children().props.children.length - 1);
      setActive(active + 1);
  };

  const prevStep = () => {
    if (active > 0) setActive(active - 1);
  };

  return (
    <div data-cid="stepper">
      {
        children({
          nextStep,
          prevStep,
          setActive,
          active
        }).props.children[active]
      }
    </div>
  );
};

E esse seria um exemplo de uso:

const steps = ["Step 1", "Step 2", "Step 3"];

const App = () => {
    return (
        <Stepper>
          {({ nextStep, prevStep, active }) => (
            <>
              {steps.map((step) => (
                <div key={step} id="step">
                  <p>{step}</p>
                  <button onClick={prevStep}>Prev Step</button>
                  <button onClick={nextStep}>Next Step</button>
                </div>
              ))}
            </>
          )}
        </Stepper>
    );
}

Porém, ao pesquisar um pouco mais, encontrei alguns conteúdos, e o que mais me chamou atenção, foi um artigo do Kent C. Dodds , que explica e soluciona isso através da Context API do React, entregando os métodos via Hooks. Tornando esse o uso:

import React, {
  createContext,
  useCallback,
  useContext,
  useMemo,
  useState
} from "react";
import CommonStep from "../CommonStep";

const StepperContext = createContext(null);

type StepperContextModel = {
  nextStep: () => void;
  prevStep: () => void;
  setActive: (index: number) => void;
  active: number;
};

type StepperProps = {
  children: JSX.Element[];
};

const Stepper = ({ children }: StepperProps) => {
  const [active, setActive] = useState(0);

  const nextStep = useCallback(() => {
    if (active < children.length - 1) setActive(active + 1);
  }, [active, children]);

  const prevStep = useCallback(() => {
    if (active > 0) setActive(active - 1);
  }, [active]);

  const value: StepperContextModel = useMemo(
    () => ({
      nextStep,
      prevStep,
      setActive,
      active
    }),
    [active, nextStep, prevStep]
  );

  return (
    <StepperContext.Provider value={value}>
      {children[active]}
    </StepperContext.Provider>
  );
};

export const useStepperContext = (): StepperContextModel => {
  const context = useContext(StepperContext);

  if (!context) {
    throw new Error(
      `Stepper compound components cannot be rendered outside the Stepper component`
    );
  }

  return context;
};

const Step = ({ children }) => {
  const { nextStep, prevStep, active } = useStepperContext();

  return (
    <CommonStep nextStep={nextStep} prevStep={prevStep} active={active}>
      {children}
    </CommonStep>
  );
};

Stepper.Step = Step;

export default Stepper;

E esse, um exemplo de uso:

const steps = ["Step 1", "Step 2", "Step 3"];

const App = () => {
    return (
        <Stepper>
            {steps.map((step) => (
                <Stepper.Step>
                    <p>{step}</p>
                </Stepper.Step>
            ))}
        </Stepper>
    );
}

Exemplo dos componentes em ação: https://codesandbox.io/s/stepper-function-og2bl1
E o repositório: https://github.com/AdrianKnapp/compound-components

Basicamente, funciona por um contexto criado com o React, que armazena o estado e os mecanismos para o atualizarmos. Sendo o <Stepper>, o componente responsável por prover o valor desse contexto para o resto da árvore de elementos.

Muito mais simples, não? Porém, cada alternativa tem suas vantagens e casos de uso. Tendo utilidade em muitos cenários, não só em um Stepper, por exemplo.

Espero que esse conteúdo ajude você a solucionar futuros problemas, e que gere novas ideias na hora de criar componentes, criando APIs mais expressivas e efetivas.

Esse artigo foi baseado e inspirado em um post do Kent C. Dodds, feito em seu blog. Acesse em: https://kentcdodds.com/blog/compound-components-with-react-hooks