DE{KODE}: Gutenberg dan WordPress Tanpa Kepala

Gutenberg, alias blok WordPress, memberi produsen konten cara baru yang ampuh untuk menata konten di situs WordPress tradisional. Tapi bagaimana pengembang WordPress tanpa kepala memberdayakan tim pemasaran dengan kemampuan yang sama? Dalam sesi DE{CODE} ini, pendiri GraphQL untuk WordPress (WPGraphQL), Jason Bahl, membagikan kemampuan baru dan praktik terbaik untuk menggunakan editor blok WordPress di situs headless.

Slide Sesi

Transkrip Teks Lengkap

JASON BAHL : Hai. Selamat datang di pembicaraan saya di Gutenberg dan Headless WordPress. Nama saya Jason Bahl. Saya adalah pencipta dan pengelola WPGraphQL. Saya seorang insinyur perangkat lunak utama di WP Engine. Anda dapat menemukan saya di Twitter @jasonbahl atau juga di Twitter @wpgraphql.

Jadi hari ini, saya ingin berbicara dengan Anda tentang apa itu Gutenberg, WordPress tanpa kepala, kapan dan mengapa Anda mungkin ingin menggunakan WordPress Tanpa Kepala, bagaimana Anda dapat menggunakan Gutenberg, khususnya, dengan WordPress Tanpa Kepala, dan kapan dan mengapa WordPress Tanpa Kepala dan Gutenberg bersama-sama mungkin masuk akal untuk proyek Anda.

Jadi WordPress secara historis memiliki editor yang terlihat sedikit seperti ini. Kami memiliki area teks TinyMCE, tempat kami dapat mengedit konten kami. Kami dapat memasukkan media dan kemudian menerbitkan konten kami dan kemudian pada tahun 2018 datanglah Gutenberg, editor berbasis blok ini, yang memungkinkan kami untuk memasukkan konten ke dalam kanvas kosong ini dan berinteraksi dengan konten kami di tingkat blok.

Jadi setiap paragraf memiliki pengaturan. Setiap gambar memiliki pengaturan. Setiap galeri, tajuk– apa pun yang dapat Anda pikirkan untuk konten adalah apa yang disebut blok. Dan kami dapat benar-benar terperinci dengan cara kami mengontrol konten kami sekarang dan kami dapat menarik dan melepasnya serta menyusun konten kami. Jadi ini pengalaman pengeditan yang sangat kaya di WordPress sekarang dan jadi ini adalah primer tentang apa itu Gutenberg.

Jadi apa itu WordPress Tanpa Kepala sekarang? Jadi untuk memahami Headless, mari kita lihat WordPress tradisional. Jadi WordPress tradisional, kami masuk ke WordPress, UI admin, dan kami menerbitkan konten kami dan kemudian pengguna mengunjungi situs kami, dan PHP, bahasa bawaan WordPress, merender halaman. Jadi itu memuat CSS, HTML, dan JavaScript dan mengirimkan halaman ke pengguna. Jadi itu semacam WordPress tradisional.

Dengan Headless WordPress, Anda masih menggunakan WordPress sebagai CMS. Anda masih menerbitkan konten, membuat konten, mengelola konten di WordPress, tetapi alih-alih mengirimkan halaman dalam HTML ke browser, WordPress mengirimkan data biasanya dalam format JSON, dan kemudian aplikasi klien dapat menggunakan data tersebut sehingga kami dapat memiliki aplikasi iOS atau Android asli atau bahkan aplikasi realitas virtual.

Kolega saya, Anthony, telah membagikan konten tentang bagaimana dia menggunakan WordPress untuk mendukung aplikasi realitas virtual. Atau saya bekerja di surat kabar tempat kami menggunakan WordPress sebagai titik masuk untuk surat kabar cetak kami. Jadi jika Anda membaca hard copy koran cetak, Anda sedang membaca konten yang diproduksi di WordPress.

