DE{CODE}: Gutenberg และ WordPress หัวขาด

Gutenberg หรือบล็อก WordPress ช่วยให้ผู้ผลิตเนื้อหามีวิธีใหม่ๆ ในการจัดวางเนื้อหาในไซต์ WordPress แบบดั้งเดิม แต่นักพัฒนา WordPress หัวขาดจะช่วยให้ทีมการตลาดมีความสามารถเดียวกันได้อย่างไร ในเซสชัน DE{CODE} นี้ Jason Bahl ผู้ก่อตั้ง GraphQL สำหรับ WordPress (WPGraphQL) ได้แชร์ความสามารถใหม่ๆ และแนวทางปฏิบัติที่ดีที่สุดในการใช้ตัวแก้ไขบล็อก WordPress บนไซต์ที่ไม่มีส่วนหัว

สไลด์เซสชัน

การถอดเสียงแบบเต็ม

เจสัน บาห์ล : สวัสดี ยินดีต้อนรับสู่การพูดคุยของฉันเกี่ยวกับ Gutenberg และ Headless WordPress ฉันชื่อเจสัน บาห์ล ฉันเป็นผู้สร้างและดูแล WPGraphQL ฉันเป็นวิศวกรซอฟต์แวร์หลักที่ WP Engine คุณสามารถหาฉันได้ที่ Twitter @jasonbahl หรือที่ Twitter @wpgraphql

วันนี้ฉันอยากจะคุยกับคุณเกี่ยวกับสิ่งที่ Gutenberg คืออะไร WordPress แบบไม่มีหัวคืออะไร เมื่อใดและทำไมคุณจึงควรใช้ WordPress แบบไม่มีหัว วิธีที่คุณจะใช้ Gutenberg โดยเฉพาะกับ WordPress แบบไม่มีหัว และเมื่อใดและทำไม WordPress แบบไม่มีหัว และ Gutenberg ร่วมกันอาจเหมาะสมสำหรับโครงการของคุณ

ดังนั้นในอดีต WordPress จึงมีตัวแก้ไขที่มีลักษณะเช่นนี้ เรามีพื้นที่ข้อความ TinyMCE ซึ่งเราสามารถแก้ไขเนื้อหาของเราได้ เราสามารถแทรกสื่อและเผยแพร่เนื้อหาของเราได้ จากนั้นในปี 2018 Gutenberg ก็เปิดตัวเครื่องมือแก้ไขแบบบล็อกนี้ ซึ่งช่วยให้เราสามารถแทรกเนื้อหาลงในผืนผ้าใบเปล่านี้และโต้ตอบกับเนื้อหาของเราในระดับบล็อกได้

ดังนั้นแต่ละย่อหน้าจึงมีการตั้งค่า แต่ละภาพมีการตั้งค่า แต่ละแกลเลอรี หัวข้อ– สิ่งใดก็ตามที่คุณนึกถึงสำหรับเนื้อหาคือสิ่งที่เรียกว่าบล็อก และเราสามารถเข้าใจวิธีการควบคุมเนื้อหาของเราได้อย่างละเอียดยิ่งขึ้น และเราสามารถลากและวางและเขียนเนื้อหาของเราได้ ดังนั้นจึงเป็นประสบการณ์การแก้ไขที่สมบูรณ์มากใน WordPress ในขณะนี้ ดังนั้นจึงเป็นข้อมูลเบื้องต้นเกี่ยวกับสิ่งที่ Gutenberg คืออะไร

แล้ว Headless WordPress ตอนนี้คืออะไร? ดังนั้นเพื่อทำความเข้าใจกับ Headless เรามาดู WordPress แบบดั้งเดิมกัน ดังนั้น WordPress แบบดั้งเดิม เราจึงลงชื่อเข้าใช้ WordPress, UI ของผู้ดูแลระบบ และเราเผยแพร่เนื้อหาของเรา จากนั้นผู้ใช้จะเยี่ยมชมไซต์ของเรา และ PHP ซึ่งเป็นภาษาที่ WordPress มีให้ในตัว แสดงผลหน้าเว็บ ดังนั้นจึงโหลด CSS, HTML และ JavaScript และส่งหน้าไปยังผู้ใช้ นั่นคือ WordPress แบบดั้งเดิม

ด้วย Headless WordPress คุณยังคงใช้ WordPress เป็น CMS คุณยังคงเผยแพร่เนื้อหา จัดการเนื้อหา จัดการเนื้อหาใน WordPress แต่แทนที่จะส่งหน้าใน HTML ไปยังเบราว์เซอร์ WordPress จะส่งข้อมูลโดยทั่วไปในรูปแบบ JSON จากนั้นแอปพลิเคชันไคลเอ็นต์สามารถใช้ข้อมูลนั้น ดังนั้นเราจึงมีแอปพลิเคชัน iOS หรือ Android ดั้งเดิมได้ หรือแม้แต่แอพพลิเคชั่นเสมือนจริง

Anthony เพื่อนร่วมงานของฉันได้แบ่งปันเนื้อหาเกี่ยวกับวิธีที่เขาใช้ WordPress เพื่อขับเคลื่อนแอปพลิเคชันความจริงเสมือน หรือฉันทำงานในหนังสือพิมพ์ที่เราใช้ WordPress เป็นจุดเริ่มต้นสำหรับหนังสือพิมพ์ฉบับพิมพ์ของเรา ดังนั้นหากคุณกำลังอ่านหนังสือพิมพ์ฉบับพิมพ์ คุณกำลังอ่านเนื้อหาที่ผลิตใน WordPress

