DEV Community: Dominik D

Why React isn't dying

Dominik D — Tue, 31 Jan 2023 13:34:42 +0000

Last Thursday, I took part in the State of React Ecosystem panel discussion, where we mainly talked about one question: "Is React dying" ? I couldn't finish my train of thought due to a StreamYard outage, so I thought I'd follow this up with a blogpost. So, why would React be dying?

Twitter bubble

There's a bit of fuzz, mainly on Twitter, about React dying and other libraries being better than React, and that you're doing something wrong or missing out if you're choosing React right now.

The truth is, my bubble consists of very smart people, library authors, maintainers and tech influencers who love to live on the bleeding edge, where you constantly have to be on the lookout for the next big thing. In that world, you see everything through a different lens - one that is more focussed on the future than the status quo. It is only natural that you see lots of push and innovation in that space. Things are pronounced dead way before they really are, and I think it's no different this time.

To understand why React is here to stay, we have to look back a bit:

Looking back

React has been around for almost 10 years now, and it has pioneered so many things that we now take for granted. This includes the two biggest reasons why I think react has "won" in the first place: Component Driven Development and JSX - two things that most new tech now embraces as well.

Also, React gave us a predictable way to render our UI. Before that, everything we used was a mess (compared to today's standards). We had the choice to either update the DOM manually in an imperative spaghetti mess (jQuery 👀) or wrestle with two-way data binding and a weird templating syntax (👋 angular).

So React allowed us to abstract our UI into components and couple functionality (JS) with markup (HTML) in a declarative, reusable way. This was revolutionary at the time. When it came out, lots of people jumped ship rather fast (me included), because React was so much better than the given alternatives.

New horizons

The new kids on the block now try to take the good parts of React and use that to invent something that doesn't have its drawbacks. Things usually cited are performance, virtual dom overhead and a generally hard way to interact with the dom directly, e.g. for animations or a11y (refs 😭).

However, being up against the top dog React will be very hard, for two reasons:

Growth loop

Every day, there are so many people just starting out with web development. They look around for what is the best tech to learn right now to get a job. Something that pays the bills and is not terrible to work with. And everything points towards React. Companies have lots of existing React Applications, and are still choosing React for new stuff. It's an easy and safe choice.

On the other hand, companies choose React because that's where all the developers are. If you want to build something that can be maintained years from now, you better not choose the next hype train that goes straight to nowhere (remember CoffeeScript ?). You want something battle tested that has stood the test of time, where you won't have trouble finding developers to scale once you need to. And nobody ever got fired for choosing React.

Ecosystem

It can take years to build a good ecosystem and community. Libraries and Frameworks that come out right now won't have everything figured out immediately. It needs early adopters to figure things out, find and teach patterns and invent community solutions to problems. To grow adoption, a vibrant ecosystem is an absolute necessity.

React is years ahead here. Even critical articles state that they can't quit React because it has the "best community and the best third-party modules".

The TanStack

This is where the TanStack comes in. I really hope that the fact that the TanStack has all packages built in a framework-agnostic way will help adoption of non-React libraries over time. Think about it: If you need to fetch some data, render a table and maybe virtualize it - you can do all of that with the TanStack. And if you know how to do this in React, you also already know how to do it in Solid, Svelte or Vue.

Knowing the concepts is transferable knowledge. And it takes away a bunch of things you'd have to re-learn when moving to a different, newer tech, while retaining the same great developer experience.

Closing thoughts

It's true that there are already solutions out there that are "better than React" in some aspects. More modern, more performant, different paradigms, "really reactive", ...

But to break the growth loop, to get a lot of developers to move over, to build a large community and ecosystem, I think it will need something that's a lot better than React to replace it. Just like React was so much better than the alternatives when it came out.

And we aren't there yet. React is still "good enough" for most things that are built right now, and I don't see that changing in the near future. That doesn't mean finding new tech isn't worth trying. We need innovation. It might happen in React, or it might happen outside of it. Only time will tell.

Actually, both might happen. It's not a given that you have one tech ruling them all. A monopoly is also not something to strive for. Competition helps everyone, especially users. We can already see how the rise of fine-grained reactivity influences existing libs like Preact.

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

It's exciting times for sure - but don't feel that you have to stay on top of the bleeding edge, that you have to learn everything the moment it comes out or that React isn't good enough.

Because it's not dying.

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below. ⬇️

Seeding the Query Cache

Dominik D — Sun, 11 Dec 2022 18:50:38 +0000

A new RFC about first class support for Promises has been released last week, and it got some talk going about how this would introduce fetch waterfalls if used incorrectly. So what are fetch waterfalls exactly?

Fetch waterfalls

A waterfall describes a situation where one request is made, and we wait for it to complete before firing another request.

Sometimes, this is unavoidable, because the first request contains information that is needed to make the second request. We also refer to these as dependent queries:

In many cases though, we can actually fetch all the data we need in parallel, because it is independent data:

In React Query, we can do that in two different ways:

// 1. Use useQuery twice
const issues = useQuery({ queryKey: ['issues'], queryFn: fetchIssues })
const labels = useQuery({ queryKey: ['labels'], queryFn: fetchLabels })

// 2. Use the useQueries hook
const [issues, labels] = useQueries([
  { queryKey: ['issues'], queryFn: fetchIssues },
  { queryKey: ['labels'], queryFn: fetchLabels },
])

In both variants, React Query will kick off data fetching in parallel. So where do waterfalls come in?

Suspense

Note: Please keep in mind that at the time of this writing, suspense for data fetching is still experimental! In the following examples, I will not be using the proposal from the RFC, but rather the suspense implementation that is already available in React Query (which is also experimental).

As described in the above linked RFC, suspense a way to unwrap promises with React. A defining trait of promises is that they can be in three different states: pending, fulfilled or rejected.

When rendering components, we are mostly interested in the success scenario. Handling loading and error states in each and every component can be tedious, and suspense is aimed at solving this problem.

When a promise is pending, React will unmount the component tree and render a fallback defined by a Suspense boundary component. In case of errors, the error is bubbled up to the nearest ErrorBoundary.

This will decouple our components from handling those states, and we can focus on the happy path. It almost acts like synchronous code that just reads a value from a cache:

function Issues() {
  // 👓 read data from cache
  const { data } = useQuery({
    queryKey: ['issues'],
    queryFn: fetchIssues,
    // ⬇️ this enables experimental suspense mode
    suspense: true,
  })

  // 🎉 no need to handle loading or error states

  return (
    <div>
      {data.map((issue) => (
        <div>{issue.title}</div>
      ))}
    </div>
  )
}

function App() {
  // 🚀 Boundaries handle loading and error states
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <ErrorBoundary fallback={<div>On no!</div>}>
        <Issues />
      </ErrorBoundary>
    </Suspense>
  )
}

A note on TypeScript

Sadly, when using TypeScript, data will still be potentially undefined in the above example, as suspense is just a flag on useQuery that can be turned on and off at will. It can also be combined with the enabled option, which will make the query not fire and thus make the component not suspend at all.

We might change this in the future with a dedicated useSuspenseQuery hook.

Suspense waterfalls

So this is nice and all, but it can backfire when you use multiple queries in the same component that have suspense turned on. Here is what happens:

Component renders, tries to read the first query
Sees that there is no data in the cache yet, so it suspends
This unmounts the component tree, and renders the fallback
When the fetch is finished, the component tree is remounted
First query is now read successfully from the cache
Component sees the second query, and tries to read it
Second query has no data in the cache, so it suspends (again)
Second query is fetched
Component finally renders successfully

This will have pretty impactful implications on your application's performance, because you'll see that fallback for waaay longer than necessary.

The best way to circumvent this problem is to make sure that there is already data in the cache when the component tries to read it.

Prefetching

The earlier you initiate a fetch, the better, because the sooner it starts, the sooner it can finish. 🤓

If your architecture supports server side rendering - consider fetching on the server.
If you have a router that supports loaders, consider prefetching there.

But even if that's not the case, you can still use prefetchQuery to initiate a fetch before the component is rendered:

const issuesQuery = { queryKey: ['issues'], queryFn: fetchIssues }

// ⬇️ initiate a fetch before the component renders
queryClient.prefetchQuery(issuesQuery)

function Issues() {
  const issues = useQuery(issuesQuery)
}

The call to prefetchQueries is executed as soon as your JavaScript bundle is evaluated. This works very well if you do route base code splitting, because it means the code for a certain page will be lazily loaded and evaluated as soon as the user navigates to that page.

This means it will still be kicked off before the component renders. If you do this for both queries in our example, you will get those parallel queries back even when using suspense.

As we can see, the query will still suspend until both are done fetching, but because we've triggered them in parallel, the waiting time is now drastically reduced.

Note: useQueries doesn't support suspense right now, but it might do in the future. If we add support, the goal is to trigger all fetches in parallel to avoid those waterfalls.

Update: useQueries supports suspense as of v4.15.0. 🎉

The use RFC

I don't know enough about the RFC yet to properly comment on it. A big part is still missing, namely how the cache API will work. I do think it is a bit problematic that the default behaviour will lead to waterfalls unless developers explicitly seed the cache early on. I'm still pretty excited about it because it will likely make internals of React Query easier to understand and maintain. It remains to be seen if it is something that will be used in userland a lot.

Seeding details from lists

Another nice way to make sure that your cache is filled by the time it is read is to seed it from other parts of the cache. Oftentimes, if you render a detail view of an item, you will have data for that item readily available if you've previously been on a list view that shows a list of items.

