HTMX Mungkin Menjadi Masalah Besar untuk WordPress

Membangun pengalaman pengguna yang kaya di browser bisa menjadi tugas yang menantang, yang sering kali memerlukan sejumlah besar kode JavaScript. Seiring dengan meningkatnya kebutuhan dan ambisi aplikasi kita, kompleksitas kode JavaScript kita juga meningkat. Oleh karena itu, tidak mengherankan betapa seringnya pengembang merevisi cara kita berpikir dan menulis aplikasi JavaScript.

Hari sejak kerangka JS terakhir.

Pengembang plugin WordPress mengalami hal yang lebih buruk. Lingkungan yang kami targetkan bukanlah server yang kami kendalikan, atau lingkungan yang memiliki kendali penuh atas keseluruhan halaman. Meskipun sangat mungkin untuk berhasil menggunakan kerangka JavaScript di plugin WordPress, akan sangat mudah juga untuk mendapatkan proyek yang skala dan kompleksitasnya melebihi apa yang Anda inginkan atau harapkan.

Namun bagaimana jika tidak perlu seperti ini? Pada artikel ini, kita akan mengeksplorasi bagaimana UI web modern dibuat dengan JavaScript, kesulitan yang dihadapi pengembang, dan alternatif yang ditawarkan oleh HTML. Secara khusus, kita akan melihat mengapa HTMX dan WordPress bisa menjadi pasangan yang cocok.

Bagaimana kita sampai di sini

Sebelum JavaScript, browser pada dasarnya hanyalah pembaca dokumen yang dimuliakan. Oleh karena itu, sebagian besar pengalaman di web adalah 'aplikasi multi-halaman', atau disingkat MPA. MPA adalah aplikasi web yang terdiri dari beberapa dokumen HTML, satu untuk setiap halaman dalam aplikasi. Saat pengguna menggunakan aplikasi, mereka diperlihatkan dokumen berbeda dengan tindakan berbeda yang tersedia.

Pembangunan KKP sangatlah mudah. Navigasi dilakukan menggunakan tag <a> untuk menghubungkan ke dokumen lain, dan masukan pengguna dapat ditangkap dengan elemen <form> . Server merespons permintaan tautan dan formulir dengan dokumen HTML baru, menggantikan halaman yang ditampilkan di layar.

Contoh KKP yang mungkin sudah Anda kenal adalah WP Admin. Setiap halaman admin merupakan dokumen dengan HTML yang dihasilkan oleh kode PHP WordPress yang berjalan di server. Sebagian besar halaman di WP Admin, seperti halaman pengaturan WordPress, cenderung sebagian besar terdiri dari formulir yang dapat Anda kirimkan, sebagai pengguna.

Sebaliknya, aplikasi satu halaman, atau SPA, adalah aplikasi yang menggunakan satu halaman HTML. Navigasi dan masukan pengguna kemudian ditangani oleh kode JavaScript, yang secara dinamis mengubah bagian halaman di tempatnya tanpa perlu menukar seluruh halaman atau menyegarkannya. Hal ini menghasilkan pengalaman pengguna yang lebih lancar dan responsif.

Saat ini, banyak aplikasi web menggunakan SPA untuk antarmuka webnya. Di RebelCode, kami telah membuat SPA untuk antarmuka admin dari dua plugin WordPress utama kami: Spotlight dan Aggregator. Editor situs yang relatif baru di WordPress juga merupakan SPA, seperti halnya editor posting berbasis blok.

Harga yang kita bayar

SPA adalah aplikasinya sendiri, ditulis dalam JavaScript dan dijalankan di browser. Definisi mereka sendiri juga merupakan peringatan terbesar mereka: mereka tidak memiliki akses langsung ke sumber daya server. Artinya kita perlu membangun saluran komunikasi antara SPA dan server.

Mari kita buat plugin WordPress sederhana untuk menggunakan contoh. Plugin ini menyediakan
antarmuka pengguna CRUD sederhana untuk mengelola buku. API internal plugin di server mungkin terlihat seperti ini:

 <?php function get_books(?int $count = null, int $page = 1): Book[]; function get_book(int $id): Book; function insert_book(Book $book): Book; function update_book(Book $book): Book; function delete_book(int $id): void;

