Forem: Yurui Zhang

What do you do with your old programming books?

Yurui Zhang — Mon, 03 Feb 2020 00:58:12 +0000

I've been trying to clean up my bookshelf at home & my desk in my office recently and noticed I have a lot of outdated programming books - like really old ones - WebMatrix, Angular 1.x, Joomla, Rails 3...

I guess the only sensible thing to do is to recycle them? 🤔 what do you do with yours?

Make Your Own create-react-app Templates

Yurui Zhang — Mon, 16 Dec 2019 00:09:02 +0000

Running npx create-react-app is probably the most popular way of starting a new React project - however don't you wish if the bootstrapped project uses the folder structure you prefer? or comes with more strict eslint rules (or custom ones your team use all the time)? or includes more popular stuff like prettier auto-formatting, some UI component library you prefer? With the release of create-react-app@3.3.0 it's now possible to use a custom template to create new projects:

npx create-react-app PROJECT_NAME --template my-awesome-template

So how do we create & publish our own templates?

Project Structure

There are some limited documentation on the official site - however the official templates repo offers more clues.

When we look at the official template repo, we can see there are three major components to a template:

package.json - this has nothing to do with the package.json file we see in a typical react project. This file here defines the template package - A cra template is just another npm package - once it's published - anyone can use the create-react-app cli just by referencing the name of the package.
template.json - interesting, it seems it's an extension to package.json - if we want to include any extra dependencies, we can put them here.
template - it's the main project folder, this should include all the files we would like to include in the newly bootstrapped project. Notice that there are no package.json or package-lock.json files here - we should let create-react-app handle them.

Seems pretty straight forward, let's create our own template!

Setting Up

I would like to start with the template folder - the easiest way is to create an empty project with create-react-app

npx create-react-app my-awesome-template

Now, let's go to the project folder and add some extra dependencies with yarn.

cd my-awesome-template
yarn add node-sass @material-ui/core prettier

We can edit & re-organize the files in this project, add a .prettierrc or .eslintrc, change the components, add your own logos, fonts, etc. Go crazy, make it look like the ideal project you want it to be! Don't forget to edit the README file as well.

Publishing to npm

Now we've got the templates, let's make a new folder which will be the home to our template project:

mkdir cra-template-my-awesome-template

Usually we should use something like npm init to create a new package.json file for our package, but here let's just copy the one from the official template

Open the file in your favorite editor, and make sure to change the following fields:

name: name of the template package. By convention the name of the package should be prefixed with cra-template-, however it's not required. The benefit of having that prefix is that the users won't have to type the full name of the package to use it. If you need to publish the package under an organization, your users will have to use the fullname of the template, instead of just the part after the prefix. e.g. if the name here is @acme-inc/cra-template-acme, the user will have to speicify --template @acme-inc/cra-template-acme in the command line.
version: your own version - by default cra will always use the latest version found on npm.
description, author, keywords : introduce yourself and your template to the world
repository: if you don't have a repo for this, just delete this for now, however we should always check our templates into source control.

Now, create a template.json file, and copy the dependencies we installed earlier to this file. If you have some custom scripts, you can add a scripts field here as well. Remember not to include anything that usually comes with create-react-app.

{
  "dependencies": {
    "@material-ui/core": "^4.8.0",
    "node-sass": "^4.12.0",
    "prettier": "^1.19.1"
  },
  "scripts": {
    "fix-formatting": "prettier --write src/**/*.{js,jsx}"
  }
}

At the time of writing, only dependencies and scripts are supported, everything else will be ignored. Also, if you have npm run in your scripts, they will be replaced automatically with yarn if your user uses yarn to bootstrap their apps. Nice!

Next, let's copy the project we setup previously to the template folder. A few notes:

don't copy package.json or yarn.lock or package-lock.json - we want create-react-app cli to manage them
don't copy node_modules or build - or anything that you don't want to check into source control.
rename .gitignore to gitignore (cra will rename it back)

And it's ready to be shipped to the world! 🚀

npm publish

Don't forget to share your awesome template repo with the world as well - keeping the dependencies up-to-date and fixing bugs ASAP are as important as sharing your awesome ideas with the community.

And we are done! Congrats and happy coding!

Testing API Request Hooks with Jest, Sinon, and react-testing-library

Yurui Zhang — Sun, 27 Oct 2019 22:04:47 +0000

In this mini series we have developed a simple hook that abstracts away the logic of managing some common states used in data fetching. Now let's talk about testing.

I'm assuming that you are already familiar with the basics of unit testing React apps with Jest. If that's not the case, Jest's official document site is a great place to start: https://jestjs.io/docs/en/getting-started

What To Test

Before we start writing any tests, we need to know what we need to test. This is a bit different from Test Driven Development (TDD) where we know what our desired outcomes are so we write tests first. But our tests should follow the same sets of rules, for example:

