Program Studi Bisnis Digital • FEB

Laboratorium Pemrograman

Pertemuan 10 — Penggunaan Dummy API untuk Simulasi Pertukaran Data dalam Aplikasi

Sebelum backend sungguhan siap, aplikasi tetap bisa "hidup" — berkat data palsu yang berperilaku seperti data asli.

RPS MINGGU 11 • 2 × 50 MENIT

Selamat datang kembali, Anda semua. Minggu lalu kita merancang struktur database untuk mendukung aplikasi, dan minggu sebelumnya kita membangun REST API. Sekarang bayangkan situasi yang sangat umum di dunia kerja: tim front-end React Native sudah siap membangun tampilan aplikasi, tetapi tim back-end masih butuh dua minggu lagi untuk menyelesaikan server dan database sungguhan. Apa yang harus dilakukan agar pekerjaan tidak berhenti? Jawabannya adalah dummy API — API tiruan yang mengembalikan data contoh, sehingga aplikasi tetap bisa dites seolah-olah sudah terhubung ke server nyata. Hari ini kita akan belajar cara memakai dummy API untuk mensimulasikan pertukaran data, mulai dari konsep dasar sampai mengintegrasikannya ke komponen React Native, lengkap dengan contoh nyata seperti Tokopedia dan aplikasi UMKM.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menggunakan dummy API untuk mensimulasikan pertukaran data dalam aplikasi React Native, tanpa bergantung pada backend yang sudah jadi.

KONSEP

Lapisan Pemahaman

Memahami apa itu dummy API, kapan dipakai dalam alur kerja tim, dan bagaimana bentuk data JSON yang dipertukarkan.

PRAKTIK

✓

Integrasi Nyata

Mampu mengambil data dari dummy API memakai fetch/axios, menampilkannya di layar, serta menangani status loading dan error.

Kemampuan ini adalah jembatan langsung menuju pertemuan berikutnya: mengganti dummy API dengan API dan database sungguhan untuk operasi CRUD.

Mari kita samakan target belajar hari ini. Pertama, Anda akan memahami apa itu dummy API secara konseptual — bukan sekadar tahu istilahnya, tetapi paham mengapa ia begitu penting dalam proses pengembangan aplikasi tim. Kedua, Anda akan mengenal beberapa layanan dummy API populer yang bisa langsung dipakai tanpa instalasi rumit, seperti yang biasa dipakai developer pemula di Indonesia saat membangun portofolio aplikasi. Ketiga, dan ini yang paling penting, Anda akan praktik langsung mengambil data dari dummy API dan menampilkannya di aplikasi React Native, lengkap dengan menangani kondisi saat data sedang dimuat atau saat terjadi kesalahan koneksi. Semua kemampuan ini akan langsung dipakai dua pertemuan lagi saat kita mengganti data palsu dengan data sungguhan dari database yang kita rancang minggu lalu.

Di Mana Posisi Kita Sekarang?

Dummy API adalah jembatan antara desain API/database (minggu lalu) dan integrasi backend sungguhan (dua minggu lagi).

P8–P9 (LALU)

Rancang REST API & struktur database

P10 (HARI INI)

Dummy API

Simulasi pertukaran data tanpa backend nyata

P11 (BERIKUTNYA)

Ganti dummy dengan CRUD & database sungguhan

Analogi: dummy API seperti manekin di etalase toko — bentuknya persis pakaian asli, cukup untuk latihan memajang dan menata, sebelum barang produksi masal tiba.

Penting bagi Anda untuk melihat gambaran besar sebelum masuk detail teknis. Dua pertemuan lalu kita merancang REST API dan struktur database — itu adalah cetak biru bagaimana data seharusnya mengalir. Tetapi cetak biru saja tidak cukup untuk menguji tampilan aplikasi, karena server sungguhan belum tentu selesai dibangun. Di sinilah dummy API berperan sebagai jembatan: ia memberi front-end data yang bentuknya sama persis dengan data asli nantinya, sehingga Anda bisa membangun dan menguji tampilan aplikasi lebih dulu. Analoginya seperti manekin di etalase toko pakaian — bentuknya identik dengan baju asli, cukup untuk latihan menata dan memajang, meski baju produksi massal yang sesungguhnya belum tiba dari pabrik. Dua pertemuan lagi, kita akan mencabut manekin ini dan menggantinya dengan barang asli lewat operasi CRUD ke database sungguhan.

