Menguasai State Modul JavaScript: Seluk Beluk Pola Manajemen Perilaku

Dalam dunia pengembangan perangkat lunak modern, 'state' adalah hantu di dalam mesin. Ia adalah data yang menggambarkan kondisi aplikasi kita saat ini—siapa yang sedang login, apa yang ada di keranjang belanja, tema mana yang aktif. Mengelola state ini secara efektif adalah salah satu tantangan paling kritis yang kita hadapi sebagai developer. Ketika ditangani dengan buruk, hal itu mengarah pada perilaku yang tidak dapat diprediksi, bug yang membuat frustrasi, dan basis kode yang menakutkan untuk dimodifikasi. Ketika ditangani dengan baik, hasilnya adalah aplikasi yang tangguh, dapat diprediksi, dan menyenangkan untuk dipelihara.

JavaScript, dengan sistem modulnya yang kuat, memberi kita alat untuk membangun aplikasi berbasis komponen yang kompleks. Namun, sistem modul yang sama ini memiliki implikasi yang halus namun mendalam tentang bagaimana state dibagikan—atau diisolasi—di seluruh kode kita. Memahami pola manajemen state yang melekat dalam modul JavaScript bukan hanya latihan akademis; ini adalah keterampilan mendasar untuk membangun aplikasi profesional yang skalabel. Panduan ini akan membawa Anda menyelami pola-pola ini, beralih dari perilaku default yang implisit dan seringkali berbahaya ke pola yang disengaja dan tangguh yang memberi Anda kendali penuh atas state dan perilaku aplikasi Anda.

Tantangan Inti: Ketidakpastian dari State yang Dibagikan

Sebelum kita menjelajahi polanya, kita harus terlebih dahulu memahami musuh kita: state yang dapat diubah dan dibagikan (shared mutable state). Ini terjadi ketika dua atau lebih bagian dari aplikasi Anda memiliki kemampuan untuk membaca dan menulis ke bagian data yang sama. Meskipun terdengar efisien, ini adalah sumber utama kompleksitas dan bug.

Bayangkan sebuah modul sederhana yang bertanggung jawab untuk melacak sesi pengguna:

            // session.js
let sessionData = {};

export function setSessionUser(user) {
  sessionData.user = user;
  sessionData.loginTime = new Date();
}

export function getSessionUser() {
  return sessionData.user;
}

export function clearSession() {
  sessionData = {};
}
            

              
                Copy
              
            
          

Sekarang, pertimbangkan dua bagian berbeda dari aplikasi Anda yang menggunakan modul ini:

            // UserProfile.js
import { setSessionUser, getSessionUser } from './session.js';

export function displayProfile() {
  console.log(`Menampilkan profil untuk: ${getSessionUser().name}`);
}

// AdminDashboard.js
import { setSessionUser, clearSession } from './session.js';

export function impersonateUser(newUser) {
  console.log("Admin menyamar sebagai pengguna yang berbeda.");
  setSessionUser(newUser);
}

export function adminLogout() {
  clearSession();
}
            

              
                Copy
              
            
          

Jika seorang admin menggunakan `impersonateUser`, state berubah untuk setiap bagian dari aplikasi yang mengimpor `session.js`. Komponen `UserProfile` tiba-tiba akan menampilkan informasi untuk pengguna yang salah, tanpa tindakan langsung dari komponen itu sendiri. Ini adalah contoh sederhana, tetapi dalam aplikasi besar dengan puluhan modul yang berinteraksi dengan state yang dibagikan ini, proses debug menjadi mimpi buruk. Anda akan bertanya-tanya, "Siapa yang mengubah nilai ini, dan kapan?"

Pengantar Modul dan State JavaScript

Untuk memahami polanya, kita perlu menyentuh sedikit tentang cara kerja modul JavaScript. Standar modern, ES Modules (ESM), yang menggunakan sintaks `import` dan `export`, memiliki perilaku spesifik dan krusial mengenai instance modul.

