- Format untuk menyusun secara visual perilaku sistem yang kompleks, yang memperluas state machine dasar agar lebih mampu menangani masalah state explosion
- Memungkinkan pemisahan perilaku dan komponen, sehingga perubahan perilaku dan penalaran kode menjadi lebih mudah, serta cocok untuk pengujian yang independen dari komponen dan eksplorasi kondisi pengecualian
- Dalam proses membuat statechart, semua kemungkinan status akan dieksplorasi, dan ada pula hasil riset yang menunjukkan jumlah bug lebih rendah pada kode berbasis statechart dibandingkan kode tradisional
- Melalui standar SCXML dan alat serta pustaka di berbagai bahasa, model dapat dibaca, ditulis, dan dijalankan, serta membantu menangani urutan perilaku seperti entry/exit action dengan benar
- Jika menggunakan machine format yang dapat dieksekusi, satu definisi dapat dijadikan single source of truth untuk menjaga perilaku runtime dan diagram tetap selaras, sehingga menjaga sinkronisasi antara implementasi dan desain menjadi penting
Gambaran Umum Statecharts
- Statechart adalah format visual untuk menangani sistem yang kompleks, berupa perluasan dari state machine dasar
- Ini diperkuat untuk menangani masalah state explosion yang muncul saat state machine membesar
- Perilaku bisa dinyatakan dalam bentuk gambar, tetapi dalam rekayasa perangkat lunak, ini lebih dekat ke pemodelan perilaku dan penyusunan struktur daripada visualisasi itu sendiri
- Penjelasan dasar terkait dilanjutkan di What is a state machine?, What is a statechart?
Mengapa Menggunakan Statecharts
- Memiliki struktur yang mudah dipahami, sehingga lebih mudah dimengerti dibanding banyak bentuk kode lainnya
- Memungkinkan pemisahan perilaku dan komponen
- Perubahan perilaku menjadi lebih mudah
- Penalaran terhadap kode menjadi lebih mudah
- Perilaku dapat diuji secara independen dari komponen
- Dalam proses membuat statechart, kita akan mengeksplorasi semua status yang mungkin
- Ada hasil riset yang menunjukkan jumlah bug lebih rendah pada kode berbasis statechart dibandingkan kode tradisional
- Cocok untuk menangani kondisi pengecualian yang mudah terlewat
- Semakin besar kompleksitasnya, semakin baik skalabilitasnya
- Mudah dipahami bahkan oleh orang non-developer, dan QA dapat memanfaatkannya sebagai alat eksplorasi
- Banyak kode sebenarnya sudah memuat state machine secara implisit, dan statechart bekerja sebagai cara untuk menampakkannya secara eksplisit
Beban dan Faktor Penolakan terhadap Statecharts
- Membutuhkan biaya pembelajaran baru
- Meski konsep dasarnya, yaitu state machine, mungkin sudah akrab bagi banyak programmer
- Cukup berbeda dari cara menulis kode yang ada, sehingga bisa terasa sebagai paradigma yang asing
- Hal ini bisa menimbulkan penolakan di tingkat tim
- Pada statechart kecil, proses memisahkan perilaku bisa membuat jumlah baris kode bertambah
- Alasan mengapa ini belum digunakan secara luas antara lain kurangnya kesadaran dan YAGNI yang bekerja bersamaan
- Argumen penolakan yang umum adalah merasa ini tidak terlalu perlu, tidak sesuai dengan arus teknologi tertentu, dan menambah jumlah pustaka
- Pada aplikasi web, waktu muat bisa bertambah
- Meski melihat kelebihan dan kekurangan ini secara bersamaan, efek adopsinya secara umum tetap lebih dekat ke keuntungan bersih
Cara Penggunaan dan SCXML
- SCXML adalah format yang distandardisasi oleh W3C dari 2005 hingga 2015, yang mendefinisikan berbagai aturan semantik statechart dan penanganan edge case
- Ada alat di berbagai bahasa untuk membaca, menulis, dan menjalankan SCXML
- Ada juga format turunan dengan sintaks berbeda sambil mempertahankan model yang sama
- Tersedia pustaka statechart untuk berbagai platform, dengan tingkat dukungan berbeda-beda terhadap aturan semantik SCXML
- Menggunakan pustaka-pustaka ini membantu menangani urutan perilaku seperti entry/exit action dengan benar
- Panduan penggunaan tambahan dilanjutkan di how to use statecharts
Statecharts yang Dapat Dieksekusi
- Alih-alih memakai statechart hanya sebagai dokumen, machine format yang dapat dieksekusi dapat digunakan bersama untuk desain dan runtime
- Satu definisi dapat dijadikan single source of truth untuk menggerakkan perilaku runtime nyata dan diagram visual sekaligus
- Tidak lagi perlu memindahkan diagram ke dalam kode
- Dapat mengurangi bug yang muncul saat menerjemahkannya secara manual
- Diagram dan implementasi selalu menjaga keadaan yang tersinkronisasi
- Diagram menjadi lebih presisi
- Sebaliknya, diagram juga bisa menjadi cukup kompleks
- Pilihan format dan alat untuk statechart yang dapat dieksekusi masih terbatas
- Sulit untuk menjamin type safety yang kuat antara statechart dan komponen
- Jika definisi statechart ada di dalam kode, representasi itu dapat dipakai untuk menghasilkan statechart visual secara otomatis
- Ini menjadi lebih sederhana jika definisinya berada di file terpisah seperti JSON atau XML
Komunitas dan Materi Tambahan
1 komentar
Opini Hacker News
Senang melihat statecharts terus mendapat perhatian
Saya membuat XState, library untuk menulis/menjalankan/memvisualisasikan state machine dan statecharts untuk JS/TS, dan bisa dilihat di https://github.com/statelyai/xstate
Hal terpenting yang saya pelajari selama lebih dari 10 tahun mengerjakannya adalah bahwa statecharts paling bernilai ketika diperlakukan bukan sekadar sebagai dokumentasi, melainkan sebagai perilaku yang dapat dieksekusi
Tidak perlu dipakai di semua tempat, tetapi sangat kuat terutama ketika "apa yang terjadi berikutnya?" bergantung pada status saat ini dan juga event
Diagram seperti ini bisa dipakai seperti oracle yang menjawab, "jika event ini datang pada status ini sekarang, status berikutnya apa dan efek apa yang dijalankan?"
Alpha untuk major version berikutnya dari XState juga hampir siap, dengan fokus pada ergonomics, type safety, composability, dan visualizer/editor baru
Alat visualisasi open source dasarnya ada di https://sketch.stately.ai
Untuk sisi spesifikasi formal, SCXML layak dibaca: https://www.w3.org/TR/scxml
Makalah asli David Harel juga sangat berharga: https://www.weizmann.ac.il/math/harel/sites/math.harel/files/users/user50/Statecharts.pdf
Ada juga video presentasi di Laracon yang merangkum pemikiran tentang state machines dan statecharts
https://www.youtube.com/watch?v=1A1xFtlDyzU
Ini implementasi yang cukup matang, tetap sangat dekat dengan SCXML sambil menghapus kebutuhan XML, terutama untuk konten yang dapat dieksekusi
XState juga masuk sebagai referensi di bagian prior art
Saya memakainya bersama lit.js untuk komponen navigasi tipe drawer yang responsif terhadap lebar halaman dan punya banyak props serta state internal; saya bahkan tak bisa membayangkan betapa mengerikannya tanpa XState
Sangat menantikan versi berikutnya, dan terima kasih banyak
Inferensi tipe TS otomatisnya cukup bagus, jadi nyaman dipakai saat butuh logika state machine yang ringan
Dulu rasanya statecharts mulai mendapat momentum di frontend/UI ecosystem, jadi sayang aliran itu seperti menghilang entah kenapa
Untuk interaksi UI, memakai state machine, khususnya komposisi state machine seperti statecharts, membuat alur yang kompleks jauh lebih mudah dipahami
Kalau baru pertama kali mengenalnya, saya sangat merekomendasikan Ian Horrucks, "Constructing the user interface with statecharts"
Memang buku tahun 1999, tetapi sebagai pengantar yang menjelaskan cara benar-benar menerapkan dan memakainya, ini masih termasuk yang terbaik
https://archive.org/details/isbn_9780201342789/mode/2up
Unduhan npm mingguannya sudah melewati 4 juta, dan alat animasi seperti Rive dan LottieFiles juga sangat menonjolkan kemampuan state machine
Alat AI seperti LangGraph juga dibangun di atas dasar state machine
Mungkin masih perlu waktu agar aplikasi dan alat ini benar-benar mengeluarkan seluruh potensi statecharts, tetapi awalnya bagus
https://github.com/derkork/godot-statecharts
Bagian yang sering hilang dari buku pengantar adalah history pseudo-states
Jika memakai H, H, maka dari sudut pandang luar statechart menjadi tidak deterministik secara formal
Sering dijelaskan bahwa "status saat ini adalah fungsi murni dari input", tetapi history merusak asumsi itu
Saat masuk kembali ke parent state melalui H, kita kembali ke child terakhir yang aktif, jadi dengan event yang sama dan status luar yang sama pun kita bisa masuk ke status internal yang berbeda
"Child aktif terakhir" yang tersembunyi itu sendiri adalah state, tetapi biasanya tidak digambar di diagram
Makalah asli Harel juga mengakui ini, dan SCXML maupun XState juga mengimplementasikannya, tetapi justru bagian ini hampir tidak pernah dibahas
Jadi jika Anda mempertahankan state subtree saat re-entry dengan deep history, pada dasarnya Anda memindahkan bookkeeping ke sisi chart engine
Itu pilihan yang wajar, tetapi gambar saja tidak bisa menjelaskan seluruh perilaku, dan transisi history juga perlu diuji terpisah seperti logika state lainnya
Dengan tafsir kedua, mesinnya sepenuhnya deterministik, dan pointer deep history juga hanya bagian dari state state machine
Misalnya, node H, H bisa diurai menjadi beberapa node, dan H' bisa diletakkan di depan tiap node seperti write-ahead log
Saya penasaran apakah engine durable execution seperti Temporal, DBOS, Restate bisa digabungkan dengan statecharts
Di perusahaan, kami memakai Cloudflare Workflows untuk mengelola workflow onboarding dan payment, dan diagram flowchart yang muncul otomatis membantu memahami perilaku workflow dengan cepat
Ini terasa sangat mirip dengan nilai yang ingin dicapai statecharts
https://zindex.ai/
Diagram yang dibuat AI biasanya hanya Mermaid/SVG/PNG sekali jadi, jadi tidak punya state diagram yang persisten yang bisa diperbarui, divalidasi, di-diff, dan dipakai ulang
Zindex memperlakukan diagram itu sendiri sebagai state terstruktur
Agent melakukan patch pada node, edge, group, relationship, constraint, dan revision lewat Diagram Scene Protocol (DSP), lalu Zindex menangani validation, layout, rendering, versioning, dan storage
Jadi saya rasa ini bisa ditempelkan di samping Temporal/DBOS/Restate/Cloudflare Workflows, sehingga sumber kebenaran eksekusi tetap dijaga engine, sementara Zindex mengelola model visual persisten yang bisa diperiksa dan diturunkan dari kode atau riwayat eksekusi
Padahal kalau ditambah durable execution, statecharts sepenuhnya mampu melakukan hal yang sama
Cloudflare sempat terlihat mengarah ke model actor durable object, tetapi saya tidak tahu apakah proyek itu sudah dihentikan
Apakah itu fitur bawaan Cloudflare Workers, atau sesuatu yang dibuat sendiri oleh tim?
Saya benar-benar suka XState
Ia telah menyelesaikan banyak sekali masalah di berbagai codebase, dan belakangan menjadi kerangka inti aplikasi suara yang kami bangun untuk sektor perbankan
Terima kasih sudah mencurahkan waktu dan usaha untuk membuatnya sebaik ini
Saya juga sempat menulis sedikit di blog tentang pengalaman dengan finite state machines, serta arsitektur yang saya bangun dengan XState + Mastra
Setelah dipublikasikan, saya beralih dari Mastra ke Pipecat
https://blog.davemo.com/posts/2026-02-14-deterministic-core-agentic-shell.html
Saya lempar ini juga
ETL State Chart dan Hierarchial FSM:
https://www.etlcpp.com/state_chart.html / https://www.etlcpp.com/hfsm.html
Quantum Leaps:
https://www.state-machine.com
Saya terutama memakainya di sistem safety-critical; di sana kompleksitas, timing, dan kemampuan verifikasi perilaku sangat penting
Sangat membantu bahwa pengambilan keputusan bisa dipisahkan dari tindakan
Cara mereduksi pengambilan keputusan menjadi "dalam state ini sekarang, jika event ini datang, apa yang dilakukan berikutnya" memang agak berbeda dari struktur program biasa, tetapi itu menciptakan pemisahan yang baik dan memudahkan penalaran perilaku di berbagai kondisi
Saya selalu berharap adopsi state machine tumbuh lebih besar
Di era ketika kita tidak memahami kode buatan AI sedalam kode tulisan manusia, pemahaman visual terhadap state menjadi semakin penting
Meski begitu, framework frontend tampaknya masih lebih menyukai reactive state berbasis store
Saya sendiri juga menjadikannya default sehingga tidak merasa perlu berubah, dan library seperti xstate juga punya kesan lebih sulit dipelajari serta lebih verbose
Namun dengan AI, hambatan itu hampir hilang, jadi saya penasaran apakah ada alasan lain yang tidak saya lihat, atau memang statechart belum mencapai puncaknya
Permukaan API juga berkurang, kurva belajar lebih rendah, dan lebih mudah ditulis baik oleh developer maupun agent
Pada saat yang sama, model frontier modern sudah cukup bagus dalam menulis kode XState
Saat mengerjakan proyek https://github.com/xlnfinance/xln, saya sadar butuh cara untuk mengemulasikan jaringan nyata secara deterministik
Lalu saya berpikir, semua blockchain pada akhirnya adalah replicated state machine, jadi bagaimana kalau setiap node pengguna dibungkus dengan hierarki state machine 3 tingkat berupa Runtime -> Entity -> Account
Strukturnya membuat mesin luar sepenuhnya mengendalikan mesin di dalam, jadi semacam gambaran "blockchain di dalam blockchain" dengan mode konsensus yang berbeda-beda
Setelah itu saya mencari "hierarchical state machines" dan menemukan statecharts, dan saya merasa kedua ide itu cukup mirip
Menurut saya, lebih banyak software seharusnya memakai hierarki state machine untuk mengurangi bug terburuk yang lahir dari non-determinisme
Di bidang otomotif, pendekatan seperti ini sudah dipakai sejak lama
Kalau melihat matlab/simulink, Anda bisa menggambar algoritme sebagai state machine lalu menghasilkan kode darinya
Belakangan saya juga mengimplementasikan state machine untuk mengelola komponen React yang cukup kompleks, dengan struktur yang melewati CSS transition dan berpindah di antara berbagai state visual
State machine itu sendiri tidak terlalu sulit, tetapi sepertinya orang belum cukup terbiasa dengannya
Di perusahaan, sejak saya membuat interpreter di dalam Postgres, kami menjalankan semua proses bisnis dengan statecharts
Pengalamannya sangat baik, prosesnya menjadi sangat tahan terhadap perubahan, dan tetap mudah dipahami bahkan saat dilihat kembali beberapa tahun kemudian
Library-nya juga sudah saya rilis sebagai open source
https://github.com/kronor-io/statecharts