Test the outcomes, not the implementation. Treat the components/functions you are testing like black boxes - we feed it with data and check what we are getting back - try to avoid testing implementation details.
Tests should be isolated. A test should not affect other tests in any way, nor should it depend on any code inside another test.
Tests should be deterministic. Given the same input, a test should always give the same results.

Testing React components are usually pretty straight forward - we "render" the component (sometimes with props), and check if its output matches our expectations. If the component is interactive, we will simulate the user interactions (events) and see if it behaves correctly.

Testing hooks is somewhat trickier, however with the same rules, we can confidently say:

For hooks that return values, we test if the expected values are returned for the same sets of inputs;
For hooks that provides actions (for example, useState returns a function that lets you change the state value), we can fire those actions and see if the outcome is correct;
For hooks that causes "side effects" - we will try to observe the side effect, and make sure that everything is cleaned up so other tests won't be affected.

Now let's take a quick look at our useGet hook - it:

Causes a side-effect: it sends a request over the network (using fetch)
Takes one parameter: url and returns values: isLoading, data, and error; The values changes based on the outcome of the side-effect it causes: when a request is pending, isLoading is true; when the request is successful, we will receive some data; if anything bad happens, error value will be populated.
discards the first side-effect, if we provide a new value before fetch is resolved.

Now we know what to test!

Mocking Async Requests

Now how do we observe the side-effect the hook is causing? Spinning up a server that responds to our testing requests sounds cumbersome - and the tests won't be isolated & deterministic - there could be network issues and they are going to make the tests fail; our tests will depend on the server to return correct responses, instead of user inputs/actions.

Luckily there are couple of mocking libraries that allow us to observe asynchronous requests and control their results. To test React apps, I usually prefers sinon which provides a very easy API to setup fake request handlers and clean things up.

Here we will need to use its fakeServer method:

import { fakeServer } from 'sinon';

// setup a fake server
// we will need to hold a reference to the server so we can tell it when/what to respond to requests (and clean it up later)
let server;

beforeEach(() => {
  server = fakeServer.create();
});

sinon doesn't really spin up a "server" that runs along side of our tests. Under the hood, it just fakes the native XMLHttpRequest so all of our outgoing requests are intercepted. This change is global - we want to make sure that one request fired in one tests won't interfere with a different test, so we need to remove the fake after each test:

afterEach(() => {
  server.restore();
});

In our tests, we can tell the fake server how to handle each request, like so:

server.respondWith('GET', url, [
  200,
  {},
  JSON.stringify(mockData),
]);

The code above tells our server that:

It accepts "GET" requests to the url
It should respond with status code 200 (OK)
It doesn't return any headers
The body of the response is mockData (as a string)

If we want a request to fail, we can just change the status code to 4xx (e.g. 400 for "Bad Request",403 for "Forbidden") or 5xx (500 for "Internal Server Error"), and provide an error message in the response body.

respondWith is very flexible - you can find all the options, and all the stuff you can do here.

Often we don't want the server to respond right away, we can control when the server should respond by calling: server.respond();.

Writing the Test

Hooks look like they are just plain old JavaScript functions, but if we call one directly outside a React component we are going to see this:

    Invariant Violation: Invalid hook call. Hooks can only be called inside of the body of a function component.

There are a couple of different ways to get around this - one of them is creating a simple function component that uses this hook, and we can test the rendered output of that component. It's not a bad solution honestly, however there is a much easier, and more elegant way - using @testing-library/react-hooks. I'm fairly new to "@tesing-library" packages but I fell in love with this one immediately just after writing a few tests.

To setup our hook, we can simply call renderHook like so:

import { renderHook } from '@testing-library/react-hooks';

// ... test setup

const url = '/foo/bar';
const { result, waitForNextUpdate } = renderHook(() => useGet({ url }));

It returns lots of useful goodies, here we only need result and waitForNextUpdate.

result, as its name suggests, is an object that holds the values that our hook returns;
waitForNextUpdate is a function that allows us to wait until all async stuff our hook is doing. This is where this testing library really shines.

Now let's write our first test: we want to make sure that the initial states are as expected:

it('returns proper initial states', () => {
  const url = '/foo/bar';
  const { result } = renderHook(() =>
    useGet({ url })
  );

  expect(result.current.isLoading).toEqual(true);
  expect(result.current.data).toBeNull();
  expect(result.current.error).toBeNull();
});

Isn't it easy? Now let's combine it with fake server - we want to make sure returns the data from the server when the request finishes.