There are two common approaches to fill a detail cache with data from a list cache:

Pull approach

This is the one also described in the docs: When you try to render the detail view, you look up the list cache for the item you want to render. If it is there, you use it as initial data for the detail query.

const useTodo = (id: number) => {
  const queryClient = useQueryClient()
  return useQuery({
    queryKey: ['todos', 'detail', id],
    queryFn: () => fetchTodo(id),
    initialData: () => {
      // ⬇️ look up the list cache for the item
      return queryClient
        .getQueryData(['todos', 'list'])
        ?.find((todo) => todo.id === id)
    },
  })
}

If the initialData function returns undefined, the query will proceed as normal and fetch the data from the server. And if something is found, it will be put into the cache directly.

Be advised that if you have staleTime set, no further background refetch will occur, as initialData is seen as fresh. This might not be what you want if your list was last fetched twenty minutes ago.

As shown in the docs, we can additionally specify initialDataUpdatedAt on our detail query. It will tell React Query when the data we are passing in as initialData was originally fetched, so it can determine staleness correctly. Conveniently, React Query also knows when the list was last fetched, so we can just pass that in:

const useTodo = (id: number) => {
  const queryClient = useQueryClient()
  return useQuery({
    queryKey: ['todos', 'detail', id],
    queryFn: () => fetchTodo(id),
    initialData: () => {
      return queryClient
        .getQueryData(['todos', 'list'])
        ?.find((todo) => todo.id === id)
    },
    initialDataUpdatedAt: () =>
      // ⬇️ get the last fetch time of the list
      queryClient.getQueryState(['todos', 'list'])?.dataUpdatedAt,
  })
}

🟢 seeds the cache "just in time"
🔴 needs more work to account for staleness

Push approach

Alternatively, you can create detail caches whenever you fetch the list query. This has the advantage that staleness is automatically measured from when the list was fetched, because, well, that's when we create the detail entry.

However, there is no good callback to hook into when a query is fetched. onSuccess on useQuery would technically work, but it would be executed for every instance of useQuery. If we have multiple observers, this would lead to the same data being written to the cache multiple times. The global onSuccess callback on the cache itself might also work, but it would be executed for every query, so we'd have to narrow it down to the right query key.

The best way I've found to execute the push approach is to do it directly in the queryFn, after data has been fetched:

const useTodos = () => {
  const queryClient = useQueryClient()
  return useQuery({
    queryKey: ['todos', 'list'],
    queryFn: async () => {
      const todos = await fetchTodos()
      todos.forEach((todo) => {
        // ⬇️ create a detail cache for each item
        queryClient.setQueryData(['todos', 'detail', todo.id], todo)
      })
      return todos
    },
  })
}

This would create a detail entry for each item in the list immediately. Since there is no one interested in those queries at the moment, those would be seen as inactive, which means they might be garbage collected after cacheTime has elapsed (default: 15 minutes).

So if you use the push approach, the detail entries you've created here might no longer be available once the user actually navigates to the detail view. Also, if your list is long, you might be creating way too many entries that will never be needed.

🟢 staleTime is automatically respected
🟡 there is no good callback
🟡 might create unnecessary cache entries
🔴 pushed data might be garbage collected too early

Keep in mind that both approaches only work well if the structure of your detail query is exactly the same (or at least assignable to) the structure of the list query. If the detail view has a mandatory field that doesn't exist in the list, seeding via initialData is not a good idea. This is where placeholderData comes in, and I've written a comparison about the two in #9: Placeholder and Initial Data in React Query.

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below. ⬇️

Refs, Events and Escape Hatches

Dominik D — Fri, 30 Sep 2022 20:05:36 +0000

I hope that after reading part one about stale closures in React, you now have a good understanding of why they can occur and how to avoid them.

However, it is sometimes quite cumbersome to have to think about referential stability when passing functions around, and it can also get a bit boilerplate-y with all those additional useCallbacks.

I already left a bunch of clues in the previous article that there might be a way to make this easier, so here we go:

Photoshop

Remember this sentence?

The thing about the picture is - it cannot change. Once we have taken it, its content is sealed (unless we use photoshop).

In React, we almost always think in immutability. Props cannot be changed (from within a component), and state updates are merely scheduled and also need to happen in an immutable way. Everything we see and work with is essentially a const.

We always see the things from the time they were created, but if they are mutated in place, we would still see the latest value. Let's take the basic example from part 1 and store the value in a mutable variable outside the React component:(note: examples are interactive on my blog: https://tkdodo.eu/blog/refs-events-and-escape-hatches)

let count = 1
function App() {
  const rerender = React.useReducer(() => ({}))[1]

  // 😱 logCount is stable, but it still sees
  // the latest value of count
  const logCount = React.useCallback(() => {
    console.log(count)
  }, [])

  return (
    <div>
      <div>count is {count}</div>
      <button
        onClick={() => {
          count++
          rerender()
        }}
      >
        increment
      </button>
      <button onClick={logCount}>log</button>
    </div>
  )
}

Now it's hopefully obvious that this is not how you would work with React. Having a variable outside the component means it's shared between component instances, and React doesn't know about it, which is why we have to manually force our component to re-render.

But it showcases one thing: mutating a variable in place bypasses our mental modal of pictures that cannot change.

Mutations are literally photoshop. They can alter existing images after they have been taken. And what's the React way to hold mutable values? Refs!

Refs

Refs are just bags that can contain an arbitrary mutable value. The ref itself is referentially stable, so we don't have to include it in dependency arrays, and the .current property has the actual value. Refs offer an escape hatch from Reacts one way data flow model, because updates on refs are not going to make your component to re-render. This comes in quite handy if we have to pass functions around, e.g. to custom hooks.

As an example, let's implement a somewhat common use-case of storing a value and triggering a callback after some debounced time:

export const useDebouncedState = (callback, delay) => {
  const [value, setValue] = React.useState('')

  React.useEffect(() => {
    const timeoutId = setTimeout(() => {
      if (value) {
        callback(value)
      }
    }, delay)

    return () => {
      clearTimeout(timeoutId)
    }
  }, [value, delay, callback])

  return [value, setValue]
}

We've added callback to the effect's dependency array as the linter wants, but that has a downside: consumers will need to memoize the function, which is not a very developer friendly interface. Of course, they'll most often just want to use an inline function, without having to care about referential stability:

const [state, setState] = useDebouncedState((value) => {
  alert(value)
}, 1000)

This will potentially run our effect too often, e.g. if the component re-renders for another reason. However, omitting the function from the dependency array is not an option, as it would potentially introduce stale closures.

The latest ref

I first read about a pattern called the latest ref in this article by Kent C. Dodds. The idea is to store the function (our callback) in a ref so that we can omit it from the dependency array. All we then need to do is to make sure that the ref is updated when the function changes, and we can do that with an additional effect:

export const useDebouncedState = (callback, delay) => {
  const [value, setValue] = React.useState('')
  // 👇 store callback in a ref
  const ref = React.useRef(callback)

  // 👇 update the ref when the callback changes
  React.useLayoutEffect(() => {
    ref.current = callback
  }, [callback])

  React.useEffect(() => {
    const timeoutId = setTimeout(() => {
      if (value) {
        // 👇 use the ref instead of the callback
        ref.current(value)
      }
    }, delay)

    return () => {
      clearTimeout(timeoutId)
    }
  // 👇 no need to include the callback
  }, [value, delay])

  return [value, setValue]
}

Admittedly, this does add more boilerplate, but it pays off - especially for libraries or reusable hooks due to the improved developer experience for consumers of the hook. Also, hold on tight because React might actually ship a hook that does this for us in the future:

useEvent

Recently, the React team has worked on an RFC about a dedicated hook for this behaviour called useEvent. The idea is to have a hook that is similar to useCallback, except that it doesn't have a dependency array, but still returns a stable function reference without suffering from stale closure problems.

As pointed out in the new beta docs, those event functions behave a lot more like an event handler (hence the name). The logic inside it is not reactive, and it always sees the latest values of your props and state.

Would that hook exist already, we could rewrite our useDebouncedState hook like this:

export const useDebouncedState = (callback, delay) => {
  const [value, setValue] = React.useState('')

  // 👇 declare the event
  const onTimeout = React.useEvent(callback);

  React.useEffect(() => {
    const timeoutId = setTimeout(() => {
      if (value) {
        // 👇 use the event
        onTimeout(value);
      }
    }, delay);

    return () => {
      clearTimeout(timeoutId);
    };
  // 🎉 no need to include onTimeout
  }, [value, delay]);

  return [value, setValue]
}

This looks pretty clean to me, and if you want to have a user-land implementation of useEvent right now, have a look at this implementation by Diego Haz:

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

You can use it until React ships their own hook, but be aware that you have to include the returned function in the dependency array because unlike the native implementation, the linter cannot know that the function is stable. I personally can't wait until this ships because it will simplify a lot of my code. 🙌

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below. ⬇️

React Query meets React Router

Dominik D — Mon, 12 Sep 2022 19:18:45 +0000

Remix is changing the game, and they are bringing their data fetching concepts (loaders and actions) to purely client side rendered applications with React Router 6.4. At the time of this writing, v6.4 is still in beta, but I went through their great tutorial that shows the concept very well and demonstrates how you can quickly build a small, but feature-rich app.

With React Router coming into the data fetching game, it is naturally interesting to understand how this competes or correlates with existing data fetching and caching libraries like React Query. So let me spoil it right here:

They are a match made in heaven

A router that fetches data