Cache Modul ES: Singleton Secara Default

Ketika Anda mengimpor (`import`) sebuah modul untuk pertama kalinya di aplikasi Anda, mesin JavaScript melakukan beberapa langkah:

1. Resolusi: Menemukan file modul.
2. Parsing: Membaca file dan memeriksa kesalahan sintaks.
3. Instansiasi: Mengalokasikan memori untuk semua variabel tingkat atas modul.
4. Evaluasi: Menjalankan kode di tingkat atas modul.

Poin kuncinya adalah ini: sebuah modul dievaluasi hanya sekali. Hasil dari evaluasi ini—ikatan langsung ke ekspornya—disimpan dalam peta modul global (atau cache). Setiap kali Anda mengimpor (`import`) modul yang sama di tempat lain dalam aplikasi Anda, JavaScript tidak menjalankan ulang kodenya. Sebaliknya, ia hanya memberi Anda referensi ke instance modul yang sudah ada dari cache. Perilaku ini menjadikan setiap modul ES sebagai singleton secara default.

Pola 1: Singleton Implisit - Bawaan dan Bahayanya

Seperti yang baru saja kita bahas, perilaku default Modul ES menciptakan pola singleton. Modul `session.js` dari contoh kita sebelumnya adalah ilustrasi sempurna dari ini. Objek `sessionData` dibuat hanya sekali, dan setiap bagian dari aplikasi yang mengimpor dari `session.js` mendapatkan fungsi yang memanipulasi objek tunggal yang dibagikan tersebut.

Kapan Singleton Menjadi Pilihan yang Tepat?

Perilaku default ini tidak secara inheren buruk. Faktanya, ini sangat berguna untuk jenis layanan di seluruh aplikasi di mana Anda benar-benar menginginkan satu sumber kebenaran:

• Manajemen Konfigurasi: Modul yang memuat variabel lingkungan atau pengaturan aplikasi sekali saat startup dan menyediakannya ke seluruh aplikasi.
• Layanan Logging: Satu instance logger yang dapat dikonfigurasi (misalnya, level log) dan digunakan di mana saja untuk memastikan logging yang konsisten.
• Koneksi Layanan: Modul yang mengelola satu koneksi ke database atau WebSocket, mencegah koneksi ganda yang tidak perlu.

            // config.js
const config = {
  apiKey: process.env.API_KEY,
  apiUrl: 'https://api.example.com',
  environment: 'production'
};

// Kita bekukan objek untuk mencegah modul lain memodifikasinya.
Object.freeze(config);

export default config;
            

              
                Copy
              
            
          

Dalam kasus ini, perilaku singleton adalah persis seperti yang kita inginkan. Kita membutuhkan satu sumber data konfigurasi yang tidak dapat diubah.

Kelemahan Singleton Implisit

Bahaya muncul ketika pola singleton ini digunakan secara tidak sengaja untuk state yang seharusnya tidak dibagikan secara global. Masalahnya meliputi:

• Ketergantungan yang Erat (Tight Coupling): Modul menjadi secara implisit bergantung pada state bersama dari modul lain, membuatnya sulit untuk dipahami secara terpisah.
• Pengujian yang Sulit: Menguji modul yang mengimpor singleton stateful adalah mimpi buruk. State dari satu pengujian dapat bocor ke pengujian berikutnya, menyebabkan pengujian yang tidak stabil atau bergantung pada urutan. Anda tidak dapat dengan mudah membuat instance baru yang bersih untuk setiap kasus uji.
• Ketergantungan Tersembunyi: Perilaku sebuah fungsi dapat berubah berdasarkan bagaimana modul lain yang sama sekali tidak terkait telah berinteraksi dengan state bersama. Ini melanggar prinsip kejutan terkecil (principle of least surprise) dan membuat kode sangat sulit untuk di-debug.

Pola 2: Pola Factory - Menciptakan State yang Terisolasi dan Dapat Diprediksi