Dan tentu saja, kita masih bisa menggunakan data itu untuk merender ke web juga, tetapi alih-alih dikunci ke template PHP, kita memiliki fleksibilitas untuk memilih teknologi front-end apa pun yang kita inginkan. Jadi Headless memisahkan bagian belakang, pengelolaan konten, dan cara kami menampilkan data yang dikelola di WordPress.

Jadi ada dua cara umum kita dapat menggunakan data ini. Kita bisa mendapatkan data dalam format JSON dari WP REST API, yang merupakan API bawaan untuk WordPress dan ada API lain yang disebut WPGraphQL. Ini adalah plugin sumber terbuka yang dapat Anda pasang dan dapatkan data dari WordPress dan JSON. Dan kita akan berbicara tentang WPGraphQL hari ini.

Jadi sekarang kita tahu apa itu WordPress, mengapa Anda pergi dan membangun proyek WordPress Tanpa Kepala? Seperti yang saya sebutkan, Anda memiliki banyak fleksibilitas dalam memilih teknologi front-end Anda. Dan bagi sebagian orang, itu adalah hal yang sangat penting untuk dapat memilih bagaimana mereka membangun proyek front-end. Ada beberapa framework seperti Next dan Gatsby dan Svelte yang benar-benar menargetkan peningkatan vital web inti. Jadi, Anda mungkin dapat menggunakan Headless dengan WordPress dan telah meningkatkan data vital web inti.

Anda bisa mendapatkan keuntungan dari hal-hal seperti pemecahan kode dalam kode Anda. Jadi Anda dapat membuat komponen untuk aplikasi front-end Anda. Dan berdasarkan komponen apa yang sedang dibangun untuk halaman tertentu akan mengirimkan lebih sedikit atau lebih sedikit aset ke klien dan mempercepat halaman Anda. Headless juga memberi pengembang kontrol yang lebih baik atas pengalaman pengguna front-end, sehingga plugin yang dipasang di admin WordPress, berdampak lebih kecil pada front-end

Jadi pengguna admin tidak bisa hanya menginstal plugin dan menambahkan skrip arbitrer atau markup arbitrer ke front-end situs Headless. Ini lebih merupakan pengembang yang menentukan batasan di front-end dan WordPress mendapatkan data yang dikirim dan kemudian salah satu hal yang ingin saya masukkan adalah pengalaman pengembang.

Dengan Headless WordPress, karena Anda memiliki fleksibilitas untuk menggunakan tumpukan teknologi apa pun yang Anda inginkan, ada keuntungan dari pengalaman pengembang yang lebih baik dalam beberapa kasus. Dan salah satu kasus yang akan saya bahas adalah pengembangan berbasis komponen dan kita akan membicarakan banyak hal sebentar lagi.

Nah itulah beberapa alasannya. Jadi situasi apa yang mungkin Anda alami saat ingin menggunakan Headless WordPress? Nah, jika Anda perlu membuat aplikasi non-web seperti ponsel asli, Anda mungkin ingin menggunakan Headless. Sekali lagi, jika web vital inti Anda buruk di situs WordPress Anda, situs WordPress Anda saat ini, atau baik-baik saja, tetapi menjadi sangat mahal untuk membuatnya tetap bagus, Anda mungkin ingin mempertimbangkan Headless.

Jika Anda memiliki beberapa aplikasi di organisasi Anda yang perlu mengeluarkan data dari WordPress, Anda mungkin perlu menggunakan Headless juga. Dan jika Anda sudah berinvestasi dalam pustaka komponen, atau sistem desain berbasis komponen untuk organisasi Anda dan Anda memerlukan data dari WordPress, Anda mungkin ingin berinvestasi untuk menggunakan Headless. Jika tim lebih suka JavaScript dan tidak suka membuat sesuatu di PHP, itu juga alasan untuk mempertimbangkan Headless.

