Interactivity API showcase

[johnbillion]

Hey everyone,

Let's use this discussion as a showcase for what's been built with the Interactivity API so far and how successful those projects have been.

Show us your stuff!

[luisherranz]

Hey John. Right now we have all the interactive Core blocks (Navigation, Search, File), the new Image "expand on click" feature and the first of the client-side navigation-based user experiences that prevents full reloads when users paginate on the Query block.

Those have been in production in Gutenberg for a while, so they have been used in production by anyone using the Gutenberg plugin and all the sites hosted on WordPress.com. All these blocks and features are coming to WordPress 6.4, which will bundle a private version of the Interactivity API that only Core blocks can use, (so it can still be tweaked or even removed if people finally reject the proposal).

Apart from that, WooCommerce is now shipping its own bundled version of the Interactivity API. If I recall correctly, they have the following blocks (either in production or about to be released): the Product Button block (Add to Cart, which now shows the number of items in the cart and is animated when the quantity changes), the Products Collection block (which has client-side navigation on pagination and filter changes, similar to the Query block), the Product Filters (which filter what's shown in the Product Collection block) and the Product Gallery block.

Their intention is to keep shipping their own bundled version of the Interactivity API if/until WordPress includes a public version. The new store() API proposal is basically the result of the learnings from WooCommerce, among other improvements. We also have refactorings for the Image and Navigation blocks in mind, and want to keep exploring other client-side navigation-based user experiences like instant search or infinite scroll.

[Poliuk]

Looks like @sethrubenstein has been playing with it lately

We've been experimenting with the wordpress/interactivity api all week and I am 1000% sold and onboard with the concept. I'll have a more in-depth write up along with some examples soon.

In just the last 72 hours here's what we've done with the interactivity API:

• Convert our input-text block to support interactivity
• Convert our mailchimp-form block to support interactivity
• Add interactivity support to core/button (input, button, form.... you see where this is going)
• Experimenting with region based rendering in the interactivity api to allow for routing
• Started planning broader interactivity support in our block library by adding new isInteractive and interactiveNamespace attributes to any block that has interactivity support set to true.

We'll have lots to show in the new year!

[sethrubenstein]

You beat me to it! I'm working on a write up now with some minimal video and code examples, but first I want to make a little more progress on understanding some concepts. I'll share more soon!

[JosefJezek]

Why does interactivity API on the front-end need 31 kB? Why does every page need this big js file?

https://2024.wordpress.net/wp-content/plugins/gutenberg/build/interactivity/index.min.js?ver=17.1.3

I would like to see a WP page with minimum JS or zero JS. Framework Astro shows this path with 0 JS on the front-end, see https://dev.to/ekqt/shipping-zero-javascript-with-astro-9ol

[luisherranz]

Exactly! The Interactivity API works like Astro, shipping 0kBs by default, and using the concept of islands. Islands are just interactive blocks. If a page doesn't have any interactive blocks, WordPress won't ship any JavaScript (so 0kBs!).

Actually, if you take a look at the code, there are some places where we still mention islands, although we are replacing them with the word "interactive" to avoid introducing the concept of islands in WordPress (that was actually suggested by @carolinan here).

As for the size, take into account that 31kBs is the size unzipped. People usually talk about zipped sizes. For example, jQuery is 88.3kBs unzipped, and 31.7kBs zipped. The zipped size of the Interactivity API runtime is currently 11.3kBs:

So, again, this works exactly like Astro:

• If you don't have any interactive blocks (islands) on your page, it won't send any JavaScript (0kBs!).
• If you have islands in Astro, you need to choose a framework. For the Interactivity API, we chose Preact, which is one of the smallest. If I'm not mistaken, Preact + Preact hooks + Preact signals is about 8kBs (zipped). That's size would be the same in Astro. In WordPress, we had to a small runtime on top of Preact to process the directives, so that's the ~3kB difference that you see from 8kBs to 11.3kBs. But other than that, it's exactly the same in Astro.

That said, we have not implemented some optimizations yet, but we will apply them in future versions:

• Code split any non-necessary runtime piece (like the router).
• Code split all the directives and only load the ones used on the page.
• Add lazy loading techniques (similar to Astro ones)

With that, we will probably be able to save 1-2kBs more on the initial load of the runtime, and also improve the time-to-interactive metrics by delaying the hydration of the non-essential islands (interactive blocks).

More importantly, we will be able to apply most of these optimizations without requiring any intervention or code change on the developers side.

[JosefJezek]

The Astro doesn't need any front-end framework to create interactive components. I can create Astro component with Web Components standard API without any lib. See the script in the search component https://github.com/withastro/starlight/blob/main/packages/starlight/components/Search.astro

The interactivity lib has 31 kB code for all browsers. Low-end phones have limited computing power. The computing of every kB of JS code needs extra energy from nature.

Why do I need Preact for navigation in Twenty Twenty-Four theme? Demo site https://2024.wordpress.net/index.php/sample-page/

Preact for navigation is overkill !!! We don't need Preact.

We have HTTP2 multiplexing, see https://stackoverflow.com/questions/36517829/what-does-multiplexing-mean-in-http-2

Please separate preact lib from interactivity lib. A new version of Preact needs a new version of interactivity lib now. This solution needs to download next unnecessary kB of JS code !!!

I don't like Preact. Preact creates its own API on the web platform. I like Web Components API for simple components and Lit lib for complex components, see lit.dev.

Components without dependencies

• https://github.com/mdn/web-components-examples
• https://github.com/thepassle/generic-components
• https://github.com/zachleat/table-saw
• https://github.com/zachleat/infinity-burger
• https://github.com/zachleat/browser-window
• https://github.com/zachleat/announcement-banner

Lit components

• https://github.com/ing-bank/lion
• https://github.com/material-components/material-web
• https://github.com/adobe/spectrum-web-components
• https://github.com/google/model-viewer
• https://github.com/google/playground-elements

Best island component

• https://github.com/11ty/is-land

[johnbillion]

These are all great points but they would be better made in their own discussion topic so the conversation can continue and get more input from others. Can you move this to a separate discussion topic?

[JosefJezek]

here #56681

[sethrubenstein]

(reposting this to the main thread) Heres an example for everyone of the interactivity api in action. We just recently converted our Tabs blocks to the api, heres how that went:

CleanShot.2023-11-29.at.18.12.56.mp4

This is comprised of 5 blocks:

1. Tabs Controller
2. Tabs Menu
3. Tabs Menu Item
4. Tabs Panes
5. Tabs Pane

With really only 3 of them being "interactive". Tabs Controller is where the majority of the logic is for the tabs to work. Heres a quick sample of its view.js

/**
* WordPress Dependencies
*/
import { store } from "@wordpress/interactivity";
import { addQueryArgs } from '@wordpress/url';

function updateHash(tab, uuid) {
	tab.focus();
	// add a tabItem query arg to the url with the id of the new tab
	const { href } = window.location;
	const newUrl = addQueryArgs(href, {
		tabItem: uuid
	});
	window.history.pushState({ path: newUrl }, '', newUrl);
}

store( {
	state: {
		tabsController: {
			// A simple log of all the tab controller blocks on the page
			onPage: [],
		}
	},
	actions: {
		tabsController: {
			setActiveTab: ({actions, selectors, context, ref}) => {
				const { uuid } = context;
				context.tabsController.activeUUID = uuid;
				// When we select a new tab also update the browser history state and add the tab's uuid to the url. This allows users to copy the url and provide deep linking activation of a specific tab by url. Thats handled server side with a query var check on the block render.
				updateHash(ref, uuid);
			},
		}
	},
	selectors: {
		tabsController: {
			isActive: ({context, ref}) => {
				// Each panel|tab has its own context containing its own uuid, we can then compare that to the activeUUID in the tabsController context to see if it is active.
				const { uuid, tabsController: { activeUUID } } = context;
				if ( ! uuid ) {
					return false;
				}
				return activeUUID === uuid;
			}
		}
	},
	effects: {
		tabsController: {
			onInit: ({actions, selectors, context, state, ref}) => {
				const id = ref.getAttribute('id');
				state.tabsController.onPage = [
					...state.tabsController.onPage,
					id,
				];
				const event = new CustomEvent('tabsReady', {detail: {id}});
				// Fire a custom event when the tabs are ready
				document.dispatchEvent(event);
			}
		}
	}
} );

For the controller's block render heres what the looks like:

/**
 * Either return the uuid from the `tabItem` url var or get the uuid for the first menu item block.
 * @param mixed $block
 * @return mixed
 */
private function get_first_menu_item_uuid($block) {
    $url_var_value = get_query_var('tabItem');
    if ( $url_var_value ) {
        return $url_var_value;
    }

    $parsed_block = $block->parsed_block;
    $tabs_controller_innerblocks = $parsed_block['innerBlocks'];
    $menu_block = wp_get_first_block($tabs_controller_innerblocks, 'prc-block/tabs-menu');
    $first_menu_item_block = wp_get_first_block($menu_block['innerBlocks'], 'prc-block/tabs-menu-item');
    return $first_menu_item_block['attrs']['uuid'];
}

/**
 * Render the Tabs Controller
 * @param mixed $attributes
 * @param mixed $content
 * @param mixed $block
 * @return string
 */
public function render_block_callback( $attributes, $content, $block ) {
    $initial_context = array(
        'tabsController' => array(
            'activeUUID' => $this->get_first_menu_item_uuid($block),
        )
    );

    $block_wrapper_attrs = get_block_wrapper_attributes(
        array(
            'id'    => 'tabs-'. md5( wp_json_encode( $attributes ) ),
            'class' => \PRC\Platform\Block_Utils\classNames( array(
                'is-vertical-tabs' => $attributes['vertical'],
                'is-horizontal-tabs' => ! $attributes['vertical'],
            ) ),
            'data-wp-interactive' => true,
            'data-wp-context' => wp_json_encode($initial_context),
            'data-wp-init' => 'effects.tabsController.onInit',
        )
    );

    return wp_sprintf(
        '<div %1$s><div>%2$s</div></div>',
        $block_wrapper_attrs,
        $content,
    );
}

The menu item block render:

<?php
namespace PRC\Platform\Blocks;

$uuid = array_key_exists( 'uuid', $attributes ) ? $attributes['uuid'] : false;
if ( ! $uuid ) {
	return;
}

$block_wrapper_attrs = get_block_wrapper_attributes(
	array(
		'data-wp-interactive' => true,
		'data-wp-key' => 'tab-'.$uuid,
		'data-wp-class--is-active' => 'selectors.tabsController.isActive',
		'data-wp-context' => wp_json_encode(array('uuid' => $uuid)),
		'data-wp-on--click' => 'actions.tabsController.setActiveTab',
	)
);

$content = wp_kses( $attributes['title'], 'post' );

echo wp_sprintf(
	'<button %1$s>%2$s</button>',
	$block_wrapper_attrs,
	$content,
);

And then lastly this is the tabs pane render:

<?php
namespace PRC\Platform\Blocks;

$uuid = array_key_exists( 'uuid', $attributes ) ? $attributes['uuid'] : false;
if ( ! $uuid ) {
	return;
}

$block_wrapper_attrs = get_block_wrapper_attributes(
	array(
		'aria-role'   => 'tabpanel',
		'data-wp-interactive' => true,
		'data-wp-key' => 'panel-' . $uuid,
		'data-wp-class--is-active' => 'selectors.tabsController.isActive',
		'data-wp-context' => wp_json_encode(array('uuid' => $uuid)),
	)
);
echo wp_sprintf(
	'<section %1$s>%2$s</section>',
	$block_wrapper_attrs,
	$content,
);

Our experience with the API has been good so far. However, our dev team has expressed some consternation and confusion regarding the naming of "state" and "context". They suggest that calling them "Global State" and "Local State" or "Block State" might be more appropriate, given their functionality in a "reacty" way. Personally, I believe the current naming is fine, but additional documentation explaining the differences between the two and how they work together would be helpful.

We're also interested in exploring another aspect: using the API with real React components. For instance, we're currently working on a searchable multiselect dropdown that can interact with global state, block context, and actions more smoothly. Although we have achieved some success in making it work, the approach still feels somewhat hacky. I'll share some examples of our progress soon.

Looking forward to Gutenberg 17.2 releasing and really exploring (and I assume updating some of the blocks we've already converted) the updated store api.

[luisherranz]

The namespace injection allows us to use the captcha block and other interactive form blocks (such as input, dropdown, checkbox, etc.) in different form blocks. Each form block has its own interactivity namespace

Hey Seht, with the final 1.0 version of the Interactivity API, you don't need to pass down the namespace because it is inherited from the parents. So reusing blocks that trigger actions or read state defined in the store defined by their parent blocks works fine and will be supported.

For example, the same submit-button block can be used without modification for two different form blocks:

my-plugin/some-form

<!-- wp:my-plugin/some-form -->
<div data-wp-interactive="my-plugin/some-form">
  <span>Some markup here..</span>
  <!-- wp:my-plugin/submit-button -->
    <button data-wp-on--click="actions.submit">
      This triggers the submit action of `my-plugin/some-form`
    </button>
  <!-- /wp:my-plugin/submit-button -->
</div>
<!-- /wp:my-plugin/some-form -->

store("my-plugin/some-form", {
  actions: {
    submit() {
      // Logic triggered by the submit-button block.
    }
  }
})

my-plugin/other-form

<!-- wp:my-plugin/other-form -->
<div data-wp-interactive="my-plugin/other-form">
  <span>Some markup here..</span>
  <!-- wp:my-plugin/submit-button -->
    <button data-wp-on--click="actions.submit">
      This triggers the submit action of `my-plugin/other-form`
    </button>
  <!-- /wp:my-plugin/submit-button -->
</div>
<!-- /wp:my-plugin/other-form -->

store("my-plugin/other-form", {
  actions: {
    submit() {
      // Logic triggered by the submit-button block.
    }
  }
})

[poof86]

I read in the changelog that inserting (p)react components through the data-wp-text directive has been removed. I need to combine my React components (I’m not sure if I can convert them to preact but I also want to try this). What is the proper way of doing this now? Could I get a tiny example? 🙏🏻

[luisherranz]

Hey Niels, as I said, we want to support it at some point, but we need to know more about the use cases first to understand how to do it right.

We can add it again to Gutenberg and experiment with it, maybe as a new directive, like data-wp-component, for example.

Would you mind opening a new discussion with your use case so we can start figuring out the requirements? Thanks!

[poof86]

Here it is: #60418

[luisherranz]

Thanks!

[felixarntz]

I just opened this experimental proof of concept PR WordPress/wordpress-develop#5795 to use the Interactivity API to replace all dynamic frontend functionality in Twenty Twenty-One. This is mostly an exploration which explores how the API could be used even in classic theme contexts. While we speak a lot about blocks today, by no means is (or should be) the API limited to blocks.

[felixarntz]

FYI, WordPress/wordpress-develop#5795 has been updated to use the Interactivity API as of WordPress 6.5, including the recently added data-wp-on-window and data-wp-on-document directives for more declarative implementation of those features.

[pshemek]

Hi @felixarntz!

I tried your approach and it worked in major browsers except to Safari where I got:

TypeError: Module specifier, '@wordpress/interactivity' does not start with "/", "./", or "../".

Have you perhaps encountered this problem in Safari?

EDIT: Actually it works in Safari as well although the above error is present.

[luisherranz]

Actually it works in Safari as well although the above error is present

We are polyfilling import maps so that error message is expected on old Safari versions.

[renatonascalves]

👋🏾 So, this is my first block using the interactivity API. I opted to use the template from https://todomvc.com/, so that I could focus only on learning, and hooked the reactivity with the interactivity API.

The documentation here has been helpful. Knowing a little bit of Alpine.js, I run into some issues with the "design" of the API. Like, "why can't the interactivity API do this Alpine.js does? Like x-show".

The work on the vscode extension might help make the task easier/faster. Compared to Alpine, it takes more typing to bind and hook stuff (a lot of data-wp....). Maybe with snippets, it'll be faster.

As an aside: I'd suggest adding an alias for wp-css. Got into trouble while adding data-wp-css rather than data-wp-class and thinking, "why is the CSS class not working?" 😆

But as soon as you understand the design of the API, all goes smoothly after that. :)

CleanShot.2024-02-17.at.22.16.29-converted.mp4

[luisherranz]

Ohhh, todomvc. Lovely 🙂

Do you have the code for that? It would be a great example to show!

Oh, data-wp-show is definitely coming in an upcoming release.

[renatonascalves]

Sure! Let me first finish the app. I'm in the process of trying/testing the router bundled with the API. After that, I can share the complete code.

[ndiego]

I just used a bit of the Interactivity API in my tutorial on mega menus for the Developer Blog. It's not a very complex implementation, but it should be helpful for those looking to get started.

[colorful-tones]

I'm attempting to recreate the feedback form interactivity featured on Nextjs.org/docs/ (at bottom of each docs - screenshot below). I've made some pretty good progress on hooking the toggling up. However, I'm hung up on processing and handling the submission of the form and passing along the post ID, sanitize, validate and nonce the form. Perhaps I'm stuck in the old ways of thinking on how to do things with WordPress, and I'm wondering if I'm missing something here.

Here is some of the logic I'm working on for noncing and passing the info from a Post. Is reaching for WP's admin-ajax.php still a valid and ideal approach? 🤔

/**
 * Adds a script to the footer that initializes the wpeFeedbackResponse object with necessary data.
 *
 * This function is hooked to the 'wp_footer' action.
 */
function devrel_feedback_response_script() {
	if ( ! is_singular( 'post' ) ) {
		return;
	}
	$data     = array(
		'ajaxUrl' => admin_url( 'admin-ajax.php' ),
		'nonce'   => wp_create_nonce( 'devrel_feedback_nonce' ),
	);
	$localise = wp_json_encode( $data );

	printf( '<script type="text/javascript">let wpeFeedbackResponse = %s</script>', $localise ); // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped
}
add_action( 'wp_footer', 'devrel_feedback_response_script' );

/**
 * Handles the submission of feedback form via AJAX.
 *
 * This function is responsible for processing the feedback form submission and saving the feedback
 * to the corresponding post meta. It checks the AJAX referer, retrieves the post ID and feedback
 * from the request, sanitizes the input, and updates the post meta with the feedback value.
 * If the feedback and post ID are valid, it returns a success message. Otherwise, it returns an error message.
 */
function devrel_feedback_submission_handler() {
	// Check the AJAX referer.
	check_ajax_referer( 'wpe_devrel_feedback_nonce', 'feedback_form_nonce' );
	// Obtain the post ID and feedback from the request.
	$comment         = wp_filter_nohtml_kses( $_POST['feedback'] );
	$comment_post_id = intval( $_POST['comment_post_id'] );

	$commentdata = array(
		'comment_post_id'   => $comment_post_id,
		'comment_content'   => $comment,
		'comment_author_ip' => $_SERVER['REMOTE_ADDR'],
		'comment_agent'     => $_SERVER['HTTP_USER_AGENT'],
		'comment_approved'  => 0, // Hold for moderation
	);

	wp_insert_comment( $commentdata );
	echo 'Success';

	wp_die();
}
add_action( 'wp_ajax_submit_feedback', 'devrel_feedback_submission_handler' );
add_action( 'wp_ajax_nopriv_submit_feedback', 'devrel_feedback_submission_handler' );

Is there a different method to do this in my block, and would this impact with Interactivity API integration planning (limitations, challenges)?

[colorful-tones]

I'm running WP 6.5-RC1 and Gutenberg plugin only and I cannot get a successful AJAX request. Everything else works fine though. 🤔

[sethrubenstein]

@colorful-tones We're relying entirely on custom rest endpoints for such things. I have a pretty simple example I can point to for the interactivity (disregard my commented out nonces right now 🤫this is still in development).

Our MailChimp From block hits a custom endpoint we've created to handle newsletter subscriptions https://github.com/pewresearch/prc-block-library/blob/develop/blocks/mailchimp-form/src/render.php and using @wordpress/url and @wordpress/api-fetch to put together a quick little submission handler. https://github.com/pewresearch/prc-block-library/blob/develop/blocks/mailchimp-form/src/view.js#L12-L58.

Basically, we're watching for a true value on a flag that lets the submission handler finally run. That true value is set by our Captcha (https://github.com/pewresearch/prc-block-library/blob/develop/blocks/form-captcha/src/render.php, and https://github.com/pewresearch/prc-block-library/blob/develop/blocks/form-captcha/src/view.js respectively)

[sethrubenstein]

@colorful-tones Hmm, not sure about the bad request from admin-ajax though, I see you're basically doing the same thing. My only guess would be to try changing the order of operations a bit and have the on click just set some flag to true and have a data-wp-watch-- callback wait for the signal to run the submit handler? I've come across a few race conditions when using an action that are best handled this way.

[luisherranz]

why I get Bad Request from admin-ajax.php here?

Does it work when you don't use the Interactivity API?

set some flag to true and have a data-wp-watch-- callback wait for the signal to run the submit handler?

Do you have a reproducible example of that behavior? There should not be any race condition.

[colorful-tones]

I got it working and was a matter of the formatted data I was passing from client to server was malformed. I'll be pushing up the latest code tomorrow. Thanks all!

[colorful-tones]

I just wanted to circle back and share that I put up my demo Feedback block plugin. I would love any insight on how to improve any of the code, and always still learning! ❤️

[luisherranz]

That looks awesome! Great example about how to use ajax with the Interactivity API 🙂

I would love any insight on how to improve any of the code

I would only change two things:

1. Use generators for any asynchronous operation, instead of async/await (or promises).

    *submitForm( event ) {
      const context = getContext();
      const { ref } = getElement();

      event.preventDefault();

      const formData = new FormData( ref );
      formData.append( 'action', 'submit_feedback' );
      formData.append( 'nonce', context.nonce );
      formData.append( 'postId', context.postId );
      context.isFormProcessing = true;

      try {
        const data = yield fetch( context.ajaxUrl, {
          method: 'POST',
          credentials: 'same-origin',
                body: formData
        }).then( r => r.text() )

        context.hasSuccess = true;
        context.formMessage = "Success!";
      } catch( error ) {
        console.error( 'Error:', error );
        context.hasError = true;
        context.formMessage = "Error!";
      }
    },

This is a requirement for the Interactivity API. In your case, everything works fine, but it could cause issues with the scope.

If you want to keep using promises instead, you need to wrap all the promise callbacks with a withScope(cb) function.

2. Avoid storing state that can be derived from other state.

const { state } = store( "...", {
  state: {
    get hasSucess() {
      const { status } = getContext();
      return status === "success";
    },
    get hasError() {
      const { status } = getContext();
      return status === "error";
    },
    get formMessage() {
      const { status } = getContext();
      if ( status === "success" ) return "Success!";
      if ( status === "error" ) return "Error!";
    }
  },
  actions: {
    *submitForm( event ) {
       // ...

       try {
        yield fetch( context.ajaxUrl, {
          method: 'POST',
          credentials: 'same-origin',
                body: formData
        }).then( r => r.text() )
        context.status = "success";
      } catch( error ) {
        console.error( 'Error:', error );
        context.status = "error";
      }
    },
  }
});

This keeps things more declarative and avoids out-of-sync issues when the code starts getting complex.

I hope that helps 🙂

[fabiankaegy]

Hey all 👋

Question: I've been going through the starter documentation again (https://developer.wordpress.org/block-editor/reference-guides/packages/packages-interactivity/#quick-start-guide) and in the basic toggle example I'm surprised to see that the data-bind to handle the show / hide actually doesn't get server rendered and I'm getting a layout shift on the client because of it.

Do you have any insights on what I may be missing here?

[SantosGuillamot]

Have you tried with the latest version of wordpress-develop and Gutenberg? There were a couple of issues fixed lately related to the server side rendering: link. Especillay this one I think could affect here.

[fabiankaegy]

@SantosGuillamot Thanks :)