Solusi untuk masalah state bersama yang tidak diinginkan adalah dengan mendapatkan kendali eksplisit atas pembuatan instance. Pola Factory adalah pola desain klasik yang dengan sempurna memecahkan masalah ini dalam konteks modul JavaScript. Alih-alih mengekspor logika stateful secara langsung, Anda mengekspor fungsi yang membuat dan mengembalikan instance baru yang independen dari logika tersebut.

Refactoring ke Pola Factory

Mari kita refactor modul counter stateful. Pertama, versi singleton yang bermasalah:

            // counterSingleton.js
let count = 0;

export function increment() {
  count++;
}

export function getCount() {
  return count;
}
            

              
                Copy
              
            
          

Jika `moduleA.js` memanggil `increment()`, `moduleB.js` akan melihat nilai yang diperbarui saat memanggil `getCount()`. Sekarang, mari kita ubah ini menjadi factory:

            // counterFactory.js
export function createCounter() {
  // State sekarang dienkapsulasi di dalam lingkup fungsi factory.
  let count = 0;

  // Sebuah objek yang berisi metode-metode dibuat dan dikembalikan.
  const counterInstance = {
    increment() {
      count++;
    },
    decrement() {
      count--;
    },
    getCount() {
      return count;
    }
  };

  return counterInstance;
}
            

              
                Copy
              
            
          

Cara Menggunakan Factory

Konsumen modul sekarang secara eksplisit bertanggung jawab untuk membuat dan mengelola state-nya sendiri. Dua modul yang berbeda bisa mendapatkan counter independen mereka sendiri:

            // componentA.js
import { createCounter } from './counterFactory.js';

const myCounter = createCounter(); // Buat instance baru
myCounter.increment();
myCounter.increment();
console.log(`Counter Komponen A: ${myCounter.getCount()}`); // Hasil: 2

// componentB.js
import { createCounter } from './counterFactory.js';

const anotherCounter = createCounter(); // Buat instance yang sama sekali terpisah
anotherCounter.increment();
console.log(`Counter Komponen B: ${anotherCounter.getCount()}`); // Hasil: 1

// State dari counter komponen A tetap tidak berubah.
console.log(`Counter Komponen A masih: ${myCounter.getCount()}`); // Hasil: 2
            

              
                Copy
              
            
          

Mengapa Factory Unggul

• Isolasi State: Setiap panggilan ke fungsi factory menciptakan closure baru, memberikan setiap instance state privatnya sendiri. Tidak ada risiko satu instance mengganggu yang lain.
• Testabilitas Luar Biasa: Dalam pengujian Anda, Anda cukup memanggil `createCounter()` di blok `beforeEach` Anda untuk memastikan setiap kasus uji dimulai dengan instance yang baru dan bersih.
• Ketergantungan Eksplisit: Pembuatan objek stateful sekarang eksplisit dalam kode (`const myCounter = createCounter()`). Jelas dari mana state berasal, membuat kode lebih mudah diikuti.
• Konfigurasi: Anda dapat meneruskan argumen ke factory Anda untuk mengonfigurasi instance yang dibuat, membuatnya sangat fleksibel.

Pola 3: Pola Berbasis Constructor/Class - Memformalkan Enkapsulasi State

Pola berbasis Class mencapai tujuan yang sama yaitu isolasi state seperti pola factory tetapi menggunakan sintaks `class` JavaScript. Ini sering disukai oleh pengembang yang berasal dari latar belakang berorientasi objek dan dapat menawarkan struktur yang lebih formal untuk objek yang kompleks.

Membangun dengan Class

Berikut adalah contoh counter kita, ditulis ulang sebagai class. Sesuai konvensi, nama file dan nama class menggunakan PascalCase.

            // Counter.js
export class Counter {
  // Menggunakan private class field untuk enkapsulasi sejati
  #count = 0;