Bagian 1 dari 3

Mengapa Dummy API?

Konsep dasar, alasan penggunaan dalam alur kerja tim, dan layanan-layanan yang tersedia gratis.

Apa itu Dummy API?

Dummy API (atau mock API) adalah layanan API tiruan yang mengembalikan data contoh berformat JSON, dengan struktur dan perilaku menyerupai API sungguhan — tanpa perlu server backend yang benar-benar dibangun.

Analoginya: contoh soal ujian tahun lalu. Formatnya identik dengan soal ujian sesungguhnya, cukup untuk latihan menjawab, walau isinya bukan soal yang akan benar-benar keluar.

CIRI-CIRI DUMMY API

Alamat URL nyata — bisa dipanggil lewat internet seperti API sungguhan.
Format respons JSON — sama persis strukturnya dengan API produksi.
Data statis/acak — bukan data bisnis asli, hanya untuk simulasi dan latihan.

Mari kita definisikan dengan bahasa sederhana. Dummy API, atau sering disebut mock API, adalah layanan di internet yang berperilaku seperti API sungguhan — Anda mengirim permintaan, ia membalas dengan data JSON — tetapi datanya bukan data bisnis asli, melainkan data contoh yang sudah disiapkan sebelumnya. Analoginya seperti contoh soal ujian tahun lalu yang dibagikan dosen: formatnya sama persis dengan soal ujian sesungguhnya, jumlah soal dan jenis pertanyaannya mirip, sehingga Anda bisa berlatih menjawab dengan pola yang tepat, meskipun isi soal yang keluar nanti pasti berbeda. Tiga ciri utama dummy API adalah: ia punya alamat URL nyata yang bisa diakses lewat internet, format responsnya JSON persis seperti API produksi, dan datanya statis atau acak, bukan data transaksi sungguhan seperti yang akan Anda temui di aplikasi Tokopedia atau BCA mobile yang sudah beroperasi penuh.

Kapan Dummy API Dipakai dalam Proyek?

Dalam tim pengembangan aplikasi, front-end dan back-end sering dikerjakan secara paralel — dummy API membuat keduanya tidak saling menunggu.

Saat tim back-end selesai, aplikasi tinggal mengganti alamat URL dummy API dengan URL API produksi — struktur kode tidak perlu diubah total.

Perhatikan diagram ini dengan saksama, karena inilah inti alasan praktis dummy API dipakai. Dalam proyek nyata, tim front-end yang membangun tampilan aplikasi dan tim back-end yang membangun server serta database biasanya bekerja pada waktu yang bersamaan, bukan bergantian. Kalau tim front-end harus menunggu tim back-end selesai seratus persen dulu, proyek akan jauh lebih lambat. Solusinya, tim front-end memanggil dummy API untuk sementara, sehingga bisa langsung membangun dan menguji tampilan aplikasi. Sementara itu, tim back-end tetap bekerja membangun API produksi yang sesungguhnya. Begitu API produksi selesai dan sudah diuji, langkah yang diperlukan hanyalah mengganti alamat URL di kode aplikasi, dari alamat dummy API menjadi alamat API produksi — karena strukturnya sudah dirancang mirip sejak awal, perubahan kodenya sangat minimal. Pola kerja seperti ini biasa dipakai startup fintech dan e-commerce di Indonesia agar peluncuran aplikasi tidak molor.

Layanan Dummy API yang Populer

Anda tidak perlu membangun dummy API sendiri — banyak layanan gratis siap pakai untuk latihan.

JSONPLACEHOLDER

Data contoh siap pakai: pengguna, postingan, komentar — tanpa perlu daftar akun

MOCKAPI

Bisa membuat struktur data sendiri (mis. daftar produk toko) lewat antarmuka web

JSON-SERVER

Dijalankan di komputer sendiri dari satu file JSON — cocok untuk latihan offline

Untuk latihan hari ini, kita memakai MockAPI agar Anda bisa membuat struktur data sendiri, misalnya daftar produk UMKM dengan kolom nama, harga, dan stok — mirip data yang dijual di Tokopedia atau Shopee.