Namun, beberapa alasan Anda mungkin tidak ingin menggunakan Headless– saat ini, memang membutuhkan waktu pengembangan yang sedikit lebih lama. Jadi jika Anda memiliki anggaran yang lebih rendah atau mengurangi waktu dan Anda sudah memiliki solusi di WordPress tradisional, Anda mungkin belum menggunakan Headless. Jika admin situs Anda benar-benar membutuhkan kendali untuk menginstal plugin yang memodifikasi front-end, Anda mungkin belum menggunakan Headless.

Jika tim Anda benar-benar lebih menyukai PHP dan tidak ingin mempelajari JavaScript atau front-end alternatif, Anda mungkin tetap menggunakan WordPress tradisional juga. Dan jika Anda tidak berinvestasi dalam pengembangan berbasis komponen atau pustaka berbasis komponen, jika Anda tidak tertarik dengan itu, Anda mungkin tetap menggunakan alur kerja pengembangan WordPress tradisional.

Dan jika web vital inti Anda di WordPress tradisional benar-benar bagus, dan biaya perawatan Anda sangat rendah untuk membuat situs web Anda berjalan sangat cepat, Anda mungkin boleh tetap menggunakan WordPress tradisional. Jadi Anda tidak harus pergi tanpa kepala. Tapi saya akan menunjukkan kepada Anda mengapa menurut saya pergi Tanpa Kepala bisa bagus untuk beberapa tim.

Jadi jika kita melihat lagi pengalaman pengembang WordPress, kita menerbitkan konten kita dalam satu bidang yang menghasilkan potongan besar HTML. Dan bahkan jika kita menggunakan editor Gutenberg, yang memiliki blok terperinci ini, hasil akhirnya adalah satu bagian besar dari HTML. Jadi apakah kami menerbitkan di Gutenberg atau editor klasik tradisional, potongan HTML ini dikirim melalui PHP ke tema kami dan kami memiliki satu halaman global yang memuat HTML, CSS, dan JavaScript kami. Dan aset ini diterapkan ke halaman secara global.

Jadi pengembang WordPress biasanya akan memisahkan pengembangan kami berdasarkan jenis file, jadi kami akan menempatkan CSS kami di file terpisah yang diterapkan secara global ke halaman, atau HTML akan ditulis dalam PHP, dan menarik data yang kami butuhkan dari WordPress lalu JavaScript akan melakukannya sering ditulis dengan jQuery di file terpisah. Jadi ketiga hal ini akan bersatu untuk membangun halaman.

Masalahnya adalah ini tidak terisolasi, mereka diterapkan ke seluruh halaman. Jadi terkadang Anda bisa membuat perubahan. Seperti ini yang terjadi pada saya. Suatu kali saya mengubah gaya di footer situs seperti yang diminta oleh manajer saya dan tiga hari kemudian, dilaporkan bahwa gaya di tempat lain di situs telah berubah karena peninjauan kode sandi tersebut. Kami melewatinya.

Tiba-tiba, sesuatu yang lain di situs rusak dan ini karena CSS diterapkan secara global dan mungkin memengaruhi hal-hal yang tidak Anda sadari. Namun, ada tren baru, di masa lalu– entahlah– tujuh, delapan tahun mungkin disebut arsitektur berbasis komponen. Hal ini memungkinkan kita membangun bagian tertentu dari aplikasi kita dalam apa yang disebut komponen.

Dan kita dapat menggabungkan JavaScript kita, HTML kita, CSS kita dalam potongan-potongan kecil yang dapat kita uji secara terpisah sehingga kita dapat membuat bagian dari aplikasi kita. Beberapa masalah, markup, JavaScripts, gaya, dan kami dapat menyusun komponen ini bersama-sama untuk membangun aplikasi yang lebih kompleks.