และแน่นอน เรายังสามารถใช้ข้อมูลนั้นเพื่อเรนเดอร์ไปยังเว็บได้เช่นกัน แต่แทนที่จะถูกจำกัดไว้ที่เทมเพลต PHP เรามีความยืดหยุ่นในการเลือกเทคโนโลยีส่วนหน้าที่เราต้องการ ดังนั้น Headless จึงแยกส่วนแบ็คเอนด์ การจัดการเนื้อหา และวิธีที่เรานำเสนอข้อมูลที่จัดการใน WordPress

ดังนั้น มีสองวิธีทั่วไปที่เราสามารถใช้ข้อมูลนี้ได้ เราสามารถรับข้อมูลในรูปแบบ JSON ได้จาก WP REST API ซึ่งเป็น API ในตัวสำหรับ WordPress และมี API อื่นที่เรียกว่า WPGraphQL นี่คือปลั๊กอินโอเพ่นซอร์สที่คุณสามารถติดตั้งและรับข้อมูลจาก WordPress และ JSON และเราจะพูดถึง WPGraphQL ในวันนี้

ตอนนี้เรารู้แล้วว่า WordPress คืออะไร ทำไมคุณถึงไปสร้างโครงการ Headless WordPress อย่างที่ฉันได้กล่าวไปแล้ว คุณมีความยืดหยุ่นอย่างมากในการเลือกเทคโนโลยีส่วนหน้าของคุณ และสำหรับบางคน นั่นเป็นสิ่งสำคัญมากในการเลือกวิธีสร้างโปรเจ็กต์ส่วนหน้า มีเฟรมเวิร์กบางอย่างเช่น Next และ Gatsby และ Svelte ที่กำหนดเป้าหมายไปยัง Vitals หลักของเว็บที่ได้รับการปรับปรุง ดังนั้นคุณอาจสามารถใช้งาน WordPress ได้โดยไม่หัวเสียและปรับปรุง core web Vitals

คุณสามารถได้รับประโยชน์จากสิ่งต่างๆ เช่น การแยกรหัสในรหัสของคุณ คุณจึงสามารถสร้างส่วนประกอบสำหรับแอปพลิเคชันส่วนหน้าของคุณได้ และขึ้นอยู่กับองค์ประกอบที่ถูกสร้างขึ้นสำหรับหน้าใดหน้าหนึ่ง จะส่งเนื้อหาที่น้อยลงหรือน้อยลงไปยังไคลเอนต์ และทำให้หน้าของคุณเร็วขึ้น Headless ยังช่วยให้นักพัฒนาสามารถควบคุมประสบการณ์ผู้ใช้ส่วนหน้าได้ดียิ่งขึ้น ดังนั้นปลั๊กอินที่ติดตั้งใน WordPress admin จึงมีผลกระทบต่อส่วนหน้าน้อยกว่า

ดังนั้นผู้ดูแลระบบจึงไม่สามารถเพียงแค่ติดตั้งปลั๊กอินและเพิ่มสคริปต์ตามอำเภอใจหรือมาร์กอัปตามอำเภอใจในส่วนหน้าของไซต์ Headless นักพัฒนาซอฟต์แวร์เป็นผู้กำหนดข้อจำกัดในส่วนหน้าและ WordPress รับข้อมูลที่ส่งมา จากนั้นสิ่งหนึ่งที่ฉันต้องการจะกล่าวถึงก็คือประสบการณ์ของนักพัฒนา

ด้วย Headless WordPress เนื่องจากคุณมีความยืดหยุ่นในการใช้สแต็กเทคโนโลยีใดก็ได้ที่คุณต้องการ จึงมีประโยชน์จากประสบการณ์ของนักพัฒนาที่ดีขึ้นในบางกรณี และหนึ่งในกรณีเหล่านั้นที่ฉันจะกล่าวถึงเรียกว่าการพัฒนาตามส่วนประกอบ และเราจะพูดถึงเรื่องนี้อีกมากในอีกไม่ช้า

นั่นเป็นเหตุผลบางประการ คุณอยู่ในสถานการณ์ใดเมื่อต้องการใช้ Headless WordPress? ถ้าคุณต้องการสร้างแอปพลิเคชันที่ไม่ใช่เว็บ เช่น เนทีฟมือถือ คุณอาจต้องการไปที่ Headless ย้ำอีกครั้งว่า หาก core web Vitals ของคุณไม่ดีบนไซต์ WordPress หรือไซต์ WordPress ปัจจุบันของคุณ หรือใช้งานได้ดี แต่การรักษาให้ใช้งานได้ดีนั้นมีค่าใช้จ่ายสูงมาก คุณอาจต้องพิจารณาใช้ Headless

หากคุณมีแอปพลิเคชันหลายตัวในองค์กรของคุณที่ต้องการดึงข้อมูลออกจาก WordPress คุณอาจต้องใช้ Headless เช่นกัน และหากคุณลงทุนในไลบรารีคอมโพเนนต์หรือระบบการออกแบบที่ใช้คอมโพเนนต์สำหรับองค์กรของคุณอยู่แล้ว และคุณต้องการข้อมูลจาก WordPress คุณอาจต้องการลงทุนเพื่อใช้งาน Headless หากทีมชอบใช้ JavaScript และไม่ชอบสร้างสิ่งต่างๆ ใน ​​PHP นั่นเป็นเหตุผลที่ควรพิจารณา Headless

