Interactivity API: Add wp-data-on-window and wp-data-on-document directives
#57931
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cbravobernal
added
[Type] Feature
cbravobernal
commented
Jan 17, 2024
|
Size Change: +395 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
luisherranz
reviewed
Jan 18, 2024
| @@ -8,7 +8,7 @@ import { deepSignal, peek } from 'deepsignal'; | |||
| * Internal dependencies | |||
| */ | |||
| import { createPortal } from './portals'; | |||
| import { useWatch, useInit } from './utils'; | |||
| import { useWatch, useInit, useEffect } from './utils'; | |||
There was a problem hiding this comment.
If you're going to use useEffect from @wordpress/interactivity, you can use useInit instead.
@DAreRodz: or what do we do? Do we keep using useWatch and useInit in the directives? Or do we switch back to hooks that don't have an unnecessary call to withScope? To me, it feels weird to have that double set of the scope.
There was a problem hiding this comment.
If there are cases in which we need useWatch and useInit. It may be worth the cost of that withScope and simplify all the directives with one solution.
There was a problem hiding this comment.
Yeah, I'm still thinking about what approach is better. I would prefer the same hooks for directives and store callbacks, but I agree that double-setting the same scope feels weird. 🤔
Let's consider the DevX.
- If we stay with the same hooks and
evaluate, everything is transparent for the developer (although internally weird things happen). - If we have multiple hook versions, we would have to clarify which one is used in which case. And, if the API is meant to be publicly exposed from
@wordpress/interactivity, we should use different names. E.g.useEffectanduseScopedEffect. And maybe you could have more complex cases where you need to use a scoped hook and callevaluate()inside, leading to the same weirdness as the first option (I haven't thought of any, but who knows). - We can also get rid of the scoped versions and expose a
withScope()function (maybe even forevaluate) so devs explicitly decide when the scope is available.withScope( evaluate )( entry ); useEffect( withScope( () => { // Do something. } );
Any other ideas? 😄
There was a problem hiding this comment.
I'm just talking about our directives.js file.
Replace this:
import { useInit } from "..";
// ...
// data-wp-init--[name]
directive("init", ({ directives: { init }, evaluate }) => {
init.forEach((entry) => {
useInit(() => evaluate(entry));
});
});with this:
import { useEffect } from "preact/hooks";
// ...
// data-wp-init--[name]
directive("init", ({ directives: { init }, evaluate }) => {
init.forEach((entry) => {
useEffect(() => evaluate(entry), []);
});
});Exporting our own useInit, useWatch, useEffect, useMemo… with integrated withScope is fine, we should keep doing that, because people using them in data-wp-run won't use them with evaluate.
packages/e2e-tests/plugins/interactive-blocks/directive-on-document/render.php
Outdated
Show resolved
Hide resolved
packages/e2e-tests/plugins/interactive-blocks/directive-on-window/render.php
Outdated
Show resolved
Hide resolved
cbravobernal
force-pushed
the
feature/add-dom-window-on-directives
branch
from
d855787
to
99e2ed8
Compare
cbravobernal
requested review from
kevin940726,
Mamaduka,
ntwb,
nerrad and
ajitbohra
as code owners
47 tasks
luisherranz
requested changes
Jan 18, 2024
|
Flaky tests detected in c8635c4. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7570845563
|
luisherranz
requested changes
Jan 18, 2024
luisherranz
approved these changes
Jan 18, 2024
|
It seems like the e2e tests are failing though... |
I accidentaly removed one check, that waits for the counter to appear again. Fixed in f9eb31c |
Mamaduka
reviewed
Jan 19, 2024
| await page.keyboard.press( 'ArrowDown' ); | ||
| await expect( counter ).toHaveText( '1' ); | ||
| } ); | ||
| test( 'the event listener is removed when the element is removed', async ( { |
There was a problem hiding this comment.
@c4rl0sbr4v0, this test is flaky it failed 20+ times since PR got merged. Ref: #57983.
luisherranz
added
the
[Feature] Interactivity API
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Add two new directives.
Why?
As commented in the respective discussion.
data-wp-on-windowanddata-wp-on-documentwill be directives widely used to add event listeners.How?
Testing Instructions
E2E tests are included, but feel free to use the new directives!
Testing Instructions for Keyboard
Screenshots or screencast