// note, this is an `async` test 
it('GETs data from the server', async () => {
  const url = '/foo/bar';
  const expectedData = { some: 'data' }; // we define some data the server will be returning
  // setup the server
  server.respondWith('GET', url, [
    200,
    {},
    JSON.stringify(expectedData),
  ]);

  // setup our hook
  const { result, waitForNextUpdate } = renderHook(() =>
    useGet({ url })
  );

  // just to make sure our data is still `null` at this point
  expect(result.current.data).toBeNull();

  // tell our server it's time to respond!
  server.respond();

  // magic! we will wait until our hook finishes updating its internal states;
  await waitForNextUpdate();

  // assert the outcomes! 
  expect(result.current.data).toEqual(expectedData);
  expect(result.current.isLoading).toEqual(false);
  expect(result.current.error).toBeNull();
});

Similarly we can test that it returns expected messages when the server responds with an error code.

How do we test the request cancellation bit? How do we provide the hook with a new url before we call server.respond()? I'm glad you asked 😄 renderHook also returns a rerender method that allows us to provide some props to the hook - the setup looks slightly different from the example above though:

const initialUrl = '/first/request';
const { rerender } = renderHook(({ url }) => useGet({ url }), {
  initialProps: { url: initialUrl }
});

Now the function we provide to renderHook accepts a url prop which is in turn used in the useGet call. And with the second argument we are telling renderHook that the initial value of url should be '/first/request'.

In order to re-run our hook with new props, we can simply do:

rerender({ url: '/new/url' });

Putting it together, to write this test we will:

setup our server to respond to two URLs with different data
render the hook with an initialUrl
rerender our hook with a new url
tell the fake server that it's time to send back responses
assert that our result should only include data from the second call

Now you've got everything you need to write this test, would you accept this challenge?

Hint: You probably will need to use a different method to handle requests in order to resolve the second request before the first one. Read the docs here.

It's a Wrap

Thanks for reading my very first blog series on React & testing! React is a wonderful library to work with and its community is actively working to improve experiences of both the developers and the end-users. And hooks make things much easier to share common states / workflows within the codebase. I hope you find those posts helpful 🤗 and please stay tuned for more React best practices posts!

Use Hooks In Class Components Too

Yurui Zhang — Sat, 12 Oct 2019 20:26:22 +0000

With the official release of hooks, everybody seems to be writing function components exclusively, some even started refactoring all of their old class components. However class components are here to stay. We can't use hooks everywhere (yet), but there are some easy solutions.

Higher Order Components

Higher Order Components (or HOCs) are functions that takes a Component in its arguments, and returns a Component. Before hooks, HOCs are often used to extract common logic from the app.

A simple HOC with a useState hook looks like this:

const withFoo = (Component) => {
  function WithFoo(props) {
    const [foo, setFoo] = useState(null);

    return <Component foo={foo} setFoo={setFoo} {...props} />
  }

  WithFoo.displayName = `withFoo(${Component.displayName})`;

  return WithFoo;
};

Here, our withFoo function, can be called with a Component. Then, it returns a new Component that receives an additional prop foo. The WithFoo (note the capitalized With) is actually a function component - that's why we can use Hooks!

A few quick notes before we move on:

Personally I usually name my HOCs with*, just like we always use the pattern use* for hooks.
Setting a displayName on the HOC is not necessary, but it is very helpful for debugging your app in react-devtools
Usually I spread the original props last - this avoids overwriting props provided by the users of the component, while allowing the users to override the new fields easily.

Our Custom Hook

How do apply this to our useGet hook?

Let's replace useState from the example above to useGet ... but wait, useGet needs to be called with { url } - where do we get that? 🤔

For now let's assume the url is provided to the component in its props:

const withGetRequest = (Component) => {
  function WithGetRequest(props) {
    const state = useGet({ url: props.url });

    return <Component {...state} {...props} />
  }

  WithGetRequest.displayName = `withGetRequest(${Component.displayName})`;

  return WithGetRequest;
};