เหตุผลบางประการที่คุณอาจไม่ต้องการเล่น Headless – ขณะนี้ต้องใช้เวลาในการพัฒนาเพิ่มขึ้นเล็กน้อย ดังนั้น หากคุณมีงบประมาณที่ต่ำกว่าหรือปรับขนาดเวลาย้อนหลัง และคุณมีโซลูชันใน WordPress แบบดั้งเดิมอยู่แล้ว คุณอาจยังไม่ได้ใช้ Headless หากผู้ดูแลไซต์ของคุณต้องการการควบคุมการติดตั้งปลั๊กอินที่ปรับเปลี่ยนส่วนหน้าจริงๆ คุณอาจยังไม่ได้ใช้ Headless

หากทีมของคุณชอบ PHP จริง ๆ และไม่ต้องการเรียนรู้ JavaScript หรือฟรอนต์เอนด์อื่น ๆ คุณอาจใช้ WordPress แบบดั้งเดิมเช่นกัน และหากคุณไม่ได้ลงทุนในการพัฒนาโดยใช้คอมโพเนนต์หรือไลบรารีที่ใช้คอมโพเนนต์ หากคุณไม่สนใจสิ่งนั้น คุณอาจยึดติดกับเวิร์กโฟลว์การพัฒนา WordPress แบบดั้งเดิม

และถ้าเว็บหลักของคุณบน WordPress แบบเดิมนั้นดีจริง ๆ และค่าบำรุงรักษาของคุณก็ต่ำมากเพื่อให้เว็บไซต์ของคุณทำงานได้เร็วมาก คุณอาจจะโอเคถ้าจะใช้ WordPress แบบเดิม ดังนั้นคุณไม่จำเป็นต้องไปหัวขาด แต่ฉันจะแสดงให้คุณเห็นว่าทำไมฉันถึงคิดว่า Headless อาจดีสำหรับบางทีม

ดังนั้นหากเราดูประสบการณ์ของนักพัฒนา WordPress อีกครั้ง เราจะเผยแพร่เนื้อหาของเราในฟิลด์เดียวที่สร้าง HTML จำนวนมาก และแม้ว่าเราจะใช้โปรแกรมแก้ไข Gutenberg ซึ่งมีบล็อกย่อยเหล่านี้ ผลลัพธ์สุดท้ายก็คือ HTML ก้อนใหญ่ก้อนหนึ่ง ดังนั้นไม่ว่าเราจะเผยแพร่ใน Gutenberg หรือโปรแกรมแก้ไขแบบคลาสสิกดั้งเดิม HTML จำนวนมากนี้จะถูกส่งผ่าน PHP ไปยังธีมของเรา และเรามีหน้าเดียวที่โหลด HTML, CSS และ JavaScript ของเรา และเนื้อหาเหล่านี้ถูกนำไปใช้กับเพจทั่วโลก

ดังนั้นโดยทั่วไปแล้วนักพัฒนา WordPress จะแยกการพัฒนาของเราตามประเภทไฟล์ ดังนั้นเราจะใส่ CSS ของเราในไฟล์แยกต่างหากซึ่งนำไปใช้กับเพจทั่วโลก หรือ HTML จะเขียนด้วย PHP และดึงข้อมูลที่เราต้องการจาก WordPress จากนั้น JavaScript จะ มักจะเขียนด้วย jQuery ในไฟล์แยกต่างหาก และทั้งสามสิ่งนี้จะมารวมกันเพื่อสร้างเพจ

ปัญหาคือสิ่งเหล่านี้ไม่ได้ถูกแยกออกจากกันซึ่งใช้กับทั้งหน้า บางครั้งคุณสามารถเปลี่ยนแปลงได้ เช่นนี้เกิดขึ้นกับฉัน ครั้งหนึ่งฉันทำการเปลี่ยนแปลงรูปแบบในส่วนท้ายของไซต์ตามที่ผู้จัดการร้องขอ และสามวันต่อมา มีรายงานว่ารูปแบบที่อื่นในไซต์เปลี่ยนไปเนื่องจากการตรวจสอบรหัสผ่านนั้น เราผ่านมันไปได้

จู่ๆ ก็มีบางอย่างในไซต์เสียหาย และนี่เป็นเพราะ CSS ถูกนำไปใช้งานทั่วโลกและอาจส่งผลกระทบต่อสิ่งที่คุณไม่รู้ มีแนวโน้มใหม่ ๆ ในอดีต - ฉันไม่รู้ - เจ็ดหรือแปดปีอาจเรียกว่าสถาปัตยกรรมแบบอิงส่วนประกอบ สิ่งนี้ช่วยให้เราสร้างส่วนเฉพาะของแอปพลิเคชันของเราในสิ่งที่เรียกว่าส่วนประกอบ

และเราสามารถจับคู่ JavaScript, HTML, CSS ของเราในบิตเล็กๆ ที่เราสามารถทดสอบแบบแยกส่วนได้ และเพื่อให้เราสามารถสร้างส่วนต่างๆ ของแอปพลิเคชันของเราได้ ข้อกังวลสองสามข้อ มาร์กอัป JavaScript สไตล์ และเราสามารถรวมส่วนประกอบเหล่านี้เข้าด้วยกันเพื่อสร้างแอปพลิเคชันที่ซับซ้อนมากขึ้น

