Desain v3.1: identitas halaman tanpa marker
Spesifikasi desain v3.1 memindahkan identitas halaman dari marker HTML tersembunyi ke page_id di config, dengan verifikasi baca-kembali.
Ringkasan
Desain v3-1 mindahin identitas halaman dari marker HTML ngumpet ke page_id eksplisit biar nggak gampang hilang pas sanitasi. Sekarang verifikasinya pakai retrieve-after-write dengan bandingin hash yang udah dinormalisasi dan fail-loud kalau ada bentuk aneh. Ini masih sebatas desain, belum di-ship, tapi bikin pemisahan data jadi lebih rapi.
Saya sedang menelusuri diff dari sebuah commit desain, dan mata saya tertuju pada satu perubahan kecil yang sebenarnya punya dampak besar. Dulu, kita mengandalkan marker HTML tersembunyi untuk mengenali sebuah halaman. Ternyata, pendekatan itu bikin proses validasi jadi rapuh saat berhadapan dengan berbagai variasi input.
Awalnya saya kira cukup dengan menambahkan atribut data khusus di level root DOM. Saya pikir itu solusi paling bersih dan minim gangguan. Tapi setelah dipikir ulang, parser HTML punya kebiasaan sendiri saat menangani struktur yang tidak sepenuhnya standar. Marker tersembunyi sering kali terpotong atau berubah bentuk tanpa peringatan saat disanitasi.
Spesifikasi desain v3.1 ini justru menggeser logika tersebut secara fundamental. Konsep desain v3.1 ini sekarang dipindahkan dari marker HTML tersembunyi menjadi konfigurasi page_id yang eksplisit, ditambah dengan konvensi penamaan yang ketat. Ini bukan sekadar perubahan kosmetik, tapi pergeseran arsitektur cara kita melacak state.
Pergeseran dari Marker Tersembunyi
Plane melakukan sanitasi pada HTML dan mengonversinya ke format dokumen editor sebelum diproses lebih lanjut [1]. Saat proses parsing berjalan, modul HTMLParser mengekspos handler callbacks untuk tag, teks, dan komentar [2].
Jika kita masih memaksakan marker tersembunyi di dalam konten yang akan disanitasi, risiko hilang atau berubah formatnya sangat besar. Dengan memindahkan logika ini ke konfigurasi page_id di luar konten mentah, kita memisahkan concern dengan lebih rapi. Data identitas nggak lagi bercampur aduk dengan data presentasi.
Verifikasi dan Normalisasi Hash
Perubahan ini memaksa kita untuk melakukan verifikasi retrieve-after-write. Kita nggak bisa cuma asal kirim data dan berasumsi semuanya aman di sisi server.
Mekanisme yang dirancang sekarang membandingkan hash yang sudah dinormalisasi. Artinya, sebelum data dianggap valid, sistem akan ngecek apakah bentuk yang diterima sesuai dengan ekspektasi. Hanya transformasi editor yang sudah teramati dan didokumentasikan yang diizinkan.
Jika ada bentuk yang tidak dikenal, sistem dirancang untuk fail-loud. Lebih baik proses berhenti dan memberi peringatan jelas daripada diam-diam menghasilkan data yang korup. Pemicu untuk kanonikalisasi server yang jarang terjadi memang belum diidentifikasi secara spesifik dalam desain ini, tapi prinsip fail-loud sudah memberikan jaring pengaman yang cukup.
Batasan Spesifikasi Desain
Ini spesifikasi desain v3.1, bukan implementasi yang sudah shipped atau rollout ke produksi. Saya belum mengklaim adanya resolusi insiden, perilaku universal, atau benchmark performa dari perubahan ini.
Membaca dokumen desain dengan mata perancang membantu saya menyiapkan fondasi yang lebih kokoh sebelum baris kode eksekusi benar-benar ditulis. Saya jadi tahu persis batasan apa yang boleh dilanggar dan mana yang harus dijaga ketat.
Desain lengkapnya ada di commit ini [3], dan perubahan kecilnya mengingatkan saya bahwa solusi teknis yang elegan sering kali datang dari menyederhanakan asumsi, bukan menambah kompleksitas.
Sumber