This works, but at the same time, this means whoever uses our wrapped component will have to provide a valid url in its props. This is probably not ideal because often we build urls dynamically either based on some ids or in some cases, user inputs (e.g. In a Search component, we are probably going to take some fields from the component's state.)

One of the limitations of HOCs is they are often "static": meaning we can't change its behavior easily at run-time. Sometimes we can mitigate that by building "Higher Higher Order Components" (not an official name) like the connect function provided by react-redux:

// connect() returns a HOC
const withConnectedProps = connect(mapStateToProps, mapDispatchToProps);

// we use that HOC to wrap our component
const ConnectedFoo = withConnectedProps(Foo);

So, if our resource's url relies on some fields from the from the props maybe we can build something like this:

// first we take a function that will be called to build a `url` from `props`
const makeWithGetRequest = (urlBuilder) => {
  return withGetRequest = (Component) => {
    return function WithGetRequest(props) {
      const url = urlBuilder(props);
      const state = useGet({ url });

      return <Component {...state} {...props} />;
    }
  };
};

It's safe to assume that different components will have different logic for building the URLs they need. For example, to wrap an ArticlePage component:

// we know articleId and categoryId will be provided to the component
const buildArticleUrl = ({ articleId, categoryId }) => {
  return `/categories/${categoryId}/articles/${articleId}`;
};

// now our enhanced component is using the `useGet` hook!
export default makeWithGetRequest(buildArticleUrl)(ArticlePage);

This seems nice, but it doesn't solve the problem of building url with the component's state. I think we are too fixated on this HOC idea. And when we examine it closely we will discover another flaws with this approach - we are relying on props with fixed names being provided to the component, this could lead to a couple of problems:

Name Collision: Users of the enhanced component will have to be extra careful to not accidentally override props provided by HOCs
Clarity: Sometimes the prop names are not descriptive. In our ArticlePage example above, the component will receive data and error in its props and it could be confusing to future maintainers.
Maintainability: When we compose multiple HOCs, it becomes harder and harder to tell which props must be provided by the user? which props are from HOCs? which HOC?

Let's try something else.

Render Props / Function as Child

Render Props and Function as Child are both very common react patterns and they are very similar to each other.

Render Props is a pattern where a component takes a function in its props, and calls that function as the result of its render (or conditionally, in advanced use cases).

An example with hooks looks like this:

const Foo = ({ renderFoo }) => {
  const [foo, setFoo] = useState(null);

  return renderFoo({ foo, setFoo });
};

// to use it:
class Bar extends Component {
  // ...

  render () {
    return (
      <Foo
        renderFoo={
          ({ foo, setFoo }) => {
            // we have access to the foo state here!
          };
        }
      />
    );
  };
};

When we decide that the user should always provide that render function as children, then we are using the "Function as Child" pattern. Replacing renderFoo with children in our example above will allow us to use it this way:

<Foo>
  {
    ({ foo, setFoo }) => {
      // now we can use foo state here
    }
  }
</Foo>

The two patterns here are often interchangeable - many devs prefer one over the other, and you can even use them at the same time to provide max flexibility, but that'll be a topic for another time.

Let's try this pattern with our useGet hook.

// it takes two props: url and children, both are required.
const GetURL = ({ url, children }) => {
  const state = useGet({ url });

  return children(state); // children must be a function.
};


// now we can use it like this!
class Search extends Component {
  // ...

  render() {
    const { keyword } = this.state;

    return (
      <GetURL url={buildSearchUrl({ keyword })}>
      {
        ({ isLoading, data, error }) => {

          // render the search UI and results here!
        }
      }
      </GetURL>
    );
  }
}

Easy, right?

Function as Child & Render Props are not without trade-offs. They are more flexible than HOCs but now our original component's JSX is now nested in an inline function - making it a bit tricky to test when using the shallow renderer from enzyme. And what happens if we want to compose multiple hooks in a component? I wouldn't nest another function child inside an existing one.

Wrapping Up

Now we have two ways of making hooks (re-)usable everywhere! If a hook doesn't rely on any dynamic inputs, I would go with the HOC solution; If you want to be more flexible, providing a component with Render Props / Function as Child would be a much better choice.

Next let's talk about testing our hooks & components with jest, sinon and @testing-library/react-hooks. 🎉

Avoid Those Mistakes When You Work On Your Next Take-Home Interview Assignment

Yurui Zhang — Mon, 07 Oct 2019 00:14:28 +0000

Lots of companies send take-home interview assignments to candidates before meeting them on-site. Those are generally small projects that might take a day or two to complete. Usually the candidates receive a description of the problem (or, "requirements") and (sometimes) acceptance criteria. Companies / teams use the submission to get a feel of the candidate's skill level and/or personal style, and the solution is often discussed in the actual interview process.

In the past few months I've been asked to review numerous submissions of a simple take-home test that my company sent to front-end candidates. And here are the mistakes I think people (especially junior developers) should try to avoid:

Copying Someone Else's Solution

You might not believe this is the very top mistake people make. Me neither, until we caught three candidates who just copied someone else's repository and called it a day. (One of them didn't even bother to change the author field in package.json.) I'm sorry the assignment is not a very original one, or it didn't interest you enough - but being dishonest about your work is a big no-no in pretty much every industry.

It's true that many (if not most) developers often use Google or StackOverflow to search for solutions, and that's OK - nobody knows everything after all. However, unless the description of the problem says the company is looking for someone who is really good at googling solutions, please give your genuine effort to code the solution yourself.

Not Reading the Requirements Carefully

The first thing I do when I review a submission is to run it myself and compare the outcome with the requirements. To a surprising degree, most of the submission I've seen doesn't satisfy all the requirements.