To recap: React Router will allow you to define loaders on each route, which will be called when the route is visited. In the route component itself, you can useLoaderData() to get access to that data. Updating data is as simple as submitting a Form, which will call an action function. Actions invalidate all active loaders, so you'll automagically see updated data on your screen.

If this sounds very similar to queries and mutations - you are right, it does. So the questions that have been popping up after the announcement of Remixing React Router are:

Would we still want React Query now that we can fetch in the route?
If we already use React Query, do we want to (and how can we) leverage the new React Router features?

It's not a cache

To me, the answers to both questions are clearly: YES. As Ryan Florence from the remix team has put it: "React Router is not a cache":

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

Fetching "as early as possible" is an important concept to provide the best possible user experience. Full Stack frameworks like NextJs or Remix move this step to the server, because that is the earliest entry point. With client rendered applications, we have no such luxury.

Fetching early

What we are usually doing is fetching on component mount - when data is first needed. That is not great, as it will lead to a loading spinner visible to the user for as long as we are initially fetching. Prefetching can help, but only for subsequent navigations, and you need to manually set it up for every way to navigate to a route.

The router however is the first component that always knows which page you are trying to visit, and because it now has loaders, it can know which data those pages need to render. This is great for the first page visit - but loaders are called on every page visit. And as the router has no cache, it will hit the server again, unless we do something about it.

As an example (yes, this is from the tutorial mentioned before. Credits go to Ryan Florence), suppose you have a list of contacts. If you click on one of them, you show the contact details:

import { useLoaderData } from 'react-router-dom'
import { getContact } from '../contacts'

// ⬇️ this is the loader for the detail route
export async function loader({ params }) {
  return getContact(params.contactId)
}

export default function Contact() {
  // ⬇️ this gives you data from the loader
  const contact = useLoaderData()
  // render some jsx
}

import Contact, { loader as contactLoader } from './routes/contact'

ReactDOM.createRoot(document.getElementById('root')).render(
  <DataBrowserRouter>
    <Route path="/" element={<Root />}>
      <Route
        path="contacts/:contactId"
        element={<Contact />}
        // ⬇️ pass the loader to the route
        loader={contactLoader}
      />
    </Route>
  </DataBrowserRouter>
)

If you navigate to contacts/1, data for that contact will be fetched before the component is rendered. By the time we want to show the Contact, useLoaderData will have data readily available. This is awesome as it not only improves the user experience, but look at that developer experience of co-located data fetching and rendering! I love it. 🥰

Fetching too often

The big drawback of not having a cache shows when you go to Contact 2 and then back to Contact 1 again. If you are used to React Query, you will know that data for Contact 1 is cached already, so we can show it instantly and kick of a background refetch if data is considered stale. With the loader approach, we will have to fetch that data again (and wait for it to finish fetching!), even though we have already fetched it before.

And that is exactly where React Query comes in.