I retested this with RC2 and I can confirm that it works as expected. Thanks for the help :)

[garridinsi]

Hi! I made this block plugin with the Interactivity API. https://github.com/garridinsi/carbonbadge-block/ I used this simple project to test the API and is awesome!!

Also, I'm going to talk about the API on WordCamp Chiclana 2024!

[garridinsi]

The plugin was published to the WordPress plugins repo on Wednesday!

https://wordpress.org/plugins/carbonbadge-block

[luisherranz]

This is the talk by the way (in Spanish): https://youtube.com/watch?v=tVEGusGpogk

(I hope you don't mind me sharing it 😄)

[garridinsi]

Thank you for sharing Luis!

[ahsanshaheen199]

Hello! I have created a to-do list block using the Interactivity API to learn more about it. You can find the demo of this plugin by clicking on this link. If you're interested, you can check out the code by clicking on this link. I would be highly appreciative of any suggestions to improve the code. Thank you!

[luisherranz]

That's wonderful. Really well structured code and a great example of how to use the Interactivity API, including things like derived state and wp-each. Thanks for sharing it. Oh, and I love that you used TypeScript! 🙂

I would be highly appreciative of any suggestions to improve the code.

Sure. Here are a couple of small nitpicks:

• Using ref.dataset.filterId to reuse the same selectFilter action is a great approach. Just one note: ref is null during the first hydration and if the element is unmounted and mounted again (like in React), so in general is safer to use attributes:

  const { attributes } = getElement();
  const filterId = attributes["data-filter-id"];

  We need to improve the docs about this.
• You used data-wp-key inside the li elements of wp-each. That's great, but unfortunately, it won't work as expected because internally, wp-each adds a <Provider> wrapper to add the context (context.todo) and the key needs to be added to that component. So, instead of data-wp-key in the li element, you should use data-wp-each-key in the template:

  <template
    data-wp-each--todo="state.filterTodos"
    data-wp-each-key="context.todo.id"
  >
    <li
      data-wp-class--editing="context.todo.isEditing"
      data-wp-class--completed="context.todo.completed"
    >
      ...
    </li>
  </template>

  We need to improve the docs about this.

I can't find anything else to comment on. As I said, the code is wonderful 😄

cc: @DAreRodz

[ryanwelcher]

Looks like we already have some MVC To-do apps here so I'll add mine to the mix as well! It should have all of the functionality expected and uses wordpress/interactivity-router for the All, Active, and Completed toggles.

Demo: https://delicately-adorable.wp.build/
Code: https://github.com/ryanwelcher/interactivity-api-todomvc

I've been live-streaming building this as well:

Part 1: https://www.youtube.com/watch?v=VWUE2StCp_M
Part 2: https://www.youtube.com/watch?v=OAhSgpomOjw

[ryanwelcher]

I have a gallery slider that uses the IAPI as well. It also uses the HTML API to add interactivity to core blocks

Demo:

slider-demo.mp4

Code: https://github.com/ryanwelcher/iapi-gallery-slider/

[r-chrzan]

I've created instant search using Interactivity API:

Instant-search-interactivity-api.mov

I created a thread some time ago

Code: https://github.com/r-chrzan/instant-search-interactivity

[luisherranz]

This is incredibly well done; congratulations! It's the best use of client-side navigation I've seen outside of Core blocks.

I love the way you've reused the Query block, creating a variation and filtering the query. It's also great that you've added a pattern. Excellent use of all the available resources to extend the core blocks 😄

Would you like to collaborate to add instant search to the Core blocks? We haven't decided exactly how it would work yet; if it should be a variation of the Query block or just an option of the Search block. But we can brainstorm the design and make a decision. At the code level, it would be very similar to what you've done in your plugin.

[r-chrzan]

@luisherranz Thanks again! It will be a pleasure 😊

[luisherranz]

Awesome. I'll send you a DM on Slack 🙂

[scottblackburn]

Some really nice examples here. I put together a simple interactivity API tutorial, might be useful for someone:

GitHub: https://github.com/bigbite/interactivity-api-tutorial/tree/main
Site post: https://bigbite.net/2024/05/14/getting-started-with-the-interactivity-api/

[luisherranz]

Great tutorial, thanks Scott! 👏

I noticed you used data-wp-class-isDark and then isdark as the class name, which might be confusing, so I opened a PR to recommend the usage of kebab-case class names when using data-wp-class. I'd love if you could take a look and let me know what you think 🙂

• Docs/iAPI: Recommend kebab-case in data-wp-class #62817

[scottblackburn]

@luisherranz thanks for the feedback! this makes sense to keep things consistent and avoid confusion.

[djuric]

Hey all! I wanted to share a booking form block I'm experimenting with. It's been really interesting working with Interactivity API for this one.

I'm learning a lot about how Interactivity API works, I think I'm going to have a lot of fun experimenting with it in future!

3-step-booking-form.mov

Repo: https://github.com/djuric/booking-form

[luisherranz]

Looks great, thanks for sharing. Best usage of data-wp-each I've seen so far! 😄

A couple of suggestions:

• I wonder why you need @wordpress/i18n at all?

  Why don't you just put the translated string in the state, similar to what you are doing with the other strings in context, and save the 6.32 kB (gzipped) of i18n?

  Something like this (not tested): djuric/booking-form@db3b4f2

• Also, there are a few actions that, although they work fine, they are technically "derived state".

  Something like this (not tested): djuric/booking-form@92607ff

[djuric]

@luisherranz Thank you very much for the feedback, it's super helpful :)

• This is great! I'm definitely going to remove @wordpress/i18n package entirely and simply translate from state loaded via PHP
• I thought of that initially (and it works nice!) but I had a small concern. I would like to allow this block to be used multiple times on the page, each block having its own local context without any state sharing. If I put these in state, and state is shared across the blocks, is there any danger of eg. get isFirstStep() derived state being incorrect at some point? It's almost as if in my case I should use some sort of "derived context" 😅

Thanks!

[luisherranz]

is there any danger of eg. get isFirstStep() derived state being incorrect at some point? It's almost as if in my case I should use some sort of "derived context"

This is a great question, and I hope to address it in a new guide we are preparing to explain how state, context and derived state work.

The answer to your question is... no. Derived state (created with getters) can access the context and will have the correct value because it is evaluated as a function:

get isFirstStep() {
  const { steps } = getContext();
  return steps[0].isActive;
},

The reason for not exposing some type of "derived context" and only having derived state is that the derived state can access both context and state at the same time.

We thought about adding a context key in the store where you can add getters, but it seemed confusing. First, context is supposed to live in the HTML tree, so being able to set it in the store as a global thing is a bit confusing. Second, you can generate derived state from many sources (global state, context, element attributes, in the future maybe element state or other sources), and combine them. So derived state can derive from global state and context at the same time. The same would happen for derived context. In that scenario, which key would you choose? And why? Isn't it confusing to have multiple keys that do the same? Finally, refactorings and public APIs. When you expose an API, you want it to be stable (even if it's for yourself). If everything is in a single key (state) it helps with that, so people reading from your store don't need to update their code when you refactor your code. For plugins that expose public stores, my suggestion would be to never include any context key in their public APIs, just in case that value needs to be refactored/derived later without doing a breaking change. So even if you want to expose context.someValue, create a getter and expose state.someValue instead.