At the very least, please read the requirement carefully and follow the instructions. Make a list of things that you need to deliver, and note how each condition should be handled.

Not Asking Any Questions

This is somewhat related to the point above. There is no such thing called a perfect software requirement. Don't jump into coding right away - check your assumptions first. The people who wrote those requirements are people too and they might have their own sets of assumptions.

Don't be afraid to ask questions - if this is your first software developer job, trust me, you will be asking questions all the time whenever someone asks you to create anything.

Ask about edge cases, if you can think of any.
Ask about tools, if the interviewers have any preferences.
Write down your assumptions and ask if they are correct / acceptable.

If you don't think doing the test is the best way to demonstrate your skills, don't be afraid to ask if there are other ways.

Overcomplicating Your Solution

Of course you want to impress the interviewers. Doing the bare minimum of what the requirement document asks is probably not going to make you stand out. (But still, your solution should at least meet all the basic requirements).

It's totally OK if you want to add a few extra features to enhance your solution and show off your skills. However - know that the more code you write, the more mistakes you are going to make!

If a simple solution works, always go with the simple one. In a problem we sent to a candidate, there is this small part of the program that requires checking if a point { x, y } is inside of a up-right rectangle with { width, height }. One of the solutions I looked at, tried to create a class for Point and then wrote over 40 lines of code just trying to solve this small part by using "scalar product of vectors". Does it solve the problem? Yes. Is it better than a one-liner if/else check? Not really.

Oh by the way, don't immediately go OO for everything. I know JavaScript has class now and all the cool kids seems to be using it. But that doesn't mean you should use it for everything.

Skipping Unit Tests

Like it or not, unit testing is an essential part of software development. You probably have seen tons of articles talking about test-driven development now. However one of the most often heard (by me, at least) complaints from junior developers is "writing unit test is slowing them down." or "it feels like a waste of time."

Well, yes, it takes extra time and effort to write good unit tests. But I can guarantee you that it's never a waste of time.

When you work on an assignment, make sure you have good unit tests accompanying your code. This not only helps you discover issues in your code early, but also serves as simple documentation for your solution and your thought process.

Having simple, concise unit tests is a big plus in my books, even if it's not part of the requirements.

Not Linting Your Code

I've seen a couple of solutions, while solving the problem and meeting most of the requirements, riddled with linting issues: unused variables, inconsistent indentations, missing semi-colons (or extra semi-colons, if you prefer "no semis" in JS).

A common misconception is that code is meant to be executed by machines. In reality, code is to be read and understood by humans. Software is ever evolving - everything you write will eventually be read by other developers, or your future self. One way to improve your code's readability is making sure your code is free of clutter and consistent in styling.

When you start working on a JavaScript project, always use a linter. There are many popular (and opinionated) configurations out there (airbnb, standardJS, just to name a few). And now we've got prettier which formats your code automatically. Setting those up probably won't take you more than 10 minutes, just do it, your code will be much pleasing to the eyes of your interviewers.

In Short

I don't think being able to solve the problem is the most most most important part of the interview process. Being a developer is not as easy as it might seem - if you are not passionate about what you craft, you are probably not going to go very far. Please use the assignment as an opportunity not only to prove your skills but also to show that you care.

Clean Up Async Requests in `useEffect` Hooks

Yurui Zhang — Fri, 04 Oct 2019 23:38:45 +0000

In my previous post, we talked about how to replace some component lifecycle functions with useEffect and useReducer hooks, while making the resource fetching logic re-usable in the app.

https://dev.to/pallymore/refactoring-an-old-react-app-creating-a-custom-hook-to-make-fetch-related-logic-reusable-2cd9

The custom hook we got at the end looks like this:



export const useGet = ({ url }) => {
  const [state, dispatch] = useReducer(reducer, {
    isLoading: true,
    data: null,
    error: null,
  });

  useEffect(() => {
    const fetchData = async () => {
      dispatch(requestStarted());

      try {
        const response = await fetch(url);

        if (!response.ok) {
          throw new Error(
            `${response.status} ${response.statusText}`
          );
        }

        const data = await response.json();

        dispatch(requestSuccessful({ data }));
      } catch (e) {
        dispatch(requestFailed({ error: e.message }));
      }
    };

    fetchData();
  }, [url]);

  return state;
};

Looks pretty neat, right? However it has a critical flaw - if the fetch request is slow, and the component has already unmounted when the async request finishes, you will see this error message from React:

Or - it could have a serious problem - imagine your component that uses this hook received a different ID before the request finishes - so it tries to fetch data from the new url, and the second request finished just a few ms before the first one - what's gonna happen? Your component will be showing the data from the first request!

The great async/await might make your code look like it is synchronous, but in reality they are just syntax sugar - your code after await will still be executed even your component no longer exists on the page. We should always be careful whenever we want to update the state in an asynchronous function.

