FluentStack

Keeping Types Readable

Mode tersedia: dark, light, paper
MasukDaftar
Intermediate · Level 6: TypeScriptIntermediate45 menitBahasa Indonesia

Keeping Types Readable

Memutuskan kapan type cukup inline, kapan perlu diberi nama, dan kapan perlu disederhanakan.

StatusMemuat progres
ProgresMemuat...

...

Memuat progres

Menyiapkan langkah berikutnya

Tujuan belajar

  • Membaca tanda type yang mulai terlalu rumit
  • Memecah type panjang menjadi nama yang jelas
  • Menjaga type boundary tetap praktis dan tidak over-engineered
TypeScriptReadable TypesRefactoring

Isi lesson

6 blok
  1. 1.
    Type yang aman juga harus bisa dibacaBelum selesaiWajib
  2. 2.
    Type panjang dipecah menjadi namaBelum selesaiWajib
  3. 3.
    Aturan kecil untuk readabilityBelum selesaiWajib
  4. 4.
    Coding practiceBelum selesaiWajib
  5. 5.
    Checklist sebelum lanjutBelum selesaiWajib
  6. 6.
    RingkasanBelum selesaiWajib

Type yang aman juga harus bisa dibaca

Wajib

TypeScript bisa membantu, tetapi type yang terlalu panjang bisa membuat kode lebih sulit dipahami. Tujuan module ini bukan membuat type paling pintar. Tujuannya membuat boundary data aman dan tetap enak dirawat.

Readable type biasanya punya nama yang menjelaskan niat. Jika sebuah shape dipakai berulang, menjadi bagian boundary, atau punya arti domain, beri nama. Jika shape sangat kecil dan hanya dipakai sekali, inline type masih wajar.

Bagian ini memengaruhi progres lesson.

Type panjang dipecah menjadi nama

Wajib
ts
type ApiResult<TData> =
  | { ok: true; data: TData }
  | { ok: false; message: string };

type LessonCard = {
  id: string;
  title: string;
  durationLabel: string;
};

type LessonCardsResult = ApiResult<LessonCard[]>;

Nama LessonCard dan LessonCardsResult membuat maksud data lebih cepat terbaca dibanding menulis semua bentuk type langsung di setiap function.

Bagian ini memengaruhi progres lesson.

Tips

Wajib

Aturan kecil untuk readability

Inline type boleh untuk bentuk kecil yang hanya muncul sekali. Beri nama jika type dipakai ulang, muncul di boundary, punya arti produk, atau membuat function signature terlalu panjang. Sederhanakan jika type mulai butuh penjelasan panjang hanya untuk dibaca.

Bagian ini memengaruhi progres lesson.

Coding practice

WajibDibuka di workspace khusus

Refactor type agar readable

Latihan memecah type boundary panjang menjadi nama yang lebih mudah dibaca.

Tujuan awal: Fokus di tab TS.

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

Tombol selesai aktif setelah semua validasi wajib lolos.

5 cek otomatis4 checklist
Belum selesaiBuka practice

Catatan penting

Wajib

Checklist sebelum lanjut

Cek type boundary kamu: nama type menjelaskan niat, tidak memakai `any`, tidak memakai `as` sebagai jalan pintas utama, dan tidak terlalu generik sampai pembaca harus menebak data apa yang sedang dimodelkan.

Bagian ini memengaruhi progres lesson.

Ringkasan

Wajib
  • Type yang baik harus aman dan mudah dibaca.
  • Beri nama pada type yang dipakai ulang atau menjadi boundary penting.
  • Jangan membuat type lebih kompleks dari kebutuhan data saat ini.
  • `any` dan cast agresif biasanya tanda boundary belum dipikirkan.
  • Berikutnya, Uji Kompetensi akan mengecek API, form, UI data shape, helper result, dan readability sekaligus.

Bagian ini memengaruhi progres lesson.

Langkah berikutnya

Selesaikan bagian penting lesson ini

Lanjutkan blok wajib berikutnya: Type yang aman juga harus bisa dibaca.