What if we can use the loader to pre-fill the React Query Cache, but still useQuery in the component to get all the React Query goodies like refetchOnWindowFocus and showing stale data instantly? To me, this sounds like the best of both worlds. The router is responsible for fetching data early (if we don't have it), and React Query is responsible for caching and keeping the data fresh.

Querifying the example

Let's try to move the example in that direction:

import { useQuery } from '@tanstack/react-query'
import { getContact } from '../contacts'

// ⬇️ define your query
const contactDetailQuery = (id) => ({
  queryKey: ['contacts', 'detail', id],
  queryFn: async () => getContact(id),
})

// ⬇️ needs access to queryClient
export const loader =
  (queryClient) =>
  async ({ params }) => {
    const query = contactDetailQuery(params.contactId)
    // ⬇️ return data or fetch it
    return (
      queryClient.getQueryData(query.queryKey) ??
      (await queryClient.fetchQuery(query))
    )
  }

export default function Contact() {
  const params = useParams()
  // ⬇️ useQuery as per usual
  const { data: contact } = useQuery(contactDetailQuery(params.contactId))
  // render some jsx
}

const queryClient = new QueryClient()

ReactDOM.createRoot(document.getElementById('root')).render(
  <QueryClientProvider client={queryClient}>
    <DataBrowserRouter>
      <Route path="/" element={<Root />}>
        <Route
          path="contacts/:contactId"
          element={<Contact />}
          // ⬇️ pass the queryClient to the route
          loader={contactLoader(queryClient)}
        />
      </Route>
    </DataBrowserRouter>
  </QueryClientProvider>
)

There are a couple of things going on here, so let's break it down:

The loader needs access to the QueryClient.

The loader is not a hook, so we can't useQueryClient. Importing the QueryClient directly is something that I'm not recommending, so passing it explicitly seems like the best alternative.

getQueryData ?? fetchQuery

We want the loader to wait for our data to be ready and return it to get a good experience on the first loads. We also want errors to be thrown to the errorElement, so fetchQuery is the best option. Note that prefetchQuery doesn't return anything and catches errors internally (otherwise, they are equivalent).

getQueryData does the trick for returning any data we have in the cache, even if it's stale. This ensures that recurring visits to a page will show data immediately. Only if getQueryData returns undefined (meaning nothing is in the cache), we'll actually do the fetch.

An alternative approach would be to set a staleTime for fetchQuery:

export const loader =
  (queryClient) =>
  ({ params }) =>
    queryClient.fetchQuery({
      ...contactDetailQuery(params.contactId),
      staleTime: 1000 * 60 * 2,
    })

Setting the staleTime to two minutes tells fetchQuery to resolve data immediately if it's available and not older than two minutes, otherwise, it will go and fetch it. If you are fine with stale data not being shown in the component, this is a good alternative.

Setting staleTime to Infinity is almost equivalent to the getQueryData approach, except that manual query invalidation takes precedence over staleTime. So I like the getQueryData approach a bit better, even if it is slightly more code.

A TypeScript tip

With this, it is guaranteed that calling useQuery in the component will have some data available, just like calling useLoaderData would. However, TypeScript has no way of knowing this - the data returned is of type Contact | undefined.

Thanks to Matt Pocock and his contribution to React Query v4, we can now exclude undefined from the union if initialData is provided.

And where would we get initialData from? useLoaderData of course! We can even infer the type from the loader function:

export default function Contact() {
  const initialData = useLoaderData() as Awaited<
    ReturnType<ReturnType<typeof loader>>
  >
  const params = useParams()
  const { data: contact } = useQuery({
    ...contactDetailQuery(params.contactId),
    initialData,
  })
  // render some jsx
}

It's a bit much to write because our loader is a function that returns a function, but we can tuck that away in a single util. Also, it seems that right now, using type assertions is the only way to narrow the return type of useLoaderData. 🤷‍♂️
But it will nicely narrow the type of the useQuery result, which is what we want. 🙌

Invalidating in actions

The next piece of the puzzle involves query invalidation. Here is how an action would look without React Query, straight from the tutorial (yes, this is all it takes to perform an update):

export const action = async ({ request, params }) => {
  const formData = await request.formData()
  const updates = Object.fromEntries(formData)
  await updateContact(params.contactId, updates)
  return redirect(`/contacts/${params.contactId}`)
}

Actions invalidate loaders, but because we've setup our loaders to always return data from the cache, we won't see any updates unless we somehow invalidate the cache. It's just one line of code really:

export const action =
  (queryClient) =>
  async ({ request, params }) => {
    const formData = await request.formData()
    const updates = Object.fromEntries(formData)
    await updateContact(params.contactId, updates)
    await queryClient.invalidateQueries(["contacts"]);
    return redirect(`/contacts/${params.contactId}`)
  }

The fuzzy matching of invalidateQueries will make sure that our list and our detail view will get new data in the cache by the time the action is finished and we're redirecting back to the detail view.

await is the lever

However, this will make our action function take longer and block the transition. Would we not be able to trigger the invalidation, then redirect to the detail view, show the stale data and then let it update in the background once the new data is available? Of course we can: Just leave out the await keyword:

export const action =
  (queryClient) =>
  async ({ request, params }) => {
    const formData = await request.formData()
    const updates = Object.fromEntries(formData)
    await updateContact(params.contactId, updates)
    // ⬇️ no await here
    queryClient.invalidateQueries(["contacts"]);
    return redirect(`/contacts/${params.contactId}`)
  }

Await literally becomes a lever you can pull in either direction (This analogy is based on Ryan's great talk When To Fetch. Please watch it if you haven't already):

Is it important to transition back to the detail view as soon as possible? Do not await.
Is it important to avoid potential layout shifts when showing stale data, or do you want to keep the action pending until you have all new data? Use await.

If multiple invalidations are involved, you can also mix and match the two approaches to wait for important refetches, but let less important ones be done in the background.

Summary

I'm very excited about the new React Router release. It's a great step forward to enable all applications to trigger fetches as early as possible. However, it is not a replacement for caching - so go ahead and combine React Router with React Query to get the best of both worlds. 🚀

If you want to explore this topic some more, I've implemented the app from the tutorial and added React Query on top of it - you can find it in the examples of the official docs.

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below. ⬇️

Avoiding useEffect with callback refs

Dominik D — Sun, 14 Aug 2022 19:10:53 +0000

Note: This article assumes a basic understanding of what refs are in React.

Even though refs are mutable containers where we can theoretically store arbitrary values, they are most often used to get access to a DOM node:

const ref = React.useRef(null)

return <input ref={ref} defaultValue="Hello world" />

ref is a reserved property on build-in primitives, where React will store the DOM node after it was rendered. It will be set back to null when the component is unmounted.

Interacting with refs

For most interactions, you don't need to access the underlying DOM node, because React will handle updates for us automatically. A good example where you might need a ref is focus management.

There's a good RFC from Devon Govett that proposes adding FocusManagement to react-dom, but right now, there is nothing in React that will help us with that.

Focus with an effect

So how would you, right now, focus an input element after it rendered? (I know autofocus exists, this is an example. If this bothers you, imagine you'd want to animate the node instead.)

Well, most code I've seen tries to do this:

const ref = React.useRef(null)

React.useEffect(() => {
  ref.current?.focus()
}, [])

return <input ref={ref} defaultValue="Hello world" />

This is mostly fine and doesn't violate any rules. The empty dependency array is okay because the only thing used inside is the ref, which is stable. The linter won't complain about adding it to the dependency array, and the ref is also not read during render (which might be troublesome with concurrent react features).

The effect will run once "on mount" (twice in strict mode). By that time, React has already populated the ref with the DOM node, so we can focus it.

Yet this is not the best way to do it and does have some caveats in some more advanced situations.

Specifically, it assumes that the ref is "filled" when the effect runs. If it's not available, e.g. because you pass the ref to a custom component which will defer the rendering or only show the input after some other user interaction, the content of the ref will still be null when the effect runs and nothing will be focussed:

function App() {
  const ref = React.useRef(null)

  React.useEffect(() => {
    // 🚨 ref.current is always null when this runs
    ref.current?.focus()
  }, [])

  return <Form ref={ref} />
}

const Form = React.forwardRef((props, ref) => {
  const [show, setShow] = React.useState(false)

  return (
    <form>
      <button type="button" onClick={() => setShow(true)}>
        show
      </button>
      // 🧐 ref is attached to the input, but it's conditionally rendered
      // so it won't be filled when the above effect runs
      {show && <input ref={ref} />}
    </form>
  )
})

Here is what happens:

Form renders.
input is not rendered, ref is still null.
effect runs, does nothing.
input is shown, ref will be filled, but will not be focussed because effect won't run again.

The problem is that the effect is "bound" to the render function of the Form, while we actually want to express: "Focus the input when the input is rendered", not "when the form mounts".

Callback refs

This is where callback refs come into play. If you've ever looked at the type declarations for refs, we can see that we can not only pass a ref object into it, but also a function:

type Ref<T> = RefCallback<T> | RefObject<T> | null

Conceptually, I like to think about refs on react elements as functions that are called after the component has rendered. This function gets the rendered DOM node passed as argument. If the react element unmounts, it will be called once more with null.

Passing a ref from useRef (a RefObject) to a react element is therefore just syntactic sugar for:

<input
  ref={(node) => {
    ref.current = node;
  }}
  defaultValue="Hello world"
/>

Let me emphasize this once more:

All ref props are just functions!

And those functions run after rendering, where it is totally fine to execute side effects. Maybe it would have been better if ref would just be called onAfterRender or something.

With that knowledge, what stops us from focussing the input right inside the callback ref, where we have direct access to the node?

<input
  ref={(node) => {
    node?.focus()
  }}
  defaultValue="Hello world"
/>

Well, a tiny detail does: React will run this function after every render. So unless we are fine with focussing our input that often (which we are likely not), we have to tell React to only run this when we want to.

useCallback to the rescue

Luckily, React uses referential stability to check if the callback ref should be run or not. That means if we pass the same ref(erence, pun intended) to it, execution will be skipped.

And that is where useCallback comes in, because that is how we ensure a function is not needlessly created. Maybe that's why they are called callback-refs - because you have to wrap them in useCallback all the time. 😂

Here's the final solution:

const ref = React.useCallback((node) => {
  node?.focus()
}, [])

return <input ref={ref} defaultValue="Hello world" />

Comparing this to the initial version, it's less code and only uses one hook instead of two. Also, it will work in all situations because the callback ref is bound to the lifecycle of the dom node, not of the component that mounts it. Further, it will not execute twice in strict mode (when running in the development environment), which seems to be important to many.

And as shown in this hidden gem in the (old) react docs, you can use it to run any sort of side effects, e.g. call setState in it. I'll just leave the example here because it's actually pretty good:

function MeasureExample() {
  const [height, setHeight] = React.useState(0)

  const measuredRef = React.useCallback(node => {
    if (node !== null) {
      setHeight(node.getBoundingClientRect().height)
    }
  }, [])

  return (
    <>
      <h1 ref={measuredRef}>Hello, world</h1>
      <h2>The above header is {Math.round(height)}px tall</h2>
    </>
  )
}

So please, if you need to interact with DOM nodes directly after they rendered, try not to jump to useRef + useEffect directly, but consider using callback refs instead.

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below. ⬇️

React Query and Forms

Dominik D — Mon, 27 Jun 2022 13:57:18 +0000

Disclaimer: Please note that I will be using react-hook-form throughout this article, merely because I think it's a great library. That doesn't mean that the shown patterns will only work with react-hook-form - the concepts are applicable to any form library, and also if you are not using a form library at all.

Forms are an important part in many web applications as the primary means to update data. We are using React Query not only to fetch data (queries), but also to modify it (mutations), so we need to somehow integrate our beloved async state manager with forms.

The good news is that realistically, there isn't anything special about forms: It is still just a bunch of html elements that we render in order to display some data. However, as we'd also like to change that data, the lines between what is Server State and what is Client State start to blur a bit, which is where the complexity might come in.

Server State vs. Client State

To recap, Server State is state that we do not own, that is mostly async and where we only see a snapshot of how the data looked like the last time we fetched it.

Client State is state that the frontend has full control over, is mostly synchronous and where we know the accurate value of it at all times.

When we display a list of Persons, that is undoubtedly Server State. But what happens when we click on a Person to show their details in a Form with the intention of maybe updating some values? Does that Server State now become Client State? Is it a hybrid?

The simple approach

I have gone on the record already about how I am not a fan of copying state from one state manager to another, be it putting props to state or copying state from React Query to local state.

I do think that forms can be an exception to this rule though, if you are doing it deliberately and know about the tradeoffs (everything is a tradeoff after all). When rendering our Person form, we very likely want to treat the Server State as initial data only. We fetch the firstName and lastName, put it into the form state, and then let the user update it.

Let's take a look at an example:

function PersonDetail({ id }) {
  const { data } = useQuery(['person', id], () => fetchPerson(id))
  const { register, handleSubmit } = useForm()
  const { mutate } = useMutation((values) => updatePerson(values))

  if (data) {
    return (
      <form onSubmit={handleSubmit(mutate)}>
        <div>
          <label htmlFor="firstName">First Name</label>
          <input {...register('firstName')} defaultValue={data.firstName} />
        </div>
        <div>
          <label htmlFor="lastName">Last Name</label>
          <input {...register('lastName')} defaultValue={data.lastName} />
        </div>
        <input type="submit" />
      </form>
    )
  }

  return 'loading...'
}

This works incredibly well - so what are those tradeoffs?

Data might be undefined

You might know that useForm would also take defaultValues directly for the whole form, which would be pretty nice for larger forms. However, because we cannot call hooks conditionally, and because our data is undefined on the first render cycle (as we need to fetch it first), we cannot just do this in the same component:

const { data } = useQuery(['person', id], () => fetchPerson(id))
// 🚨 this will initialize our form with undefined
const { register, handleSubmit } = useForm({ defaultValues: data })

We'd have the same problem when copying into useState, or when using uncontrolled forms (which react-hook-form does under the hood by the way). The best solution to this would be to split up the form into its own component:

function PersonDetail({ id }) {
  const { data } = useQuery(['person', id], () => fetchPerson(id))
  const { mutate } = useMutation((values) => updatePerson(values))

  if (data) {
    return <PersonForm person={data} onSubmit={mutate} />
  }

  return 'loading...'
}

function PersonForm({ person, onSubmit }) {
  const { register, handleSubmit } = useForm({ defaultValues: person })
  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <div>
        <label htmlFor="firstName">First Name</label>
        <input {...register('firstName')} />
      </div>
      <div>
        <label htmlFor="lastName">Last Name</label>
        <input {...register('lastName')} />
      </div>
      <input type="submit" />
    </form>
  )
}

This is not too bad, as it separates our data fetching from the presentation. I'm personally not a big fan of such a split, but it does get the job done here.

No background updates

React Query is all about keeping your UI up-to-date with Server State. As soon as we copy that state somewhere else, React Query cannot do its job anymore. if a background refetch happens for whatever reason, and it yields new data, our form state will not update with it. This is likely not problematic if we are the only one working on that form state (like a form for our profile page). If that's the case, we should likely at least disable background updates by setting a higher staleTime on our query. After all, why would we keep querying our server if the updates will not be reflected on the screen?

// ✅ opt out of background updates
const { data } = useQuery(['person', id], () => fetchPerson(id), {
  staleTime: Infinity,
})

This approach can get problematic on bigger forms and in collaborative environments. The bigger the form, the longer it takes our users to fill it out. If multiple people work on the same form, but on different fields, whoever updates last might override the values that others have changed, because they still see a partially outdated version on their screen.

Now react hook form allows you to detect which fields have been changed by the user and only send "dirty" fields to the server with some user land code (see the example here), which is pretty cool. However, this still doesn't show the latest values with updates made by other users to you. Maybe you would change your input had you known that a certain field was changed in the meantime by someone else.

So what would we need to do to still reflect background updates while we are editing our form?

Keeping background updates on

One approach is to rigorously separate the states. We'll keep the Server State in React Query, and only track the changes the user has made with our Client State. The source of truth that we display then to our users is derived state from those two: If the user has changed a field, we show the Client State. If not, we fall back to the Server State:

function PersonDetail({ id }) {
  const { data } = useQuery(['person', id], () => fetchPerson(id))
  const { control, handleSubmit } = useForm()
  const { mutate } = useMutation((values) => updatePerson(values))

  if (data) {
    return (
      <form onSubmit={handleSubmit(mutate)}>
        <div>
          <label htmlFor="firstName">First Name</label>
          <Controller
            name="firstName"
            control={control}
            render={({ field }) => (
              // ✅ derive state from field value (client state)
              // and data (server state)
              <input {...field} value={field.value ?? data.firstName} />
            )}
          />
        </div>
        <div>
          <label htmlFor="lastName">Last Name</label>
          <Controller
            name="lastName"
            control={control}
            render={({ field }) => (
              <input {...field} value={field.value ?? data.lastName} />
            )}
          />
        </div>
        <input type="submit" />
      </form>
    )
  }

  return 'loading...'
}

With that approach, we can keep background updates on, because it will still be relevant for untouched fields. We are no longer bound to the initialState that we had when we first rendered the form. As always, there are caveats here as well:

You need controlled fields

As far as I'm aware, there is no good way to achieve this with uncontrolled fields, which is why I've resorted to using controlled fields in the above example. Please let me know if I'm missing something.

Deriving state might be difficult

This approach works best for shallow forms, where you can easily fall back to the Server State using nullish coalesce, but it could be more difficult to merge properly with nested objects. It might also sometimes be a questionable user experience to just change form values in the background. A better idea might be to just highlight values that are out of sync with the Server State and let the user decide what to do.

Whichever way you choose, try to be aware of the advantages / disadvantages that each approach brings.

Tips and Tricks

Apart from those two principal ways of setting up your form, here are some smaller, but nonetheless important tricks to integrate React Query with forms:

Double submit prevention

To prevent a form from being submitted twice, you can use the isLoading prop returned from useMutation, as it will be true for as long as our mutation is running. To disable the form itself, all you need to do is to disable the primary submit button:

const { mutate, isLoading } = useMutation((values) => updatePerson(values))
<input type="submit" disabled={isLoading} />

Invalidate and reset after mutation

If you do not redirect to a different page right after the form submission, it might be a good idea to reset the form after the invalidation has completed. As described in Mastering Mutations, you'd likely want to do that in the onSuccess callback of mutate. This also works best if you keep state seperated, as you only need to reset to undefined in order for the server state to be picked up again:

function PersonDetail({ id }) {
  const queryClient = useQueryClient()
  const { data } = useQuery(['person', id], () => fetchPerson(id))
  const { control, handleSubmit, reset } = useForm()
  const { mutate } = useMutation(updatePerson, {
    // ✅ return Promise from invalidation
    // so that it will be awaited
    onSuccess: () => queryClient.invalidateQueries(['person', id]),
  })

  if (data) {
    return (
      <form
        onSubmit={handleSubmit((values) =>
          // ✅ rest client state back to undefined
          mutate(values, { onSuccess: () => reset() })
        )}
      >
        <div>
          <label htmlFor="firstName">First Name</label>
          <Controller
            name="firstName"
            control={control}
            render={({ field }) => (
              <input {...field} value={field.value ?? data.firstName} />
            )}
          />
        </div>
        <input type="submit" />
      </form>
    )
  }

  return 'loading...'
}

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below. ⬇️

Hooks, Dependencies and Stale Closures

Dominik D — Mon, 25 Apr 2022 18:32:55 +0000

Working with closures is something that can become quite tricky, especially when dealing with hooks that have dependencies in React (think useEffect, useMemo, useCallback). A lot of bugs and frustration are tied pretty closely to that concept - even though it is nothing that React itself introduced. It's rather a language concept that hooks rely upon.

I love this question from Mark Erikson:

Mark Erikson

@acemarke

Question for the React community:

Has the shift from "how does `this`/binding work?"-type questions to "why is my state stale due to closures?"-type questions made things better, worse, or just "same thing but different" ?

(Inspired by the questions we see in @reactiflux daily)

02:15 AM - 06 Aug 2020

To me, it has gotten subjectively better. Working with this in class components was a pain, and errors did mostly show up at runtime. However, the behaviour you get due to stale closures are more subtle, and come up in more edge cases. The big advantage though is that they can be statically analyzed - and that's exactly what the react-hooks/exhaustive-deps eslint rule does.

In this article, I'll try to break down what stale closures are, what they have to do with React and hooks, and why the lint rule is so important that I think you should set it to error. To get there, we must first understand what (stale) closures are:

What are closures

I find the concept of closures somewhat hard to explain. Let's take a look at the definition on MDN:

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function's scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

I would best rephrase this as: JavaScript functions can "see", and interact with, things that were defined outside of them. You might not know it, but you are probably using this concept very often, for example, when using props of your React component inside a callback:

function Counter({ count }) {
  const logCount = () => {
    // 💡 accessing count from the outer scope
    console.log('count', count)
  }

  return <button onClick={logCount}>Show me the count</button>
}

logCount can access everything we define in the Counter component, for example, the count prop. You can easily check that you are relying on closures by moving the function to the outside of its parent. If it doesn't work anymore, it's because you don't have access to something you were "closing over" anymore:

// ❌ 'count' is not defined. (no-undef)
const logCount = () => {
  console.log('count', count)
}
function Counter({ count }) {
  return <button onClick={logCount}>Show me the count</button>
}

The nice part about closures in React is that it will "just work" if your component re-renders with a new prop. Have a look at this examples (note: examples are interactive on my blog: https://tkdodo.eu/blog/hooks-dependencies-and-stale-closures)

function App() {
  const [count, increment] = React.useReducer((prev) => prev + 1, 1)

  const logCount = () => {
    console.log(count)
  }

  return (
    <div>
      <div>count is {count}</div>
      <button onClick={increment}>increment</button>
      <button onClick={logCount}>log</button>
    </div>
  )
}

You can click both buttons a bunch of times, and you should see that the log function, which closures over count, will always have access to the "latest" count. Or so it seems.

But why is that, and is that always true?

Taking a picture

The last sentence of the MDN definition is the most important one, so let's have another look (emphasis mine):

In JavaScript, closures are created every time a function is created, at function creation time.

Let me try to explain this with an analogy that has made closures "click" for me:

Suppose every time you are creating a function, you are taking a picture of it. That picture contains everything from the moment when the picture was created. In the foreground, you have the most important things (what the function is doing, the code it is executing etc.). In the background of the picture, you have everything that lives outside your function, but that you are also using inside. It's as if the count variable has photo-bombed our picture - it is also in it.

The thing about the picture is - it cannot change. Once we have taken it, its content is sealed (unless we use photoshop).

Calling a function is just looking at the picture and doing what's on it. We will then see everything from the time when it was created.

Every time the function is created, we throw away the old picture and take a new one. When React re-renders a component tree, it just re-runs everything top down. Here, this works to our advantage: Our logCount function gets re-created because the App component re-renders when the count state is updated.

Because of that, we take a new picture (= re-create the logCount function), that contains the "latest" count variable. So when we click our button, we know the correct count.

Memoization

For 98% of the code we write, this behaviour is great, and as I said, it just works. We don't even have to think about closures. That is, until we introduce memoization.

The remainder of the time, re-creating a function every render just doesn't cut it. Maybe we need to pass it to a memoized child component that is expensive to re-render, so we have memoized it.

For these cases, React offers ways to not create functions (or values) every time, in the form of useCallback and useMemo.

By allowing us to pass a dependency array to those hooks, we can let React know when it should re-create those things, and when it is safe to give us an old version of it.

It comes with the aforementioned eslint rule that tries to point us in the right direction, and tells us which dependencies we should include. Because the rule is set to warn per default, it seems like an innocent thing to ignore. But it is not.

Ignoring the linter

Oftentimes, I see people ignore the rule with arguments like: "I only want to run this effect when the component mounts", or: "I only want to create the function once".

Whenever you do that, no new picture is taken. React will just give you the old one to look at. And as we now know, that means we'll have the old photo-bombed variables at our disposal, as opposed to "the latest ones". And that is commonly referred to as a "stale closure". Because the things you are seeing are not up-to-date, but stale.

We can see how ignoring the linter in our example will lead to non working code:

function App() {
  const [count, increment] = React.useReducer((prev) => prev + 1, 1)

  // 🚨 the linter says we should include count
  // as a dependency, but we don't
  const logCount = React.useCallback(() => {
    log(count)
  }, [])

  return (
    <div>
      <div>count is {count}</div>
      <button onClick={increment}>increment</button>
      <button onClick={logCount}>log</button>
    </div>
  )
}

We instruct React to only create our logCount function once, "on mount". It doesn't have any dependencies (an empty dependency array), so it will always "see" the count from the first render cycle, which is 1. Every time we click the button, it will log 1. This is certainly not what we had in mind.

Obviously, this was a very basic example. We can just include the count in the dependency Array, like the linter wants to, without problems. If count changes, we get a new picture. If our App re-renders for some other reason and count stays the same, we don't have to create a new function, and React can give us the old one. Nothing is stale here, because the only dependency we have is count, and that hasn't changed. This is pretty sweet.

But what about more complex dependencies? Like an object or a callback function that get provided via props that are not referentially stable?

Another example

Once upon a time, we had a component that wasn't fast. It looked something like this:

function SlowComponent({ value, onChange }) {
  return <RenderSomethingSlow value={value} onChange={onChange} />
}

Our idea was to memoize it by wrapping it in React.memo so that it doesn't get rendered too often. Because onChange is a function that gets passed in by consumers, they would need to memoize the function to not make the component slow again.

We thought: "We actually only want to re-render our component when value changes, so why don't we just omit the onChange prop from the comparison function and side-step that problem?" 🤔

const FastComponent = React.memo(
  SlowComponent,
  (prevProps, nextProps) => prevProps.value === nextProps.value
)

As the React docs suggest, we can "return true if passing nextProps to render would return the same result as passing prevProps to render, otherwise return false".

We only care about value for our render result, so what's wrong with this approach?

The answer lies again in stale closures: If the caller component re-creates onChange for some reason, but value doesn't change, we are not taking a new picture of our SlowComponent, which means it still sees the old onChange function:

function User({ name }) {
  const [count, increment] = React.useReducer((prev) => prev + 1, 1)

  // 🚨 name can become stale
  const logUser = () => {
    console.log(name, count)
  }

  return (
    <div>
      <button onClick={increment}>increment</button>
      <button onClick={logUser}>log</button>
      <FastComponent value={count} onChange={logUser} />
    </div>
  )
}

The logUser function closures over name and count, but FastComponent knows nothing of the name prop. It will only be re-created when value changes, so if onChange is called, it sees the name from the last time count has changed - which might or might not be stale.

This is a very tricky situation to be in, because your application can run perfectly fine for weeks or even months before you get a bug report that is likely very tricky to reproduce.

Don't lie

The best thing you can do is: Don't get yourself in this situation by lying about the dependencies. Functions cannot be easily excluded from dependency arrays, so take the linter seriously, and make that rule an error in your codebase!

Spoiler: There are ways to have your cake and eat it, too, but I will leave that for the next article. 😄

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below. ⬇️

Offline React Query

Dominik D — Mon, 14 Feb 2022 19:26:45 +0000

I've said it time and time again - React Query is an async state manager. As long as you give it a Promise, resolved or rejected, the library is happy. Doesn't matter where that Promise comes from.

There are many ways to produce promises, but by far the biggest use-case is data fetching. Very often, that requires an active network connection. But sometimes, especially on mobile devices where the network connection can be unreliable, you need your app to also work without it.

Issues in v3

React Query is very well-equipped to handle offline scenarios. Because it provides a caching layer, as long as the cache is filled, you can keep working even if you don't have a network connection. Let's look at a couple of edge-case scenarios where v3 will not work as expected. I will use our basic post list / post detail example from the docs for illustration:

1) no data in the cache

As I said, in v3, things work well as long as the cache is filled. An edge case scenario where things get weird would be the following:

You have a good network connection and navigate to the list view
You lose connection and click on a post.

What happens is that your query will stay in loading state until you regain connection. Also, you can see a failed network request in the browser devtools. That is because React Query will always fire off the first request, and if that fails, it will pause retries if you have no network connection.

Further, the React Query Devtools will show that your query is fetching, which is not entirely true. The query is actually paused, but we have no concept to represent that state - it's a hidden implementation detail.

2) no retries

