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