Untuk membuat antarmuka SPA modern, kami akan menggunakan kerangka JavaScript seperti React; kerangka JavaScript paling populer yang juga digunakan oleh WordPress. Mari kita mulai dengan menambahkan halaman admin:

 <?php add_action('admin_menu', function () { add_menu_page('Books', 'Books', 'manage_options', 'books', 'books_page'); }); function books_page() { echo '<div></div>'; }

Halaman kita akan merender satu elemen <div> kosong yang akan berfungsi sebagai root aplikasi React kita tempat UI lainnya akan dirender.

 const rootEl = document.getElementById("books-app"); const root = ReactDOM.createRoot(rootEl); root.render(<BooksApp />); function BooksApp() { return ( <div> <h1>My Books</h1> ... </div> ); }

Lalu bagaimana cara kita membuat daftar buku-buku yang disimpan di database? Kode untuk melakukan itu ada di server, jadi kita memerlukan cara untuk memanggilnya dan mendapatkan hasilnya.

Untuk melakukan itu, kita dapat mengekspos API JSON dari server. Aplikasi React kemudian dapat membuat permintaan di URL API kami, menerima buku dalam format JSON, lalu merender daftarnya. Untuk contoh ini, anggaplah kita telah menambahkan titik akhir ke REST API WordPress:

 GET https://my-wp-site.com/wp-json/books { "books": [ { "id": 15, "title": "Mistborn", "author": "Brandon Sanderson", }, { "id": 44, "title": "The Hobbit", "author": "JRR Tolkien", }, ] }

Kita kemudian dapat menulis komponen React yang mengambil buku-buku tersebut dan menjadikannya sebagai daftar:

 function BookList() { const [books, setBooks] = useState([]); const [isLoading, setIsLoading] = useState(true); const [error, setError] = useState(null); useEffect( function () { setIsLoading(true); fetch("https://my-wp-site.com/wp-json/books") .then((res) => res.json()) .then((data) => setBooks(data.books)) .else((error) => setError(error)) .finally(() => setIsLoading(false)); }, [setBooks, setIsLoading], ); if (isLoading) { return <div>Loading...</div>; } if (error) { return <div>Error: {error}</div>; } return ( <ul> <li> {books.map((book) => ( <a key={book.id} href={book.url}> {book.title} </a> ))} </li> </ul> ); }

Namun solusi ini terlalu naif, dan menghasilkan pengalaman pengguna yang kasar. Ini tidak melayani perubahan status setelah komponen dilepas, menyimpan respons dalam cache, mencoba kembali kueri yang gagal, atau mencegah status lama menimpa status yang lebih baru. Faktanya, cara kita menggunakan fetch() dalam efek React umumnya tidak disarankan.

Dalam banyak hal, hal ini bisa lebih buruk dibandingkan KKP tradisional. Jadi untuk melakukan ini dengan benar, kita perlu menerapkan beberapa hal lagi di klien kita. Atau lebih realistisnya, gunakan paket pihak ketiga.

Namun semua ini mulai terasa seperti upaya yang tidak proporsional hanya untuk membuat daftar buku. Apakah kita benar-benar perlu membuat aplikasi JavaScript dan API JSON untuk menciptakan pengalaman pengguna yang lancar?

Mari kita bandingkan hal ini dengan MPA, di mana rendering daftar buku dapat dilakukan hanya dalam beberapa baris kode PHP, tanpa ketergantungan apa pun:

 <?php function render_books() { ?> <ul> <?php foreach (get_books() as $book): ?> <li> <a href="<?= $book->url ?>"> <?= $book->title ?> </a> </li> <?php endforeach; ?> </ul> <?php }

Namun tentu saja ini bukanlah perbandingan yang adil. Daftar buku ini hanyalah HTML statis; itu tidak reaktif terhadap perubahan status atau masukan pengguna.

