Forem: Zachary Davis

How to move to react-query v1

Zachary Davis — Mon, 02 Mar 2020 01:29:33 +0000

react-query v1 is here! And with it comes several breaking changes that will render your code useless if you try to upgrade without making any changes. This guide will cover several examples of old code using react-query v0.4.3 or older, and how to get the same functionality out of v1.0.*.

Firstly, if you are unfamiliar with react-query, this guide won't be too useful for you. Instead, I recommend jumping right into the Readme if you want a simple, hook-based library to help you make API calls.

If you do have code using an older version, however, look no further!

Pagination

We're going to start with pagination, as this is the first breaking change in v1. Gone is the paginated flag on the useQuery hook. Instead, there is a new usePaginatedQuery hook.

  const {
    status,
    resolvedData,
    latestData,
    error,
    isFetching,
  } = usePaginatedQuery(['projects', page], fetchProjects);

As you can see, the code is fairly similar, and we still are able to find out if the query is still running via the isFetching status, but there is no longer an isFetchingMore function to call as we are only receiving one page's worth of data at a time here.

data does not exist when using this hook, however. Now, there are two different objects that contain data, resolvedData and latestData:

resolvedData is data from the last known successful query result at first, and will remain the same until the next query successfully resolves.
latestData is only ever the data from the latest query, so it will be undefined until the latest query resolves.

Both objects can be mapped over similarly to how one might use data, like this:

<div>
  {resolvedData.projects.map(project => (
    <p key={project.id}>{project.name}</p>
  ))}
</div>

Other than that, we are just syntactically telling the library to do a paginated query in a different way: specifying the hook instead of having a more generic one where we pass in whether things are paginated or not.

This makes the resulting code a little cleaner in my opinion than how we used to do it, which involved the same generic useQuery hook that was available in v0.4.3, and telling it that it was paginated like this:

const { data,
    isLoading,
    isFetching,
    isFetchingMore,
    fetchMore,
    canFetchMore,
  } = useQuery(
    'projects',
    ({ nextId } = {}) => fetch('/api/projects?page=' + (nextId || 0)),
    {
      paginated: true,
      getCanFetchMore: lastPage => lastPage.nextId,
    }
  );

Infinite Loading

Previously, if you wanted to load more, you had to implement a loadMore function like so:

const loadMore = async () => {
    try {
      const { nextId } = data[data.length - 1];

      await fetchMore({
        nextId,
      });
    } catch {}
  };

While this is still the case if you want to manually control which pages you load and when it is no longer necessary to continuously call a function like that if you want to implement an infinite load to get all of the resources from your API.

The useInfiniteQuery is aptly named to help you get that job done, all while providing an interface similar to that of the olduseQuery:

const {
    status,
    data,
    isFetching,
    isFetchingMore,
    fetchMore,
    canFetchMore,
  } = useInfiniteQuery('projects', fetchProjects, {
    getFetchMore: (lastGroup, allGroups) => lastGroup.nextCursor,
  });

useQuery used to be able to do this for you, separating this functionality out into its own hook helps make the code a little more clear and readable in my opinion.

useMutation

The useMutation hook has also changed quite a bit. Gone are the refetchQueries and updateQuery options. Now, we have onSuccess, onError, and onSettled callbacks. These align to how people had been using the library anyhow, and are a welcome change.

If you want to run a query every time you update a variable, you can do something like this:

const [mutatePostTodo] = useMutation(
    text =>
      fetch('/api/data', {
        method: 'POST',
        body: JSON.stringify({ text }),
      }),
    {
      // to revalidate the data and ensure the UI doesn't
      // remain in an incorrect state, ALWAYS trigger a
      // a refetch of the data, even on failure
      onSettled: () => queryCache.refetchQueries('todos'),
    }
  );

