Menguasai Manipulasi DOM Sepenuhnya dengan JavaScript Vanilla

 (phuoc.ng)
6 poin oleh GN⁺ 2023-11-07 | 1 komentar | Bagikan ke WhatsApp
  • Artikel ini membahas penguasaan manipulasi Document Object Model (DOM) menggunakan JavaScript vanilla.
  • Meski alat modern seperti Angular, VueJS, React, Solid, dan Svelte banyak digunakan, artikel ini menekankan pentingnya memahami DOM API browser untuk pengembangan web.
  • Penulis menyediakan kumpulan materi yang mencakup API browser dasar, contoh yang mudah dipahami, demo langsung, tips dan praktik terbaik, kasus penggunaan nyata, serta kompatibilitas dengan browser modern dan Internet Explorer.
  • Materi tersebut dibagi menjadi tiga level: dasar, menengah, dan lanjutan.
  • Level dasar mencakup tugas seperti mengubah favicon secara dinamis sesuai preferensi skema warna pengguna, menghitung waktu baca halaman web, dan memperbarui variabel root CSS secara dinamis.
  • Level menengah mencakup tugas seperti menghapus indentasi di area teks menggunakan kombinasi tombol Shift+Tab, masuk ke mode layar penuh, dan membangun input spin.
  • Level lanjutan mencakup tugas seperti membuat kursor kustom, menyanitasi string HTML, dan membuat scrollbar kustom.
  • Penulis juga memberikan tips seperti menghindari pergeseran layout saat membuka modal, serta mendapatkan kotak pembatas dari node teks.
  • Artikel ditutup dengan ajakan untuk berlangganan newsletter penulis tentang konten teknologi frontend.

Bacaan terkait

