[Suggestion]: Wrong example in fetching data section on You Might not need a Effect Page

Inizia dalla sezione Fetching Data della pagina You Might Not Need an Effect e confronta il suo esempio con le indicazioni circostanti sui gestori degli eventi e sulla condivisione della logica. Esamina gli scenari proposti relativi all’URL e alla paginazione, quindi aggiorna la documentazione solo se la spiegazione distingue in modo coerente gli eventi dell’utente dalla sincronizzazione; il lavoro è concluso quando l’esempio e il testo circostante non danno più indicazioni contraddittorie.

Summary

In the Fetching Data Section of You might not need an effect is solving for different scenario with different problem altogether which will a create a confusion whether it requires a effect or not

Page

https://react.dev/learn/you-might-not-need-an-effect#fetching-data

Details

The Fetching Data Section of You might not need an effect is solving a different scenario with a different problem altogether.

In this code block:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);
  useEffect(() => {
    // 🔴 Avoid: Fetching without cleanup logic
    fetchResults(query, page).then(json => {
      setResults(json);
    });
  }, [query, page]);
  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

The documentation mentions that:

This might seem like a contradiction with the earlier examples where you needed to put the logic into the event handlers! However, consider that it's not the typing event that's the main reason to fetch. Search inputs are often prepopulated from the URL, and the user might navigate Back and Forward without touching the input.

It doesn't matter where page and query come from. While this component is visible, you want to keep results synchronized with data from the network for the current page and query. This is why it's an Effect.

This encourages people to add page as a dependency in the useEffect and also categorize the page change event as an effect altogether. But page changes are user events (wrt to the context like the results are shown in a table), and the documentation should encourage people to fetch data inside the change handler rather than using an effect (similar to how we encourage handling POST request on a form).

Regarding the URL scenario: let's say the user goes to page 3, navigates to a different page, and comes back again. The URL page param should be read inside the effect callback like this:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(new URLSearchParams(window.location.search).get("page"));
  
  useEffect(() => {
    const urlSearchParams = new URLSearchParams(window.location.search);
    const currentPage = urlSearchParams.get("page");
    fetchResults(query, currentPage).then(json => {
      setResults(json);
    });
  }, [query]);
  
  function handleNextPageClick() {
    setPage(page + 1);
    fetchResults(query, page + 1).then(json => {
      setResults(json);
    });
  }
  // ...
}

This way, page can be removed as a dependency altogether, and the effect only runs whenever the query changes while always getting the latest page param value. When the page is changed by the user, the fetch should be invoked inside handleNextPageClick since page change is an event.

The earlier example will result in more confusion, and people will add things that should be inside the event handler into the effect with dependencies, making Event handlers sharing logic obsolete too. This also make the people aware on avoiding the "setState triggers effect" pattern for user events and follows the same principle on removing effects and using events properly as the article intended.