Jika kita ingin mendapatkan pengalaman seperti SPA sambil merender HTML di server, di mana kode kita memiliki akses langsung ke database, kita harus mencari cara agar HTML yang dirender di server dapat menemukan jalannya ke browser. dan ganti daftar buku sebelumnya. Namun mencapai hal ini tanpa kode JavaScript apa pun saat ini tidak mungkin dilakukan, jadi kami harus mengambil tindakan dan tetap menggunakan JavaScript.

Tapi kita tidak perlu menulisnya sendiri.

Memperkenalkan HTML

HTML adalah pustaka JavaScript kecil yang pada dasarnya melakukan satu hal: mengizinkan HTML meminta HTML baru dari server. Hal ini dilakukan dengan menggunakan atribut baru, yang memungkinkan kita memberi tahu HTML dari mana mendapatkan HTML baru, dengan apa menukarnya, dan apa yang memicu pertukaran tersebut. Ini bertindak sebagai jembatan antara server HTML kami dan halaman di browser.

Ini adalah cara berpikir yang sangat berbeda tentang SPA, karena kami tidak membangun aplikasi JavaScript klien untuk memperbarui halaman saat ini. Sebagai gantinya, kami cukup menambahkan beberapa atribut HTML untuk memberi tahu HTML bagaimana kami ingin halaman berubah ketika peristiwa tertentu terjadi.

Bahkan tanpa HTML, Anda sudah bisa mengubah apa yang ditampilkan di layar hanya dengan menggunakan HTML, meski dengan cara yang sangat terbatas. Anda sudah familiar dengan fitur HTML ini: elemen tautan <a> yang sederhana.

 <a href="https://my-wp-site.com/books">View books</a>

Elemen tautan memberi browser semua informasi yang diperlukan untuk melakukan navigasi. Ketika diklik, browser mengambil href dari elemen, membuat permintaan pada URL tersebut, mendownload respon dan, dengan asumsi bahwa URL tersebut berisi HTML, mengganti konten halaman dengan HTML baru.

Elemen <form> adalah contoh lain bagaimana HTML dapat meminta HTML baru.

 <form action="/contact.php"> <label> Your message: <input type="text" name="message" /> </label> <button type="submit">Send message</button> </form>

Kali ini, browser mengumpulkan nilai dari semua masukan dalam formulir, mengirimkannya ke server, mengunduh respons, dan menampilkannya di layar.

Mengapa hanya <a> dan <form> yang dapat membuat permintaan HTTP? Mengapa Anda hanya bisa mengganti seluruh layar?

Dari readme GitHub HTML

Nah, HTML mengubahnya.

 <a href="https://my-wp-site.com/books" hx-target="#books"> View books </a> <div></div>

Dengan atribut HTMX hx-target , mengeklik tautan kini akan menempatkan respons dari https://my-wp-site.com/books di dalam elemen dengan ID "books" . Tentu saja, menyematkan halaman di dalam halaman lain bukanlah tujuannya di sini. Server kami tidak perlu merespons dengan satu halaman penuh, dan cukup merespons dengan fragmen HTML.

Dengan mengekspos fragmen HTML dari server kami dan memberi tahu HTMX bagaimana, dari mana, dan kapan mendapatkan fragmen tersebut, kami dapat membuat aplikasi web seperti SPA tanpa JavaScript apa pun, di mana server memegang kendali penuh. Dalam arti tertentu, HTML telah menjadi JSON baru kami.

Dan yang perlu kita lakukan hanyalah memuat skrip HTML ke halaman kita:

 <script src="https://unpkg.com/[email protected]"></script>

(Pastikan untuk memeriksa dokumentasi HTMX untuk mendapatkan petunjuk, karena kode di atas mungkin sudah ketinggalan zaman).

Mari kita lihat contoh lainnya:

 <button hx-get="/button/off" hx-target="this" hx-swap="outerHTML"> Turn off </button>

Masih banyak lagi yang terjadi di sini, jadi mari kita uraikan:

• hx-get menentukan URL untuk mengirim permintaan GET ketika tombol diklik.
• hx-target="this" memberitahu HTML untuk menukar tombol yang diklik dengan respons.
• hx-swap="outerHTML" memberitahu HTML untuk menukar seluruh tombol, bukan hanya isinya.