Similarly, if you have turned off retries altogether in the above scenario, your query will go to error state immediately, with no way of stopping that.

Why do I need retries for my query to pause if I have no network connection 🤷‍♂️?

3) queries that don't need the network

Queries that don't need a network connection to work (e.g. because they do an expensive async processing in a web worker) will be paused until you regain network connection if they fail for some other reason. Also, those queries won't run on window focus because that feature is completely disabled if you have no network connection.

In summary, there are two major issues: In some cases, React Query assumes that network connection is needed when that might not be true (case 3), and in other cases, React Query fires off a query even though it probably shouldn't (cases 1 and 2).

The new NetworkMode

In v4, we've tried to tackle this problem holistically with a new networkMode setting. With this, we can clearly distinguish between online and offline queries. It is an option for useQuery as well as useMutation, which means you can set it globally or on a per-query basis. After all, you might have some queries that need network connection, and some that don't.

online

This is the new default mode in v4, as we expect most users to use React Query in combination with data fetching. In short, with this setting, we assume that a query can only run if it has an active network connection.

So what happens if you want to run a query that needs network connection when you don't have one? The query will go to a new paused state. That paused state is secondary to the main state that the query can be in: idle, loading, success or error, because you can lose your network connection at any time.

This means you can be in success state and paused, for example, if you've fetched data successfully once but a background refetch got paused.