ดังนั้นการพัฒนาตามส่วนประกอบทำให้เราสามารถแยกคุณลักษณะที่ซับซ้อนออกเป็นชิ้นเล็ก ๆ ที่แยกกันได้ และเราสามารถทดสอบพวกมันแยกกันได้ ตรวจสอบให้แน่ใจว่าพวกมันใช้งานได้จริง UI ทุกชิ้นมีความรับผิดชอบเฉพาะ หากเป็นการ์ดรูปภาพ อาจต้องรับผิดชอบในการแสดงรูปภาพในขนาดที่กำหนดด้วย URL เฉพาะ

ดังนั้นจึงมีการพึ่งพามาร์กอัป มีการพึ่งพาสไตล์ อาจมีการโต้ตอบแบบมีสถานะ ทั้งหมดนี้เกี่ยวข้องกับองค์ประกอบเฉพาะนั้น ดังนั้นเราจึงสามารถจับคู่มาร์กอัป JavaScript และ CSS ของเราในที่เดียว ทดสอบและตรวจสอบให้แน่ใจว่าทำงานได้ดี และด้วยเหตุนี้ เราจึงสามารถนำส่วนประกอบเหล่านี้กลับมาใช้ใหม่ได้ตลอดทั้งแอปพลิเคชันของเรา หรือแม้แต่เราสามารถนำส่วนประกอบของเรากลับมาใช้ซ้ำได้ในทุกโครงการ

ดังนั้นจึงมีแนวโน้มที่เรียกว่าไลบรารีคอมโพเนนต์ มีโปรเจ็กต์อย่าง Material UI หรือส่วนประกอบการออกแบบปลายทาง หรือ Chakra UI ก็เป็นที่นิยมเช่นกัน และเราสามารถใช้ส่วนประกอบเหล่านี้ในโครงการต่างๆ และเราสามารถแก้ไขข้อกังวลหลัก เช่น มาร์กอัปที่เข้าถึงได้ และเราสามารถอัปเดตสิ่งเหล่านั้นและใช้สิ่งเหล่านั้นกับหลายโครงการในองค์กรของเราได้ในคราวเดียว และด้วยเหตุนี้ ด้วยเหตุผลเหล่านี้ เราจึงสามารถทำซ้ำและจัดส่งได้เร็วขึ้นบ่อยครั้งด้วยความมั่นใจมากขึ้น

แล้วเราจะใช้ Headless WordPress ได้อย่างไร? อย่างที่ฉันได้กล่าวไปแล้ว มีสองวิธีในการรับข้อมูลจาก WordPress และเข้าสู่ส่วนประกอบ หนึ่งจะเป็น REST API หนึ่งจะเป็น WPGraphQL Drake เพื่อนของฉันสร้างไซต์ Headless มาระยะหนึ่งแล้ว ฉันจึงถามเขาและนี่คือสิ่งที่เขาพูด...

เขาชอบ WPGraphQL มากกว่า นั่นคือสิ่งที่เราจะพูดถึงในวันนี้ WPGraphQL คืออะไร คุณอาจถาม มันเป็นปลั๊กอิน WordPress โอเพ่นซอร์สฟรีที่ให้สคีมา GraphQL และ API ที่ขยายได้สำหรับไซต์ WordPress ใด ๆ GraphQL คืออะไร มันเป็นภาษาแบบสอบถามกราฟ

ได้เลย เจสัน ฉันยังไม่เข้าใจสิ่งที่คุณพูด เอาล่ะ ให้ฉันแสดงให้คุณดู ดังนั้น GraphQL วิธีการทำงานคือไคลเอนต์แอปพลิเคชันส่งคำขอที่ระบุสิ่งที่พวกเขาต้องการจากเซิร์ฟเวอร์ และคำขอมีลักษณะดังนี้ ดูเหมือนคีย์ JSON ที่ไม่มีค่า ในกรณีนี้ คำขอเป็นการขอผู้ดู และเราต้องการคืนฟิลด์ "ชื่อ" ให้กับผู้ดู

และการตอบสนองจากเซิร์ฟเวอร์ GraphQL อาจมีลักษณะดังนี้ ข้อมูล คีย์ และค่า JSON จริงของมัน และตรงกับรูปร่างของคำขอ ในกรณีนี้ เราจะได้ชื่อ หรือเราเรียกผู้ชมว่า เจสัน บาห์ล ดังนั้น GraphQL ให้แอปพลิเคชันไคลเอนต์ดึงต้นไม้ออกจากกราฟข้อมูลแอปพลิเคชัน

และสิ่งที่ดูเหมือนสายตาคือสิ่งนี้ เราสามารถป้อนกราฟได้ เช่น เพิ่มผู้ดูหรือฟิลด์ผู้ใช้หรือโหนด และโหนดนั้นอาจมีคุณสมบัติเช่นชื่อเจสัน และโหนดนั้นอาจมีการเชื่อมต่อกับโหนดอื่นๆ ในกราฟ เช่น อวตาร ซึ่งอาจมีคุณสมบัติเช่น URL รูปภาพ

และผู้ใช้รายนั้นอาจมีการเชื่อมต่อกับโหนดอื่นๆ เช่น โพสต์ที่ผู้ใช้รายนั้นเขียน และโพสต์เหล่านั้นอาจมีคุณสมบัติในตัวเอง เช่น ชื่อเรื่อง สวัสดีชาวโลก หรือลาก่อน Mars และโพสต์เหล่านี้อาจมีการเชื่อมต่อกับโหนดอื่นๆ ในกราฟ เช่น หมวดหมู่ที่มีชื่อของตัวเอง เช่น ข่าวหรือกีฬา และหมวดหมู่เหล่านั้นอาจมีการเชื่อมต่อกับโหนดอื่นๆ เช่นเดียวกับโพสต์อื่นๆ และโพสต์เหล่านั้นอาจมีรูปภาพเด่นและอื่นๆ เป็นต้น ดังนั้นเราจึงมีกราฟข้อมูลขนาดใหญ่ที่เราสามารถขอส่วนต่าง ๆ ด้วย GraphQL