Jadi pengembangan berbasis komponen memungkinkan kita memecah fitur kompleks menjadi bagian-bagian kecil yang terisolasi dan kita dapat mengujinya secara terpisah, memastikannya berfungsi dan kemudian kita dapat memasangkan masalah kita yang harus digabungkan. Setiap irisan UI memiliki tanggung jawab khusus. Jika itu adalah kartu gambar, itu mungkin bertanggung jawab untuk merender gambar pada ukuran tertentu dengan URL tertentu.

Jadi itu memiliki ketergantungan markup. Ini memiliki ketergantungan gaya. Itu mungkin memiliki interaksi stateful. Ini semua berkaitan dengan komponen spesifik itu. Jadi kita dapat memasangkan markup kita, JavaScript kita, dan CSS kita di satu tempat, mengujinya, dan memastikannya bekerja dengan baik. Dan karena ini, kami kemudian dapat menggunakan kembali komponen ini di seluruh aplikasi kami, atau kami bahkan dapat menggunakan kembali komponen kami di seluruh proyek.

Jadi ada tren yang disebut pustaka komponen. Ada proyek seperti Material UI, atau komponen desain akhir, atau Chakra UI yang juga populer. Dan kita dapat menggunakan komponen ini di seluruh proyek. Dan kami dapat menyelesaikan masalah utama seperti markup yang dapat diakses. Dan kami dapat membuat pembaruan untuk itu dan menerapkannya di beberapa proyek di organisasi kami sekaligus dan karena ini– karena alasan ini, kami dapat mengulang dan mengirim lebih cepat dengan lebih percaya diri.

Jadi bagaimana kita bisa menggunakan Headless WordPress? Seperti yang saya sebutkan sebelumnya, ada dua cara untuk mengeluarkan data dari WordPress dan menjadi komponen. Salah satunya adalah REST API. Salah satunya adalah WPGraphQL. Teman saya, Drake, telah membangun situs Headless selama beberapa waktu, jadi saya bertanya kepadanya dan inilah yang dia katakan…

Dia lebih suka WPGraphQL. Jadi itulah yang akan kita bicarakan hari ini. Jadi apa itu WPGraphQL? Anda mungkin bertanya. Ya, ini adalah plugin WordPress sumber terbuka gratis yang menyediakan skema dan API GraphQL yang dapat diperpanjang untuk situs WordPress mana pun. Lalu apa itu GraphQL? Ya, ini adalah bahasa kueri grafik.

Baiklah, Jason. Aku masih tidak mengerti apa yang kamu katakan. Baiklah, jadi izinkan saya menunjukkannya kepada Anda. Jadi GraphQL, cara kerjanya adalah aplikasi klien mengirim permintaan yang menentukan apa yang mereka inginkan dari server. Dan permintaan terlihat seperti ini. Sepertinya kunci JSON tanpa nilai. Jadi dalam hal ini, permintaan meminta penampil dan penampil, kami ingin bidang "nama" dikembalikan.

Dan respons dari server GraphQL mungkin terlihat seperti ini. Data, kunci, dan nilai JSON aktualnya dan cocok dengan bentuk permintaan. Jadi dalam hal ini, kita mendapatkan namanya, atau kita mendapatkan penampil dengan nama Jason Bahl. Jadi GraphQL mari aplikasi klien mencabut pohon dari grafik data aplikasi.

Dan apa yang terlihat secara visual adalah seperti ini. Kita dapat memasukkan grafik, katakanlah, tambahkan penampil atau bidang pengguna atau simpul. Dan simpul itu mungkin memiliki properti seperti nama Jason. Dan simpul itu mungkin memiliki koneksi ke simpul lain dalam grafik seperti avatar, yang mungkin memiliki properti seperti URL gambar.