  constructor(initialValue = 0) {
    this.#count = initialValue;
  }

  increment() {
    this.#count++;
  }

  decrement() {
    this.#count--;
  }

  getCount() {
    return this.#count;
  }
}

            

              
                Copy
              
            
          

Cara Menggunakan Class

Konsumen menggunakan kata kunci `new` untuk membuat instance, yang secara semantik sangat jelas.

            // componentA.js
import { Counter } from './Counter.js';

const myCounter = new Counter(10); // Buat instance yang dimulai dari 10
myCounter.increment();
console.log(`Counter Komponen A: ${myCounter.getCount()}`); // Hasil: 11

// componentB.js
import { Counter } from './Counter.js';

const anotherCounter = new Counter(); // Buat instance terpisah yang dimulai dari 0
anotherCounter.increment();
console.log(`Counter Komponen B: ${anotherCounter.getCount()}`); // Hasil: 1
            

              
                Copy
              
            
          

Membandingkan Class dan Factory

Untuk banyak kasus penggunaan, pilihan antara factory dan class adalah masalah preferensi gaya. Namun, ada beberapa perbedaan yang perlu dipertimbangkan:

• Sintaks: Class menyediakan sintaks yang lebih terstruktur dan familiar bagi pengembang yang nyaman dengan OOP.
• Kata Kunci `this`: Class mengandalkan kata kunci `this`, yang bisa menjadi sumber kebingungan jika tidak ditangani dengan benar (misalnya, saat meneruskan metode sebagai callback). Factory, dengan menggunakan closure, menghindari `this` sama sekali.
• Pewarisan (Inheritance): Class adalah pilihan yang jelas jika Anda perlu menggunakan pewarisan (`extends`).
• `instanceof`: Anda dapat memeriksa tipe objek yang dibuat dari class menggunakan `instanceof`, yang tidak mungkin dilakukan dengan objek biasa yang dikembalikan dari factory.

Pengambilan Keputusan Strategis: Memilih Pola yang Tepat

Kunci manajemen perilaku yang efektif bukanlah untuk selalu menggunakan satu pola, tetapi untuk memahami trade-off dan memilih alat yang tepat untuk pekerjaan tersebut. Mari kita pertimbangkan beberapa skenario.

Skenario 1: Manajer Feature Flag Seluruh Aplikasi

Anda memerlukan satu sumber kebenaran untuk feature flag yang dimuat sekali saat aplikasi dimulai. Bagian mana pun dari aplikasi harus dapat memeriksa apakah sebuah fitur diaktifkan.
Putusan: Singleton Implisit sangat cocok di sini. Anda menginginkan satu set flag yang konsisten untuk semua pengguna dalam satu sesi.

Skenario 2: Komponen UI untuk Dialog Modal

Anda harus dapat menampilkan beberapa dialog modal yang independen di layar pada saat yang bersamaan. Setiap modal memiliki state-nya sendiri (misalnya, buka/tutup, konten, judul).
Putusan: Factory atau Class sangat penting. Menggunakan singleton berarti Anda hanya bisa memiliki satu state modal yang aktif di seluruh aplikasi pada satu waktu. Factory `createModal()` atau `new Modal()` akan memungkinkan Anda untuk mengelola masing-masing secara independen.

Skenario 3: Kumpulan Fungsi Utilitas Matematika

Anda memiliki modul dengan fungsi seperti `sum(a, b)`, `calculateTax(amount, rate)`, dan `formatCurrency(value, currencyCode)`.
Putusan: Ini membutuhkan Modul Stateless. Tidak ada dari fungsi-fungsi ini yang bergantung pada atau memodifikasi state internal apa pun di dalam modul. Mereka adalah fungsi murni yang outputnya hanya bergantung pada inputnya. Ini adalah pola yang paling sederhana dan paling dapat diprediksi dari semuanya.

Pertimbangan Lanjutan dan Praktik Terbaik

Dependency Injection untuk Fleksibilitas Tertinggi