It's a part of the API that we are not super happy with, but we couldn't find something for global/local/derived state that would make things clearer. Some people suggested renaming context to localState, but we didn't like that much either.

We also thought about using a different name for the "view" to consolidate all the state, like data, but that either creates too much boilerplate (you would need to interface all the non-derived global state and context keys) or too introduce something too magic (data.value would automatically read from state.value or context.value).

So in the end we preferred to keep state as that "view" layer, with optional direct non-derived context access for convenience (context.value)

By the way, in the server, the initial values of non-derived context are defined (in the data-wp-context directives), and both global state and derived state need to be defined manually. So in the server, there are no difference between derived and global state.

[djuric]

@luisherranz Thanks for the great explanation!

It makes a lot of sense to just use state for this purpose, it's the simple and easy to use. As long as the code contained within it just manipulates context (as it is in my case with blocks not having any global state) there won't be any side effects.

I like what the Interactivity API can do so far!

[tuanfront-end]

Is there a way to add React packages? For example https://react-hot-toast.com/
Thank you 🙏

[luisherranz]

Not at the moment, but it's something we want to explore. Actually, using Preact underneath the Interactivity API was partly done to keep this possibility open. However, it is very important to understand that it could only be used for parts of the UI that do not require server-side rendering or PHP filtering. For those, you must use directives.

Here’s an example of how it might work, although it’s also necessary to address the bundling part (aliasing react packages to preact/compat and enqueuing it, maybe changing JSX to Preact's h instead of React's createElement).

[djuric]

I experimented with region-based navigation within a custom Tabs Block 🤘

Repo: https://github.com/djuric/tabs