Recommended
More Related Content
What's hot
What's hot (20)
Similar to The Headless Block Editor
Similar to The Headless Block Editor (20)
Recently uploaded
Recently uploaded (20)
The Headless Block Editor
- 1. Photo by Bruno Martins on Unsplash Headless THE BLOCK EDITOR
- 2. “ It’s rapidly becoming much easier to implement a bridge from the Block Editor to headless applications. Anything other than the Block Editor for headless projects is a compromise too far. ~ Me (by the end of this presentation)
- 3. Headless + Block Editor Why How { { Challenges Solutions Opportunities Future The Block Editor Headless Applications What {
- 4. I’m Sean Blakeley Tech Director at AmericanEagle.com
- 5. Before The Block Editor
- 7. Hero Title Featured Hero YES / NO Title Sub-Title Featured Hero Colors Background Color Text Color Link Color Hover Color Hero Content SEO Title SEO Meta Description SEO Tags Non-visual CMS
- 8. ● Visual editing experience ● Core WordPress ● Intuitive ● Avoid abstract inputs ● Enriched UX Why the Block Editor?
- 10. ● Total cost of ownership ● Maintain custom solutions ● Increased time to value ● Higher dev LOE ● No plugin-and-play ● More complex governance Why Not Headless?
- 11. ● Scalability ● Security ● Portability ● Integrate multiple data sources ● OmniChannel distribution ● Technical flexibility ● Component-driven design Why Headless?
- 12. Photo by Shoeib Abolhassani on Unsplash Why the Block Editor & Headless?
- 13. Photo by bruce mars, Nubelson Fernandes & ConvertKit on Unsplash Engineers Content Creators End Users Visual CMS Flexibility Future-Ready Performance UX & Usability Interaction Technology Freedom Security Scalability
- 14. Photo by Brandable Box and Marvin Meyer on Unsplash Delivery + Adoption + Usage
- 15. Photo by Alvin Mahmudov on Unsplash TUX* * Total User Experience
- 17. Photo by Sung Shin on Unsplash Block Bridge
- 18. Photo by Luis Reyes on Unsplash A Lot of Heavy Lifting
- 19. Photo by Nathan Dumlao on Unsplash Previous Headless Block Editor Options
- 20. Static HTML - a Single String
- 21. ● Easy ● Works well across static blocks ● Only static content ● Html unpredictable ● Performance issue ○ Sanitize content ○ Parse translate to React components ● Lose React benefits ● Need to parse ● HTML data-attributes means using DOM as API Good Not so Good Static HTML - Good & Bad
- 23. ● Explicit Query ● Response defined by requester ● Single endpoint ● Defined schema ● Self-documenting ● Implicit Query ● Response defined by server ● Single JSON blob ● Documented externally, no schema GraphQL Rest API GraphQL vs Rest API
- 25. ● Exposed blocks ● Structured data ● Only global blocks available to page ● Not complete list of attributes ● Not scalable ● No definitive schema ● Single data blob Good Not so Good GraphQL - Good & Bad
- 26. Photo by Jukan Tateisi on Unsplash Challenges
- 27. Photo by Michael Dziedzic on Unsplash Invisibility
- 28. Invisibility WP CLI, GraphQL, REST API
- 30. Midjourney Prompt: A graphical representation of a contract Contracts Contracts
- 31. Contracts Registries in WP are Contracts
- 32. Midjourney Prompt: a posed studio photograph of a blob Data Blob
- 33. Non-Core, Custom Block Library
- 34. ACF -> Headless
- 35. Photo by Joshua Earle on Unsplash success!
- 36. Mecum.com
- 38. Block Bridge Photo by Sung Shin on Unsplash Data Bridge Mecum Architecture
- 40. Content Slots
- 41. Dual Saving - Programmatic and Editorial
- 43. Data Mapping
- 45. A Fews Gaps
- 47. GraphQL Field
- 48. Switch Statement
- 50. Native Component
- 52. Carmine Colicino & John Jeeves The Mecum Team
- 53. Midjourney Prompt: data moving quickly through cables neoncolor 8k new opportunities
- 54. Block Bridge Photo by Sung Shin on Unsplash
- 56. Photo by Volodymyr Hryshchenko on Unsplash Rewind
- 57. block.json
- 59. Photo by Isabella Fischer on Unsplash block.json Turning the Lights On
- 68. Photo by James Allen on Unsplash Remaining Tension
- 69. Photo by Jesper Aggergaard on Unsplash Changing Environment
- 70. Midjourney Prompt: minority report interactive screen Dynamic Blocks Individual block IDs PUT method - create blocks Pre-config payload Theme.json Shared Components SEO fields Future Direction
- 71. Photo by Tandem X Visuals on Unsplash Block Protocol Further Forward
- 72. Photo by Gl Co on Unsplash Huge Progress & Remaining Challenges
- 73. Photo by hani Pirzadian on Unsplash TUX Total User Experience
- 74. “ It’s rapidly becoming much easier to implement a bridge from the Block Editor to headless applications. Anything other than the Block Editor for headless projects is a compromise too far. ~ Sean Blakeley
- 75. Photo by ANIRUDH on Unsplash WordPress Defacto Visual Headless CMS
- 76. Thank You!
Editor's Notes
- Welcome to The Headless Block Editor
- It’s rapidly becoming much easier to implement a bridge from the Block Editor to headless applications. Anything other than the Block Editor for headless projects is a compromise too far. Journey together - see if it rings true.
- What, Why, How Fly over the what quick look at the why Dive in bit deeper into challenges & how
- Sean Blakeley Americaneagle.com 800-strong consultancy Enterprise WP
- Briefly remind ours Pre-Gutenberg = TinyMCE editor Learn shortcodes Gutenberg removes limitations
- Visual CMS Flexible Control Gold standard If you’re creating a headless app - Gutenberg gold standard
- Alternative Non-Visual Editor Abstract Not obvious consequences Structured data Poor content creation Friction Indicative of non-WordPress CMS experiences
- Why Gutenberg? Core Visual Intuitive Avoid abstract inputs Enriched UX
- Headless WP Replace PHP templating
- Total cost of ownership High development & maintenance costs No plugin-and-play
- Compelling why Scalable Secure by design Portable Integrations
- bring together - why? Simple: Best both worlds
- Best opportunity for success Headless Gutenberg Potential Gold Standard Engineer: Technology Freedom Content Creators: Drag-and-Drop editing End User: Usability This is really important because it
- Maximise the chances of client achieves true success - Make our agencies successful Make partnerships strong Holistic whole Measured by True success is: Delivery Adoption Usage
- Only achieve that by considering whole picture Consider all needs TUX Total user experience That’s why block editor into headless is gold standard
- We have a number of challenges & approaches
- Essence of idea Blocks Bridge Frontend Application (native) – Deceptively simple
- Heavy lift - why?
- Until very recently, 2 options: Static HTML GraphQL
- Static HTML 1 big string Expose via GraphQL or Rest API Display into a frontend Parsed Link components (otherwise hard refresh) Point links to app not backend No benefit of React components (Next Image)
- Good Easy flexible Bad Only static HTML unpredictable HTML data-attributes as an API Performance due to parsing and mapping
- WP GraphQL Gutenberg Plugin Pluck out exactly what want
- GraphQL Declarative Reponse shaped by requestor Single endpoint Avoids over-fetching API Implicit Defined by server Blog JSON
- WP GraphQL Gutenberg Plugin Exposed a new field BlocksJSON One blob - structured data
- Great Gave us access to blocks Bad Only global blocks Partial attributes Not scalable No schema 13m
- big challenges On your own
- Gutenberg is invisible
- Gutenberg Client Side CLI, API & GraphQL know nothing WordPress doesn’t know
- Used WP GraphQL Plugin Opens iframe Reads JavaScript registry Only blocks exposed to generic page Does not scale to complex blocks Saves in options table - now available server side
- Contracts Accepted set of rules and structure A schema Currently lacking Lack current notion of meta blocks and definitive structure Relationships are tricky Particularly what relationships CAN exist
- WP registries CPT and taxonomies = Contract Plugins can interact, API etc - clear rules Gutenberg not adhere to this pattern
- One big data lump Lots of parsing to deconstruct, sanitize and map So far, all data exposure Mapping to frontend Take our blob Parse it Pattern match Extract HTML data-attributes Reconstruct and distribute frontend components Recreate the parse_blocks() function on frontend
- Changes to core block structure Going to break mapping Pattern matching Update frontend Avoid changes by avoiding core Create custom blocks Easier support Miss core enhancements
- Enough issues drive away from Gutenberg completely ACF-driven
- In spite of challenges, Still seen huge success 17:15 min
- Mecum Powered by Gutenberg Innovative usage auctions Headless WordPress 120m views 250k lots 8m digital assets
- Salesforce push WP >>> WP push into frontend app Salesforce -> Gutenberg Lot data Share programmatic and editorial content
- Custom Mecum block Bridge Data going the other way into the application
- Data coming in Salesforce → into Gutenberg Slow down
- Content Slots
- Dual saving Data feed Gutenberg blocks Create content in slot Update arretary field See change in Gutenberg See change in frontend app
- Salesforce to WP
- Sales data pulled into mapping See class call for core blocks mapped into PHP
- Server side map Programmatic block generation across almost all blocks Programmatically insert data into and render a block
- Have to mindful of gaps Dynamic blocks Some attributes Youtube embed
- All Gutenberg - with content slots No editorial input Automated generation – – Half our journey
- Exposed via GraphQL Only option, WPGraphQL Gutenberg
- Frontend application Switch statement pivoting on name
- Fairly heavy sanitisation and processing in molecule Lot of heavy lifting
- Generating a native component Beauty of 1-2-1 mapping Support block patterns Collections of native components
- Final output Entirely automated from end to end Ability to further enrich with content No interaction required - all automated Further enrichment
- Shout out 27m
- Projects like Mecum huge success helped accelerate change New opportunities
- Standardised Block Bridge becoming possible An end-to-end solution
- Advances in just last few weeks and months
- Rewind Just over 2 years ago
- Block.json address Born out of way to add Block Directory, become source of truth
- special metafile Dual registration Backend and frontend Attributes Source of truth Shared PHP & JS Even add to previously client side only blocks
- Block.json is like turning the lights on - now we can see blocks
- End-to-end opinionated solution 2 parts 1/ WPGraphQL Content blocks GraphQL extension 2/ @faustwp/blocks package Connector facilitate set-up render blocks
- WPGraphQL Content Blocks Exposes blocks as GraphQL Types Self-documented schema new field added in the Post and Page models called editorBlocks get blocks encapsulated to that post type Issue of nested blocks - flat Temporarily assigns a unique id to rebuild hierarchy
- @faustwp/blocks - npm package Currently single wrapper component - renders blocks Opinionated way to discover and display blocks Includes flatListToHierarchical() function rebuild inner blocks Nice smart fallback to rendered HTML
- WPE - open source Fold into large offering Previews Template hierarchy
- VIP Block Data API Extends existing endpoints with /blocks extension 32m
- Available for any site Opt in option within VIP MU Plugins folder Discrete, clear attributes ‘Inner blocks’ more naturally, nested Json Potentially more problematic to map Big blog Narrow down to individual types of blocks Only block content - not rest of site Issue for static regeneration Focused on app routing where components pull data in directly?
- 10up Headless https://headstartwp.10up.com/docs/learn/gutenberg/rendering-blocks/ Pre-built core block support Only Supports Rest API Thin layer on top Next.js Opt-in way of selection components to be rendered as native components
- Human Made Suggest hybrid Rest API & GraphQL Use both in same project?
- We haven’t removed all challenges Huge progress Tension & challenges remain: Core & Rest API is not primarily focused on headless sites WPGraphQL is not part of core - not focus for core team
- Things are changing quickly Reduce: Time to value Entry bar Time and investment complexity Potential Reusable community supported bridge and mapping
- Dynamic Blocks interactivity API? Individual block IDs PUT - create blocks Pre-configure payload Theme.json bridge for styles? Shared Styles, Queries - Components 37m
- Project further forward Standardisation of blocks Blocks protocol underlying Block builders just opinionated implementations Standardise the output for ingestion for all manor of services built in predictable ways to Post types and taxonomy registries More robust registry and a single source of truth
- Still huge challenges But huge advances
- Continue focus on TUX Holistic whole
- Really starts to ring true Block Bridge - It’s easier, not easy rapidly becoming easier Maybe ANYTHING is too strong, But the resistance should be reducing Enterprise-level content teams Non-Gutenberg is too big a sacrifice
- Irrespective, WordPress opportunity defacto Visual CMS for headless applications Which means headless will remain Open Source Enabling WordPress continue huge positive impact on the tech world and beyond
- Thank You
- Resources