Dan pengguna itu mungkin memiliki koneksi ke node lain seperti pos yang telah ditulis pengguna itu. Dan postingan tersebut mungkin memiliki properti sendiri seperti judul, halo dunia, atau selamat tinggal Mars. Dan postingan ini mungkin memiliki koneksi ke node lain dalam grafik, seperti kategori dengan judulnya sendiri seperti berita atau olahraga. Dan kategori tersebut mungkin memiliki koneksi ke node lain juga seperti lebih banyak posting. Dan postingan itu mungkin menampilkan gambar dan sebagainya. Jadi kami memiliki grafik data yang besar ini yang dapat kami minta dengan GraphQL.

Jadi kita bisa menggunakan tooling di admin GraphQL atau di admin WordPress. Ada alat yang disebut GraphiQL, tempat saya dapat membuat kueri. Dan di sini saya memilih bidang Penampil dengan subpilihan, nama, avatar, URL dan ketika kami menjalankannya, kami mendapatkan bidang yang kami minta dan secara visual kueri itu terlihat seperti ini.

Kami memasukkan grafik dan kami meminta satu pengguna. Kami menanyakan nama pengguna, avatar yang terhubung di URL avatar. Kami memiliki semua grafik data ini yang tersedia untuk kami, tetapi kami hanya meminta kumpulan data tertentu dan sebagai tanggapan, kami mendapatkan kumpulan khusus itu kembali. Dan kemudian kita dapat mengambil– kita sekarang dapat menggunakan komponen.

Jadi saya berbicara tentang manfaat pengembangan berbasis komponen, dan saya ingin menunjukkannya kepada Anda dalam tindakan. Dan inilah yang saya sebut komponen presentasi. Jadi ini adalah komponen kartu yang bertanggung jawab. Ini memiliki satu tanggung jawab untuk merender kartu ini dengan gambar dan judul.

Dan kita dapat melihat kodenya dan kita melihat kita memiliki beberapa kontrol gaya. Kita bisa mengatur lebarnya, kita bisa memberikannya gambar yang kita inginkan dan kita bisa memberikannya judul. Jadi kami dapat menggunakan kembali komponen ini di seluruh proyek kami. Dan komponen ini memiliki semua dependensi yang kita butuhkan. Ini memiliki HTML untuk dirender. Ini memiliki gaya. Kami memiliki beberapa kontrol gaya di sini. Ini memiliki beberapa komponen stateful seperti status hover dan yang lainnya.

Jadi ini adalah komponen terisolasi yang dapat kita gunakan kembali dan dengan GraphQL sekarang, kita dapat mengambil kueri yang baru saja kita susun di admin WordPress menggunakan GraphQL dan kita dapat memasukkannya dan memiliki komponen kartu penampil sekarang. Jadi kita bisa menulis kueri kita, memasangkannya dengan komponen kartu kita dan sekarang sudah melengkapi komponennya.

Kami memiliki HTML kami, CSS JavaScript kami. Dan karena datanya, kami sekarang memiliki sesuatu untuk dirender dengan data yang kami minta. Jadi sekarang kita bisa menggunakan ini di seluruh aplikasi kita dan ada fitur GraphQL yang disebut fragmen dan ini memungkinkan kita untuk mengambil kueri GraphQL kita dan memecahnya menjadi bagian yang dapat digunakan kembali.

Jadi dalam hal ini, saya membuat fragmen kartu profil pengguna, dan saya menentukan nama, avatar, dan URL, lalu saya menggunakan fragmen itu dalam kueri yang lebih besar. Saat kami mengeksekusi, kami mendapatkan hasil yang kami harapkan. Kita sekarang dapat mengambil fragmen itu, memasukkannya ke dalam sebuah komponen. Sekarang kami memiliki komponen berbeda yang disebut Kartu Profil Pengguna.

Kartu profil pengguna ini menetapkan bahwa setiap kali kami meminta pengguna, kami harus mendapatkan nama, avatar, dan URL avatar untuk digunakan dalam komponen. Jadi sekarang kami memiliki komponen yang dapat digunakan kembali ini di mana pun dalam aplikasi kami, kami meminta pengguna, kami bisa mendapatkan data yang diperlukan untuk merender kartu yang dapat digunakan kembali ini dengan avatar dan nama pengguna.