Kabar baiknya, Anda tidak perlu repot membangun dummy API dari nol — sudah banyak layanan gratis yang siap dipakai. JSONPlaceholder adalah yang paling populer untuk pemula, menyediakan data contoh seperti daftar pengguna, postingan blog, dan komentar, dan Anda bisa langsung memanggilnya tanpa perlu mendaftar akun sama sekali. MockAPI sedikit lebih fleksibel, karena Anda bisa membuat struktur data sendiri lewat antarmuka web yang mudah dipakai, misalnya membuat tabel produk dengan kolom nama, harga, dan stok, persis seperti data yang biasa dijual di marketplace seperti Tokopedia atau Shopee. Ada juga json-server, yang dijalankan langsung di komputer Anda sendiri dari satu file JSON sederhana, cocok kalau Anda ingin latihan tanpa koneksi internet. Hari ini kita akan memakai MockAPI karena memungkinkan Anda merancang struktur data sesuai kebutuhan proyek aplikasi masing-masing, mirip dengan skenario nyata membangun aplikasi UMKM.

Anatomi Pertukaran Data: Request & Response

Setiap kali aplikasi "berbicara" dengan dummy API, terjadi pertukaran dua arah yang selalu mengikuti pola yang sama.

Aplikasi mengirim request ke alamat URL dummy API (mis. GET /produk) — seperti mengetuk pintu dan bertanya "boleh minta daftar produk?"
Server dummy API menerima permintaan dan mencari data yang sesuai dalam penyimpanannya.
Server mengirim balik response berupa teks berformat JSON, berisi data yang diminta plus kode status (mis. 200 OK).
Aplikasi menerima JSON tersebut, mengubahnya jadi objek JavaScript, lalu menampilkannya di layar.

Mari kita bongkar apa yang sebenarnya terjadi setiap kali aplikasi mengambil data dari dummy API, karena polanya ini akan selalu sama di sepanjang karier Anda sebagai pengembang aplikasi. Langkah pertama, aplikasi mengirim permintaan atau request ke alamat tertentu, misalnya meminta daftar produk — bayangkan seperti Anda mengetuk pintu kasir dan bertanya, boleh saya lihat katalog barang. Langkah kedua, di sisi server dummy API, permintaan itu diterima dan sistem mencari data yang cocok di dalam penyimpanannya. Langkah ketiga, server mengirim balik jawaban berupa response, berbentuk teks JSON yang berisi data yang diminta, disertai kode status seperti dua ratus yang berarti berhasil, atau empat ratus empat yang berarti data tidak ditemukan. Langkah keempat, aplikasi menerima teks JSON itu, mengubahnya menjadi objek JavaScript yang bisa dibaca kode program, lalu menampilkannya di layar sebagai daftar produk yang rapi. Pola empat langkah ini persis sama saat aplikasi GoPay mengambil daftar riwayat transaksi Anda.

Bagian 2 dari 3

Mengambil Data ke React Native

Dari konsep ke kode: memanggil dummy API dan menampilkan hasilnya di layar aplikasi.

Dua Cara Memanggil API: fetch vs axios

React Native menyediakan fetch() bawaan, sementara axios adalah pustaka tambahan yang lebih ringkas.

FETCH (BAWAAN)

Sudah tersedia tanpa instalasi tambahan
Perlu .json() manual untuk membaca respons
Penanganan error butuh kode lebih panjang

AXIOS (PUSTAKA)

Perlu instalasi: npm install axios
Data JSON otomatis tersedia lewat .data
Penanganan error dan timeout lebih ringkas

fetch('URL').then(r => r.json()) | axios.get('URL').then(r => r.data)

Ada dua cara umum yang akan Anda temui untuk memanggil API dari kode JavaScript, dan penting bagi Anda mengenal keduanya karena akan sering muncul di proyek nyata maupun saat membaca kode orang lain. Cara pertama adalah fetch, fungsi bawaan yang sudah tersedia langsung di React Native tanpa perlu instalasi apa pun, tetapi Anda harus memanggil fungsi tambahan bernama titik json untuk mengubah responsnya menjadi data yang bisa dipakai, dan penanganan errornya sedikit lebih panjang kodenya. Cara kedua adalah axios, sebuah pustaka pihak ketiga yang perlu diinstal lebih dulu memakai perintah npm install axios, tetapi hasilnya kode jadi lebih ringkas karena data JSON langsung tersedia lewat properti titik data, dan penanganan error maupun batas waktu tunggu jauh lebih mudah diatur. Banyak developer profesional di Indonesia memilih axios untuk proyek yang lebih besar karena kepraktisannya, tetapi memahami fetch tetap penting karena itu adalah fondasi bawaan JavaScript yang tidak bergantung pustaka luar.