1 komentar

 
GN⁺ 2023-11-07
Opini Hacker News

  • Daftar contohnya bagus, dan bahkan hanya dengan melihat sekilas beberapa saja, ketelitian dan detailnya terasa mengejutkan
    Saat berpindah dari platform seperti React ke implementasi yang lebih kecil dan minimal, saya sering buntu soal bagaimana menangani pola yang kompleks dengan JS standar. Namun ketika melihat kodenya, kadang terasa, “ternyata jauh lebih mudah daripada meneruskan banyak sekali properti ke library raksasa.”

    • Saya mendapat pencerahan serupa setelah mengalami 3–4 pembaruan mayor RiotJS
      Bahkan framework JS minimal pun, ketika permintaan fitur yang tampak polos menumpuk, pada akhirnya mudah berubah menjadi monster berisi hook, event, dan tambalan side effect
      Sekarang saya bahkan tidak memakai jQuery, dan hal seperti ES module memang saya pakai untuk merapikan kode, tetapi tidak perlu sampai menjalankan perintah npm. Ini bukan barang yang harus ditarik sebagai vendor dependency, melainkan standar browser global
      Belakangan ini saya menganggap MDN seperti kitab suci. Jika diikuti dengan percaya, hampir selalu membawa kita sampai akhir, sementara framework justru mulai menghambat di titik tertentu. Lima tahun lalu belum sampai seperti ini, tetapi API browser cepat berkonvergensi ke elemen dasar yang kuat dan konsisten seperti module, flexbox, dan grid
    • Contoh-contoh di artikel asli bukanlah sesuatu yang sifatnya bersaing dengan framework klien web. Masalah umum yang diselesaikan framework adalah manajemen state dan pembaruan UI saat state berubah
      Misalnya, sebagian besar contoh di artikel asli lebih dekat dengan kode yang tetap harus ditulis sendiri meskipun memakai React

  • Sebagai proyek sampingan, saya sedang membuat sesuatu yang belum bernama, semacam “vim untuk desainer web”. Seperti Webflow, ini membuat website atau komponen di browser, tetapi semuanya digerakkan oleh bahasa perintah
    Awalnya saya bertekad melakukannya tanpa framework. Saya sudah mengerjakan hal ini sejak 2009 dan sudah lama memakai JS sebelum menyentuh framework, jadi saya pikir native DOM API sudah cukup
    Namun memindahkan data masuk dan keluar dari DOM terlalu membosankan dan rawan salah, sehingga demi kesehatan mental, akhirnya saya mulai menulis mini-framework sendiri. Baru saat itu saya teringat alasan awal orang mulai memakai framework. Pada akhirnya, kita akan memakai framework dalam bentuk apa pun; bedanya hanya apakah itu buatan sendiri yang khusus, atau standar industri buatan komunitas
    Untuk situs dengan sedikit interaksi, native DOM juga bagus, dan sebagian besar situs yang memakai React sebenarnya mungkin tidak membutuhkannya. Namun jika produk punya sedikit saja nuansa atau kompleksitas, saya akan memakai framework dan menghindari kerepotannya. Pada akhirnya saya pindah ke Svelte dan jauh lebih puas

    • Proyek yang superminimal pada akhirnya akan mengimplementasikan ulang setengah dari jquery atau lodash. Jauh lebih mudah mencari library bagus seperti ramda yang tree shaking-nya bekerja baik, lalu memakainya secukupnya
    • Ungkapan “jika tidak memilih framework, Anda akan membuatnya sendiri” benar-benar tepat
    • Ini kasus membuat aplikasi, jadi dari deskripsinya saja bisa diduga bahwa membungkus interaksi DOM adalah pilihan yang lebih baik
      Untuk website yang membutuhkan interaksi, manipulasi DOM bisa menjadi pilihan yang lebih baik karena memakai teknologi yang lebih fundamental dan universal, proses build-nya ringan atau tidak ada, eksekusinya cepat, dan eksplisit
      Tentu ada banyak area abu-abu, tetapi kasus ini tepat masuk kategori ketika framework memberikan keuntungan
    • SvelteKit sekarang berfokus pada SSR, dan Svelte sendiri tidak punya router client-side bawaan. Saya sempat mencoba memakai Svelte untuk aplikasi satu halaman CSR, lalu menyerah

  • value.startsWith('javascript:') saja menimbulkan celah. Karena URL bisa diawali whitespace sembarang, setidaknya perlu value.trim().startsWith('javascript:')
    Meski begitu, menurut saya allowlist lebih baik daripada blocklist. Cukup izinkan http:, https:, dan jika perlu mailto:, ftp:, sftp:, sementara URL relatif yang diawali / mungkin bisa diizinkan
    Namun karena semua atribut yang benar-benar bisa menjadi URL harus ditangani dengan tepat, pada akhirnya mungkin lebih baik hanya mengizinkan beberapa tag beserta atributnya

  • Ini terlihat seperti daftar yang berguna untuk diketahui, dan meski belum melihat semuanya, sejauh ini tampak oke
    Saat membuka contoh pertama, terlihat window.matchMedia('(prefers-color-scheme: dark)') dijalankan dua kali tanpa perlu
    Jika setFavicon akan dipakai sebagai callback event listener, cukup gunakan event.matches dari parameter event yang diteruskan ke callback
    Secara pribadi, saya lebih suka menanganinya di HTML, karena itu juga mendukung pengguna yang mematikan JS
    https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...

    • Menanganinya di HTML juga bisa mencegah kilatan singkat konten dari tema lain. Pendekatan yang sama dapat diterapkan pada meta theme-color; ini fitur bagus yang jarang dipakai, bahkan oleh developer PWA yang peduli detail

  • Teknik “textarea yang meluas otomatis” mulai usang karena properti CSS baru form-sizing
    https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
    Bahkan tanpa memakai properti CSS baru ini, cara menyesuaikan height elemen tidak ideal dan bisa terasa tersendat
    Pendekatan yang lebih baik adalah memakai elemen cermin yang disembunyikan
    https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...

  • Cukup banyak hal di sini memakai API lama dan canggung, padahal ada API native yang lebih baik
    Misalnya “mengganti elemen” ditulis sebagai ele.parentNode.replaceChild(newEle, ele);, tetapi kalau tidak menargetkan Chrome di bawah 54, Firefox di bawah 49, atau Safari di bawah 10, cukup pakai ele.replaceWith(newEle)
    replaceWith juga bisa mengganti satu node dengan beberapa node atau teks
    Demikian pula untuk “mengiterasi NodeList”, disarankan memakai spread array lalu forEach, tetapi cukup for (let ele of nodelist) ...

    • Perlu diingat bahwa NodeList bisa berupa objek live. Jika daftar itu dimanipulasi saat iterasi, hasilnya bisa di luar dugaan

  • Bagus. Sudah saya bookmark. Ada juga materi bagus dengan nuansa serupa: https://youmightnotneedjquery.com/
    Saya tidak sering mengerjakan web, tetapi setiap kali melakukannya, kelebihan framework di dunia itu benar-benar mematahkan semangat. Proyek React baru yang dimulai dengan ratusan dependency sudah di luar kendali, dan beratnya kompleksitas itu mengejutkan
    Sebaliknya, teknologi browser lintas platform bawaan kini lebih kuat dari sebelumnya, dan jumlah kode untuk tugas umum juga tidak terlalu banyak
    Para developer frontend, kalian baik-baik saja?

    • Saya sama sekali bukan penggemar React atau npm, tetapi menurut saya beberapa framework masih punya tempat karena menyediakan hal-hal berguna yang tidak diberikan oleh DOM API murni
      Misalnya manajemen state aplikasi dan routing adalah bagian besar yang harus diimplementasikan sendiri kalau hanya memakai DOM API murni
      Tergantung kompleksitas aplikasi, ini mungkin bukan masalah besar, tetapi begitu melewati aplikasi dasar, nilai fitur tambahan seperti ini cepat meningkat. Namun kalau yang dipakai membutuhkan NPM, urusannya jadi merepotkan
    • Materi hebat lain dengan nuansa serupa adalah https://javascript.info/ yang keren
      Sebagai developer frontend yang menyukai platform dasar dan fiturnya, saya senang melihat hal-hal bagus hadir, seperti CSS bersarang, container queries, dan pengalaman JS yang secara umum membaik sejak ES6
      Pada saat yang sama, saya juga heran karena terlalu banyak orang memakai komponen bahkan untuk hal sepele seperti tombol atau teks tebal
      Saya menyukai framework itu sendiri, tetapi banyak pemasaran framework dan library bersandar pada keyakinan bahwa CSS dan manipulasi DOM murni itu luar biasa sulit, sementara menarik paket apa saja dari NPM bukan hanya cepat dan mudah, tetapi juga pekerjaan yang profesional
    • Saya setuju bahwa ini sudah di luar kendali. Namun selama setahun terakhir saya pindah ke tim platform dan untuk pertama kalinya mulai menangani tool di sisi DevOps, dan kompleksitasnya juga tidak kalah dari frontend
      Lihat saja Kubernetes, Helm, Terraform, CircleCI; jumlah istilah yang bertumpuk-tumpuk itu tidak masuk akal
    • Saya penasaran apakah pernah melakukan sesuatu yang tidak sepele dengan “teknologi lintas platform yang kuat” itu. Dan React bukan satu-satunya pilihan

  • Saya benar-benar terkejut saat mengetahui bahwa beberapa fungsi DOM mengembalikan live HTMLCollection yang diperbarui otomatis
    Saya penasaran seberapa aktif fitur ini dipakai dalam kode produksi nyata sebelum demam framework, atau sekitar saat tren kembali mengembangkan tanpa framework mulai sedikit populer lagi

  • Yang lama menjadi baru lagi. Peran frontend pertama saya pada 1999 adalah membuat aplikasi web
    Fitur-fitur keren seperti drag-and-drop tree view, klik untuk mengedit, bahkan sesuatu yang pada dasarnya seperti single-page app, semuanya dibuat dengan JS “Vanilla”
    Bagian tersulit adalah menyelaraskan perbedaan antara Netscape dan Internet Explorer

    • Saya penasaran bagaimana state dan perubahannya dikelola
      Kenapa sekarang kita terlihat seperti tidak tahu cara melakukannya ;]

  • Fitur JavaScript murni favorit saya belakangan ini adalah Element.insertAdjacentHTML, yang sudah ada sejak Chrome 1.0 dan masa IE
    Mengatakan bahwa fitur ini berguna, terutama bersama string multi-baris dengan backtick, masih kurang menggambarkan manfaatnya. Sulit dipercaya fitur ini sudah ada begitu lama dan saya baru mengetahuinya sekitar setahun lalu
    insertAdjacentHTML(position, text) mem-parse teks yang ditentukan sebagai HTML atau XML, lalu menyisipkan node hasilnya ke posisi yang ditentukan di pohon DOM
    Kalau hanya memakai DOM biasa, kita harus membuat elemen li, membuat elemen a, menambahkannya sebagai anak, mengatur atribut href, memasukkan nilai teks, lalu menyisipkannya ke ul. Atau mengumpulkannya sebagai string besar dan memasukkannya dengan innerHTML, sementara memodifikasi daftar yang sudah ada akan lebih menyakitkan dan bertele-tele

    1. https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...