Jadi ini sekarang dapat dibawa masuk dan digunakan di sebagian besar aplikasi kita. Jadi, inilah kueri yang kami miliki sebelum kueri penampil menggunakan fragmen yang kami impor dari komponen kartu profil pengguna yang dapat digunakan kembali. Dan kemudian kami mengeluarkannya ke komponen kartu penampil dan sekarang kami dapat menggunakannya kembali di seluruh aplikasi kami.

Kami dapat membuat bagian yang lebih besar dari aplikasi kami yang mengandalkan kartu pengguna ini atau kartu penulis. Jadi kita sekarang dapat memiliki banyak komponen seperti komponen judul blog yang bertanggung jawab atas judul. Kami dapat memiliki kartu profil pengguna yang baru saja kami buat yang merender profil pengguna. Kita dapat memiliki komponen konten atau kutipan yang bertanggung jawab atas markup dan data untuk bagian aplikasi kita ini.

Dan ya, kita dapat membangun komponen kecil yang bertanggung jawab atas markup, CSS, dan data yang dibutuhkan untuk membangun aplikasi ini. Dan kita bisa menyusunnya bersama. Kami dapat mengujinya secara terpisah, juga mengujinya sebagai unit yang lebih besar. Jadi kita bisa menggunakan ini di berbagai template juga.

Kita dapat menggunakan komponen yang dapat digunakan kembali ini untuk posting blog atau peran blog kita di mana kita memiliki penulis yang berbeda, tetapi kita dapat menggunakan komponen yang sama untuk merendernya. Kita dapat menggunakannya untuk– halaman arsip lainnya. Sangat mirip dengan komponen template WordPress, kita dapat memecah aplikasi Headless kita menjadi potongan-potongan kecil tetapi kita mendapatkan keuntungan dari menggabungkan teknologi kita bersama.

Nah itulah sedikit tentang Headless WordPress developer yang mengalami desain berbasis komponen dan manfaatnya. Jadi sekarang ketika berbicara tentang Gutenberg, khususnya, mengapa Anda mempertimbangkan WordPress Tanpa Kepala dengan Gutenberg secara khusus? Nah, jika tim Anda sudah menggunakan Headless WordPress, mungkin dengan Advanced Custom Fields dan flexfields, dan Anda ingin memperbarui pengalaman editor untuk menggunakan Gutenberg, itu jelas salah satu alasan Anda memilih Headless dengan Gutenberg.

Jika Anda ingin mendapatkan keuntungan dari membuat komponen yang digunakan di admin dan komponen yang digunakan di front-end, ada baiknya mempertimbangkan untuk menggunakan Headless dengan Gutenberg karena editor back end Gutenberg dari editor blok semuanya berbasis komponen. Anda mungkin ingin memanfaatkan input terstruktur. setiap blok di admin memiliki bidang yang terstruktur.

Anda memiliki atribut khusus yang dapat Anda kontrol di tingkat lapangan. Dan Anda mungkin ingin mendapatkan keuntungan dengan memiliki output terstruktur yang masuk ke komponen Anda juga. Dan seperti yang saya sebutkan, Anda mungkin ingin menggunakan kembali komponen dan blok di seluruh proyek. Misalnya, Anda mungkin ingin memiliki pustaka blok yang dibuat oleh agensi Anda yang menyelesaikan hal-hal seperti aksesibilitas dan masalah markup khusus yang ingin Anda gunakan di seluruh proyek. Dan kemudian Anda dapat memperbaruinya di seluruh proyek Anda, tidak hanya dalam satu proyek individu.

Jadi ini adalah bagian di mana seperti tema anak di WordPress bisa sulit untuk diukur karena Anda harus pergi ke setiap situs dan memperbarui markup dan yang lainnya di setiap situs. Nah, di sini, Anda dapat menggunakan pustaka blok sebagai dependensi NPM dan memperbaruinya di seluruh organisasi Anda.