Async/Await: Menunggu Data dengan Sabar

Memanggil API butuh waktu (data melintasi internet) — kode harus menunggu tanpa membekukan seluruh aplikasi.

Fungsi ditandai kata kunci async — artinya "fungsi ini boleh menunggu sesuatu selesai".
Kata kunci await diletakkan di depan pemanggilan API — kode berhenti sejenak di baris itu tanpa membekukan seluruh aplikasi.
Setelah data tiba, kode lanjut ke baris berikutnya seolah-olah tidak pernah menunggu.
Blok try...catch membungkus proses ini untuk menangkap kegagalan (mis. koneksi internet putus).

Konsep ini sering membingungkan pemula, jadi mari kita pelan-pelan. Memanggil dummy API artinya data harus melintasi internet dan kembali lagi, dan proses itu butuh waktu, mungkin sepersekian detik, mungkin lebih lama kalau koneksi lambat. Masalahnya, JavaScript pada dasarnya berjalan satu per satu baris kode secara berurutan, jadi kita butuh cara agar aplikasi bisa menunggu data datang tanpa membuat seluruh layar membeku selama menunggu. Solusinya adalah kata kunci async yang menandai sebuah fungsi boleh menunggu, dan await yang diletakkan tepat sebelum pemanggilan API, membuat kode berhenti sejenak di baris itu tetapi bagian aplikasi lain tetap bisa merespons sentuhan pengguna. Setelah data benar-benar tiba, kode otomatis melanjutkan ke baris berikutnya seolah tidak pernah berhenti. Kita juga membungkus semua ini dengan try dan catch, supaya kalau terjadi kegagalan, misalnya koneksi internet Anda putus saat membuka aplikasi seperti sering terjadi di area dengan sinyal lemah, aplikasi tidak crash tetapi menampilkan pesan error yang ramah.

Menggabungkan dengan useState & useEffect

Data dari dummy API perlu disimpan di state agar tampilan otomatis diperbarui saat data tiba.

const [produk, setProduk] = useState([]);
useEffect(() => {
async function ambilData() {
const res = await fetch('https://mockapi.io/produk');
const data = await res.json();
setProduk(data);
}
ambilData();
}, []);

Array kosong [] di akhir useEffect berarti "jalankan kode ini satu kali saja, saat komponen pertama kali muncul di layar" — bukan berulang setiap kali tampilan me-render ulang.

Sekarang kita rangkai semua yang sudah dipelajari sebelumnya di pertemuan tentang state dan props. UseState kita pakai untuk menyimpan data produk yang diambil dari dummy API, dimulai sebagai array kosong sebelum data tiba. UseEffect kita pakai untuk menjalankan proses pengambilan data, dan di dalamnya kita definisikan sebuah fungsi async yang memanggil fetch, menunggu hasilnya dengan await, mengubahnya jadi JSON, lalu menyimpannya ke state lewat setProduk. Begitu state berubah, React Native otomatis menggambar ulang tampilan dengan data terbaru, tanpa Anda perlu menulis kode tambahan untuk memperbarui layar secara manual. Perhatikan array kosong di bagian akhir useEffect — itu adalah sinyal penting yang memberi tahu React bahwa kode pengambilan data ini hanya perlu dijalankan sekali saat aplikasi pertama kali dibuka, bukan berulang-ulang setiap kali ada perubahan kecil di layar, yang kalau terjadi bisa membuat aplikasi memanggil API berkali-kali tanpa perlu dan memboroskan kuota internet pengguna.

Hitung dari Nol: Sekuensial vs Paralel

Aplikasi menampilkan daftar produk, lalu memanggil detail untuk 5 produk unggulan. Berapa total waktu tunggu pengguna?