Secara keseluruhan, ini memberi tahu HTML:

Saat tombol diklik, kirim permintaan GET ke /button/off dan ganti tombol ini dengan respons.

Katakanlah server merespons /button/off dengan HTML di bawah ini:

 <button hx-get="/button/on" hx-target="this" hx-swap="outerHTML"> Turn on </button>

Bisakah Anda melihat perbedaannya? Atribut hx-get sekarang mengarah ke /button/on dan teks di dalam tombol sekarang adalah "Aktifkan". Ketika tombol ini diklik, maka akan digantikan juga dengan respon dari /button/on . Seperti yang dapat Anda bayangkan, kami dapat meminta server merespons dengan tombol asli untuk menyelesaikan peralihan kami!

Ide sederhana yang mengizinkan elemen apa pun meminta HTML baru dari server dan memutuskan ke mana HTML tersebut akan pergi ternyata cukup ampuh. Kita dapat membuat tab, mencari dengan hasil langsung, bilah kemajuan, dan banyak lagi.

Pro dan kontra

Tidak seperti kebanyakan kerangka kerja JavaScript, HTMX tidak memerlukan kode aplikasi klien kami untuk dikompilasi dan digabungkan. Ini saja merupakan manfaat yang sangat besar; Sistem pembangunan JavaScript bisa jadi sangat sulit untuk diatur dan dipelihara, terutama ketika Anda mulai memperkenalkan fitur dan perpustakaan yang lebih eksotis, seperti TypeScript, JSX, pra-pemroses CSS, dll. Bukan hal yang aneh bagi tim menengah hingga besar untuk memilikinya. satu atau lebih anggota yang berdedikasi untuk tugas ini.

Manfaat nyata lainnya adalah tidak adanya aplikasi klien terpisah. Karena yang kita butuhkan hanyalah server HTTP yang merespons dengan HTML, kita dapat menggunakan bahasa pemrograman apa pun yang kita suka. Ini mungkin menjadi nilai jual yang besar bagi Anda jika tim Anda kurang memahami JavaScript modern, atau tidak cukup besar untuk membangun dua aplikasi. Ini bisa sangat menggoda jika Anda seorang pengembang plugin WordPress, karena Anda bisa menggunakan PHP untuk semua aspek plugin Anda.

Namun mungkin manfaat yang paling penting adalah Anda tidak lagi memerlukan API antara back-end dan front-end aplikasi Anda. Hal ini dapat menghemat banyak waktu pengembangan, serta mengurangi jumlah kode yang dapat menghasilkan bug, sehingga juga menghemat waktu dalam jangka panjang.

Namun, kita tidak boleh terlalu naif dengan berasumsi bahwa menggunakan HTML berarti tidak perlu menulis JavaScript apa pun . Sejumlah JavaScript mungkin masih diperlukan untuk hal-hal seperti drag-and-drop, bagan, pemilih warna dan tanggal, dan sebagainya. Meskipun kita selalu dapat menggunakan solusi framework-agnostic, seperti SortableJS dan Floating UI. Selain itu, kebutuhan akan JavaScript juga akan berkurang di masa mendatang karena standar web terus berkembang dengan elemen HTML baru, seperti elemen <dialog> terbaru.

Kedua, ironisnya PHP tidak terlalu bagus dalam membuat template HTML, meskipun PHP dibuat untuk melakukan hal itu. Sintaks tagnya terlalu bertele-tele, dan sintaksis string HEREDOC-nya memiliki dukungan terbatas untuk interpolasi string.

Terakhir, membuat endpoint di WordPress tidaklah mudah. Pertimbangkan plugin buku dari contoh sebelumnya. Kita perlu memiliki jalur di server yang merespons dengan daftar buku dalam bentuk HTML. Bagaimana cara kami mendaftarkan titik akhir ini?

• Deteksi parameter GET selama tindakan init atau admin_init ?
• Gunakan API Admin Ajax?
• Daftarkan titik akhir REST API?
• Tambahkan aturan penulisan ulang khusus?

Ada banyak pilihan, namun tidak ada yang membuatnya sesederhana yang seharusnya.

