Jelajahi bagaimana React karya Jordan Walke memperkenalkan komponen yang dapat digunakan ulang, UI deklaratif, dan rendering berbasis state—mengubah arsitektur frontend modern.
Jordan Walke adalah seorang software engineer yang paling dikenal karena menciptakan React saat bekerja di Facebook. Sebelum React, frontend sering dibangun di sekitar halaman, template, dan tumpukan “glue code” yang mencoba menyinkronkan HTML, CSS, dan JavaScript. Ide kunci Walke adalah membalik model: alih-alih memperlakukan UI sebagai sekumpulan dokumen yang Anda tambal dari waktu ke waktu, perlakukan UI sebagai pohon komponen kecil yang dapat dipakai ulang yang Anda susun menjadi fitur lebih besar.
Ini bukan sekadar library baru—ini cara berpikir baru tentang pekerjaan UI. Sebuah komponen mengemas sepotong antarmuka dengan logika dan state yang dibutuhkan, lalu mengekspose antarmuka bersih (props) ke seluruh aplikasi. Itu membuat membangun UI terasa lebih seperti menyusun balok Lego daripada mengedit satu halaman yang rapuh.
React penting karena membantu tim:
Kita akan menjelaskan ide praktis yang membuat React berpengaruh:
Anda tidak perlu menjadi ahli framework untuk mengikuti. Tujuannya adalah memperjelas model mental—agar Anda bisa mengenali pola React yang baik, menghindari kesalahpahaman umum, dan menerapkan prinsip yang sama bahkan di luar React.
Sebelum React, banyak tim membangun antarmuka kaya dengan menambal template, manipulasi DOM ala jQuery, dan tumpukan aturan “ketika X terjadi, perbarui Y”. Itu bekerja—sampai UI menjadi sibuk.
Polanya sering: ambil data, render HTML, lalu pasang event handler yang memutasi DOM secara langsung. Saat state berubah (item baru, error validasi, toggle), seseorang harus ingat setiap tempat yang bergantung padanya.
Itu menyebabkan bug seperti:
Seiring layar berkembang, aturan bisnis yang sama berakhir terduplikasi di banyak handler: “nonaktifkan tombol jika field kosong,” “sorot item belum dibaca,” “tampilkan empty state jika tidak ada hasil.” Saat kebutuhan berubah, Anda harus memburu file yang tidak terkait untuk memperbarui setiap salinan.
Data bisa dimodelkan dengan beberapa struktur jelas: daftar post, objek user, sekumpulan filter. UI, bagaimanapun, menambahkan kombinasi: loading vs loaded, error vs success, dibaca vs belum dibaca, mengedit vs melihat, terfilter vs tidak—seringkali sekaligus.
Bayangkan sebuah news feed:
Tanpa aturan prediktabel seperti “UI adalah fungsi dari state,” Anda akan mengoordinasikan banyak edit DOM yang bisa saling bertentangan. Tujuan React adalah membuat pembaruan dapat diandalkan: ubah data/state, dan UI me-render ulang untuk menyesuaikan—setiap kali.
Sebuah komponen adalah potongan kecil antarmuka yang bisa Anda beri nama, pakai ulang, dan pahami sendiri. Dalam bahasa sederhana: sebuah komponen menerima input, dan mengembalikan bagaimana UI seharusnya terlihat untuk input tersebut.
Pembingkaian “input → output” inilah inti model komponen. Alih-alih memperlakukan layar sebagai satu template besar, Anda membaginya menjadi blok bangunan yang bertujuan—tombol, kartu, menu, form, hingga bagian lengkap—lalu menyusunnya.
Di React, input yang paling umum adalah props (singkatan dari “properties”). Props adalah nilai yang Anda sertakan ke dalam sebuah komponen untuk mengkonfigurasinya: teks, angka, flag, event handler, atau bahkan UI lain.
Outputnya adalah UI yang dirender komponen. Jika props berubah, komponen bisa menghasilkan output berbeda—tanpa Anda harus berburu manual di mana memperbarui DOM.
Misalnya, komponen Button mungkin menerima props seperti label, disabled, dan onClick. UserCard mungkin menerima name, avatarUrl, dan status. Anda bisa membaca antarmuka komponen (props) seperti spes produk: “Apa yang dibutuhkan UI ini agar dapat dirender dengan benar?”
Memecah UI menjadi komponen memberi manfaat cepat:
Modal, Input, atau Dropdown yang sama bisa muncul di banyak halaman.Ini adalah pergeseran besar dari menyalin dan mengubah markup per halaman. Komponen membuat duplikasi terasa tak perlu—dan akhirnya, tidak dapat diterima.
React mendorong Anda merancang UI seperti merancang sistem: sebagai bagian yang dapat dikomposisi. Halaman “Checkout” menjadi pohon komponen—CheckoutPage berisi OrderSummary, ShippingForm, dan PaymentMethod. Setiap bagian punya input yang jelas dan tanggung jawab yang jelas.
Perubahan ini—memikirkan komponen terlebih dahulu—adalah alasan utama React mengubah arsitektur frontend. Ia memberi tim unit bersama untuk desain dan pengembangan: komponen.
Perubahan mental terbesar React adalah UI deklaratif: Anda mendeskripsikan seperti apa antarmuka untuk sebuah state, dan React menangani memperbarui halaman saat state itu berubah.
Alih-alih mencari elemen, mengubah teks, men-toggle class, dan menjaga DOM tetap sinkron, Anda fokus pada “bentuk” UI. Saat data berubah, UI dideskripsikan ulang, dan React menentukan set minimal perubahan yang diperlukan.
JSX adalah cara praktis menulis struktur komponen dengan sintaks yang mirip HTML di dalam JavaScript. Bukan bahasa templating baru yang harus Anda pelajari dari nol; ini adalah shorthand untuk “komponen ini merender pohon elemen ini.”
Manfaat utamanya adalah markup dan logika yang memutuskan apa yang ditampilkan hidup bersama, sehingga komponen lebih mudah dipahami secara terpisah.
Kode imperatif fokus pada bagaimana memperbarui UI langkah demi langkah:
// Imperatif: secara manual menjaga DOM tetap sinkron
function setLoggedIn(isLoggedIn) {
const el = document.querySelector('#status');
el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
el.classList.toggle('ok', isLoggedIn);
el.classList.toggle('warn', !isLoggedIn);
}
Kode deklaratif fokus pada apa UI seharusnya untuk state saat ini:
function Status({ isLoggedIn }) {
return (
\u003cp className={isLoggedIn ? 'ok' : 'warn'}\u003e
{isLoggedIn ? 'Welcome back' : 'Please sign in'}
\u003c/p\u003e
);
}
Karena rendering diekspresikan sebagai deskripsi murni, komponen cenderung lebih mudah dibaca, lebih mudah direview, dan lebih sederhana untuk direfaktor. Desainer, engineer yang berfokus produk, dan rekan baru sering dapat mengikuti JSX tanpa memburu handler event dan mutasi DOM.
Kejelasan ini meningkatkan kolaborasi: keputusan UI terlihat di satu tempat, dan perubahan kecil kemungkinannya menciptakan efek samping tersembunyi di tempat lain.
"State" hanyalah data yang dapat berubah seiring interaksi pengguna dengan UI. Bisa berupa teks saat ini di kotak pencarian, apakah menu terbuka, item di keranjang, atau hasil permintaan jaringan. Jika itu bisa berubah dan layar harus mencerminkan perubahan itu, maka itu state.
Langkah kunci React adalah memperlakukan rendering sebagai konsekuensi dari state, bukan rangkaian langkah DOM manual. Anda mendeskripsikan seperti apa UI untuk sebuah state. Saat state diperbarui, React me-render ulang bagian relevan.
Model mental ini berbeda dari “temukan elemen, lalu perbarui teksnya, lalu toggle class ini.” Sebaliknya, Anda memperbarui state, dan UI memperbarui secara alami karena bersumber dari state itu.
Aliran data satu arah berarti data bergerak satu arah:
Ini mengurangi kejutan karena Anda bisa mengikuti jalur pembaruan: sebuah event terjadi, state berubah di satu tempat, dan UI me-render ulang dari state baru itu. Lebih sedikit ambiguitas “siapa yang mengubah nilai ini?”.
function Counter() {
const [count, setCount] = React.useState(0);
return (
\u003cdiv\u003e
\u003cp\u003eCount: {count}\u003c/p\u003e
\u003cbutton onClick={() =\u003e setCount(count + 1)}\u003eAdd\u003c/button\u003e
\u003c/div\u003e
);
}
Di sini, count adalah state. Klik tombol memperbarui state lewat setCount. React lalu me-render ulang, dan paragraf menampilkan angka baru. Anda tidak pernah secara langsung “mengedit DOM.”
Pola yang sama bisa diskalakan untuk memfilter daftar (state = teks filter, UI = item yang difilter) atau validasi form (state = nilai field dan error, UI = pesan). Data berubah dulu; tampilan adalah hasilnya.
Gagasan kunci React bukanlah “menggambar ulang halaman lebih cepat.” Ini: perlakukan UI sebagai hasil dari state, dan saat state berubah, bandingkan apa yang Anda inginkan sekarang dengan apa yang Anda punya sebelumnya—lalu perbarui hanya yang benar-benar berubah.
Ketika state atau props sebuah komponen berubah, React memanggil komponen Anda lagi untuk menghasilkan deskripsi UI baru. Pikirkan seperti mengambil dua snapshot:
Daripada membersihkan DOM dan membangunnya ulang, React mencoba menghitung set operasi DOM terkecil yang diperlukan untuk berpindah dari A ke B.
"Virtual DOM" adalah representasi ringan di memori dari UI milik React—sebuah pohon elemen dan output komponen yang mendeskripsikan apa yang seharusnya ada di layar. Itu bukan browser kedua atau DOM yang lebih cepat. Itu struktur data yang bisa diperiksa dan dibandingkan React secara efisien.
Rekonsiliasi adalah proses menentukan apa yang berubah antara pohon virtual sebelumnya dan yang berikutnya. React memakai heuristik untuk melakukan ini dengan cepat, misalnya:
<div> bukan <span>)Setelah React tahu apa yang berubah, ia menerapkan pembaruan terarah ke DOM nyata.
Ini bukan sihir. Performa bergantung pada pola: key yang stabil, menghindari re-render tidak perlu, menjaga kerja komponen kecil, dan tidak melakukan komputasi mahal selama rendering. React bisa mengurangi churn DOM, tetapi struktur komponen dan aliran data Anda tetap menentukan seberapa lancar aplikasi terasa.
Trik skalabilitas terbesar React bukan fitur atau add-on—melainkan komposisi: membangun layar dengan menanamkan komponen, mengoper data lewat props, dan menggunakan children agar sebuah komponen bisa “membungkus” UI lain.
Saat tim mengedepankan komposisi, mereka berhenti berpikir dalam istilah halaman sekali pakai dan mulai memikirkan bagian kecil yang andal yang bisa disusun ulang tanpa menulis ulang semuanya.
childrenNesting adalah versi visual dari bagaimana UI terstruktur: sebuah halaman berisi bagian, yang berisi kartu, yang berisi tombol. Props adalah kenop konfigurasi (teks, state, callback). children adalah cara membuat komponen yang menyediakan struktur sambil membiarkan pemanggil menentukan isi di dalamnya.
Model mental yang baik: props menyesuaikan, children mengisi, nesting merakit.
Komponen layout mendefinisikan struktur dan spasi tanpa memiliki logika bisnis. Contoh: Page, SidebarLayout, Stack, Modal. Mereka sering bergantung pada children, sehingga layout yang sama bisa membungkus banyak layar berbeda.
Input yang dapat digunakan ulang menstandarisasi perilaku dan styling form: TextField, Select, DatePicker. Daripada menyalin label, status error, dan pesan validasi di banyak layar, Anda memusatkan keputusan itu dan mengekspos API props sederhana.
Komponen list dan item menjaga UI berulang menjadi dapat diprediksi. Pemisahan umum adalah ItemList (fetching, pagination, empty states) dan ItemRow (bagaimana satu item terlihat). Ini memudahkan mengubah tampilan tanpa merusak penanganan data.
Hooks adalah cara modern untuk menggunakan kembali perilaku stateful (seperti toggle, state form, atau fetching) di banyak komponen tanpa memaksa mereka berbagi bentuk UI yang sama. Pemisahan itu membantu tim mengembangkan desain sambil menjaga logika konsisten.
Komposisi adalah bagaimana sistem desain tetap konsisten: komponen menjadi blok bangunan “resmi”, dan layout mendefinisikan aturan spasi dan hierarki. Saat sistem diperbarui—warna, tipografi, status interaksi—produk mewarisi perbaikan dengan lebih sedikit pengeditan manual.
State hanyalah “data yang bisa berubah.” Di React, tempat state disimpan sama pentingnya dengan state itu sendiri.
State lokal milik satu komponen (atau widget kecil) dan tidak perlu dibaca di tempat lain. Pikirkan: apakah dropdown terbuka, nilai input saat ini, atau tab yang dipilih.
Menjaga state ini lokal mengurangi koordinasi dan membuat komponen lebih mudah dipakai ulang. Aturan bagus: jika hanya satu komponen peduli, jangan ekspor ke seluruh aplikasi.
State bersama adalah data yang harus disepakati beberapa bagian UI. Contoh umum:
Saat banyak komponen membutuhkan sumber kebenaran yang sama, menduplikasi state menyebabkan ketidaksesuaian (“header bilang 3 item, halaman keranjang bilang 2”).
Lift state up: pindahkan state ke parent bersama terdekat dan oper lewat props. Ini sering paling sederhana dan membuat aliran data eksplisit.
Context: berguna ketika banyak komponen butuh nilai yang sama tanpa prop drilling, seperti tema atau auth. Context terbaik untuk perhatian aplikasi yang relatif stabil.
External stores: ketika state tumbuh kompleks (pembaruan sering, data turunan, alur lintas-halaman), store khusus bisa memusatkan logika dan pembaruan.
Aliran data satu arah React bersinar ketika ada pemilik yang jelas untuk tiap potongan state. Usahakan satu sumber kebenaran bila memungkinkan, dan turunkan sisanya (counts, totals, daftar terfilter) dari state itu alih-alih menyimpan duplikat.
Kemenangan sehari-hari terbesar React bukan trik render—melainkan bagaimana batas komponen mengubah pekerjaan UI menjadi perubahan yang lebih kecil dan lebih aman. Saat sebuah komponen punya tanggung jawab jelas dan “surface” publik stabil (props), tim bisa merombak internal tanpa memaksa penulisan ulang di seluruh aplikasi. Stabilitas itu membuat review kode lebih mudah, mengurangi kerusakan tidak sengaja, dan membantu rekan baru memahami tempat membuat perubahan.
Model mental berguna: diberi props dan state, sebuah komponen seharusnya dapat memprediksi UI yang dideskripsikan. Meskipun efek dan API browser ada, sebagian besar logika komponen bisa tetap deterministik. Itu sebabnya testing React yang mudah dipelihara sering fokus pada perilaku dan output:
Pemeriksaan aksesibilitas masuk secara natural: jika Anda mengetes menggunakan roles dan nama yang dapat diakses, Anda akan menangkap label yang hilang, fokus yang rusak, dan semantik yang tidak konsisten lebih awal. Pengecekan konsistensi (linting, formatting, penggunaan sistem desain) memperkuat ide yang sama: komponen yang dapat diprediksi lebih mudah dipelihara.
Saat komponen mengekspos API props kecil dan menyembunyikan detail implementasi, banyak orang bisa bekerja paralel—satu mengubah styling, yang lain mengubah fetching data, yang lain memperbarui test—tanpa saling mengganggu.
Performa React biasanya kurang soal “React itu lambat” dan lebih soal seberapa banyak pekerjaan yang Anda minta browser lakukan. UI tercepat adalah yang melakukan paling sedikit: lebih sedikit node DOM, lebih sedikit layout/reflow, lebih sedikit kalkulasi mahal, dan lebih sedikit putaran jaringan.
Masalah sering adalah re-render tidak perlu: perubahan state kecil menyebabkan subtree besar re-render karena state diletakkan terlalu tinggi, atau karena props selalu berubah identitas (objek/fungsi baru dibuat inline).
Masalah klasik lain adalah daftar besar—ratusan atau ribuan baris dengan gambar, format, dan handler event. Meskipun tiap baris “murah”, total kerja menumpuk, dan scrolling jadi tersendat karena browser tak mampu mengejar.
Mulai dari struktur:
Fokus juga pada apa yang dirasakan pengguna: kurangi lag input, percepat first meaningful paint, dan jaga interaksi tetap mulus. Perbaikan 20ms pada interaksi yang sering dipakai bisa lebih berarti daripada memangkas 200ms pada layar yang jarang dipakai.
Derived state adalah data yang bisa dihitung dari state/props lain (mis. fullName dari firstName + lastName, atau item yang difilter dari daftar + query). Menyimpannya sering menimbulkan bug: Anda sekarang punya dua sumber kebenaran yang bisa menyimpang.
Lebih baik menghitung nilai turunan saat rendering (atau memoize perhitungan jika mahal). Simpan hanya yang tidak bisa diturunkan—biasanya input pengguna, respons server, dan niat UI (mis. "panel terbuka?").
React tidak hanya memperkenalkan cara menulis UI yang lebih enak; ia mendorong tim mengatur ulang bagaimana frontend dibangun, dibagi, dan dipelihara. Sebelum komponen menjadi model mental default, banyak proyek memperlakukan UI sebagai halaman dengan skrip dan template tersebar. Dengan React, unit arsitektur makin menjadi komponen: potongan UI dengan API jelas (props) dan perilaku yang dapat diprediksi.
React cocok dengan kenaikan single-page applications (SPAs). Saat rendering dipicu state, “halaman” berhenti menjadi template yang dikirim server dan mulai menjadi komposisi komponen plus routing sisi-klien. Pergeseran itu membuat kode sering disusun berdasarkan area fitur dan bagian UI yang dapat dipakai ulang daripada file HTML terpisah.
Begitu UI dibangun dari potongan yang dapat dipakai ulang, wajar bila bagian itu distandarisasi. Banyak organisasi beralih dari menyalin markup ke membangun perpustakaan komponen: tombol, kontrol form, modal, primitif layout, dan pola seperti empty state. Seiring waktu, perpustakaan ini sering berkembang menjadi sistem desain—komponen bersama plus pedoman—agar tim bisa mengirim pengalaman konsisten tanpa menciptakan ulang UI untuk tiap layar.
Komponen mendorong tim memberi nama hal yang sama. Ketika semua orang berbicara tentang <Button>, <Tooltip>, atau <CheckoutSummary>, diskusi menjadi lebih konkret: orang bisa membahas perilaku dan batasan, bukan sekadar tampilan. Kosakata bersama itu juga membantu rekan baru onboard lebih cepat, karena sistem bisa ditemukan lewat kode.
Sukses React memengaruhi cara komunitas frontend berpikir tentang UI: pengembangan berfokus komponen, rendering deklaratif, dan aliran data yang dapat diprediksi menjadi ekspektasi umum. Framework lain mengadopsi ide serupa, meski detail implementasinya berbeda, karena praktik-praktik ini terbukti lebih mudah diskalakan di tim nyata.
React mendapat reputasi karena mempermudah evolusi UI kompleks, tetapi itu bukan hal gratis. Mengetahui trade-off sebelumnya membantu tim mengadopsinya dengan alasan yang tepat—dan menghindari adopsi gaya kargo.
React punya kurva belajar: komponen, hooks, dan model mental seperti pembaruan state dan efek butuh waktu untuk dikuasai. React modern juga mengasumsikan tooling build (bundling, linting, TypeScript sering dipakai), yang menambah setup dan pemeliharaan. Akhirnya, React memperkenalkan lapisan abstraksi—perpustakaan komponen, routing, pola fetching data—yang bisa membantu, tetapi juga bisa menyembunyikan kompleksitas sampai sesuatu rusak.
"React hanya view." Secara teori iya; dalam praktik, React sangat membentuk arsitektur Anda. Batas komponen, kepemilikan state, dan pola komposisi memengaruhi aliran data dan bagaimana tim mengorganisir kode.
"Virtual DOM selalu lebih cepat." Virtual DOM terutama tentang pembaruan yang dapat diprediksi dan ergonomi developer. React bisa cepat, tetapi performa bergantung pada pola rendering, memoization, ukuran list, dan menghindari re-render tidak perlu.
React cocok untuk aplikasi dengan banyak status interaktif, basis kode jangka panjang, dan banyak pengembang yang bekerja paralel. Untuk situs marketing yang kebanyakan statis atau beberapa widget kecil, opsi lebih sederhana (template yang dirender server, JS ringan, atau framework minimal) mungkin lebih mudah dikirim dan dipelihara.
Jika Anda sedang prototipe aplikasi React dan ingin memvalidasi ide ini cepat (batas komponen, kepemilikan state, pola komposisi), workflow vibe-coding bisa membantu. Misalnya, Koder.ai memungkinkan Anda mendeskripsikan fitur lewat chat dan menghasilkan frontend React yang bekerja plus backend Go/PostgreSQL, lalu iterasi dengan snapshot/rollback dan ekspor source code saat siap mengambil alih secara manual. Ini cara praktis menguji keputusan arsitektur pada fitur nyata sebelum berkomitmen ke build penuh.
Selanjutnya: prototipe satu fitur nyata, ukur kompleksitas dan kecepatan tim, lalu skalakan pola secara sengaja—bukan karena kebiasaan.
Jordan Walke menciptakan React saat bekerja di Facebook. React penting karena menggantikan “glue code” DOM yang rapuh dan manual dengan cara membangun UI berbasis komponen dan state-driven—membuat antarmuka kompleks lebih mudah diskalakan, di-debug, dan dipelihara.
Template biasanya menyebarkan aturan UI di markup dan handler event yang tersebar ("ketika X terjadi, perbarui Y"). Komponen mengemas UI + logika di balik antarmuka kecil (props), sehingga fitur bisa disusun dari potongan yang dapat diprediksi alih-alih menambal halaman dari waktu ke waktu.
Komponen adalah unit yang dapat digunakan ulang yang menerima input (biasanya props) dan mengembalikan bagaimana UI seharusnya terlihat untuk input tersebut.
Dalam praktiknya, usahakan:
Props adalah input yang Anda kirimkan ke komponen untuk mengkonfigurasinya (teks, flag, callback, atau UI lain). Pandang props sebagai kontrak:
disabled, onSubmit) daripada objek "kitchen sink" yang samarDeclarative UI berarti Anda menjelaskan apa yang seharusnya terlihat pada antarmuka untuk state saat ini, bukan bagaimana memperbarui DOM langkah demi langkah.
Secara praktis, Anda:
JSX adalah sintaks yang memungkinkan menulis struktur UI menyerupai HTML di dalam JavaScript. Berguna karena logika render dan markup yang dikontrolnya hidup bersama, membuat komponen lebih mudah dibaca dan direview sebagai satu kesatuan.
State adalah data yang bisa berubah seiring waktu dan harus memengaruhi apa yang dilihat pengguna (teks input, status loading, isi keranjang, dll).
Aturan praktis: simpan sumber kebenaran (input pengguna, respons server, niat UI), dan turunkan semua yang bisa diturunkan (counts, daftar yang sudah difilter) daripada menyimpannya terpisah.
Aliran data satu arah berarti:
Ini memudahkan debugging karena Anda bisa menelusuri pembaruan: event → perubahan state → re-render.
Virtual DOM adalah representasi UI di memori milik React. Ketika state/props berubah, React membandingkan deskripsi UI sebelumnya dengan yang baru dan hanya memperbarui DOM nyata di tempat yang perlu.
Untuk menghindari masalah umum:
key yang stabil pada item listMulai sederhana dan perluas hanya bila perlu:
Prioritaskan satu sumber kebenaran dan turunkan sisanya untuk mencegah ketidaksesuaian.