Langkah	Perhitungan	Nilai
1. Request daftar produk (list)	1 kali panggilan API	200 ms
2. Jumlah produk butuh detail	Ditentukan desain UI	5 produk
3. Total request detail (sekuensial)	5 × 200 ms (dipanggil satu-per-satu)	1.000 ms
4. Total waktu sekuensial	200 ms + 1.000 ms	1.200 ms (1,2 detik)
5. Total waktu paralel (Promise.all)	200 ms + 200 ms (5 request serentak)	400 ms (0,4 detik)

HASIL

3× lebih cepat

1.200 ms ÷ 400 ms = 3 — memanggil API secara paralel jauh menghemat waktu tunggu pengguna

Mari kita buktikan dengan angka mengapa cara memanggil API memengaruhi kecepatan aplikasi yang dirasakan pengguna. Anggap memuat daftar produk butuh dua ratus milidetik, angka yang wajar untuk dummy API. Setelah itu, aplikasi perlu mengambil detail untuk lima produk unggulan yang ditampilkan di beranda. Jika kelima permintaan detail ini dipanggil satu per satu secara sekuensial, totalnya lima dikali dua ratus milidetik sama dengan seribu milidetik, ditambah dua ratus milidetik permintaan daftar di awal, hasilnya seribu dua ratus milidetik atau satu koma dua detik — cukup terasa lambat bagi pengguna. Tetapi kalau kelima permintaan detail itu dipanggil secara paralel atau bersamaan memakai fungsi Promise.all yang akan kita praktikkan, waktu tunggunya hanya dua ratus ditambah dua ratus milidetik, karena kelima request berjalan bersamaan, hasilnya cuma empat ratus milidetik. Itu artinya tiga kali lebih cepat. Inilah sebabnya aplikasi seperti Tokopedia terasa gesit — bukan sulap, melainkan strategi memanggil data secara paralel, bukan bergiliran.

Coba Sendiri: Bandingkan Waktu Sekuensial vs Paralel

Ubah jumlah request dan waktu tiap request, lalu amati selisih total waktu tunggu sekuensial versus paralel.

Menangani Status Loading & Error

Pengguna butuh umpan balik visual saat data sedang dimuat atau saat terjadi kegagalan koneksi.

Tampilkan spinner/teks "Memuat…" selagi menunggu response

SUKSES

Tampilkan data yang berhasil diambil ke dalam daftar

ERROR

Tampilkan pesan ramah, mis. "Gagal memuat, coba lagi"

Aplikasi yang tidak menangani ketiga status ini akan terlihat "diam" atau bahkan seperti macet saat koneksi lambat — pengalaman buruk yang sering dikeluhkan pengguna aplikasi e-commerce saat sinyal lemah di daerah.

Kode yang berfungsi secara teknis belum tentu memberi pengalaman yang baik bagi pengguna. Bayangkan Anda membuka aplikasi belanja saat sinyal di kampung halaman sedang lemah — kalau aplikasi hanya diam tanpa tanda apa pun selama menunggu data, Anda akan mengira aplikasi itu macet dan mungkin menutup paksa aplikasinya. Karena itu, setiap kali kita memanggil dummy API, sebaiknya ada tiga kondisi yang ditangani dengan jelas di kode. Pertama, kondisi loading, di mana kita menampilkan indikator berputar atau tulisan sedang memuat, supaya pengguna tahu aplikasi sedang bekerja, bukan macet. Kedua, kondisi sukses, di mana data yang berhasil diambil ditampilkan rapi dalam daftar. Ketiga, kondisi error, misalnya saat koneksi internet terputus di tengah proses, di mana kita menampilkan pesan ramah seperti gagal memuat data, silakan coba lagi, alih-alih membiarkan aplikasi diam atau menampilkan pesan error teknis yang membingungkan pengguna awam.

Bagian 3 dari 3

Praktik & Studi Kasus

Menerapkan seluruh konsep pada skenario aplikasi katalog produk mini, lengkap dengan latihan.

Studi Kasus: Katalog Produk UMKM Mini

Skenario: aplikasi katalog untuk UMKM lokal yang mengambil daftar produknya dari dummy API MockAPI.

{
"id": "7",
"nama": "Kopi Robusta Temanggung 250g",
"harga": 35000,
"stok": 42,
"kategori": "Minuman"
}

