Anda Mungkin Tidak Membutuhkan Effect

Cara menghapus Effect yang tidak perlu

Ada dua kasus umum di mana Anda tidak memerlukan Effects:

• Anda tidak memerlukan Effects untuk melakukan transformasi data untuk rendering. Sebagai contoh, katakanlah Anda ingin melakukan filter terhadap sebuah daftar sebelum menampiklannya. Anda mungkin merasa tergoda untuk menulis Effect yang memperbarui variabel state ketika daftar berubah. Akan tetapi, hal ini tidak efisien. Ketika Anda memperbarui state, React akan memanggil fungsi komponen Anda terlebih dahulu untuk menghitung apa yang seharusnya ada di layar. Kemudian React akan “commit” perubahan ini ke DOM, memperbarui layar. Kemudian React akan menjalankan Effect Anda. Jika Effect Anda juga segera memperbarui state, ini akan mengulang seluruh proses dari awal! Untuk menghindari render pass yang tidak perlu, ubah semua data pada tingkat teratas komponen Anda. Kode tersebut akan secara otomatis dijalankan ulang setiap kali props atau state anda berubah.
• Anda tidak memerlukan Efek untuk menangani event dari pengguna. Sebagai contoh, katakanlah Anda ingin mengirim request POST /api/buy dan menampilkan notifikasi ketika pengguna membeli produk. Di event handler klik tombol Beli, Anda tahu persis apa yang terjadi. Pada saat Effect berjalan, Anda tidak tahu apa yang dilakukan pengguna (misalnya, tombol mana yang diklik). Inilah sebabnya mengapa Anda biasanya akan menangani event pengguna di event handler yang sesuai.

Anda memang membutuhkan Effect untuk melakukan sinkronisasi dengan sistem eksternal. dengan sistem eksternal. Sebagai contoh, Anda dapat menulis sebuah Effect yang membuat widget jQuery tetap tersinkronisasi dengan state React. Anda juga dapat mengambil data dengan Effect: sebagai contoh, Anda dapat menyinkronkan hasil pencarian dengan kueri pencarian saat ini. Perlu diingat bahwa kerangka kerja (framework) modern menyediakan mekanisme pengambilan data bawaan yang lebih efisien daripada menulis Effect secara langsung di dalam komponen Anda.

Untuk membantu Anda mendapatkan intuisi yang tepat, mari kita lihat beberapa contoh konkret yang umum!

Memperbarui state berdasarkan props atau state

Katakanlah Anda memiliki komponen dengan dua variabel state: firstName dan lastName. Anda ingin mendapatkan fullName dengan menggabungkan keduanya. Selain itu, Anda ingin fullName diperbarui setiap kali firstName atau lastName berubah. Naluri pertama Anda mungkin menambahkan variabel state fullName dan memperbaruinya di Effect:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');

  // 🔴 Hindari: state berlebihan dan Effect yang tidak perlu
  const [fullName, setFullName] = useState('');
  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);
  // ...
}

Ini lebih rumit dari yang diperlukan. Ini juga tidak efisien: ia melakukan render pass secara keseluruhan dengan nilai usang untuk fullName, lalu segera me-render ulang dengan nilai yang diperbarui. Hapus variabel state dan Effect:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  // ✅ Baik: dikalkulasi saat render
  const fullName = firstName + ' ' + lastName;
  // ...
}

Ketika sebuah nilai dapat dihitung dari props atau state yang ada, jangan memasukkannya ke dalam state. Sebaiknya, hitunglah saat rendering. Hal ini membuat kode Anda lebih cepat (Anda menghindari pembaruan “bertingkat” tambahan), lebih sederhana (Anda menghapus beberapa kode), dan lebih tidak rawan terhadap error (Anda menghindari bug yang disebabkan oleh variabel state berbeda yang tidak sinkron satu sama lain). Jika pendekatan ini terasa baru bagi Anda, Cara Berpikir dengan React menjelaskan apa yang seharusnya masuk sebagai state.

Menyimpan penghitungan mahal di cache

Komponen ini menghitung visibleTodos dengan mengambil todos yang diterimanya berdasarkan props dan memfilternya berdasarkan prop filter. Anda mungkin tergoda untuk menyimpan hasilnya dalam keadaan dan memperbaruinya dari Effect:

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');

  // 🔴 Hindari: state berlebihan dan Effect yang tidak perlu
  const [visibleTodos, setVisibleTodos] = useState([]);
  useEffect(() => {
    setVisibleTodos(getFilteredTodos(todos, filter));
  }, [todos, filter]);

  // ...
}

Seperti pada contoh sebelumnya, hal ini tidak diperlukan dan tidak efisien. Pertama, hapus state dan Effect-nya:

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');
  // ✅ Ini baik jika getFilteredTodos() tidak lambat.
  const visibleTodos = getFilteredTodos(todos, filter);
  // ...
}

Biasanya, kode ini baik-baik saja! Namun mungkin getFilteredTodos() lambat atau Anda memiliki banyak todos. Dalam hal ini Anda tidak ingin mengkalkulasi ulang getFilteredTodos() jika beberapa variabel state yang tidak terkait seperti newTodo telah berubah.

Anda dapat melakukan cache (atau “memoisasi”) perhitungan yang mahal dengan membungkusnya dalam Hook useMemo:

import { useMemo, useState } from 'react';

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');
  const visibleTodos = useMemo(() => {
    // ✅ Tidak dijalankan ulang kecuali todos atau filter berubah
    return getFilteredTodos(todos, filter);
  }, [todos, filter]);
  // ...
}

Atau, ditulis dalam satu baris:

import { useMemo, useState } from 'react';

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');
  // ✅ Does not re-run getFilteredTodos() unless todos or filter change
  const visibleTodos = useMemo(() => getFilteredTodos(todos, filter), [todos, filter]);
  // ...
}

Hal ini memberitahu React bahwa Anda tidak ingin fungsi di dalamnya dijalankan ulang kecuali todos atau filter telah berubah. React akan mengingat nilai kembalian getFilteredTodos() selama render awal. Selama rendering berikutnya, ia akan memeriksa apakah todos atau filter berbeda. Jika sama dengan yang terakhir kali, useMemo akan mengembalikan hasil terakhir yang disimpannya. Namun jika berbeda, React akan memanggil fungsi di dalamnya lagi (dan menyimpan hasilnya).

Fungsi yang Anda bungkus dalam useMemo berjalan selama rendering, jadi ini hanya berfungsi untuk perhitungan murni.

console.time('filter array');
const visibleTodos = getFilteredTodos(todos, filter);
console.timeEnd('filter array');

console.time('filter array');
const visibleTodos = useMemo(() => {
  return getFilteredTodos(todos, filter); // Skipped if todos and filter haven't changed
}, [todos, filter]);
console.timeEnd('filter array');

Menyetel ulang keseluruhan state ketika props berubah

Komponen ProfilePage ini menerima prop userId. Halaman tersebut berisi input komentar, dan Anda menggunakan variabel state comment untuk menyimpan nilainya. Suatu hari, Anda melihat masalah: saat Anda bernavigasi dari satu profil ke profil lainnya, state comment tidak disetel ulang. Akibatnya, Anda dapat dengan mudah mengirim komentar ke profil pengguna yang salah secara tidak sengaja. Untuk memperbaiki masalah ini, Anda ingin menghapus variabel state comment setiap kali userId berubah:

export default function ProfilePage({ userId }) {
  const [comment, setComment] = useState('');

  // 🔴 Hindari: menyetel ulanh state setiap prop berubah di dalam Effect
  useEffect(() => {
    setComment('');
  }, [userId]);
  // ...
}

Hal ini tidak efisien karena ProfilePage dan turunannya akan di-render terlebih dahulu dengan nilai yang sudah usang, lalu di-render lagi. Ini juga rumit karena Anda harus melakukan ini di setiap komponen yang memiliki state di dalam ProfilePage. Misalnya, jika UI komentar disarangkan, Anda juga ingin menghapus state komentar yang disarangkan.

Sebagai gantinya, Anda dapat memberi tahu React bahwa setiap profil pengguna secara konseptual adalah profil berbeda dengan memberinya key secara eksplisit. Pisahkan komponen Anda menjadi dua dan oper atribut key dari komponen luar ke komponen dalam:

export default function ProfilePage({ userId }) {
  return (
    <Profile
      userId={userId}
      key={userId}
    />
  );
}

function Profile({ userId }) {
  // ✅ State ini dan state lain di bawahnya akan disetel ulang secara otomatis setiap kali key berubah
  const [comment, setComment] = useState('');
  // ...
}

Biasanya, React mempertahankan state ketika komponen yang sama dirender di tempat yang sama. Dengan mengoper userId sebagai key ke komponen Profile, Anda meminta React untuk memperlakukan dua komponen Profile dengan userId yang berbeda sebagai dua komponen berbeda yang tidak boleh berbagi state apa pun. Kapan pun key (yang telah Anda setel ke userId) berubah, React akan membuat ulang DOM dan mengatur ulang state dari komponen Profile dan semua turunannya. Sekarang bidang comment akan dihapus secara otomatis saat bernavigasi antar profil.

Perhatikan bahwa dalam contoh ini, hanya komponen ProfilePage bagian luar yang diekspor dan terlihat oleh file lain dalam proyek. Komponen yang merender ProfilePage tidak perlu meneruskan kuncinya: komponen meneruskan userId sebagai prop biasa. Fakta bahwa ProfilePage meneruskannya sebagai key ke komponen Profile bagian dalam adalah detail implementasi.

Menyesuaikan sebagian state ketika prop berubah

Terkadang, Anda mungkin ingin menyetel ulang atau menyesuaikan sebagian state pada perubahan prop, namun tidak semuanya.

Komponen List ini menerima list item sebagai prop, dan mempertahankan item yang dipilih dalam variabel state selection. Anda ingin menyetel ulang selection ke null setiap kali prop items menerima senarai yang berbeda:

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
  const [selection, setSelection] = useState(null);

  // 🔴 Hindari: Mengatur state saat prop berubah di dalam Effect
  useEffect(() => {
    setSelection(null);
  }, [items]);
  // ...
}

Hal ini juga tidak ideal. Setiap kali items berubah, List dan komponen turunannya akan di-render dengan nilai selection yang usang pada awalnya. Kemudian React akan memperbarui DOM dan menjalankan Effect-nya. Terakhir, panggilan setSelection(null) akan menyebabkan rendering ulang List dan komponen turunannya lagi, sehingga memulai kembali seluruh proses ini.

Mulailah dengan menghapus Effect. Sebagai gantinya, sesuaikan state secara langsung selama rendering:

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
  const [selection, setSelection] = useState(null);

  // Lebih baik: Menyesuaikan state saat rendering
  const [prevItems, setPrevItems] = useState(items);
  if (items !== prevItems) {
    setPrevItems(items);
    setSelection(null);
  }
  // ...
}

Menyimpan informasi dari render sebelumnya seperti ini mungkin sulit untuk dipahami, tetapi ini lebih baik daripada memperbarui state yang sama dalam suatu Effect. Dalam contoh di atas, setSelection dipanggil secara langsung saat render. React akan me-render ulang List segera setelah keluar dengan pernyataan return. React belum merender turunan List atau memperbarui DOM, jadi hal ini memungkinkan turunan List melewatkan rendering nilai selection yang sudah usang.

Saat Anda memperbarui komponen selama rendering, React membuang JSX yang dikembalikan dan segera mencoba lagi rendering. Untuk menghindari percobaan ulang berjenjang yang sangat lambat, React hanya mengizinkan Anda memperbarui state komponen sama selama render. Jika Anda memperbarui state komponen lain selama render, Anda akan melihat error. Kondisi seperti items !== prevItems diperlukan untuk menghindari perulangan. Anda dapat menyesuaikan state seperti ini, namun efek samping lainnya (seperti mengubah DOM atau menyetel batas waktu) harus tetap berada di event handlers atau Effect untuk menjaga komponen tetap murni.

Meskipun pola ini lebih efisien daripada Effect, sebagian besar komponen juga tidak memerlukannya. Bagaimana pun Anda melakukannya, menyesuaikan state berdasarkan props atau state lainnya akan membuat aliran data Anda lebih sulit untuk dipahami dan di-debug. Selalu periksa apakah Anda dapat mengatur ulang semua state dengan key atau menghitung semuanya selama rendering sebagai gantinya. Misalnya, alih-alih menyimpan (dan mengatur ulang) item yang dipilih, Anda dapat menyimpan ID item yang dipilih:

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
  const [selectedId, setSelectedId] = useState(null);
  // ✅ Cara terbaik: Menghitung semuanya saat rendering
  const selection = items.find(item => item.id === selectedId) ?? null;
  // ...
}

Sekarang tidak perlu lagi “menyesuaikan” state. Jika item dengan ID yang dipilih ada dalam daftar, maka item tersebut tetap dipilih. Jika tidak, selection yang dihitung selama rendering akan menjadi null karena tidak ditemukan item yang cocok. Perilaku ini berbeda, namun bisa dibilang lebih baik karena sebagian besar perubahan pada item mempertahankan pilihan.

Berbagi logika antar event handler

Katakanlah Anda memiliki halaman produk dengan dua tombol (Beli dan Checkout) yang memungkinkan Anda membeli produk tersebut. Anda ingin menampilkan notifikasi setiap kali pengguna memasukkan produk ke keranjang. Memanggil showNotification() pada handler klik kedua tombol terasa berulang sehingga Anda mungkin tergoda untuk menempatkan logika ini dalam sebuah Effect:

function ProductPage({ product, addToCart }) {
  // 🔴 Hindari: Logika khusus Event di dalam Effect
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`Added ${product.name} to the shopping cart!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }

  function handleCheckoutClick() {
    addToCart(product);
    navigateTo('/checkout');
  }
  // ...
}

Effect ini tidak diperlukan. Kemungkinan besar juga akan menyebabkan bug. Misalnya, aplikasi Anda “mengingat” keranjang belanja di antara halaman yang dimuat ulang. Jika Anda menambahkan produk ke keranjang satu kali dan me-refresh halaman, notifikasi akan muncul kembali. Ini akan terus muncul setiap kali Anda me-refresh halaman produk tersebut. Hal ini karena product.isInCart sudah menjadi true saat halaman dimuat, sehingga Effect di atas akan memanggil showNotification().

Jika Anda tidak yakin apakah beberapa kode harus berada dalam Effect atau dalam event handler, tanyakan pada diri Anda mengapa kode ini perlu dijalankan. Gunakan Effect hanya untuk kode yang harus dijalankan karena komponen ditampilkan kepada pengguna. Dalam contoh ini, notifikasi akan muncul karena pengguna menekan tombol, bukan karena halaman ditampilkan! Hapus Effect-nya dan masukkan logika bersama ke dalam fungsi yang dipanggil dari kedua event handler:

function ProductPage({ product, addToCart }) {
  // ✅ Baik: Logika khusus event dipanggil dari event handler
  function buyProduct() {
    addToCart(product);
    showNotification(`Added ${product.name} to the shopping cart!`);
  }

  function handleBuyClick() {
    buyProduct();
  }

  function handleCheckoutClick() {
    buyProduct();
    navigateTo('/checkout');
  }
  // ...
}

Hal ini menghilangkan Effect yang tidak perlu dan memperbaiki bug.

Mengirim request POST

Komponen Form ini mengirimkan dua jenis request POST. Ini mengirimkan event analitik saat dipasang. Saat Anda mengisi formulir dan mengklik tombol Kirim, request POST akan dikirim ke endpoint /api/register:

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Baik: Logika ini seharusnya dijalankan karena komponen ditampilkan
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  // 🔴 Hindari: Logika khusus event di dalam Effect
  const [jsonToSubmit, setJsonToSubmit] = useState(null);
  useEffect(() => {
    if (jsonToSubmit !== null) {
      post('/api/register', jsonToSubmit);
    }
  }, [jsonToSubmit]);

  function handleSubmit(e) {
    e.preventDefault();
    setJsonToSubmit({ firstName, lastName });
  }
  // ...
}

Mari kita terapkan kriteria yang sama seperti pada contoh sebelumnya.

Request POST analitik harus tetap dalam Effect. Ini karena alasan mengirim event analitik adalah karena formulir telah ditampilkan. (Ini akan diaktifkan dua kali dalam pengembangan, tetapi lihat di sini untuk mengetahui cara mengatasinya.)

Namun, request POST /api/register tidak disebabkan oleh formulir yang ditampilkan. Anda hanya ingin mengirim permintaan pada satu waktu tertentu: saat pengguna menekan tombol. Ini seharusnya hanya terjadi pada interaksi tertentu. Hapus Effect kedua dan pindahkan request POST tersebut ke dalam event handler:

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Baik: Logika ini dijalankan karena komponen ditampilkan
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  function handleSubmit(e) {
    e.preventDefault();
    // ✅ Baik: Logika khusus event di dalam event handler
    post('/api/register', { firstName, lastName });
  }
  // ...
}

Saat Anda memilih apakah akan memasukkan logika ke dalam event handler atau Effect, pertanyaan utama yang perlu Anda jawab adalah logika macam apa dari sudut pandang pengguna. Jika logika ini disebabkan oleh interaksi tertentu, simpan logika tersebut di event handler. Jika hal ini disebabkan oleh pengguna melihat komponen di layar, simpan di Effect.

Rantai komputasi

Terkadang Anda mungkin tergoda untuk membuat Effect berantai yang masing-masing menyesuaikan suatu bagian state berdasarkan state lainnya:

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);
  const [isGameOver, setIsGameOver] = useState(false);

  // 🔴 Hindari: Rantai Effect yang menyesuaikan state hanya untuk memicu Effect satu sama lain
  useEffect(() => {
    if (card !== null && card.gold) {
      setGoldCardCount(c => c + 1);
    }
  }, [card]);

  useEffect(() => {
    if (goldCardCount > 3) {
      setRound(r => r + 1)
      setGoldCardCount(0);
    }
  }, [goldCardCount]);

  useEffect(() => {
    if (round > 5) {
      setIsGameOver(true);
    }
  }, [round]);

  useEffect(() => {
    alert('Good game!');
  }, [isGameOver]);

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    } else {
      setCard(nextCard);
    }
  }

  // ...

Ada dua masalah dengan kode ini.

Salah satu masalahnya adalah hal ini sangat tidak efisien: komponen (dan turunannya) harus di-render ulang di antara setiap panggilan set dalam rantai. Dalam contoh di atas, dalam kasus terburuk (setCard → render → setGoldCardCount → render → setRound → render → setIsGameOver → render) ada tiga rendering ulang yang tidak diperlukan pada pohon di bawah ini.

Meskipun tidak lambat, seiring berkembangnya kode Anda, Anda akan menghadapi kasus di mana “rantai” yang Anda tulis tidak sesuai dengan persyaratan baru. Bayangkan Anda menambahkan cara untuk menelusuri sejarah gerakan permainan. Anda akan melakukannya dengan memperbarui setiap variabel state ke nilai dari masa lalu. Namun, menyetel state card ke nilai dari masa lalu akan memicu rantai Effect lagi dan mengubah data yang Anda tampilkan. Kode seperti ini seringkali kaku dan rapuh.

Dalam hal ini, lebih baik menghitung apa yang Anda bisa selama rendering, dan sesuaikan state di event handler:

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);

  // ✅ Hitung apa yang Anda bisa saat render
  const isGameOver = round > 5;

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    }

    // ✅ Hitung keseluruhan state selanjutnya dalam event handler
    setCard(nextCard);
    if (nextCard.gold) {
      if (goldCardCount <= 3) {
        setGoldCardCount(goldCardCount + 1);
      } else {
        setGoldCardCount(0);
        setRound(round + 1);
        if (round === 5) {
          alert('Good game!');
        }
      }
    }
  }

  // ...

Ini jauh lebih efisien. Selain itu, jika Anda menerapkan cara untuk melihat riwayat game, sekarang Anda akan dapat menyetel setiap variabel state ke pergerakan dari masa lalu tanpa memicu rantai Effect yang menyesuaikan setiap nilai lainnya. Jika Anda perlu menggunakan kembali logika antara beberapa event handler, Anda dapat mengekstrak fungsi dan memanggilnya dari handler tersebut.

Ingat bahwa di dalam event handler, state berperilaku seperti snapshot. Misalnya, bahkan setelah Anda memanggil setRound(round + 1), variabel round akan mencerminkan nilai pada saat pengguna mengklik tombol. Jika Anda perlu menggunakan nilai berikutnya untuk penghitungan, tentukan secara manual seperti const nextRound = round + 1.

Dalam beberapa kasus, Anda tidak dapat menghitung state berikutnya secara langsung di event handler. Misalnya, bayangkan sebuah formulir dengan beberapa dropdown di mana pilihan dropdown berikutnya bergantung pada nilai yang dipilih dari dropdown sebelumnya. Kemudian, rangkaian Effect sesuai karena Anda melakukan sinkronisasi dengan jaringan.

Initializing the application

Some logic should only run once when the app loads.

You might be tempted to place it in an Effect in the top-level component:

function App() {
  // 🔴 Avoid: Effects with logic that should only ever run once
  useEffect(() => {
    loadDataFromLocalStorage();
    checkAuthToken();
  }, []);
  // ...
}

However, you’ll quickly discover that it runs twice in development. This can cause issues—for example, maybe it invalidates the authentication token because the function wasn’t designed to be called twice. In general, your components should be resilient to being remounted. This includes your top-level App component.

Although it may not ever get remounted in practice in production, following the same constraints in all components makes it easier to move and reuse code. If some logic must run once per app load rather than once per component mount, add a top-level variable to track whether it has already executed:

let didInit = false;

function App() {
  useEffect(() => {
    if (!didInit) {
      didInit = true;
      // ✅ Only runs once per app load
      loadDataFromLocalStorage();
      checkAuthToken();
    }
  }, []);
  // ...
}

You can also run it during module initialization and before the app renders:

if (typeof window !== 'undefined') { // Check if we're running in the browser.
   // ✅ Only runs once per app load
  checkAuthToken();
  loadDataFromLocalStorage();
}

function App() {
  // ...
}

Code at the top level runs once when your component is imported—even if it doesn’t end up being rendered. To avoid slowdown or surprising behavior when importing arbitrary components, don’t overuse this pattern. Keep app-wide initialization logic to root component modules like App.js or in your application’s entry point.

Notifying parent components about state changes

Let’s say you’re writing a Toggle component with an internal isOn state which can be either true or false. There are a few different ways to toggle it (by clicking or dragging). You want to notify the parent component whenever the Toggle internal state changes, so you expose an onChange event and call it from an Effect:

function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);

  // 🔴 Avoid: The onChange handler runs too late
  useEffect(() => {
    onChange(isOn);
  }, [isOn, onChange])

  function handleClick() {
    setIsOn(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      setIsOn(true);
    } else {
      setIsOn(false);
    }
  }

  // ...
}

Like earlier, this is not ideal. The Toggle updates its state first, and React updates the screen. Then React runs the Effect, which calls the onChange function passed from a parent component. Now the parent component will update its own state, starting another render pass. It would be better to do everything in a single pass.

Delete the Effect and instead update the state of both components within the same event handler:

function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);

  function updateToggle(nextIsOn) {
    // ✅ Good: Perform all updates during the event that caused them
    setIsOn(nextIsOn);
    onChange(nextIsOn);
  }

  function handleClick() {
    updateToggle(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      updateToggle(true);
    } else {
      updateToggle(false);
    }
  }

  // ...
}

With this approach, both the Toggle component and its parent component update their state during the event. React batches updates from different components together, so there will only be one render pass.

You might also be able to remove the state altogether, and instead receive isOn from the parent component:

// ✅ Also good: the component is fully controlled by its parent
function Toggle({ isOn, onChange }) {
  function handleClick() {
    onChange(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      onChange(true);
    } else {
      onChange(false);
    }
  }

  // ...
}

“Lifting state up” lets the parent component fully control the Toggle by toggling the parent’s own state. This means the parent component will have to contain more logic, but there will be less state overall to worry about. Whenever you try to keep two different state variables synchronized, try lifting state up instead!

Passing data to the parent

This Child component fetches some data and then passes it to the Parent component in an Effect:

function Parent() {
  const [data, setData] = useState(null);
  // ...
  return <Child onFetched={setData} />;
}

function Child({ onFetched }) {
  const data = useSomeAPI();
  // 🔴 Avoid: Passing data to the parent in an Effect
  useEffect(() => {
    if (data) {
      onFetched(data);
    }
  }, [onFetched, data]);
  // ...
}

In React, data flows from the parent components to their children. When you see something wrong on the screen, you can trace where the information comes from by going up the component chain until you find which component passes the wrong prop or has the wrong state. When child components update the state of their parent components in Effects, the data flow becomes very difficult to trace. Since both the child and the parent need the same data, let the parent component fetch that data, and pass it down to the child instead:

function Parent() {
  const data = useSomeAPI();
  // ...
  // ✅ Good: Passing data down to the child
  return <Child data={data} />;
}

function Child({ data }) {
  // ...
}

This is simpler and keeps the data flow predictable: the data flows down from the parent to the child.

Subscribing to an external store

Sometimes, your components may need to subscribe to some data outside of the React state. This data could be from a third-party library or a built-in browser API. Since this data can change without React’s knowledge, you need to manually subscribe your components to it. This is often done with an Effect, for example:

function useOnlineStatus() {
  // Not ideal: Manual store subscription in an Effect
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    function updateState() {
      setIsOnline(navigator.onLine);
    }

    updateState();

    window.addEventListener('online', updateState);
    window.addEventListener('offline', updateState);
    return () => {
      window.removeEventListener('online', updateState);
      window.removeEventListener('offline', updateState);
    };
  }, []);
  return isOnline;
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

Here, the component subscribes to an external data store (in this case, the browser navigator.onLine API). Since this API does not exist on the server (so it can’t be used for the initial HTML), initially the state is set to true. Whenever the value of that data store changes in the browser, the component updates its state.

Although it’s common to use Effects for this, React has a purpose-built Hook for subscribing to an external store that is preferred instead. Delete the Effect and replace it with a call to useSyncExternalStore:

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function useOnlineStatus() {
  // ✅ Good: Subscribing to an external store with a built-in Hook
  return useSyncExternalStore(
    subscribe, // React won't resubscribe for as long as you pass the same function
    () => navigator.onLine, // How to get the value on the client
    () => true // How to get the value on the server
  );
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

This approach is less error-prone than manually syncing mutable data to React state with an Effect. Typically, you’ll write a custom Hook like useOnlineStatus() above so that you don’t need to repeat this code in the individual components. Read more about subscribing to external stores from React components.

Fetching data

Many apps use Effects to kick off data fetching. It is quite common to write a data fetching Effect like this:

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);
  }
  // ...
}

You don’t need to move this fetch to an event handler.

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.

However, the code above has a bug. Imagine you type "hello" fast. Then the query will change from "h", to "he", "hel", "hell", and "hello". This will kick off separate fetches, but there is no guarantee about which order the responses will arrive in. For example, the "hell" response may arrive after the "hello" response. Since it will call setResults() last, you will be displaying the wrong search results. This is called a “race condition”: two different requests “raced” against each other and came in a different order than you expected.

To fix the race condition, you need to add a cleanup function to ignore stale responses:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);
  useEffect(() => {
    let ignore = false;
    fetchResults(query, page).then(json => {
      if (!ignore) {
        setResults(json);
      }
    });
    return () => {
      ignore = true;
    };
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

This ensures that when your Effect fetches data, all responses except the last requested one will be ignored.

Handling race conditions is not the only difficulty with implementing data fetching. You might also want to think about caching responses (so that the user can click Back and see the previous screen instantly), how to fetch data on the server (so that the initial server-rendered HTML contains the fetched content instead of a spinner), and how to avoid network waterfalls (so that a child can fetch data without waiting for every parent).

These issues apply to any UI library, not just React. Solving them is not trivial, which is why modern frameworks provide more efficient built-in data fetching mechanisms than fetching data in Effects.

If you don’t use a framework (and don’t want to build your own) but would like to make data fetching from Effects more ergonomic, consider extracting your fetching logic into a custom Hook like in this example:

function SearchResults({ query }) {
  const [page, setPage] = useState(1);
  const params = new URLSearchParams({ query, page });
  const results = useData(`/api/search?${params}`);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

function useData(url) {
  const [data, setData] = useState(null);
  useEffect(() => {
    let ignore = false;
    fetch(url)
      .then(response => response.json())
      .then(json => {
        if (!ignore) {
          setData(json);
        }
      });
    return () => {
      ignore = true;
    };
  }, [url]);
  return data;
}

You’ll likely also want to add some logic for error handling and to track whether the content is loading. You can build a Hook like this yourself or use one of the many solutions already available in the React ecosystem. Although this alone won’t be as efficient as using a framework’s built-in data fetching mechanism, moving the data fetching logic into a custom Hook will make it easier to adopt an efficient data fetching strategy later.

In general, whenever you have to resort to writing Effects, keep an eye out for when you can extract a piece of functionality into a custom Hook with a more declarative and purpose-built API like useData above. The fewer raw useEffect calls you have in your components, the easier you will find to maintain your application.