BENCI

Ada detail halus dalam contoh kita sebelumnya yang sangat mudah untuk dilewatkan, dan kemungkinan besar akan terdengar jelas setelah ditunjukkan.

Saat kami mendapatkan HTML dari server, tombol pada halaman tersebut adalah varian ON atau varian OFF. Bergantung pada mana yang ditampilkan di layar, tindakan klik akan berbeda.

Oleh karena itu, browser tidak perlu memahami aplikasi kita. Kami biasanya membuat browser memahami dengan memberikan kode JavaScript untuk memprogram secara eksplisit semua perilaku. Sekarang, kita hanya memiliki HTML, dan browser tidak memerlukan pengetahuan sebelumnya tentang bagaimana aplikasi kita berperilaku atau statusnya. Itu hanya perlu merender HTML di layar, yang dengan sendirinya mengkodekan status aplikasi kita.

Jenis arsitektur ini dikenal sebagai HATEOAS, yang merupakan singkatan dari 'Hypermedia As The Engine Of Application State'. Ini adalah jenis arsitektur REST khusus yang menggunakan hypermedia sebagai media untuk transfer status, dan hypermedia yang sama menjadi antarmuka yang melaluinya pengguna mengarahkan aplikasi ke status baru.

Situs web HTMX memiliki banyak koleksi artikel, esai, dan pembicaraan mengenai subjek ini, jika Anda tertarik untuk mempelajari lebih lanjut. Untuk keperluan artikel ini, mari kita beralih ke mengapa HTMX bisa menjadi masalah besar bagi pengembang WordPress.

HTML <3 WordPress

WordPress adalah server PHP raksasa dan monolitik. Plugin WordPress juga sebagian besar ditulis dalam PHP. Mereka dapat menambahkan fungsionalitas baru ke situs menggunakan API PHP yang disediakan oleh WordPress, seperti Hooks API dan Database API. API ini tidak tersedia dari JavaScript, jadi pengembang plugin sebaiknya menyimpan sebanyak mungkin kode plugin mereka di server. Jika pernah ada motivasi untuk menggunakan HTML, inilah saatnya!

Dalam banyak hal, HTML dibuat untuk WordPress. Atau lebih tepatnya, untuk aplikasi seperti WordPress; aplikasi yang lebih suka tidak dibebani dengan bahasa asing yang memaksa mereka meninggalkan koleksi API servernya. Terutama ketika mentransfer status menggunakan hypermedia saja sudah cukup.

Mempermudah pembuatan UI yang bagus untuk plugin WordPress dapat berdampak besar pada ekosistem plugin. Pengembang yang mengelola plugin gratis mungkin merasa lebih layak untuk membangun pengalaman pengguna yang lebih baik bagi penggunanya, dan tim yang lebih kecil mungkin dapat melakukan iterasi fitur lebih cepat dengan menghemat waktu. Hal ini dapat membantu membuat plugin yang lebih kecil menjadi lebih kompetitif di pasar yang sangat didominasi oleh tim besar dengan anggaran lebih besar.

Plugin yang lebih besar mungkin juga menarik. Aplikasi JavaScript dapat berkembang dengan sangat cepat. HTML dapat mengizinkan plugin ini untuk menghapus API JSON dan aplikasi JavaScript yang sangat besar, dan meninggalkan server HTML ramping di tempatnya yang memiliki akses penuh ke API WordPress.

Pikiran Terakhir

Saya sudah bermain-main dengan HTML untuk sementara waktu sekarang, menggunakannya dengan PHP dan Go. Ini menawarkan alternatif yang menarik untuk membangun antarmuka pengguna di web, dan argumen yang meyakinkan untuk menggunakan hypermedia untuk menggerakkan status aplikasi.

Jika Anda seorang pengembang plugin, pastikan untuk memeriksa HTML. Kami baru saja menyentuh permukaan artikel ini, dan dokumentasinya ditulis dengan sangat baik dengan banyak contoh. Ini juga sangat singkat, mengingat banyaknya HTMX yang disertakan. Anda akan dapat memulai dengan HTML dan PHP dalam beberapa menit.