Struktur JSON di atas dirancang meniru data produk sungguhan — begitu API produksi siap, front-end tinggal ganti alamat URL, karena bentuk datanya sudah cocok sejak awal.

Mari kita lihat contoh konkret struktur data yang realistis. Bayangkan Anda membangun aplikasi katalog untuk UMKM lokal, misalnya usaha kopi dari Temanggung yang ingin memajang produknya secara digital. Data satu produk di dummy API bisa berbentuk seperti ini: ada id sebagai penanda unik, nama produk, harga dalam angka rupiah, jumlah stok yang tersedia, dan kategori produknya. Perhatikan bahwa struktur ini sengaja dirancang mirip dengan data produk sungguhan yang nanti akan disimpan di database asli sesuai rancangan pertemuan minggu lalu. Inilah kekuatan pendekatan dummy API yang baik — karena bentuk datanya sudah dirancang serupa sejak awal, ketika tim back-end selesai membangun API produksi, front-end hanya perlu mengganti alamat URL tanpa perlu menulis ulang cara menampilkan data di layar.

Hitung dari Nol: Kebutuhan Request untuk Paginasi

Katalog UMKM punya 250 produk. Berapa banyak permintaan API dibutuhkan bila ditampilkan bertahap (paginasi)?

Langkah	Perhitungan	Nilai
1. Total produk di dummy API	Diberikan (data contoh MockAPI)	250 produk
2. Ukuran per halaman	Ditentukan desain UI	20 produk/halaman
3. Total halaman dibutuhkan	250 ÷ 20 = 12,5 → dibulatkan ke atas	13 halaman
4. Total request bila semua halaman dimuat	1 request/halaman × 13	13 request
5. Total waktu (asumsi 150 ms/request, sekuensial)	13 × 150 ms	1.950 ms (≈ 2 detik)

INSIGHT

13 request

Lebih baik dimuat bertahap per halaman daripada 1 request raksasa berisi 250 produk sekaligus

Sekarang mari kita hitung skenario yang sangat sering dihadapi developer: bagaimana menampilkan data yang jumlahnya besar tanpa membebani aplikasi. Anggap katalog UMKM kita punya dua ratus lima puluh produk, jumlah yang realistis untuk toko yang sudah berkembang. Kalau kita memutuskan menampilkan dua puluh produk per halaman, sebuah pilihan umum di aplikasi e-commerce, maka total halaman yang dibutuhkan adalah dua ratus lima puluh dibagi dua puluh, hasilnya dua belas koma lima, dan karena tidak mungkin ada setengah halaman, kita bulatkan ke atas menjadi tiga belas halaman. Itu artinya, kalau pengguna scroll sampai habis, aplikasi perlu mengirim tiga belas kali permintaan API, satu untuk tiap halaman. Kalau setiap permintaan butuh waktu seratus lima puluh milidetik dan dilakukan berurutan sesuai kebutuhan scroll pengguna, totalnya sekitar seribu sembilan ratus lima puluh milidetik, atau kira-kira dua detik tersebar sepanjang proses scroll. Insight pentingnya: jauh lebih baik memuat data bertahap tiga belas kali kecil-kecil seperti ini, dibanding memaksa satu permintaan raksasa yang mengambil ke-250 data sekaligus, karena itu akan membuat pengguna menunggu lama di awal tanpa melihat apa pun di layar.

Kesalahan Umum Pemula & Cara Menghindarinya

KESALAHAN

Lupa await, sehingga data yang dipakai masih "kosong"
Tidak menangani catch saat koneksi gagal
Memanggil API berulang tanpa array kosong [] di useEffect

PRAKTIK BAIK

Selalu bungkus pemanggilan API dengan try...catch
Tampilkan status loading sejak permintaan dikirim
Uji aplikasi dalam kondisi koneksi lambat/terputus

