Interactivity API questions

[jonathanbossenger]

On December 14th I ran an intro to the Interactivity API online workshop. During this session, I walked folks through the Interactive Block scaffolded from the Getting Started Guide, as well as ran through some of the directives in the API docs.

Some questions arose that I was not able to answer, and it would be great to be able to feed back these answers to workshop attendees:

1. So after an action is trigged, any binded value is refreshed, just like a render function being called in React?
2. What will happen to interactive blocks if a website vistor has disabled javascript - will they just do nothing, or is there some sort of fallback?
3. Can I bind to events that are not related to DOM elements inside my block? Like, listen to route changes or scroll position?
4. How do we handle communication between two interactive blocks?

For the last two questions, their was also a follow up:

I'm supposing both our questions can be solved by registering events in the init lifecycle. Just was checking if there was some sort of specific implementation on the API for those cases.

[luisherranz]

Great questions! 🙂

So after an action is trigged, any binded value is refreshed, just like a render function being called in React?

Yes. The Interactivity API uses signals internally for state and context. When some part of the state or context changes, the effects and directives that are using that part are run again automatically.

What will happen to interactive blocks if a website vistor has disabled javascript - will they just do nothing, or is there some sort of fallback?

The directives are server-side rendered, so the user will see the correct values for the page. Without JavaScript, those values won't change after the render, of course.

Can I bind to events that are not related to DOM elements inside my block? Like, listen to route changes or scroll position?

Sure. There are no restrictions on what you can do. Unlike AMP, there is no validator or anything like that.

• For route changes, we will likely expose a router store with state.url.
• For scroll position, you can use the DOM APIs.

How do we handle communication between two interactive blocks?

Any block can read or change the state, context, and use actions of any store, (as long as the store is not private).

[mateuswetah]

Sure. There are no restrictions on what you can do. Unlike AMP, there is no validator or anything like that.

• For route changes, we will likely expose a router store with state.url.
• For scroll position, you can use the DOM APIs.

Can't wait to see how this router store will play out :)

Can you elaborate a bit more on the second one, maybe with a dummy example? I'm guessing we should bind a listener to things like widow.onscroll in the init method, but I'm not sure.

[luisherranz]

For now, people are using data-wp-init and attaching the event there.

<div class="wp-my-block" data-wp-init="callbacks.someScrollLogic">...</div>

store("myPlugin", {
  callbacks: {
    someScrollLogic() {
      // Get context if you need to modify it:
      const ctx = getContext();

      // Subscribe to the event
      window.addEventListener("scroll", () => {
        // your scroll logic...
      });
    },
  },
});

You can see an example in this experiment that replaces the vanilla JS logic of TwentyTwentyOne with the Interactivity API.

In that PR, @felixarntz also suggested adding a new directive for that specific use case, like data-wp-on-window--{event}, which would work like this:

<div class="wp-my-block" data-wp-on-window--scroll="callbacks.someScrollLogic">
  ...
</div>

store("myPlugin", {
  callbacks: {
    someScrollLogic() {
      // your scroll logic...
    },
  },
});

[jonathanbossenger]

Thanks @luisherranz

[goodpenguins]

The case of communication between blocks. I'm creating an acf-filter block that provides an acf field value selector in the frontend. It should re-render both selector and related core/query every time the selector changes. Currently I'm doing interactivity via Ajax, passing the render of the core/query after applying the "query_loop_block_query_vars" hook. I would like to know if I can do this with the Interactive API and how ().

Another question. Since I'm using no core blocks inside core/query, I can't use client-side navigation. Is there a way to enable it despite no core blocks?

[luisherranz]

I would like to know if I can do this with the Interactive API and how ().

If you want to use the Interactivity API to replace the inner contents of the Query block with server-generated HTML, you need:

• A structure of URLs that render the different versions. For example, a query string: /some-page/?field=someValue
• Add the directives to the relevant parts of the HTML. You can use the render_block and the WP_HTML_Tag_Processor for this, similar to the Query block ones.
• A JS file that contains the logic triggered by those directives and uses the navigate functions, similar to the Query block one.

This is the initial PR that added enhanced pagination to the Query block. You can inspect it to get a better idea but please note that that PR is using the old store() syntax and refer to the code in trunk for the latest version.

If you experiment with this, make sure to follow this discussion to get updates on breaking changes between Gutenberg versions: Changelog

Since I'm using no core blocks inside core/query, I can't use client-side navigation. Is there a way to enable it despite no core blocks?

We're still thinking about the API to declare compatible blocks: discussion

If you want to experiment before that is available, you can remove the block_core_query_disable_enhanced_pagination filter. But remove it ONLY FOR EXPERIMENTATION, and UNDER YOUR OWN RISK. Don't use it on production sites or in public plugins.

[goodpenguins]

Oh thanks @luisherranz. I really appreciate your help in pushing me to continue experimenting.