How do we prevent this from happening? First of all, we should always try to clean up our effects.

The Clean Up Function

If you don't already know - you can return a function at the end of your useEffect hook. That function will be called whenever that effect is fired again (e.g. when the values of its dependencies have changed), as well as right before the component unmounts. So if you have a useEffect hook that looks like this:



useEffect(() => {
  // logic here

  return () => {
    // clean up
  };
}, []); // no dependencies!

It is actually doing the exact same thing as this code:



class SomeComponent extends React.Component {
  componentDidMount() {
    // logic here
  }

  componentWillUnmount() {
    // clean up
  }
}

If you are attaching an event listener to window, document, or some other DOM elements, you can use removeEventListener in the clean up function to remove them. Similarly, you can clean up setTimeout/setInterval with clearTimeout/clearInterval.

A Simple Solution

Knowing this, you might think: oh well, that's great, we can set a flag that is set to false when the component unmounts so we can skip all the state updates.

And you are right, that's indeed a very simple solution to this problem:



  useEffect(() => {
    let isCancelled = false;
    const fetchData = async () => {
      dispatch(requestStarted());

      try {
        // fetch logic omitted...
        const data = await response.json();

        if (!isCancelled) {
          dispatch(requestSuccessful({ data }));
        }
      } catch (e) {
        if (!isCancelled) {
          dispatch(requestFailed({ error: e.message }));
        }
      }
    };

    fetchData();

    return () => {
      isCancelled = true;
    };
  }, [url]);

In this code - whenever a new effect runs (or the component unmounts), the previous' effect's isCancelled is set to true - and we only update the state when it is false. This makes sure that your requestSuccessful and requestFailed actions are only dispatched on the latest request.

Mission accomplished!...?

But You Really Should Do This

There is a better way though. The code above is fine, however, if your fetch request is really slow, even if you don't need the results anymore, it is still going on in the background, waiting for a response. Your user might be clicking around and leaving a bunch of stale requests behind - did you know? There is a limit of how many concurrent requests you can have going on at the same time - usually 6 to 8 depending on which browser your users are using. (This applies to HTTP 1.1 only though, things are changing thanks to HTTP/2 and multiplexing, but that's a different topic.) Your stale requests will be blocking newer requests to be executed by the browser, making your app even slower.

Thankfully, there is a new feature in the DOM API called AbortController which allows you to cancel fetch requests! It is well supported by most browsers (No IE11 though) and we should definitely take advantage of it.

The AbortController is very easy to work with. You can create a new one like this:



const myAbortController = new AbortController();

and you will find two fields on the instance: myAbortController.signal and myAbortController.abort(). signal is to be provided to the fetch call you want to cancel, and when abort is called that fetch request will be cancelled.



fetch(url, { signal: myAbortController.signal });

// call the line below to cancel the fetch request above.
myAbortController.abort();

If the request has already completed, abort() won't do anything.

Awesome, now we can apply this to our hook:



  useEffect(() => {
    const abortController = new AbortController();

    const fetchData = async () => {
      dispatch(requestStarted());

      try {
        fetch(url, { signal: abortController.signal });

        // code omitted for brevity

        dispatch(requestSuccessful({ data }));
      } catch (e) {
        dispatch(requestFailed({ error: e.message }));
      }
    };

    fetchData();

    return () => {
      abortController.abort();
    };
  }, [url]);

Now our fetch request will be promptly cancelled for each new effect, or right before the component unmounts.

Handling Cancelled Requests

Just one little thing though - when a request is cancelled it actually throws an error, so our catch block will be executed. We probably don't want to dispatch a requestFailed action in this case. Fortunately we can tell if a request has been aborted by checking the signal on the AbortController instance.

Let's do that in our catch block:



try {

 // ...

} catch (e) {

  // only call dispatch when we know the fetch was not aborted

  if (!abortController.signal.aborted) {

    dispatch(requestFailed({ error: e.message }));

  }

}

Wrapping It Up

Now our hook can properly cleans up after itself! If your hook does something async, in most cases they should be cleaned up properly to avoid any unwanted side-effects.

If you are using fetch, then abort your requests in the clean up function. Some third party libraries also provide a way to cancel requests (like the CancelToken from axios).

If you want to support older browsers, or your effect doesn't use fetch, but is using some other async operations (like Promise), before cancelable Promises becomes a reality, use the isCancelled flag method instead.

Resources

https://developer.mozilla.org/en-US/docs/Web/API/AbortController

https://reactjs.org/docs/hooks-effect.html

Refactoring An Old React App: Creating a Custom Hook to Make Fetch-Related Logic Reusable

Yurui Zhang — Mon, 30 Sep 2019 01:14:50 +0000