Sebelum Anda mulai praktik, ada beberapa jebakan umum yang sebaiknya diketahui lebih dulu agar tidak menghabiskan waktu mencari bug yang sebenarnya sederhana. Kesalahan pertama yang sangat sering terjadi adalah lupa menuliskan kata kunci await sebelum memanggil API, sehingga kode langsung lanjut memakai data yang sebenarnya belum tiba, akibatnya aplikasi menampilkan layar kosong atau error aneh. Kesalahan kedua adalah tidak menyiapkan blok catch untuk menangkap kegagalan, sehingga saat koneksi terputus, aplikasi bisa berhenti total tanpa pesan apa pun bagi pengguna. Kesalahan ketiga adalah lupa menambahkan array kosong di akhir useEffect, yang menyebabkan aplikasi memanggil API berulang-ulang setiap kali ada perubahan kecil di layar, memboroskan kuota data pengguna. Sebagai praktik baik, biasakan selalu membungkus kode pemanggilan API dengan try dan catch, tampilkan status loading sejak permintaan dikirim bukan setelah data tiba, dan sebisa mungkin uji aplikasi Anda dalam kondisi koneksi lambat, karena tidak semua mahasiswa dan pengguna aplikasi Anda nanti memiliki sinyal internet sekuat di kampus.

Latihan Laboratorium Hari Ini

Kerjakan langsung di komputer Anda selama sisa waktu pertemuan.

INSTRUKSI

1. Buat struktur data di MockAPI: minimal 15 produk UMKM (nama, harga, stok, kategori).
2. Buat komponen React Native yang memanggil dummy API dengan fetch di dalam useEffect.
3. Tampilkan daftar produk memakai FlatList, lengkap dengan status loading.
4. Tambahkan penanganan error: matikan Wi-Fi sesaat, pastikan aplikasi tidak crash.

Kumpulkan tautan repositori kode di akhir sesi lab. Dosen/asisten akan berkeliling membantu jika Anda menemui kendala.

Sekarang saatnya Anda mempraktikkan sendiri semua konsep yang sudah kita bahas. Langkah pertama, buat struktur data di MockAPI dengan minimal lima belas produk UMKM rekaan, lengkap dengan nama, harga, stok, dan kategori — boleh terinspirasi dari usaha keluarga Anda sendiri atau UMKM di sekitar tempat tinggal Anda. Langkah kedua, buat komponen React Native yang memanggil dummy API tersebut memakai fetch di dalam useEffect, persis seperti pola yang kita praktikkan bersama tadi. Langkah ketiga, tampilkan hasilnya memakai FlatList, komponen React Native untuk menampilkan daftar, dan pastikan Anda menunjukkan indikator loading selagi data sedang dimuat. Langkah keempat, dan ini penting, uji ketahanan aplikasi Anda dengan mematikan Wi-Fi sesaat saat aplikasi sedang memuat data, lalu pastikan aplikasi menampilkan pesan error yang ramah, bukan crash atau layar putih. Saya dan asisten akan berkeliling ruangan membantu kalau Anda menemui kendala, jangan ragu bertanya.

Ringkasan & Menuju Pertemuan Berikutnya

HARI INI

Dummy API sebagai simulasi pertukaran data: definisi, fetch/axios, async/await, loading/error, paginasi

P11 — BERIKUTNYA

Integrasi GUI dengan komponen Python & operasi CRUD ke database sungguhan

Kode pemanggilan API yang Anda tulis hari ini tidak akan dibuang — pola fetch, async/await, dan penanganan loading/error akan dipakai ulang saat berpindah ke API produksi minggu depan.

Mari kita rangkum perjalanan hari ini. Kita belajar bahwa dummy API bukan sekadar trik latihan, melainkan praktik nyata industri untuk memungkinkan tim front-end dan back-end bekerja paralel tanpa saling menunggu. Kita sudah memahami anatomi pertukaran data lewat request dan response, mempraktikkan fetch dan konsep async/await, menggabungkannya dengan useState dan useEffect, menghitung sendiri betapa signifikannya perbedaan waktu antara pemanggilan sekuensial dan paralel, serta menangani status loading dan error agar aplikasi terasa profesional. Kabar baiknya, kerja keras Anda hari ini tidak akan sia-sia — pola kode yang sama persis akan Anda pakai lagi minggu depan, hanya alamat URL-nya yang berganti dari dummy API menjadi API produksi yang terhubung ke database sungguhan. Di pertemuan sebelas, kita akan mengintegrasikan antarmuka dengan komponen Python dan operasi CRUD, sehingga data yang tadinya hanya simulasi akan benar-benar bisa ditambah, diubah, dan dihapus secara nyata. Sampai jumpa di laboratorium minggu depan.