Or, you can be in loading state and paused if a query mounts for the first time.

fetchStatus

We've always had the isFetching flag that indicated that a query was running. Similar to the new paused state, a query could be success and fetching, or it could be error and fetching. Background refetches give you a lot of possible states to be in (👋 state machines).

As fetching and paused are mutually exclusive, we've combined them into the new fetchStatus that now gets returned from useQuery:

fetching: The query is really executing - a request is in-flight.
paused: The query is not executing - it is paused until you have regained your connection.
idle: The query is currently not running.

As a rule of thumb, the status of the query will give you information about the data: success means you'll always have data, loading means you don't have data yet. I thought about renaming the loading state to pending, but alas, this probably would have been "too breaking". 😅

On the other hand, the fetchStatus gives you information about the queryFn: is it running or not? The isFetching and isPaused flags are derived from that status.

Let's take a look at how case 1 from above can look like in v4. Please notice the new network mode toggle button in the RQ devtools. It's pretty cool because it doesn't actually turn off your network - it just makes React Query believe that there is no network for testing purposes. Yes, I am quite proud of it. 😊

We can clearly see the state the query is in (paused) due to the new purple status badge. Also, the first network request is made once we turn the network back on.

always

In this mode, React Query does not care about your network connection at all. Queries will always fire, and they will never be paused. This is most useful if you use React Query for something other than data fetching.

offlineFirst

This mode is very similar to how React Query worked in v3. The first request will always be made, and if that fails, retries will be paused. This mode is useful if you're using an additional caching layer like the browser cache on top of React Query.

Let's take the GitHub repo API as an example. It sends the following response headers:

cache-control: public, max-age=60, s-maxage=60

which means that for the next 60 seconds, if you request that resource again, the response will come from the browser cache. The neat thing about this is that it works while you're offline, too! Service workers, e.g. for offline first PWAs, work in a similar way by intercepting the network request and delivering cached responses if they are available.

Now those things wouldn't work if React Query would decide to not fire the request because you have no network connection, like the default online mode does. To intercept a fetch request, it must happen :) So if you have this additional cache layer, make sure to use the offlineFirst networkMode.

If the first request goes out, and you hit the cache - great, your query will go to success state, and you'll get that data. And if you have a cache miss, you'll likely get a network error, after which React Query will pause the retries, which will put your query into the paused state. It's the best of both worlds. 🙌

What does all of this mean for me, exactly?

