Update on the work to make building interactive blocks easier

Over the last ten months, a group of contributors has been working on a way to make it easier to build interactive blocks. These plans were first made public in the Exploration to enable better Developer and Visitor Experiences with blocks post, and the work they’ve been doing since then has been shared publicly in this GitHub repository. Additionally, @poliuk, who has been involved in this exploratory work, presented a talk sharing the group’s vision of the future of WordPress frontend at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe, held in June 2022 in Porto.  

As stated in this post from April, these are some of the questions that have been explored:

How to enable a much more powerful interactive and dynamic Visitor Experience with blocks? 
How to have a much more delightful Developer Experience when building blocks? 
How to offer a standard way to create interactive blocks so blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. developers don’t have to reinvent the wheel? 
How to ensure the block editor takes care of performance optimizations for visitors?
How to enable nice and faster page transitions with blocks? 

This new update is to share with the community that there has been progress on these areas and to announce that an initial proposal that could positively impact WordPress’ DX & UXUX User experience will be shared soon. The goal of this proposal is to create a new standard that simplifies building rich interactive web applications with WordPress using declarative and reactive programming principles.

If you can’t wait until the initial proposal gets published and are curious about the work done so far, please visit this GitHub repo

Here’s a list of the main areas where these contributors have been working on: 

  • WordPress Directives PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (tracking issue) by @cbravobernal, @santosguillamot, @darerodz, @luisherranz & @czapla: An installable plugin that adds a set of basic directives and client-side transitions.
  • Directives Hydration (tracking issue) by the same contributors: This issue tracks the work done to implement this mechanism to hydrate the DOM.
  • Stress testing (tracking issue) by the same contributors: This issue tracks the work done to test the performance and resilience of the Directives Hydration mechanism.
  • Server-side rendering of directives (PR) by @bernhard-reiter: Experimental PR to use WP_HTML_Tag_Processor to transform wp- directives into markup that’s ready for client-side hydration.
  • Client-side navigation of the Query LoopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. block using directives (PR) by @luisherranz: An experiment to implement client-side transitions in the Query Loop block.
  • Replicate Navigation block using directives (PR) by @luisherranz, @santosguillamot, & @darerodz: An experiment to switch from micromodal + imperative code to declarative directives.

Stay tuned for the next update, in which they’ll explain these areas of exploration in more detail, demonstrate how they fit together, and outline the alternatives that were considered. 

Meanwhile, anyone who wants to contribute will be warmly welcomed, so if you want to join in with this work and get involved, please raise your hand in the comments section below or open a conversation in this Discussion board.

Thanks to @luisherranz@priethor@poliuk, @bph@bernhard-reiter, @cbravobernal, @czapla, and @mburridge for reviewing and helping shape this post!

Special thanks to @poliuk, who wrote the initial draft of this post.

#block-developer-experience, #interactive-blocks, #interactivity-api, #visitor-experience

Exploration to enable better Developer and Visitor Experiences with blocks

In this post, we are using the following terms:

Visitor Experience: to refer to the UXUX User experience of a final user visiting a WordPress site.
Editor Experience: to refer to the UX of a user in the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.
Block Developer Experience: to refer to the experience developers have when working to create blocks.

Blocks have been a huge improvement for the Editor Experience. Now, editors can create complex content and customize their site designs with the same technique: by using blocks. But from a development perspective, there’s still room for improvement with regard to the level of interactivity that can be enabled with blocks for the visitors of a WordPress site (Visitor Experience) and the Development Experience of creating blocks. 

The general acceptance of blocks as the new WordPress data abstraction is the perfect moment to provide a standard solution to create interactive blocks. 

Wouldn’t it be nice (🎶) if we could…

  • Enable a much more powerful interactive and dynamic Visitor Experience with blocks? 
  • Have a much more delightful Developer Experience when building blocks? 
  • Offer a standard way to create interactive blocks so block developers don’t have to reinvent the wheel? 
  • Ensure the block editor takes care of performance optimizations for visitors?
  • Enable nice and faster page transitions with blocks? 

This post aims to start a conversation about these challenges and highlight them as some of the problems that need to be solved in order to achieve one of the big-picture goals for 2022: To improve the Block Developer Experience.

Table of Contents

A better interactive and dynamic Visitor Experience with blocks

What does it mean, to have better interactive and dynamic Visitor Experiences with blocks? Let’s take some use cases as examples of things that would be great if they could  be done just with blocks. Imagine (🎶) :

  • A form block that doesn’t trigger a page reload to display responses from the server. 
  • A pagination block that doesn’t reload the whole page when going to “next page” and loads only the portion needed.
  • A learning management system (LMS) where users can interact with the content in a more dynamic way enabling a better learning experience
  • Create with blocks a great e-commerce experience with carts, checkouts, and product galleries that dynamically respond to the visitor interaction
  • The ability to create just with blocks things such as Infinite Scroll, Swipe Navigation or any other experience in the frontend you can imagine.

Let’s work together to enable these kinds of delightful Visitor Experiences by using blocks!

By working together we can create  a standard way to develop blocks that enable complex and performant visitor experiences (perhaps by taking advantage of techniques such as frontend block hydration). 

A better Block Developer Experience

Blocks are amazing. They are a great mechanism for writing content. And now, with Full Site Editing, the power of Blocks has reached the world of Themes, so you don’t need to know how to code to create and customize your WordPress site. 

There are still challenges to solve though regarding the Block Developer Experience (“better block deprecation management” or “avoid duplication of code across JavascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. and PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher in order to properly render a block” are some examples of things that could be improved). It would be great if blocks could enable great Visitor experiences whilst also taking care of the complexity of modern tooling and strategies.

Let’s work together to define a standard way to create blocks that makes the development of blocks a pleasant experience.  

Get involved! 

Please share your thoughts, feedback, or ideas in the comments of this post or in the Developer Experience category of Github Discussions of the Gutenberg repo. There are already some conversations started by contributors there.

We’d love to hear your ideas regarding this:

  • Do you have some exploration you’d like to share with the community? 
  • How do you think blocks could enable more powerful Visitor Experiences? 
  • Is there any specific Visitor Experience (transitions between pages, partial hydration,…) that cannot be (easily) done with blocks that you think is missing? 
  • How do you think the Block Development Experience could be improved? 
  • What are the most important aspects of Block Development Experience you would like to improve?

Thank you (🎶) to @luisherranz, @priethor, @bph, @annezazu, @poliuk, @matweb, @mburridge for reviewing and helping shape this post!

#block-developer-experience, #interactivity-api, #visitor-experience