I’m glad this topic has drawn you to 😃.

To get down to business:

The following scenarios are available:

An input search box, a submit button, click on the button back end to initiate a query request, I’m sure you’re all familiar with the scenario.

Until one day, everyone has to eat and laugh of drinking afternoon tea 🍵, the product manager called me, said: this query can really be used, but every time I point query button just real search, can the user edge input edge query? 🤔

It is of course very simple to implement, but in order to make the product no longer make excessive demands, I put down my afternoon tea, pretended to meditate for a while 🤔, smiled and said no problem 👌.

The next step is to do something familiar on the front end, which is to trigger the request event in onChange.

const Demo = () = > {
  const handleChange = () = > {
    return fetch('https://pagead2.googlesyndication.com/getconfig/sodar?sv=200&tid=gda&tv=r20211207&st=env'); // simulate the request
  };
  return <Input onChange={handleChange} />;
};

Copy the code

Write the submission code, continue to eat tea 🍵, continue to fish 🐟.

Led two days, hind end top wear a bereavement face to come over to look for me to say: your front end how do of, query interface hair all the time, server fast top not live 😭.

I head a pat, think, oh! The original oncChange did not do shake, then add to bai, this is not a small case 😎.

One line of code to fix 😎

const Demo = () = > {
  const handleChange = () = > {
    return fetch('https://pagead2.googlesyndication.com/getconfig/sodar?sv=200&tid=gda&tv=r20211207&st=env'); // simulate the request
  };
  return <Input onChange={debounce(handleChange, 1000)} / >;
};

Copy the code

Almost another two days, to the day of interaction, is touching 🐟, test rushed to run over, your front end search results with input is not on 😭, hurriedly to solve it, can not solve today is not allowed to go off work!

I thought to myself, this search box can not god, unhurried inquiry how to reproduce.

The user entered 1, 2, and 3 in sequence. However, the requests were not returned in this order, as shown in the following figure:

Although request 2 and request 3 are sent later, the response is faster than request 1. When request 1 completes, the previous request data will be reset, so the page will display the response result of request 1, which is not what the user expected.

So how do you solve this? (It’s time to get serious!)

In fact, there are many ways to solve the problem, and the author mainly talks about best practice here.

Fetch can solve this problem through its own ABORT API. The core idea is to terminate the previous request when the same request is sent later to solve the problem of response data coverage.

Note that abort is not really an interrupt request. The request is issued normally, but the response is not handled by the front end.

The general code is as follows:

const Demo = () = > {
  const [inputVal, setInputVal] = useState(' ');
  const onInputChange = useCallback((e) = > setInputVal(e.target.value));

  useEffect(() = > {
    const abortController = new window.AbortController();
    const signal = abortController.signal;
    fetch('https://pagead2.googlesyndication.com/getconfig/sodar?sv=200&tid=gda&tv=r20211207&st=env', { signal });
    return () = > {
      if(signal && abortController.abort) { abortController.abort(); }}; }, [inputVal]);return <input type="text" value={inputVal} onChange={onInputChange} />;
};
Copy the code

End result:

Application scenario: Search box, quick Tab switching, etc.

Finally, the above story is pure fiction 😂, you have any better ideas welcome to leave a message 💬.