ดังนั้นเราจึงสามารถใช้เครื่องมือในผู้ดูแลระบบ GraphQL หรือในผู้ดูแลระบบ WordPress มีเครื่องมือชื่อ GraphiQL ที่ฉันสามารถเขียนแบบสอบถามได้ และที่นี่ฉันกำลังเลือกช่อง Viewer ที่มีตัวเลือกย่อย ชื่อ รูปแทนตัว URL และเมื่อเราดำเนินการตามนั้น เราได้รับช่องที่เราขอ และเพื่อให้มองเห็นได้ว่าข้อความค้นหาจะมีลักษณะแบบนี้

เราเข้าไปในกราฟและขอผู้ใช้หนึ่งคน เราขอชื่อผู้ใช้ อวตารที่เชื่อมต่อใน URL ของอวาตาร์ เรามีกราฟข้อมูลทั้งหมดนี้พร้อมให้เราใช้งาน แต่เราขอข้อมูลชุดใดชุดหนึ่งเท่านั้น และในการตอบสนอง เราได้ชุดข้อมูลนั้นกลับมา จากนั้นเราก็สามารถใช้ - ตอนนี้เราสามารถใช้ส่วนประกอบได้แล้ว

ดังนั้นฉันจึงพูดถึงประโยชน์ของการพัฒนาตามส่วนประกอบ และฉันต้องการแสดงให้คุณเห็นถึงการใช้งานจริง และนี่คือสิ่งที่ผมเรียกว่าองค์ประกอบการนำเสนอ นี่คือส่วนประกอบของการ์ดที่ต้องรับผิดชอบ มีหน้าที่หนึ่งในการเรนเดอร์การ์ดใบนี้ด้วยรูปภาพและชื่อเรื่อง

และเราสามารถดูโค้ดและเห็นว่าเรามีการควบคุมสไตล์ เราสามารถกำหนดความกว้าง เราสามารถส่งภาพที่เราต้องการ และเราสามารถส่งชื่อ เราจึงสามารถนำส่วนประกอบนี้กลับมาใช้ใหม่ได้ตลอดทั้งโครงการ และองค์ประกอบนี้มีการอ้างอิงทั้งหมดที่เราต้องการ มี HTML ที่จะแสดงผล มันมีสไตล์ เรามีการควบคุมสไตล์ที่นี่ มีองค์ประกอบสถานะบางอย่างเช่นสถานะโฮเวอร์และอะไรก็ตาม

นี่จึงเป็นองค์ประกอบแยกที่เราสามารถนำมาใช้ซ้ำได้ และด้วย GraphQL ในตอนนี้ เราสามารถใช้คำค้นหาที่เราเพิ่งสร้างใน WordPress admin โดยใช้ GraphQL และเราสามารถนำสิ่งนั้นเข้ามาและมีส่วนประกอบการ์ดแสดงข้อมูลได้ทันที ดังนั้น เราสามารถเขียนแบบสอบถามของเรา รวมกับส่วนประกอบการ์ดของเรา และตอนนี้ส่วนประกอบก็เสร็จสมบูรณ์

เรามี HTML, CSS, JavaScript ของเรา และเนื่องจากข้อมูล ตอนนี้เรามีบางอย่างที่จะแสดงผลกับข้อมูลที่เราขอ ตอนนี้เราสามารถใช้สิ่งนี้ได้ตลอดทั้งแอปพลิเคชันของเรา และมีคุณลักษณะของ GraphQL ที่เรียกว่าแฟรกเมนต์ ซึ่งช่วยให้เรานำการสืบค้น GraphQL ของเราไปแบ่งออกเป็นส่วนๆ ที่นำมาใช้ใหม่ได้

ในกรณีนี้ ฉันกำลังสร้างส่วนย่อยของบัตรโปรไฟล์ผู้ใช้ และฉันกำลังระบุชื่อ ภาพแทนตัว และ URL จากนั้นฉันจึงใช้ส่วนย่อยนั้นในการสืบค้นที่ใหญ่ขึ้น เมื่อเราดำเนินการแล้วจะได้ผลลัพธ์ตามที่คาดหวัง ตอนนี้เราสามารถนำชิ้นส่วนนั้นมาใส่ในส่วนประกอบ ตอนนี้เรามีส่วนประกอบอื่นที่เรียกว่า User Profile Card

การ์ดโปรไฟล์ผู้ใช้นี้ระบุว่าเมื่อใดก็ตามที่เราสอบถามผู้ใช้ เราควรได้รับชื่อ รูปประจำตัว และ URL ของรูปประจำตัวเพื่อใช้ในคอมโพเนนต์ ตอนนี้เรามีคอมโพเนนต์ที่ใช้ซ้ำได้ ซึ่งทุกที่ในแอปพลิเคชันของเราที่เราขอผู้ใช้ เราสามารถรับข้อมูลที่จำเป็นในการแสดงการ์ดที่ใช้ซ้ำได้นี้ด้วยอวาตาร์และชื่อผู้ใช้

