Interactivity API iteration for WordPress 6.7
- Part of #41236.
In WordPress 6.6, work was done to improve warnings integration with Preact DevTools, as well as adding directives for asynchronous event handlers and support for derived state on the server.
In WordPress 6.7, we will continue working on internal improvements to ensure that the Interactivity API's code is as simple and stable as possible and to make the Interactivity API resilient when used asynchronously (e.g., adding directives or stores after initialization). This will pave the way for performance improvements such as directive code splitting or lazy loading of interactive blocks.
In Core blocks, work will begin on the Gallery block lightbox and the Query block's Instant Search.
Apart from the work for WordPress 6.7, investigations will continue, with the most important being the exploration of how to improve assets management in region-based client-side navigation and experimenting with full-page client-side navigation. However, those will be tracked in its own Tracking Issue.
Work is also continuing to improve the documentation with enhancements in the API Reference and new explanatory guides tracked in the Interactivity API documentation's Tracking Issue.
This is the list of initial tasks, although we will edit this post as we progress and discover other things that we need to do.
Enhancements
- [x] Refactor internal proxy and signals system
- https://github.com/WordPress/gutenberg/pull/62734
- [ ] Refactor types, support generator <-> promise transformations, add tests and fix overloads
- https://github.com/WordPress/gutenberg/pull/64577
- [ ] Refactor internal context proxy
- https://github.com/WordPress/gutenberg/pull/64713
- [ ] Refactor the
deepMergelogic- https://github.com/WordPress/gutenberg/pull/64879
- [ ] Add support for
getServerStateandgetServerContext - [ ] Add
wp_interactivity_get_elementso it can be used in the derived state Closures to inspect the element attributes with$element['attributes'](using$p->get_attributes_with_prefix('')). - [ ] Lazy loading of interactive blocks
- https://github.com/WordPress/gutenberg/pull/58284
Core blocks (optional)
- [ ] Query and Search blocks: Instant Search
- https://github.com/WordPress/gutenberg/issues/63053
- https://github.com/WordPress/gutenberg/pull/63147
- [ ] Gallery block: Lightbox
- https://github.com/WordPress/gutenberg/issues/56310
- https://github.com/WordPress/gutenberg/pull/62906
- [ ] Accordion block
- https://github.com/WordPress/gutenberg/pull/64119
- [ ] Tabs block
- https://github.com/WordPress/gutenberg/pull/63689
Bug fixes
- [x] https://github.com/WordPress/gutenberg/issues/63864
- [x] https://github.com/WordPress/gutenberg/pull/62555
- [x] ~https://github.com/WordPress/gutenberg/issues/60981~
- [x] https://github.com/WordPress/gutenberg/issues/63651
- [x] https://github.com/WordPress/gutenberg/pull/64677
- [ ] https://github.com/WordPress/gutenberg/issues/60455
- [ ] https://github.com/WordPress/gutenberg/issues/63249
- [ ] https://github.com/WordPress/gutenberg/issues/63749
Optional
- [ ] Add tests fro
getElement()attributes- https://github.com/WordPress/gutenberg/pull/63126
- [ ] Official syntax for unique-ids
- https://github.com/WordPress/gutenberg/discussions/62720
- [ ] Review all errors and make them more consistent
- [ ] Allow async directive registration
- https://github.com/WordPress/gutenberg/pull/60670
- [ ] Show directive names in Preact's dev tools
- https://github.com/WordPress/gutenberg/issues/60049
- Slack conversation
- [ ] Keep improving TypeScript support
- https://github.com/WordPress/gutenberg/pull/61695
- [ ] Support for
data-wp-client-only-component - [ ] Support handling
navigate()failure states- https://github.com/WordPress/gutenberg/issues/59856
Can you also consider https://github.com/WordPress/gutenberg/pull/60522?
Can you also consider #60522?
I thought that work was still experimental since it requires using Chrome Canary. But if you think it should be included in WordPress 6.7, sure, we can include it 🙂
I thought that work was still experimental since it requires using Chrome Canary. But if you think it should be included in WordPress 6.7, sure, we can include it 🙂
true, it is still experimental and thus maybe not ready for 6.7!
I'm hoping it lands in stable soon and this is a purely debugging related feature. Mostly I don't want the work to fall off the radar and I thought to some degree experimental features where acceptable in Gutenberg since we can always pull them before merging into core.
Ok, then let's leave it out of the list of things for WordPress 6.7 but let's keep an eye on including it in future versions once the APIs are stable 🙂
experimental features where acceptable in Gutenberg since we can always pull them before merging into core
Sure, if you want to merge it in Gutenberg to test it out, that's totally fine.
Sure, if you want to merge it in Gutenberg to test it out, that's totally fine.
That is indeed exactly what I want to do - in part the goal here is to give the team building the feature (DevTools performance panel extensibility API or "User Timings") feedback about what is useful and what is missing. By testing the feature out in Gutenberg, we can influence how it being built before it lands in stable.
Any chance of getting a data-wp-if directive included? It would be immensely helpful. Happy to attempt a PR if this is in the scope.
<template data-wp-if="context.open">
<div>Contents...</div>
</template>
Yeah, a data-wp-show directive is on the roadmap indeed.
If you're willing to work on it we'd love to help you out. As far as I remember, the work not only requires the client-side directive implementation, but also an extra function similar to this one for the server-side rendering.
But we can discuss the details in a proper issue or in Slack 🙂
Sure! I had left a comment there on the original issue here:
https://github.com/WordPress/gutenberg/discussions/53058#discussioncomment-10119649
It looks like the scope has not been decided yet, so that seems like the first item needed.
Can someone share an update here as to what's been done thus far and where the work stands?
Hey Anne, this is the status of the iteration:
-
Enhancements: We aim to complete all the points listed in enhancements, which have involved a significant and necessary internal refactor of much of the runtime. Additionally, we want to add a couple of new APIs (
getServerStateandgetServerContext). The Lazy loading of interactive blocks is managed by @westonruter, so he should update you on the status. - Core blocks: At this point, I cannot say if any of the blocks being worked on will be completed in time for WordPress 6.7. The frontend part regarding interactivity is either complete or nearly complete for most of them. However, they still might get stuck in the Editor UX.
- Bug fixes: All the important bug fixes have been addressed, and while we will try to complete all the listed ones, the remaining ones are minor.
- Optional: The items listed here will only be completed if there is time left after working on the rest.
Let me know if this is helpful or if you need more information.
@mikachan @madhusudhand, could you give us your estimate on the Gallery, Accordion and Tabs blocks?
Thank you! I want to get this right for the 6.7 roadmap so I'll remove the Core blocks work for now to be safe until/unless I hear differently.
@luisherranz Can you share a little bit about what getServerState and what getServerContext will do?
Sure! Since it's not possible for the initial server state to overwrite the client state because that approach is not compatible with region-based client-side navigation, we need an API for use cases where, after navigating, you want to inspect the initial state or context of the new page.
So those two functions will return the initial state or context that came from the server and they are reactive, so that initial state or context updates every time there is a client-side navigation. People would normally use them in a data-wp-watch. For example:
<div data-wp-watch="callbacks.updateServerContext">...</div>
store('...', {
callbacks: {
updateServerContext() {
const context = getContext();
const serverContext = getServerContext();
// Override some property with the new value that came from the server.
context.overridableProp = serverContext.overridableProp;
},
},
});
That's it! The same for state using getServerState.
@darerodz will open a pull request next week, and we appreciate any feedback and assistance testing this new API, that if everything goes well, would make it into WP 6.7 😄
@mikachan @madhusudhand, could you give us your estimate on the Gallery, Accordion and Tabs blocks?
Gallery block is close to getting merged. It is pending with following feedback
- And moving gallery_id to a shared space - related feedback ✅
- Accessibility concerns with
inertpointed here 🚧
I am looking into the second feedback item. Hopefully it will be resolved this week.
Sweet! I'll add the Gallery block back onto the 6.7 roadmap.
Updates
I've added the following bug fixes to the tracking issue:
- https://github.com/WordPress/gutenberg/pull/65090
- https://github.com/WordPress/gutenberg/pull/65135
The first bug was a regression introduced in https://github.com/WordPress/gutenberg/pull/62734, and it's merged and ready for the next Gutenberg RC. The second one is a missing piece of logic we forgot to include in https://github.com/WordPress/gutenberg/pull/64879. It's ready for review.
The following PR is also ready for review. I've introduced a change that depends on https://github.com/WordPress/gutenberg/pull/65135 being merged; the failing test should pass after that.
- https://github.com/WordPress/gutenberg/pull/64713
As the next step, I have to open a PR for getServerContext() and getServerState(), which is currently WIP.
I've just created a draft for the getServerContext() and getServerState() functions.
- https://github.com/WordPress/gutenberg/pull/65151
I've created a new issue to discuss the getServerState() & getServerContext() APIs: https://github.com/WordPress/gutenberg/issues/65243
@annezazu The current approach we took for gallery block is rendering translations on server (because i18n isn't available as script module), which is observed to be complex and is not a good example/practice for the community.
I think we should punt it to 6.8
Thanks for the update! Agreed. Let’s punt.
https://github.com/WordPress/gutenberg/pull/65151 landed this week and contains a new public API 🎉As it's going to be included in WordPress 6.7, it will need an accompanying dev note (added label) and documentation in the Interactivity API reference.
WordPress 6.7 “Rollins”, which contains all the finished work, was released last week. The work for unfinished but still applicable tasks will continue in the new iteration issue created in the following days.
Work continues in
- https://github.com/WordPress/gutenberg/issues/67276.