Nothing, unless you want to. You can still decide to ignore that new fetchStatus and only check for isLoading - React Query will behave just like before (well - case 2 from above will even work better because you won't see the network error).

However, if making your app robust for situations where you have no network connection is a priority for you, you now have the option to react to the exposed fetchStatus and act accordingly.

What you do with that new status is up to you. I'm excited to see which ux people will build on top of this. 🚀

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below ⬇️

Always provide customer value

Dominik D — Sat, 29 Jan 2022 14:26:27 +0000

Last time, I told you when not to start a refactoring and kind of left you hanging when it comes to the question: When is the right time? Let's try to answer that now!

To do that, we must first divide our potential refactorings into groups:

The small ones

A small refactoring is one that you are comfortable doing at all times. It's those little things that get suggested in a code review right before you actually wanted to ship it, and oftentimes, it's something that can even be automatically done by your IDE.

Renaming a variable. Extracting a function. Inlining an abstraction.

As engineers, it is a) our job and b) in our own best interest to produce great quality code. Whenever the circumstances allow it (see also #1: Don't mix refactorings with hotfixes), we should take the liberty to improve maintainability without asking for permission - no matter if we are fixing a bug or adding a feature.

It's like writing tests. Or making sure that our app is accessible.

It is something that I would expect anyone on my team to be passionate about. We care about our codebase, and we want to make it better with everything that we are doing.

Incrementally. One tiny refactoring at a time.

Of course, you'll have more confidence if the part you are touching is sufficiently covered with types and tests. If it is not, I would suggest that's where you start:

Add types.
Add tests.
Then refactor.

In that order. If you only make it to one or to two, that's alright. There is always a next time.

The bigger ones

Yes, not all refactorings are that small. Sometimes, you stumble upon an architecture that is flawed and needs to be changed. Or you see an outdated pattern that you have left behind long ago (or so you thought), and you really don't want to add more code to the mess before cleaning it up.

How far you go with ad-hoc refactorings is up to you and your team, and needs a bit of experience and "feeling" for the codebase. I have started refactorings that I thought were small, only to go from one rabbit hole to the next to reverting everything after two days. It sucks, but you learn from it 😄.

Once you decide that a refactoring is larger than something that you can just do on the fly, you have to somehow plan it into your sprint (or whatever way of working your team has adopted). My advice for these situations would be:

Always provide customer value

Pure refactoring issues, apart from the small ones, are rarely a good idea. It just doesn't sell very well:

I'm gonna work on this refactoring, it's about 20 story points, and it's gonna take a good amount of time. In the best case scenario, everything will still work exactly the same as before, while in the worst case, I'll introduce a bunch of regressions with it.

— A dev selling a refactoring

That doesn't sound too good for a product manager. Why would this be more important than the new feature the customer really wants?

Yes, it's an investment into the future of the product, it makes it more maintainable, and you'll likely have higher velocity later on while also producing fewer bugs. But "bugs we would have in production without this refactoring" is a very hard metric to measure. So likely, if you come up with a proposal like that, it will be squashed for not providing enough direct value.

The right package

For larger refactorings, it is important to wrap them in the right package:

Yes, we can add this new feature the customer wants, but it's a technical requirement that we also re-architect this page because it will be too hard otherwise.

— selling a "refactoring feature"

That is something most people can get behind. It might take a bit longer to ship the actual feature, but it's a good compromise where both "sides" get their win.

As an example, we had a quite complex filter component that we used in some parts of the application. When a new feature for this component was due, we decided to port it to react-query while doing so. This delivered the needed direct value (the feature for the customer), while also providing implied value (less code, better maintainability).

The huge ones

These don't come up that often, and are likely rewrites of a big part of the application. Maybe you want to replace redux-saga with react-query? Maybe it's time to move to remix? Our migration from flow to typescript some time ago would also qualify.

How on earth can you get everyone on board for such an endeavor? This will be the topic of part 3 - so stay tuned 📻

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below ⬇️

Road to Refactoring

Dominik D — Sat, 29 Jan 2022 14:24:02 +0000

Over the years, I've come to work on many medium to large scale code bases. Most of these have organically grown over time, some of them being full of Lava Layers. Doing a refactoring in those code bases is often not trivial. Incidental complexity is high, test coverage is low. There are more features than you can count.

Also, where do you start? There are so many things you'd like to tackle and do differently, but everything you touch has the potential to introduce regressions.

In this series, I'm trying to list some of the things that I've done to make refactorings a success rather than a disaster. This is by no means an exhaustive lists, and is heavily biased by my personal experience. Further, it likely doesn't apply to your side-project or early start-up, so as usual, your mileage may vary. That being said, here we go with the first tip 🚀

Don't mix refactorings with hotfixes

You get a bug report, highest prio, customer is escalating, account management is permanently asking: "what is the ETA on this, what can I tell the customer?"

You look at the code and analyze the issue. Maybe it's in an area of the code base that hasn't been touched for a while, or maybe you've not looked at it in a longer time.

Likely, you won't like what you see. Software patterns, especially in the frontend world, can evolve rapidly. Even if you start with something new, chances are you would do it differently in a couple of months.

Maybe you see a React Class Component that fetches in componentDidMount. Wtf, we've moved to react-query half a year ago, what is this? Or maybe there are some global styles or deprecated components being used. Oh, and this dependency could really need an update...

Scout's principle - time to clean up this mess...

Don't. Just don't.

There's a time and a place for everything, but this is not the time for a refactoring. You don't want to prolong the actual fix. As an engineer, you are a problem solver, and your only goal here should be to fix the actual problem. Also, you might introduce another regression, and code reviews will take longer if you add unrelated changes.

Quality

That doesn't mean we should compromise on quality. Even in those situations, we still:

Create a branch (no direct merging to main)
Write proper commit messages
Get the required amount of reviews
Run the CI pipeline

And make sure that all other quality gates that we have set up still pass. We surely want a fix as fast as possible, but not at all costs.

A failing test case

This is the flow I usually take when getting a bug report:

Dominik

@tkdodo

This is the best flow:
🐞 find a bug
🕵️‍♂️ investigate it
⇆ reproduce it
🧪 write a failing test for it
💻 fix it
🟢 see the green test
🚀 ship it

16:32 PM - 22 Nov 2021

Writing a failing test case before you start fixing the issue is something I can really recommend, as it will ensure that:

the bug is consistently reproducible.
the issue stays fixed in the future, for example, when you actually refactor that code.

This presumes that you have a somewhat easy way to add a test case for the bug. If you're in the unfortunate situation that you'd have to introduce a testing framework first to actually write a test - go back to the beginning of this article 😉

The right time

So when is the right time to refactor the horrible thing we've found? I'll try to answer this in part 2 - so stay tuned 📻

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below ⬇️

2021 in Review

Dominik D — Thu, 30 Dec 2021 17:46:09 +0000

Since I'm currently sitting at home on my couch, resting after my 3rd Covid-19 vaccine shot with not a lot else to do, I thought I'd reflect a bit on the year I've had and give a bit of an outlook of what's ahead.

Blogging

Not a lot has happened in the first five months of the year. I was getting more and more involved in open source, and I tried to blog regularly (about once every two or three weeks).

There were two reasons why I started my blog last year: Because I thought it would be fun to set up (narrator: it was not), and because I wanted to have a permanent resource I could link people to. I've also made it a rule that if I see a concept / question / (anti-)pattern at least 3 times, I would blog about it.

That was also the reason why I started my React Query related series of blog posts, which currently spans over 13 articles, as I have gotten a lot of questions around React Query.

More Open Source

2021 was definitely the year when I started to take open source seriously. I have contributed a little to open-source before, but the turning point came at around Mai 2021, when Tanner made me an official React Query maintainer. Around the same time, I also became a maintainer for remeda, my favourite TypeScript util library.

With those new responsibilities, it became clear that I couldn't just continue like before. I was already overworked, and to be honest, open-source was a lot more fun than work at that time. I had cancelled almost all of my vacations due to Covid-19 and didn't feel fully happy.

Being self-employed and catering to three different clients as a contractor, I made the decision to cancel one of my clients where I didn't feel my contributions were making much of a difference anymore, and introduced open-source-friday:

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

It might sound crazy to cancel a paid engagement to work for free on open-source instead, but it was definitely the right move for me. It gave me a bit of freedom to work on what I believe in, which can be much more fulfilling than a pay-check.

Tanner also convinced me to set up GitHub sponsors, where currently 18 amazing people are sponsoring my open source work 💖.

Oddly enough, being a React Query maintainer led to some amazing new consulting opportunities for me as well. I ❤️ React Query and React + TypeScript in general, and I also enjoy teaching, so I definitely feel very privileged that I got the opportunity to combine these aspects.

Later that summer, my blog even became a part of the official React Query docs. I'm very happy that people believe my content is good enough to be "official-docs" material, and it has kept me motivated to write more articles:

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

React 18

For the second half of the year, I kept an eye on React 18, the Working group, and how some changes would affect me as a user of React as well as a library maintainer. My probably biggest "contribution" in terms of impact in 2021 happened when I asked an innocent looking question to Dasishi Kato, author of the state manager zustand, on Twitter:

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

useMutableSource -> useSyncExternalStore

React 18 was about to ship a hook called useMutableSource, and it required input selectors to be referentially stable. I stumbled upon this when I reviewed a PR at work, where a co-worker of mine memoized all selectors to a zustand store with useCallback, something like:

import create from 'zustand'

const useStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
}))

// usage:
const bears = useStore(React.useCallback((state) => state.bears, []))
const increasePopulation = useStore(
  React.useCallback((state) => state.increasePopulation, [])
)

Naturally, that got me thinking. Why would you memoize a selector that just returns a value from the state? That's not an expensive calculation, and useCallback is just a performance optimization 🤔.

The answer I got was surprising, as my co-worker said: The zustand docs recommend that!

I looked it up, and yes, it was really there:

It is generally recommended to memoize selectors with useCallback. This will prevent unnecessary computations each render. It also allows React to optimize performance in concurrent mode.

DaiShi's answer to my question why this was suggested was: Because it will be required in React 18 to avoid infinite loops in concurrent mode.

🤯

After that, the discussion escalated a bit, as the redux team around Mark Erkison as well as react maintainers like Brian Vaughn got pulled in as well. Eventually, the discussion moved towards the React 18 Working Group, which I was later also invited to, where the hook was renamed to useSyncExternalStore, and the api was adjusted so that selector stability was no longer required.

I'm glad my little tweet kicked off the discussion that led to this decision, which probably avoided massive breaking changes for many consumers. Just imagine having to memoize every inline selector in redux 😮. I do however regret the tone in which I voiced my concerns - I'm really sorry for that.

React Query and React 18

When react-redux released v8.0.0-alpha.0 in early October, I decided it's time to take a stab at making React Query ready for concurrent features, which will be shipped in React 18. Similar to redux, React Query has an external store that manages the cache, which components need to subscribe to. If we keep doing that with our current approach (basically, with useEffect and useState), applications might suffer from an issue called tearing, where parts of the ui might display outdated values.

If that concept is unfamiliar to you, there is a great talk from Dasishi Kato at React Conf 2021: React 18 for External Store Libraries
about this topic.

To solve this issue, React 18 will ship with a new hook called useSyncExternalStore (yes, the one I mentioned above 😅), which libraries like React Query or redux need to adopt.

Right now, we have a draft PR that passes all tests against React 17 and React 18. Depending on when React 18 will become stable, we might include this PR in our next major release.

React Query v4

Speaking of React Query: at the end of October, we decided to work towards a new major version of the library, as some inconsistencies have piled up, and some issues couldn't be fixed unless we tackled them holistically with a new approach. We put our minds together and came up with a great new "Network Mode" feature to iron out these inconsistencies and to make React Query even better 🚀.

Version 4 is now in alpha, and we are looking forward to making a stable release sometime early next year. I will also very likely write a dedicated blog post about v4 in the near future.

Public Speaking