และตอนนี้เราสามารถนำสิ่งนี้มาใช้ในส่วนที่ใหญ่ขึ้นของแอปพลิเคชันของเราได้ ต่อไปนี้คือข้อความค้นหาที่เรามีก่อนข้อความค้นหาของผู้ดู โดยใช้ส่วนย่อยที่เรานำเข้าจากส่วนประกอบการ์ดโปรไฟล์ผู้ใช้ที่นำมาใช้ซ้ำได้ จากนั้นเราก็ส่งออกไปยังองค์ประกอบการ์ดแสดง และตอนนี้เราสามารถนำสิ่งนี้กลับมาใช้ใหม่ได้ทั่วทั้งแอปพลิเคชันของเรา

เราสามารถสร้างแอปพลิเคชันของเราให้ใหญ่ขึ้นโดยใช้การ์ดผู้ใช้นี้หรือการ์ดผู้เขียน ตอนนี้เราสามารถมีหลายองค์ประกอบ เช่น ส่วนประกอบชื่อบล็อกที่รับผิดชอบชื่อเรื่อง เราสามารถมีการ์ดโปรไฟล์ผู้ใช้ที่เราเพิ่งสร้างขึ้นซึ่งแสดงโปรไฟล์ของผู้ใช้ เราสามารถมีส่วนประกอบเนื้อหาหรือข้อความที่ตัดตอนมาซึ่งรับผิดชอบมาร์กอัปและข้อมูลสำหรับส่วนนี้ของแอปพลิเคชันของเรา

และใช่ เราสามารถสร้างส่วนประกอบขนาดเล็กเหล่านี้ที่รับผิดชอบมาร์กอัป CSS และข้อมูลที่จำเป็นในการสร้างแอปพลิเคชันนี้ และเราสามารถนำมาประกอบเข้าด้วยกันได้ เราสามารถทดสอบแยกกันได้ และยังทดสอบเป็นหน่วยที่ใหญ่กว่าได้อีกด้วย ดังนั้นเราจึงสามารถใช้สิ่งนี้ในเทมเพลตต่างๆ ได้เช่นกัน

เราสามารถใช้คอมโพเนนต์ที่ใช้ซ้ำได้เหล่านี้สำหรับบล็อกโพสต์หรือบทบาทบล็อกของเราที่มีผู้เขียนหลายคน แต่เราสามารถใช้คอมโพเนนต์เดียวกันเพื่อแสดงผลได้ เราสามารถใช้สำหรับ- หน้าเอกสารอื่นๆ คล้ายกับส่วนเทมเพลตของ WordPress มาก เราสามารถแยกแอปพลิเคชัน Headless ออกเป็นชิ้นเล็ก ๆ แต่เราได้รับประโยชน์จากการรวมเทคโนโลยีของเราเข้าด้วยกัน

นั่นเป็นเพียงเล็กน้อยเกี่ยวกับนักพัฒนา Headless WordPress ที่ประสบกับการออกแบบตามส่วนประกอบและประโยชน์ของสิ่งนั้น ดังนั้นเมื่อพูดถึง Gutenberg โดยเฉพาะ ทำไมคุณถึงพิจารณา Headless WordPress กับ Gutenberg โดยเฉพาะ ถ้าทีมของคุณใช้ Headless WordPress อยู่แล้ว อาจมี Advanced Custom Fields และ flexfields และคุณต้องการอัปเดตประสบการณ์การแก้ไขเพื่อใช้ Gutenberg นั่นเป็นเหตุผลหนึ่งที่คุณควรเลือกใช้ Headless กับ Gutenberg

หากคุณต้องการได้รับประโยชน์จากการสร้างส่วนประกอบที่ใช้ในผู้ดูแลระบบและส่วนประกอบที่ใช้ในส่วนหน้า ก็เป็นเหตุผลที่ดีที่จะพิจารณาเลือกใช้ Headless กับ Gutenberg เนื่องจากตัวแก้ไขส่วนหลังของ Gutenberg ของตัวแก้ไขบล็อกนั้นใช้ส่วนประกอบทั้งหมด คุณอาจต้องการใช้ประโยชน์จากอินพุตที่มีโครงสร้าง แต่ละบล็อกในผู้ดูแลระบบมีช่องที่มีโครงสร้าง

คุณมีคุณสมบัติเฉพาะที่คุณสามารถควบคุมได้ในระดับฟิลด์ และคุณอาจต้องการได้รับประโยชน์จากการมีเอาต์พุตที่มีโครงสร้างนั้นมาถึงส่วนประกอบของคุณเช่นกัน และอย่างที่ฉันได้กล่าวไป คุณอาจต้องการนำส่วนประกอบและบล็อกกลับมาใช้ใหม่ในโครงการต่างๆ เช่น คุณอาจต้องการมีไลบรารีบล็อกที่หน่วยงานของคุณสร้างขึ้นเพื่อแก้ปัญหาต่างๆ เช่น การช่วยสำหรับการเข้าถึงและข้อกังวลเกี่ยวกับมาร์กอัปเฉพาะที่คุณต้องการใช้ในโครงการต่างๆ จากนั้นคุณสามารถอัปเดตสิ่งเหล่านั้นในโครงการของคุณ ไม่ใช่แค่ภายในโครงการเดียว

ดังนั้นนี่จึงเป็นส่วนที่เหมือนกับธีมลูกใน WordPress อาจเป็นเรื่องยากที่จะปรับขนาดได้ เพราะคุณต้องไปที่ทุกๆ ไซต์เพื่ออัปเดตมาร์กอัปและอะไรก็ตามที่ไม่ได้อยู่ในทุกไซต์ ที่นี่คุณสามารถใช้ไลบรารีบล็อกเป็นการอ้างอิง NPM และอัปเดตทั่วทั้งองค์กรของคุณ