I recently picked up an old project from two years ago. The app is not a very complicated one - it reads data from a simple API server and present them to the users, pretty standard stuff. The client has been pretty happy about the results so now they have come back with more feature requirements they'd like to include in the next iteration.

The Old Fashioned Way

Before actually start working on those features, I decided to bring all the dependencies up-to-date (it was still running React 16.2 - feels like eons ago) and do some "house cleaning". I'm glad that me from 2 years ago took the time to write plenty of unit and integration tests so this process was mostly painless. However when I was migrating those old React lifecycle functions (componentWill* series) to newer ones, a familiar pattern emerged:

class FooComponent extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      isLoading: true,
      error: null,
      data: null,
    };
  }

  componentDidMount() {
    this.fetchData();
  }

  componentDidUpdate(prevProps) {
    if (prevProps.fooId !== this.props.fooId) {
      this.fetchData();
    }
  }

  fetchData() {
    const url = compileFooUrl({ fooId: this.props.fooId });

    fetch(url).then(
      // set data on state
    ).catch(
      // set error on state
    );
  }

  render() {
    // redacted. 
  }
}

Does this look familiar to you? The FooComponent here fetches foo from a remote source and renders it. A new foo will be fetched when the fooId in the props changes. We are also using some state field to track the request and the data fetched.

In this app I'm trying to improve, this pattern is seen in multiple components, but before hooks, it's often not very straight forward to share logic like this, but not anymore! Let's try to create a re-usable hook to improve our code.

First Iteration With Hooks

Now before we actually write a reusable custom hook, let's try to refactor this component. I think it's pretty obvious that we are going to need useState to replace this.state and let useEffect handle the data fetching part. useState is pretty easy to handle, but if you are not familiar with useEffect yet, Dan Abramov has a really good (and lengthy) blog article about it: https://overreacted.io/a-complete-guide-to-useeffect/

Our hooked component now looks like this:

const FooComponent = ({ fooId }) => {
  const [state, setState] = useState({
    isLoading: true,
    error: null,
    data: null,
  });

  useEffect(() => {
    const url = compileFooUrl({ fooId });

    fetch(url)
      .then((response) => {
        if (response.ok) {
          return response.json().then(data => {
            setState({
              isLoading: false,
              data,
              error: null,
            });
          });
        }

        return Promise.reject(response);
      })
      .catch(/* similar stuff here */);
  }, [fooId]);

  return (
     // redacted
  );
};

Pretty easy, eh? Our component now works almost* exactly like before with fewer lines (and cooler hook functions!), and all integration tests are still green! It fetches foo when it mounts and re-fetches it when fooId changes.

"almost" -> The component is now a function component which cannot take a ref. https://reactjs.org/docs/refs-and-the-dom.html#accessing-refs

Making Our Logic Re-useable

The next step would be making this fetch-and-set-state logic re-usable. Luckily it is extremely easy to write a custom hook - we just need to cut-and-paste our code to a separate file!

Let's name our reusable hook useGet, which takes an url - since apparently not all components are gonna use foo and not all getRequests depend on a single ID I think it's probably easier to leave that url-building logic to each component that wants to use our custom hook. Here's what we are aiming for:

const FooComponent = ({ fooId }) => {
  const fooUrl = compileFooUrl({ fooId: this.props.fooId });

  const { isLoading, data, error } = useGet({ url });

  return (
    // same jsx as before
  );
};

Let's cut-and-paste:

export function useGet = ({ url }) => {
  const [state, setState] = useState({
    isLoading: true,
    error: null,
    data: null,
  });

  useEffect(() => { /* fetch logic here */}, [url]);

  // return the `state` so it can be accessed by the component that uses this hook.

  return state;
};

By the way, then/catch is so 2017, let's use async/await instead to reduce the nested callbacks - everybody hates those. Unfortunately useEffect cannot take an async function at this moment, we will have to define an async function inside of it, and call it right away. Our new useEffect looks something like this:

useEffect(() => {
  const fetchData = async () => {
    setState({
      isLoading: true,
      data: null,
      error: null,
    });

    try {
      const response = await fetch(url);

      if (!response.ok) {
        // this will be handled by our `catch` block below
        throw new Error(`Request Error: ${response.status}`);
      }

      setState({
        isLoading: false,
        data: await response.json(),
        error: null,
      });
    } catch(e) {
      setState({
        isLoading: false,
        data: null,
        error: e.message,
      });
    }
  };

  fetchData();
}, [url]);

Much easier to read, isn't it?

The Problem with `useState`

In simple use cases like we have above, useState is probably fine, however there is a small problem with our code: we have to provide values to all of the fields in the state object every time we want to use setState. And sometimes, we don't necessarily want to reset other fields when a new request is fired (e.g. in some cases we might still want the user to be able to see the previous error message or data when a new request fires). You might be tempted to do this:

setState({
  ...state,
  isLoading: true,
})

However that means state also becomes a dependency of useEffect - and if you add it to the array of dependencies, you will be greeted with an infinite fetch loop because every time state changes, React will try to call the effect (which in turn, produces a new state).

Luckily we have useReducer - it's somewhat similar to useState here but it allows you to separate your state-updating logic from your component. If you have used redux before, you already know how it works.

If you are new to the concept, you can think a reducer is a function that takes a state and an action then returns a new state. and useReducer is a hook that let you define an initial state, a "reducer" function that will be used to update the state. useReducer returns the most up-to-date state and a function that you will be using to dispatch actions.

const [state, dispatch] = useReducer(reducerFunction, initialState);

Now in our use case here, we've already got our initialState:

{
  isLoading: false,
  data: null,
  error: null,
}

And our state object is updated when the following action happens:

Request Started (sets isLoading to true)
Request Successful
Request Failed

Our reducer function should handle those actions and update the state accordingly. In some actions, (like "request successful") we will also need to provide some extra data to the reducer so it can set them onto the state object. An action can be almost any value (a string, a symbol, or an object), but in most cases we use objects with a type field:

// a request successful action:
{
  type: 'Request Successful', // will be read by the reducer
  data, // data from the api
}

To dispatch an action, we simply call dispatch with the action object:

const [state, dispatch] = useReducer(reducer, initialState);

// fetch ... and dispatch the action below when it is successful
dispatch({
  type: 'Request Successful'
  data: await response.json(),
});

And usually, we use "action creators" to generate those action objects so we don't need to construct them everywhere. Action creators also makes our code easier to change if we want to add additional payloads to an action, or rename types.

// example of action creator:

// a simple function that takes some payload, and returns an action object:
const requestSuccessful = ({ data }) => ({
  type: 'Request Successful',
  data,
});

Often to avoid typing each type string again and again - we can define them separately as constants, so both the action creators and the reducers can re-use them. Typos are very common in programming - typos in strings are often harder to spot, but if you make a typo in a variable or a function call, your editors & browsers will alert you right away.

// a contants.js file

export const REQUEST_STARTED = 'REQUEST_STARTED';
export const REQUEST_SUCCESSFUL = 'REQUEST_SUCCESSFUL';
export const REQUEST_FAILED = 'REQUEST_FAILED';
export const RESET_REQUEST = 'RESET_REQUEST';

// action creators:

export const requestSuccessful = ({ data }) => ({
  type: REQUEST_SUCCESSFUL,
  data,
});

// dispatching an action in our component:

dispatch(requestSuccessful({ data: await response.json() }));

Now, onto our reducer - it updates the state accordingly for each action:

// reducer.js

// a reducer receives the current state, and an action
export const reducer = (state, action) => {
  // we check the type of each action and return an updated state object accordingly
  switch (action.type) {
    case REQUEST_STARTED:
      return {
        ...state,
        isLoading: true,
      };
    case REQUEST_SUCCESSFUL:
      return {
        ...state,
        isLoading: false,
        error: null,
        data: action.data,
      };
    case REQUEST_FAILED:
      return {
        ...state,
        isLoading: false,
        error: action.error,
      };

    // usually I ignore the action if its `type` is not matched here, some people prefer throwing errors here - it's really up to you.
    default:
      return state;
  }
};

Putting it together, our hook now looks like this:

// import our action creators
import {
  requestStarted,
  requestSuccessful,
  requestFailed,
} from './actions.js';
import { reducer } from './reducer.js';

export const useGet = ({ url }) => {
  const [state, dispatch] = useReducer(reducer, {
    isLoading: true,
    data: null,
    error: null,
  });

  useEffect(() => {
    const fetchData = async () => {
      dispatch(requestStarted());

      try {
        const response = await fetch(url);

        if (!response.ok) {
          throw new Error(
            `${response.status} ${response.statusText}`
          );
        }

        const data = await response.json();

        dispatch(requestSuccessful({ data }));
      } catch (e) {
        dispatch(requestFailed({ error: e.message }));
      }
    };

    fetchData();
  }, [url]);

  return state;
};

dispatch is guaranteed to be stable and won't be changed between renders, so it doesn't need to be a dependency of useEffect. Now our hook is much cleaner and easier to be reasoned with.

Now we can start refactoring other components that uses data from a remote source with our new hook!

But There Is More

We are not done yet! However this post is getting a bit too long. Here's the list of things I'd like to cover in a separate article:

Clean up our effect
Use hooks in class-components.
Testing our hooks.
A "re-try" option. Let's give the user an option to retry when a request fails - how do we do that with our new hook?

Stay tuned!