Jadi saat ini, status pengembangan WordPress dengan Gutenberg adalah kami memiliki blok di backend, yang berbasis komponen. Kita dapat membangun blok kustom kita sendiri atau menggunakan blok inti WordPress. Tetapi output dalam PHP adalah, seperti yang saya sebutkan, satu bagian besar dari HTML dan jadi bagaimana kita dapat beralih dari mendapatkan satu blok HTML ini ke memiliki komponen di backend yang juga ditransfer ke komponen di front-end kita?

Jadi kita akan melihat beberapa opsi untuk mengeluarkan data Gutenberg dari WordPress dan menjadi komponen. Jadi salah satu opsinya adalah mendapatkan konten sebagai HTML. Jadi kita dapat menanyakan konten WordPress kita sebagai HTML dan kemudian mem-parsing HTML itu ke komponen. Atau kita dapat meminta blok sebagai tipe GraphQL. Jadi kita bisa– itu memungkinkan kita untuk menanyakan daftar blok, setiap blok akan menjadi tipe GraphQL yang bisa kita petakan ke komponen.

Jadi isinya adalah HTML. Ini adalah sesuatu yang dapat kami lakukan di inti WPGraphQL hari ini. Jika Anda ingin membuat kueri blok sebagai tipe GraphQL individual, ada dua opsi saat ini. Kami memiliki GraphQL untuk ekstensi Gutenberg, yang merupakan ekstensi komunitas dan kemudian kami memiliki Editor Blok WPGraphQL, yang merupakan plugin beta yang saya kerjakan secara pribadi.

Jadi mari kita lihat opsi ini. Dalam inti WPGraphQL, kami dapat meminta konten sebagai HTML dan mengurai ke komponen. Apa yang terlihat adalah kami meminta sesuatu seperti posting, dan kami dapat meminta bidang seperti ID dan judul atau konten. Dan konten akan mengembalikan satu string besar, satu potongan besar HTML dan kemudian kita dapat mengurai HTML itu dan memetakan node DOM yang berbeda ke komponen yang berbeda.

Seperti dalam kasus ini di wpgraphql.com, tautan di sebelah kiri adalah kode di mana ini sebenarnya terjadi. Saya mengambil markup yang dikembalikan dari WPGraphQL, dan saya menguraikannya, mencari node HTML tertentu dan mengubahnya menjadi komponen React. Jadi saya dapat memiliki hal-hal interaktif seperti blok kode ini, yang melakukan penyorotan sintaks dan memungkinkan pengguna mengklik Salin dan kemudian saya juga dapat mengurai dan membuat daftar isi, misalnya. Jadi itu salah satu pendekatan. Dan saya menggunakannya di wpgraphql.com dalam produksi hari ini.

Beberapa hal yang mungkin ingin Anda pertimbangkan jika Anda mengikuti rute ini, muatan HTML tidak dapat diprediksi. Perubahan di server seperti memasang perpustakaan blok baru atau berbagai HTML yang dapat dimasukkan editor ke dalam konten, tidak dapat diprediksi. Jadi bisa sangat sulit untuk diurai. Anda tidak dapat menginterogasi perubahan. Sebagai pengembang klien, Anda tidak dapat melihat apa yang berubah, jadi pertimbangkan saja.

Saya akan mengatakan bahwa pendekatan ini bekerja paling baik untuk tim yang memiliki kontrol yang sangat ketat atas admin WordPress dan front-end. Jadi jika Anda adalah satu orang atau tim kecil yang mengerjakan backend dan front-end WordPress, ini mungkin bekerja dengan baik untuk Anda karena Anda dapat mengontrol input dan output sedikit lebih baik.