ดังนั้น สถานะของการพัฒนา WordPress กับ Gutenberg คือเรามีบล็อกที่แบ็กเอนด์ซึ่งเป็นส่วนประกอบ เราสามารถสร้างบล็อกที่กำหนดเองหรือใช้บล็อก WordPress หลักได้ แต่เอาต์พุตใน PHP นั้นเหมือนกับที่ฉันพูดถึง นั่นคือ HTML ก้อนใหญ่ก้อนหนึ่ง แล้วเราจะเปลี่ยนจากการรับ HTML หนึ่งบล็อกนี้ไปเป็นส่วนประกอบในส่วนแบ็คเอนด์ที่ถ่ายโอนไปยังส่วนประกอบในส่วนหน้าของเราได้อย่างไร

ดังนั้นเราจะดูตัวเลือกบางอย่างเพื่อรับข้อมูล Gutenberg จาก WordPress และส่วนประกอบต่างๆ ทางเลือกหนึ่งคือการรับเนื้อหาเป็น HTML ดังนั้นเราจึงสามารถค้นหาเนื้อหา WordPress ของเราเป็น HTML จากนั้นแยกวิเคราะห์ HTML นั้นเป็นส่วนประกอบ หรือเราสามารถค้นหาบล็อกเป็นประเภท GraphQL เราจึงทำได้ นั่นทำให้เราสามารถสอบถามรายการบล็อก แต่ละบล็อกจะเป็นประเภท GraphQL ที่เราสามารถแมปกับส่วนประกอบได้

เนื้อหาจึงเป็น HTML นี่คือสิ่งที่เราสามารถทำได้ใน WPGraphQL core ในวันนี้ หากคุณต้องการเคียวรีบล็อกเป็น GraphQL แต่ละประเภท มีสองตัวเลือกในขณะนี้ เรามี GraphQL สำหรับส่วนขยาย Gutenberg ซึ่งเป็นส่วนขยายของชุมชน จากนั้นเรามี WPGraphQL Block Editor ซึ่งเป็นปลั๊กอินเบต้าที่ฉันกำลังดำเนินการเป็นการส่วนตัว

ลองดูที่ตัวเลือกเหล่านี้ ในคอร์ WPGraphQL เราสามารถค้นหาเนื้อหาเป็น HTML และแยกวิเคราะห์เป็นส่วนประกอบ ดูเหมือนว่าเราจะค้นหาบางอย่างเช่นโพสต์ และเราสามารถขอฟิลด์ต่างๆ เช่น ID และชื่อเรื่องหรือเนื้อหาได้ และเนื้อหาจะส่งคืนสตริงขนาดใหญ่หนึ่งชุด HTML ขนาดใหญ่หนึ่งชุด จากนั้นเราสามารถแยกวิเคราะห์ HTML นั้นและแมปโหนด DOM ต่างๆ กับคอมโพเนนต์ต่างๆ

เช่นเดียวกับกรณีนี้ใน wpgraphql.com ลิงก์ด้านซ้ายคือโค้ดที่สิ่งนี้เกิดขึ้นจริง ฉันใช้มาร์กอัปที่ส่งคืนจาก WPGraphQL และแยกวิเคราะห์ ค้นหาโหนด HTML เฉพาะ และแปลงเป็นส่วนประกอบ React ดังนั้นฉันจึงสามารถมีสิ่งที่โต้ตอบได้ เช่น บล็อกโค้ดนี้ ซึ่งทำการเน้นไวยากรณ์และอนุญาตให้ผู้ใช้คลิกคัดลอก จากนั้นฉันยังสามารถแยกวิเคราะห์และสร้างสารบัญได้ เป็นต้น นั่นเป็นแนวทางหนึ่ง และฉันใช้มันใน wpgraphql.com ในการผลิตวันนี้

บางสิ่งที่คุณอาจต้องพิจารณาหากคุณใช้เส้นทางนี้ เพย์โหลด HTML อาจคาดเดาไม่ได้ การเปลี่ยนแปลงในเซิร์ฟเวอร์ เช่น การติดตั้งบล็อกไลบรารี่ใหม่ หรือ HTML ต่างๆ ที่เอดิเตอร์สามารถใส่ลงในเนื้อหา เป็นสิ่งที่คาดเดาไม่ได้ ดังนั้นจึงเป็นเรื่องยากมากที่จะแยกวิเคราะห์ คุณไม่สามารถตรวจสอบการเปลี่ยนแปลงได้ ในฐานะนักพัฒนาไคลเอนต์ คุณไม่สามารถมองเห็นสิ่งที่เปลี่ยนแปลง ดังนั้นสิ่งที่ควรพิจารณา

ฉันจะบอกว่าวิธีนี้ใช้ได้ผลดีที่สุดสำหรับทีมที่ควบคุมผู้ดูแลระบบ WordPress และฟรอนต์เอนด์อย่างเข้มงวด ดังนั้นหากคุณเป็นคนคนเดียวหรือทีมเล็กๆ ที่ทำงานบนแบ็กเอนด์ WordPress และฟรอนต์เอนด์ ก็อาจใช้ได้ดีสำหรับคุณ เพราะคุณสามารถควบคุมอินพุตและเอาต์พุตได้ดีขึ้นเล็กน้อย