At the end of the year, I got my first invitations to represent React Query at online Panel Discussions. As I've never done anything like that before, I was really, really nervous. Some people say this will get better over time, some say it doesn't 🤷‍♂️. Anyways, I don't like watching myself on those 🙈, but here are the links in case you missed it:

2021 in numbers

The blog

For my blog, I only have comparable metrics for the last 3 months, because I switched hosting provider and later analytics provider during the year. I am now with netlify and I'm using plausible.io for analytics, and I'm supper happy with both.

For that time period, I can see a steady stream of about 20k visitors and 35k page views per month, which is huge for my perspective, and definitely more than I would've ever thought would happen to my little blog.

From what I can tell, most people come to my blog from Google (about 50% traffic!) and from the React Query docs (another 20%). The top 6 articles in terms of page views are also all from the React Query series:

I also tried to blog regularly - about once every two to three weeks. I've written a total of 21 articles, and November was the only month without a blog post (mainly because I was working on React Query v4 instead).

Twitter

This year, I've grown my twitter friends by about 3500% 😮. Of course, that number becomes less impressive if you consider that I started the year with under 100 followers, as percentages are high when the bar is low. I'm still pretty proud of it though, as I seek to provide valuable content for the community. I try not to give random TypeScript tips that you can easily find by going to google, or explain how Array.map works in nice pictures. I think there are enough people on Twitter doing that already. Also, I'm really not in it for the followers. I think there is a sweet spot for Twitter that is right between where you feel like you're shouting into the void (< 1k) vs. where your notifications are becoming unbearable (apparently > 10k, but I can't tell yet). I'm right in there, and it feels perfect at the moment 😊.

The tweet that got the most impressions this year (74k) was one I've quickly written on my phone after answering a certain question for the Nth time - which also lead to me writing React Query as a State Manager - arguably one of my best received articles:

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

2022 and beyond

I'm quite excited for what lies ahead. With React 18 and React Query v4 around the corner, the ecosystem just keeps getting better and better, which is to everyone's advantage.

For 2022, I really want to rewrite my blog, and go away from gatsby towards either next.js or remix.run - or whichever framework will be all the rage next year. I don't want to do this because I'm unsatisfied with gatsby (I'm not), but more so for the technical challenge and to keep up-to-date with the latest developments on how to build stuff.

So let me know in the comments below ⬇️ (or reach out to me on twitter) what you think I should be choosing and why. I really hope I find the time to get around to it 😀.

With that, all that is left for me to say is merry Christmas 🎄 (if you are celebrating it), a happy new year 🎊, and I hope you say safe and healthy ⛑. I will be taking about two weeks time off to hopefully come back refreshed next year.

Beware the leaking any

Dominik D — Sun, 05 Dec 2021 14:16:21 +0000

Any is not among my favourite TypeScript types, but it is the one you will inevitably encounter, if you like it or not. This might not be a problem in some situations, but can be devastating in others. Let's dive into it:

A short introduction to the type system

Any is the top type in TypeScript's type system (while never would be the bottom type). Think about the types as a big tree, where each child type "extends" its parent, but not the other way around. This is very convenient when you have an object hierarchy, like Vehicle -> Car, because every Car is a Vehicle, but not every Vehicle is a Car.

It does however also work on a much simpler level, for example with the string type and a string literal type. Every string literal is a sub-type of the type string:

let parent: string = 'hello'
let child: 'hello' = 'hello'

Here, child would also "extend" parent, even though we don't really have a typical inheritance. That's why it's often easier to replace "extends" with "is assignable to" when thinking about types.

child is assignable to parent, but parent is not assignable to child.

Parent is not assignable to child because it's type is wider. This can be proven by trying to actually assign the variables to each other:

let parent: string = 'hello'
let child: 'hello' = 'hello'

// ✅ ok, as parent is the "wider" type
parent = child
// 🚨 Type 'string' is not assignable to type '"hello"'.(2322)
child = parent

We can assign child to parent, because child is assignable to parent, but it doesn't work the other way around.

So what about any?

In any case (pun intended), any would sit at the top of the tree. Everything is assignable to any. If we add any to the above example, our tree would be any -> string -> 'hello'

let top: any = 'hello'
let parent: string = 'hello'
let child: 'hello' = 'hello'

// ✅ ok, as parent is the "wider" type
parent = child
// ✅ also fine
top = parent

So far so good, and if any sits at the top, it must mean that you cannot assign it to a more narrow type, right? This is where things get weird with any:

let top: any = 'hello'
let parent: string = 'hello'
let child: 'hello' = 'hello'

// 🚨 Type 'string' is not assignable to type '"hello"'.(2322)
child = parent
// 🤯 no type error here
parent = top

Any is an exception to this rule, because assignments work both ways, which make any an escape hatch for the compiler. You can literally do anything with it, even things that clearly won't work.

Unknown to the rescue

In TypeScript 3.0, the unknown top type was introduced to fix this. It is like the type-safe big brother to any. If we replace any with unknown, we get the exact behavior we thought any would give us.

Anything is assignable to unknown, but unknown isn’t assignable to anything but itself and any

let top: unknown = 'hello'
let parent: string = 'hello'
let child: 'hello' = 'hello'

// ✅ ok, as parent is the "wider" type
parent = child
// ✅ also fine
top = parent
// 🚨 Type 'string' is not assignable to type '"hello"'.(2322)
child = parent
// 🚨 Type 'unknown' is not assignable to type 'string'.(2322)
parent = top

This is great, because now we have our real tree structure back with unknown sitting at the top, but it also means it's virtually impossible to do anything meaningful with unknown.

But that's okay.

Because we don't know what it is, we have to find that out at runtime first. TypeScript will narrow the type if we perform a type narrowing check:

let top: unknown = 'hello'
let parent: string = 'hello'

if (typeof top === 'string') {
  // ✅ top is of type string now, so it's assignable to parent
  parent = top
}

There are many ways to narrow types in Typescript, like using typeof, instanceof, the in operator, checks like Array.isArray or even user defined type guards. Working this way is a much safer approach because it tries to leverage the compiler, not bypass it.

When any is leaking

Okay, we've probably all used any from time to time to shut up the compiler, and that's not a problem. There are definitely diminishing returns when trying to go towards 100% type safety, and sometimes, it's just easier for everyone's sanity to disable the compiler via any and write a bunch of unit tests to make sure you don't screw up along the line.

Any becomes problematic when the scope is large, because it will disable the compiler in places you didn't think about. Let's have another look at what the TypeScript docs have to say about any:

When a value is of type any, you can access any properties of it (which will in turn be of type any), call it like a function, assign it to (or from) a value of any type, or pretty much anything else that’s syntactically legal.

— The TypeScript docs

This basically means if you have an any, and you call a function on it, the result will also be any. Every property will be any. Every function you return it from will then return any. If you use the return value of this function in a computation, the result will also be any.

All of a sudden, this little any is spreading like wildfire:

const dangerous: any = 5
// ✅ inferred to the number literal 5
const okay = 5

// 🚨 result is now `any`
const result = dangerous + okay

const dangerous2: any = { title: 'foo' }
const props = { hello: 'world' } as const

// 🚨 result2 is now `any` as well
const result2 = {
  ...dangerous2,
  ...props,
} as const

Especially the object merging took me by surprise, but it makes sense. You can't build a union type with any. Not even the awesome const assertion will help you here. This is especially dangerous when using it together with React components, as spreading the result of a function that returns any will make all props of that component fall back to any:

declare function myAnyUtil(input: Record<string, unknown>): any

function App(props: Props) {
  // ❗️ no other prop is type checked anymore
  return (
    <button onClick="yes please" {...myAnyUtil(props)}>
      click me
    </button>
  )
}

Oops. Because we spread the result of myAnyUtil, which returns any, onto our button, nothing is now type checked (if you are wondering: onClick needs to accept a function, not a string). Remember, jsx is just syntatic sugar for React.createElement, so the above code reads:

declare function myAnyUtil(input: Record<string, unknown>): any

function App(props: Props) {
  return React.createElement(
    'button',
    { onClick: 'yes please', ...myAnyUtil(props) },
    'click me'
  )
}

Now we can clearly see that the props object we pass to our button is widened to any, similar to the contrived example above, which is why the onClick prop is also not type-checked.

I believe this to be very dangerous, as its quite hidden. We rely on TypeScript to help us when refactoring, e.g. when altering union types. If I remove the 'secondary' variant of my Button component, and TypeScript wouldn't yell at me for all the existing usages, I would be lost in a larger code base.

But with a leaking any on my component, TypeScript would just stay silent. It becomes as useful as a unit test where you forgot to assert anything. It's even worse than plain JavaScript, because you think you're safe - but you're not.

When can this happen?

I believe it happens more often than you might think, especially if:

You're calling JavaScript from TypeScript - such functions will very likely just return any.
You are using a 3rd party library that has weak types (lodash.get for example).
You don't annotate your util functions with explicit return values and leak an any from them.

With any, you can do anything, but everything is better than any.

— TkDodo

The best advice I can give for situations where you have to use any is to keep it confined to a very small scope to avoid it from leaking. You can also statically analyze your type-coverage to get informed about places where any is lurking around. If the coverage decreases on a PR, you might have a problem. Further, avoid 3rd party libraries that are written in JavaScript unless they have very good types. Lastly, ensuring that your own util functions don't leak anything can be achieved by explicitly enforcing return types on them, even though I also like to utilize type inference as much as possible. This is certainly a trade-off you'd need to be willing to make.

That's it for today. Feel free to reach out to me on twitter
if you have any questions, or just leave a comment below ⬇️