Advanced · Level 16: Frontend ArchitectureAdvanced65 menitBahasa Indonesia

Component API Design

Memperlakukan props sebagai API untuk engineer lain, lalu memilih contract kecil yang menjelaskan tujuan component tanpa boolean dan variant berlapis.

StatusMemuat progres

ProgresMemuat...

...

Memuat progres

Menyiapkan langkah berikutnya

Tujuan belajar

Menjelaskan props sebagai contract developer-facing untuk component
Memilih props berdasarkan informasi dan area composition yang benar-benar dibutuhkan component
Membedakan API yang spesifik dan dapat dipahami dari component yang terlalu fleksibel
Menjaga type props sebagai dokumentasi penggunaan yang dapat diperiksa TypeScript

ReactPropsComponent APITypeScriptComposition

Isi lesson

6 blok

1.
Props adalah API untuk engineer lainBelum selesaiWajib
2.
Contract kecil untuk card informasi courseBelum selesaiWajib
3.
Coding practiceBelum selesaiWajib
4.
Cek pemahamanBelum selesaiWajib
5.
Fleksibel bukan berarti menerima semua kemungkinanBelum selesaiOpsional
6.
RingkasanBelum selesaiWajib

Props adalah API untuk engineer lain

Wajib

Saat membuat reusable component, caller tidak melihat alasan internal markup, state, atau styling dibuat seperti itu. Yang mereka lihat adalah nama component, props yang harus diberikan, props yang opsional, dan hasil yang dijanjikan. Karena itu, props adalah API developer-facing. API yang baik membuat penggunaan umum terlihat sederhana dan penggunaan yang salah terasa janggal atau tertahan oleh type.

Mulai dari tujuan yang sempit. CourseInfoCard mungkin perlu title, description, status, dan satu area action yang jelas. Ia tidak perlu menerima data, text, mode, variant, compact, showProgress, actionText, actionHref, atau body sekaligus hanya untuk mengantisipasi semua kemungkinan. Jika caller membutuhkan layout yang benar-benar berbeda, mungkin component ini bukan abstraction yang tepat. Tambahkan prop ketika ada consumer nyata dan namanya menjelaskan perubahan UI atau behavior yang terjadi.

Bagian ini memengaruhi progres lesson.

Contract kecil untuk card informasi course

Wajib

tsx

import type { ReactNode } from "react";

type CourseStatus = "not-started" | "in-progress" | "complete";

type CourseInfoCardProps = {
  title: string;
  description: string;
  status: CourseStatus;
  action?: ReactNode;
};

export function CourseInfoCard({
  title,
  description,
  status,
  action,
}: CourseInfoCardProps) {
  return (
    <article>
      <p>Status: {status}</p>
      <h2>{title}</h2>
      <p>{description}</p>
      {action ? <footer>{action}</footer> : null}
    </article>
  );
}

Card ini menerima informasi yang memang ia tampilkan dan action sebagai area bernama yang opsional. status dibatasi oleh union agar caller tidak mengirim string bebas seperti ongoing atau done dengan makna yang tidak konsisten. Bila product kemudian membutuhkan progress angka, tambahkan contract yang jelas seperti completedLessons dan totalLessons hanya ketika card benar-benar menjadi owner tampilan informasi tersebut. Jangan menambahkan prop hanya karena suatu hari mungkin berguna.

Bagian ini memengaruhi progres lesson.

Coding practice

WajibDibuka di workspace khusus

Improve course info card API

Ganti API Card yang kabur menjadi CourseInfoCard dengan data inti, union status, dan satu action slot yang bernama jelas.

Tujuan awal: Fokus di tab TSX.

Practice ini dibuka di workspace khusus. Buka practice untuk memakai editor, preview, dan cek otomatis.

Tombol selesai aktif setelah semua validasi wajib lolos.

7 cek otomatis5 checklist

Belum selesaiBuka practice

Cek pemahaman

WajibJawab dulu

Cek pemahaman singkat

Manakah perubahan API yang paling sehat ketika CourseInfoCard perlu menampilkan satu action opsional di footer?

Progres lesson naik setelah jawaban benar.

Kesalahan umum

Opsional

Fleksibel bukan berarti menerima semua kemungkinan

Props seperti variant, size, mode, type, layout, showHeader, showFooter, isCompact, dan config sering muncul ketika component mencoba melayani use case yang belum terbukti sama. Setiap prop menambah kombinasi yang perlu dipahami, diuji, dan didokumentasikan. Lebih baik punya dua component domain yang jelas daripada satu component universal yang tidak lagi dapat menjelaskan kapan ia tepat dipakai.

Opsional, tidak menghambat penyelesaian lesson.

Ringkasan

Wajib

Props adalah contract yang dipakai engineer lain untuk memahami serta mengonfigurasi component.
Mulai dari tujuan component dan use case nyata, bukan daftar kemungkinan masa depan.
Union, prop required, dan slot bernama dapat membuat penggunaan yang benar lebih jelas.
Setiap prop baru menambah kombinasi behavior yang perlu dirawat serta didokumentasikan.
Berikutnya, kita memberi nama prop yang menjelaskan isi, boolean, dan event tanpa menebak-nebak maksudnya.

Bagian ini memengaruhi progres lesson.

Langkah berikutnya

Selesaikan bagian penting lesson ini

Lanjutkan blok wajib berikutnya: Props adalah API untuk engineer lain.

Memuat progres Review module