หนึ่งในตัวเลือกอื่น WPGraphQL สำหรับ Gutenberg ซึ่งเป็นปลั๊กอินที่ดูแลโดยชุมชน และสิ่งนี้จะช่วยให้คุณสามารถสืบค้นบล็อกเนื้อหา แต่ละบล็อกเป็นประเภท GraphQL ของตัวเอง วิธีการทำงานคือหน้าการตั้งค่า คุณต้องเข้าไปในบล็อกเป็นสคีมา ดังนั้นสิ่งนี้จึงเปิด Gutenberg ใน iframe ที่มองไม่เห็น รับรีจิสทรีของบล็อกจากไคลเอนต์ JavaScript และส่งไปยังเซิร์ฟเวอร์

จากนั้นเราสามารถใช้ GraphQL เพื่อค้นหาบล็อกของเราเป็นประเภทเฉพาะ และเราสามารถใช้แฟรกเมนต์อย่างที่ฉันแสดงก่อนหน้านี้ และเราสามารถใช้แฟรกเมนต์เหล่านี้เพื่อแมปกับส่วนประกอบในส่วนหน้าของเรา นี่จึงเป็นทางเลือกหนึ่ง ข้อควรพิจารณาบางประการเกี่ยวกับปลั๊กอินนี้ การเปลี่ยนแปลงในรีจิสทรีของบล็อกสามารถพิจารณาได้ ซึ่งนั่นเป็นสิ่งที่ดี

ทีมที่ทำงานเกี่ยวกับแอปพลิเคชันส่วนหน้าสามารถใช้การหยั่งรู้ GraphQL เพื่อดูว่าสคีมาเปลี่ยนแปลงอย่างไรเมื่อเวลาผ่านไป และพวกเขาสามารถทราบได้ว่ามีการเปลี่ยนแปลงที่ผิดเพี้ยนหรือมีฟิลด์ใหม่ที่พวกเขาสามารถใช้ได้หรือไม่ ฉันจะบอกว่าวิธีนี้ใช้ได้ผลดีกว่าเล็กน้อยสำหรับโครงการที่มีหลายคนหรือหลายทีม หากคุณมีทีมที่ทำงานบนผู้ดูแลระบบ WordPress และอีกทีมที่ทำงานในส่วนหน้า แนวทางนี้อาจทำงานได้ดีกว่า พวกเขาสามารถใช้สคีมา GraphQL เป็นสัญญาระหว่างบล็อกที่ใช้ทั้งสองด้าน

สิ่งหนึ่งที่น่าสนใจเล็กน้อยคือมันโหลดบล็อกใน iframe อย่างที่ฉันพูดถึง และด้วยเหตุนี้ จึงไม่ปรับขนาดสำหรับทุกสถานการณ์เสมอไป ดังนั้น หากคุณลงทะเบียนการบล็อกไปยังหน้าใดหน้าหนึ่งหรือเทมเพลตเฉพาะหรือประเภทโพสต์เฉพาะ วิธีการรับแมปรีจิสตรีบล็อกกับสคีมานี้อาจพลาดในบางบล็อก ดังนั้นจึงอาจไม่ปรับขนาดสำหรับทุกโครงการ

โครงการต่อไป WPGraphQL Block Editor นี่เป็นปลั๊กอินเบต้าที่ฉันกำลังดำเนินการอยู่ และสิ่งนี้ยังช่วยให้คุณสืบค้นบล็อกเนื้อหาเป็นประเภท GraphQL ของตัวเองได้ และคล้ายกับ WPGraphQL สำหรับ Gutenberg มาก เราสามารถเขียนส่วนย่อยที่ส่งคืนข้อมูลที่เราระบุได้ จากนั้นเราสามารถใช้ชิ้นส่วนเหล่านั้นกับส่วนประกอบของเราในส่วนหน้า

ข้อควรพิจารณาบางประการเกี่ยวกับสิ่งนี้ มันเป็นปลั๊กอินเบต้า ดังนั้นจึงมีสิ่งนั้น คุณจะได้รับประโยชน์จากอินพุตที่มีโครงสร้างและเอาต์พุตที่มีโครงสร้าง ในฐานะผู้พัฒนาส่วนหน้า นั่นคือชัยชนะอย่างแน่นอน ทำงานกับบล็อกที่ลงทะเบียนกับไฟล์ block.json ดังนั้นบล็อก WordPress Gutenberg หลักจึงมีไฟล์นี้และวิธีนี้จะใช้งานได้กับแนวทางนั้น บุคคลที่สามจำนวนมากไม่ลงทะเบียนบล็อกด้วยวิธีนี้ ดังนั้นคุณจะต้องแมปบล็อกเหล่านั้นด้วยตนเอง

บล็อกไม่ถือเป็นโหนดเดี่ยว ฉันต้องการถือว่าบล็อกเป็นโหนดแต่ละโหนด แต่ไม่มี ID สากล ดังนั้นคุณต้องเข้าถึงบล็อกเหล่านั้นโดยเป็นส่วนหนึ่งของวัตถุที่ใหญ่กว่า เช่น หน้าโปสเตอร์

ดังนั้นฉันหวังว่าคุณจะได้เรียนรู้บางอย่างเกี่ยวกับ Headless WordPress ประโยชน์ของ Headless WordPress และการใช้ Headless WordPress กับ Gutenberg ฉันขอเชิญคุณลองใช้ WPGraphQL วันนี้ คุณสามารถลงทะเบียนบัญชี Atlas Sandbox ได้ฟรีที่ wpengine.com/atlas และขอขอบคุณที่เข้าร่วมการนำเสนอของฉัน อีกครั้ง คุณสามารถพบฉันได้ที่ Twitter, jasonbahl หรือที่ Twitter @wpgraphql ขอบคุณ