async function handleSubmit(event) {
    event.preventDefault();
    // mutate current data to optimistically update the UI
    // the fetch below could fail, so we need to revalidate
    // regardless

    queryCache.setQueryData('todos', [...data, text]);

    try {
      // send text to the API
      await mutatePostTodo(text);
      setText('');
    } catch (err) {
      console.error(err);
    }
  }

This not only updates the todo that you've edited but it then goes and gets the list again whether or not the POST call was successful. If you wanted to only update your list when the POST was successful, then you could swap out onSettled for onSuccess. Similarly, you could use onError for a failure condition. If you want to throw an exception as well when an error occurs, you can use the throwOnError function.

In the past, if you wanted to refetch your todos no matter, you had to do something like this:

const [mutatePostTodo] = useMutation(
    text =>
      fetch('/api/data', {
        method: 'POST',
        body: JSON.stringify({ text }),
      }),
    {
      refetchQueries: ['todos'],
      // to revalidate the data and ensure the UI doesn't
      // remain in an incorrect state, ALWAYS trigger a
      // a refetch of the data, even on failure
      refetchQueriesOnFailure: true,
    }
  );

  async function handleSubmit(event) {
    event.preventDefault();
    // mutate current data to optimistically update the UI
    // the fetch below could fail, so we need to revalidate
    // regardless

    setQueryData('todos', [...data, text], {
      shouldRefetch: false,
    })

    try {
      // send text to the API
      await mutatePostTodo(text);
      setText('');
    } catch (err) {
      console.error(err);
    }
  }

While the functionality is the same, the syntax in v1 is much more declarative, and the new methods allow for much more flexibility.

QueryCache

The previous example of how to refetch todos in v1 also illustrates how to use the new queryCache methods. The queryCache remembers all of your queries and the settings of those queries.

You can now easily refetchQueries by ID or refetchQueries by itself, which replaces refetchAllQueries. You can also prefetchQuery, setQueryData, clear, or removeQueries.

These also replace the standalone functions of refetchQuery, refetchAllQueries, prefetchQuery, updateQuery, and clearQueryCache.

useQuery

The main hook in the library, useQuery has also undergone some other minor changes. Gone is the isLoading boolean status, instead, there is a status string returned with different possible values. isFetching, however, has remained unchanged.

Previously we could track the status like this:

  const { data, isLoading, isFetching } = useQuery('projects', () =>
    fetch('/api/data')
  );

Now, we do this:

  const { status, data, error, isFetching } = useQuery('projects', () =>
    fetch('/api/data')
  );

Status can either be success, loading, or error when returned from useQuery and the previously mentioned useMutation, but success can generally be assumed when we are not in a loading or error state with some JSX like this:

    <div style={{ textAlign: 'center' }}>
      <h1>Trending Projects</h1>
      <div>
        {status === 'loading' ? (
          'Loading...'
        ) : status === 'error' ? (
          <span>Error: {error.message}</span>
        ) : (
          <>
            <div>
              {data.map(project => (
                <p key={project}>
                  <Link href="/[user]/[repo]" as={`/${project}`}>
                    <a>{project}</a>
                  </Link>
                </p>
              ))}
            </div>
          </>
        )}
      </div>
    </div>

Essentially, if we are not loading data, and don't have an error, we should have data to show the user.

Keys

Keys are another concept that has changed with the v1 release of react-query. String only keys are still supported (they are converted to arrays under the hood), but keys with associated variables are not limited just a tuple format anymore. Instead, keys can be any valid object syntax, making them much more flexible.

The format is not the only thing that has changed, however. Variables can now be passed down to the query function, not just the key like so:

const { status, data, error } = useQuery(
    // These will be used as the query key
    ['todo', todoId],
    // These will get passed directly to our query function
    [
      debug,
      {
        foo: true,
        bar: false,
      },
    ],
    fetchTodoById
  )
};

This will cause the query to be rerun if foo or bar change, but we can stop this if we want by setting a ReactQueryConfigProvider around the components that house this query with a queryFnParamsFilter to only pass in the key if we want.