Factory dan class membuat teknik yang kuat yang disebut Dependency Injection mudah diimplementasikan. Alih-alih modul membuat dependensinya sendiri (seperti klien API atau logger), Anda meneruskannya sebagai argumen. Ini memisahkan modul Anda dan membuatnya sangat mudah untuk diuji, karena Anda dapat meneruskan dependensi tiruan (mock).

            // createApiClient.js (Factory dengan Dependency Injection)

// Factory ini mengambil `fetcher` dan `logger` sebagai dependensi.
export function createApiClient(config) {
  const { fetcher, logger, baseUrl } = config;

  return {
    async getUsers() {
      try {
        logger.log(`Mengambil pengguna dari ${baseUrl}/users`);
        const response = await fetcher(`${baseUrl}/users`);
        return await response.json();
      } catch (error) {
        logger.error('Gagal mengambil pengguna', error);
        throw error;
      }
    }
  }
}

// Di file aplikasi utama Anda:
import { createApiClient } from './createApiClient.js';
import { appLogger } from './logger.js';

const productionApi = createApiClient({ 
  fetcher: window.fetch, 
  logger: appLogger, 
  baseUrl: 'https://api.production.com'
});

// Di file pengujian Anda:
const mockFetcher = () => Promise.resolve({ json: () => Promise.resolve([{id: 1, name: 'test'}]) });
const mockLogger = { log: () => {}, error: () => {} };

const testApi = createApiClient({ 
  fetcher: mockFetcher, 
  logger: mockLogger, 
  baseUrl: 'https://api.test.com'
});
            

              
                Copy
              
            
          

Peran Pustaka Manajemen State

Untuk aplikasi yang kompleks, Anda mungkin akan menggunakan pustaka manajemen state khusus seperti Redux, Zustand, atau Pinia. Penting untuk menyadari bahwa pustaka ini tidak menggantikan pola yang telah kita diskusikan; mereka dibangun di atasnya. Sebagian besar pustaka manajemen state menyediakan singleton store yang sangat terstruktur untuk seluruh aplikasi. Mereka memecahkan masalah perubahan yang tidak dapat diprediksi pada state bersama bukan dengan menghilangkan singleton, tetapi dengan memberlakukan aturan ketat tentang bagaimana ia dapat dimodifikasi (misalnya, melalui action dan reducer). Anda akan tetap menggunakan factory, class, dan modul stateless untuk logika tingkat komponen dan layanan yang berinteraksi dengan store pusat ini.

Kesimpulan: Dari Kekacauan Implisit ke Desain yang Disengaja

Mengelola state di JavaScript adalah perjalanan dari yang implisit ke yang eksplisit. Secara default, modul ES memberi kita alat yang kuat tetapi berpotensi berbahaya: singleton. Bergantung pada default ini untuk semua logika stateful mengarah pada kode yang sangat terikat, tidak dapat diuji, dan sulit untuk dipahami.

Dengan secara sadar memilih pola yang tepat untuk tugas tersebut, kita mengubah kode kita. Kita beralih dari kekacauan ke kontrol.

• Gunakan pola Singleton secara sengaja untuk layanan sejati di seluruh aplikasi seperti konfigurasi atau logging.
• Manfaatkan pola Factory dan Class untuk membuat instance perilaku yang terisolasi dan independen, yang mengarah ke komponen yang dapat diprediksi, terpisah, dan sangat dapat diuji.
• Berusahalah untuk modul Stateless kapan pun memungkinkan, karena mereka mewakili puncak kesederhanaan dan dapat digunakan kembali.

Menguasai pola state modul ini adalah langkah penting dalam meningkatkan level sebagai pengembang JavaScript. Ini memungkinkan Anda untuk merancang aplikasi yang tidak hanya fungsional hari ini tetapi juga skalabel, dapat dipelihara, dan tangguh terhadap perubahan untuk tahun-tahun mendatang.