Salah satu opsi lainnya, WPGraphQL untuk Gutenberg, ini adalah plugin yang dikelola komunitas. Dan ini akan memungkinkan Anda untuk meminta blok konten, setiap blok sebagai tipe GraphQL mereka sendiri. Cara kerjanya adalah halaman pengaturan, Anda harus memasukkan hanya blok sebagai skema, jadi ini membuka Gutenberg dalam iframe yang tidak terlihat, mendapatkan registri blok dari klien JavaScript dan mengirimkannya ke server.

Dan kemudian kita dapat menggunakan GraphQL untuk menanyakan blok kita sebagai tipe tertentu, dan kita dapat menggunakan fragmen seperti yang saya tunjukkan sebelumnya dan kita dapat menggunakan fragmen ini untuk memetakan ke komponen di front-end kita. Jadi ini adalah salah satu pilihan. Beberapa pertimbangan dengan plugin ini, perubahan pada registri blok dapat diintrospeksi jadi itu hal yang baik.

Tim yang mengerjakan aplikasi front-end dapat menggunakan introspeksi GraphQL untuk melihat bagaimana skema berubah dari waktu ke waktu dan mereka dapat mengetahui jika ada perubahan yang merusak atau bidang baru yang dapat mereka konsumsi. Saya akan mengatakan pendekatan ini bekerja sedikit lebih baik untuk proyek multi-orang atau banyak tim. Jika Anda memiliki satu tim yang bekerja di admin WordPress dan tim lain yang bekerja di front-end, pendekatan ini mungkin bekerja lebih baik. Mereka dapat menggunakan skema GraphQL sebagai kontrak antara blok yang digunakan di kedua sisi.

Satu hal yang sedikit menarik adalah memuat blok di iframe seperti yang saya sebutkan. Dan karena itu, tidak selalu skala untuk setiap situasi. Jadi jika Anda mendaftarkan blok ke halaman tertentu atau templat tertentu atau jenis posting tertentu, metode mendapatkan peta registri blok ke skema ini mungkin kehilangan beberapa blok. Jadi itu mungkin tidak berskala untuk setiap proyek.

Jadi proyek selanjutnya, WPGraphQL Block Editor, ini adalah plugin beta yang sedang saya kerjakan saat ini. Dan ini juga memungkinkan Anda untuk meminta blok konten sebagai tipe GraphQL mereka sendiri dan sangat mirip dengan WPGraphQL untuk Gutenberg, kami dapat menulis fragmen yang mengembalikan data yang kami tentukan. Dan kemudian kita dapat menggunakan fragmen tersebut dengan komponen kita di front-end.

Beberapa pertimbangan dengan ini, ini adalah plugin beta, jadi begitulah. Anda mendapat manfaat dari input terstruktur dan output terstruktur. Jadi sebagai pengembang front-end, itu pasti kemenangan. Itu bekerja dengan blok yang terdaftar dengan file block.json. Jadi blok inti WordPress Gutenberg memiliki file ini dan ini akan bekerja dengan pendekatan itu. Banyak pihak ketiga tidak mendaftarkan blok mereka dengan cara ini, jadi Anda harus memetakan blok tersebut secara manual.

Blok tidak diperlakukan sebagai node individu. Saya ingin memperlakukan blok sebagai node individual, tetapi tidak ada ID global, jadi Anda harus mengakses blok tersebut sebagai bagian dari objek yang lebih besar seperti halaman poster.

Jadi saya harap Anda mempelajari sesuatu tentang Headless WordPress, manfaat Headless WordPress, dan menggunakan Headless WordPress dengan Gutenberg. Saya mengundang Anda untuk mencoba WPGraphQL hari ini. Anda dapat mendaftar akun Atlas Sandbox gratis di wpengine.com/atlas. Dan terima kasih telah bergabung dengan presentasi saya. Sekali lagi, Anda dapat menemukan saya di Twitter, jasonbahl, atau juga di Twitter @wpgraphql. Terima kasih.