Overall, while v1 will require you to update many of the places in your code where you are making API calls if you are already using react-query, it will create much more readable code thanks to the more declarative API available in the newest, and first, major version.

Using `styled-components` to Style Someone Else's Component

Zachary Davis — Thu, 27 Feb 2020 12:25:55 +0000

Introduction

In writing micro front-ends (MFEs), I've made heavy use of styled-components to easily scope my CSS to just the single MFE that I'm working on to help avoid style collisions with both other MFEs on the same page as well as the legacy applications that integrate the apps that I'm writing.

This went swimmingly for both my custom components in my component library as well as the components my team chose as a base (bootstrap-styled).

Styling Someone Else's Component

But when it came time to start using third-party components that shipped their own CSS along with their components, I became worried.

Thankfully, styled-components handles this situation gracefully. You simply need to be able to pass a className prop to the component you are trying to target. And if that specific component does not accept that prop, you can get around that by creating a higher-order component that just has a wrapping div with the className passed to it.

This is exactly what I had to do with Draft.js:

With that className prop, styled-components was able to do its magic and make my Draft.js instance look exactly how I needed to without leaking any styles to the rest of the page by creating CSS rules that only took effect within the context of the randomly generated class name that styled-components gave that wrapper div.

So, CSS like this placed into a `styled-component` definition:

...still produced a normal-looking rich-text area that was micro front-end ready. Allowing me to not worry about the importing the CSS file from Draft.js.

This strategy works for any component that has known class names that you can target, making it a viable solution for most third-party components out there.

Refactoring a Class Component to a Functional Component w/ State Hooks

Zachary Davis — Mon, 17 Jun 2019 04:06:33 +0000

Introduction

Up until early this year with the release of React 16.8 in February, we as React developers have had to rely on class components to create any components that needed to rely on their own internal state.

State can be used for a variety of different purposes, but in general, it helps us keep track of variables that are only needed within the scope of the component we are using them in or in a component consumed by the component we are in.

Examples

As a simple example, I’ve created a component that consists of a button and an icon (started directly from create-react-app). When the button is clicked, the visibility of the icon is toggled. To accomplish this, we’ll keep track of the visibility in the component’s state.

Here is how we would do it in a class component:

And here is how it ended up after we refactored it into a functional component using the `useState` hook:

I greatly prefer how much simpler the code is with the useState hooks as compared to the traditional way of handling state in class components, and the process itself was simple.

First, I turned the component into a functional component, removing the constructor and therefore the binding of the handleClick function.

Then, I brought in the useState hook, which rendered the entire handleClick function pointless, so I was able to simply call the setter directly from the onClick prop of the button itself.

And voila! I got rid of 13 lines of code in two simple steps.

There is much less boilerplate when you are given a function that will directly set the state variable for you instead of writing the setState call inside of your own function, and while a 13-line difference might not look huge in this small example, imagine a larger component that needs to keep track of a handful of different variables in its state. The code can begin to get quite long and verbose when you have to write each individual state setter and bind the functions in the constructor.

13 lines per state variable, per component, can really add up!

Hooks are certainly the future of React, and hopefully, I have helped illustrate just why that is in this simple example.

Forem: Zachary Davis

How to move to react-query v1

Pagination

Infinite Loading

useMutation

QueryCache

useQuery

Keys

Using `styled-components` to Style Someone Else's Component

Introduction

Styling Someone Else's Component

This is exactly what I had to do with Draft.js:

So, CSS like this placed into a styled-component definition:

Refactoring a Class Component to a Functional Component w/ State Hooks

Introduction

Examples

Here is how we would do it in a class component:

And here is how it ended up after we refactored it into a functional component using the useState hook:

So, CSS like this placed into a `styled-component` definition:

And here is how it ended up after we refactored it into a functional component using the `useState` hook: