Dilema Framer dan Kode Kustom

Framer pada dasarnya adalah alat pembuatan situs web tanpa kode. Namun, semua situs pada dasarnya adalah aplikasi yang dibangun dengan React, dan pengguna dapat menambahkan komponen React atau override yang sudah dikustomisasi kapan saja.

Masalahnya muncul ketika komponen di aplikasi React mengalami kesalahan, struktur aplikasi secara keseluruhan akan rusak, dan layar hanya menyisakan halaman putih kosong.

Sebelumnya, situs Framer juga berfungsi demikian. Jika ada kode kustom yang salah, seluruh situs akan berhenti. Untuk memperbaikinya, kami memulai pendekatan baru musim dingin ini. Tujuannya adalah agar meskipun ada kode kustom yang rusak, hanya komponen yang bersangkutan yang disembunyikan, sementara situs lainnya berfungsi normal.
Selanjutnya, kita akan mempelajari cara menangani kesalahan di React.

Level 1: Jangkauan Error (Error Boundaries)

Secara permukaan, error boundaries di React ada untuk situasi seperti ini. Membungkus jangkauan kesalahan dari setiap komponen kode kustom → menangkap kesalahan → render null (nilai kosong) → selesai, di mana error boundary berfungsi untuk menyembunyikan bagian yang mengalami kesalahan.

class ErrorBoundary extends React.Component {
  static getDerivedStateFromError(error) {
    return { hasError: true }
  }

  render() {
    return this.state.hasError ? null : this.props.children
  }
}

Dengan membungkus setiap komponen kode kustom seperti ini, meskipun terjadi kesalahan, jika hanya null yang dirender, kode lainnya akan tetap aman. Namun, ada juga masalah di sini.

Error boundary di React hanya berfungsi di klien. Selama rendering sisi server, itu sepenuhnya diabaikan. Oleh karena itu, jika rendering di server gagal, halaman itu sendiri tidak dapat dioptimalkan dan kinerja pun berkurang.

Level 2: Suspense

Saat rendering server, React mengabaikan batas kesalahan. Sebaliknya, jika terjadi kesalahan di sisi server, React akan mencari <Suspense> terdekat dan merender kode pengganti untuk itu.

Oleh karena itu, untuk menyembunyikan komponen yang bermasalah, diperlukan dua jenis error boundaries: satu untuk klien dan satu lagi untuk server.

class ClientErrorBoundary extends React.Component {
  // 위와 동일
}

function ServerErrorBoundary({ children }) {
  return <Suspense fallback={null}>{children}</Suspense>
}

function ErrorBoundary({ children }) {
  return (
    <ServerErrorBoundary>
      <ClientErrorBoundary>
        {children}
      </ClientErrorBoundary>
    </ServerErrorBoundary>
  )
}

Tetapi membungkus semua kode dengan <Suspense> menghadirkan beberapa kesulitan. Selain menangani kesalahan di server, ada banyak tugas lain yang harus dilakukan.

Level 3: Banyak Fungsi Suspense

<Suspense> tidak hanya memiliki fungsi menangkap kesalahan, tetapi juga melakukan banyak operasi secara bersamaan. <Suspense> adalah fitur yang cukup mendasar dan menurut perkiraan tahun 2025 memberikan fungsi-fungsi seperti di bawah ini.

• <Suspense> server:

  1. Jika sesuatu terhenti, merender kode pengganti (dapat dilewati dengan stream.allReady)

  2. Jika terjadi kesalahan, merender kode pengganti

• <Suspense> klien:

  1. Jika sesuatu terhenti, merender kode pengganti (dapat dilewati dengan startTransition())

  2. Dukungan hidrasi selektif dan simultan

Apa yang terjadi ketika kode pengguna terhenti selama rendering?

export function MyCodeComponent() {
  const weather = use(weatherPromise)
  return <div>It’s {weather.temperature}° outside!</div>
}

Di server, Anda dapat menggunakan stream.allReady untuk menunggu hingga kode yang terhenti (suspend) selesai. Namun di klien, situasinya berbeda. Jika komponen terhenti, <Suspense> di dalam <ServerErrorBoundary> merender null yang disetel sebagai kode pengganti untuk sementara waktu. Ini menyebabkan komponen menghilang dari layar sebelum muncul kembali, menciptakan efek flash.

Tentu saja, jika kode yang membungkus komponen dijalankan di dalam startTransition, Anda dapat menghindari kejadian ini, tetapi kita tidak bisa mengendalikan kode pengguna. Akibatnya, pengguna cukup mengalami UX buruk ketika komponen menghilang sesaat saat data sedang diambil.

Bagaimana kita bisa menyelesaikan masalah ini?

Kami bisa mencoba menghindari merender <ServerErrorBoundary> di klien sama sekali. Tetapi ini akan menciptakan ketidakcocokan hidrasi.

Sebabnya adalah karena <ServerErrorBoundary> merender <Suspense> di dalamnya. <Suspense> tidak membuat elemen DOM sebenarnya, sebaliknya, ini menghasilkan komentar khusus (seperti <!--$-->). Komentar ini perlu ditemukan dan dinyatakan sebagai 'sama' oleh klien selama proses hidrasi. Namun, jika kita menghapus <ServerErrorBoundary> di klien, komentar-komentar tersebut hilang. Lalu React akan menganggap server dan klien berbeda dan memunculkan kesalahan.

Bagaimana jika kita menghapus komentar khusus <Suspense> sebelum hidrasi dimulai? Itu juga tidak akan berhasil. Jika kode pengguna merender null karena kesalahan di server, tetapi berfungsi normal (seperti merender JSX yang benar) di klien, hasil antara server dan klien akan berbeda. Ini menyebabkan ketidakcocokan hidrasi dan akhirnya masalah seluruh root di-remount.

Bagaimana jika kita secara sengaja membuat bagian dalam fallback di <Suspense> berhenti? Ini bisa berhasil tetapi aturannya adalah ini: "Jika <Suspense> merender fallback (elemen pengganti) dan fallback itu sendiri berhenti, React akan mengabaikan boundary <Suspense> tersebut."

Artinya, jika fallback berhenti sendiri, <Suspense> dianggap tidak ada.

function SuspenseThatIsIgnored({ children }) {
  return <Suspense fallback={<Suspend />}>{children}</Suspense>
}

function Suspend() {
  use(someInfinitePromise)
}

Dokumen hanya menyebut bahwa itu diaktifkan dalam boundary <Suspense> utama, tetapi bahkan jika tidak ada boundary utama, bisa berperilaku seolah tidak ada boundary. Ini memungkinkan Anda menjaga operasi yang diinginkan tanpa kedipan.

Mengandalkan operasi yang tidak didokumentasikan tentu berisiko, tetapi ini bisa menjadi solusi yang cukup stabil dalam jangka pendek, bukan?

Level 4: Komponen Eksternal

Mari membuat ini sedikit lebih rumit. Dalam FramerFramer, Anda tidak hanya dapat menulis kode langsung tetapi juga menggunakan kembali kode yang ditulis orang lain. Selain itu, kode ini bisa tertanam dalam UI tanpa kode yang dibuat orang lain.

Ini bisa membuat implementasi menjadi lebih rumit. Misalnya, apa yang terjadi jika komponen Form yang ditentukan pengguna memiliki kode Input di dalamnya dan Input itu mengalami kesalahan? Haruskah kita hanya menyembunyikan elemen Input yang berbenturan dengan boundary?

Menurut filosofi Framer, Form seharusnya terlihat seperti satu unit ‘buram’ oleh pembuat situs. Karena bukan komponen mereka, mereka tidak bisa melihat ke dalamnya. Jadi ketika boundary berbenturan, tidak hanya bagian dalamnya yang rusak sebagian, tetapi seluruh Form seharusnya hancur bersama-sama. Dengan begitu, pembuat dapat memahami situasi benturan dengan lebih intuitif.

Level 5…N: Masalah Terakhir

Izinkan saya memperkenalkan masalah terakhir yang harus kami selesaikan.

• Selain komponen kode, Framer juga mendukung kode override, jadi kita harus mempertimbangkan Code Boundaries untuk mencakup kasus ini.

• Banyak kesalahan kode pada dasarnya sulit untuk dipahami, terutama saat kode dikompres. Oleh karena itu, kami harus mengembangkan alat baru untuk dengan mudah menemukan komponen mana yang mengalami kesalahan.

Ini dimulai dengan sekadar menyelesaikan error boundary React, namun setelah menyelesaikan berbagai tantangan yang melibatkan perbedaan lingkungan server dan klien, operasi kompleks Suspense, dan penggunaan kembali kode eksternal, akhirnya kami memperbarui Code Boundaries.

Artikel ini adalah adaptasi dan terjemahan dari konten blog resmi Framer, 'Rabbit hole of React error handling'.