Interactivity outside blocks or as "standalone" (like Alpine.js)?

[Niq1982]

Was there any intentions to make Interactivity API work as "standalone", so you could use it just anywhere to build interactivity, like Alpine.js does really beautifully? Or to use it outside blocks? Now you can basically do nothing with it unless you set up a local environment and create&run a build process to get the store set up, which kinda rules out most of non-professionals building sites around the world. If you could create the store with it's functions within the html template, it would be easy not to just create interactivity to new projects, but also build stuff to older, non-block projects as well. Interactivity API could then potentially help to get rid of jQuery, since it would make even easier to build small JS interactions than it is with jQuery.

<div
    x-data="{
        search: '',
 
        items: ['foo', 'bar', 'baz'],
 
        get filteredItems() {
            return this.items.filter(
                i => i.startsWith(this.search)
            )
        }
    }"
>

Other IMO huge limiting issue is not to be able to run code or even set values on data-wp-on directive like <button data-wp-on--click="context.open = ?context.open">. Is there any plans to make this possible in the future?

[michalczaplinski]

Hi @Niq1982 👋

I'm not entirely sure if this is what you meant, but you can easily use Interactivity API "standalone" without even needing WordPress: https://stackblitz.com/edit/vitejs-vite-7kjzrb?file=index.html

You can use the @wordpress/interactivity in the same way as you would use Alpine.js. You could even import it as a JS module from a CDN without installing from NPM.

not to be able to run code or even set values on data-wp-on directive like . Is there any plans to make this possible in the future?

At the moment this is not planned, for a few reasons:

1. There is a potential for security risks with allowing JS expressions to be evaluated in the HTML attributes. It might be possible to define a "safe" subset of JS (like AMP did). This was not a priority for the initial release though.
2. It is preferred that that folks use the tools provided by the framework to accomplish their goals. Allowing arbitrary JS expressions to be evaluated might lead to folks (ab)using it to e.g. imperatively manipulate the DOM. So, by not allowing it it serves as a guardrail to encourages people to use the framework instead of relying on imperative JS APIs that they might already know.
3. And this is related to 2. When opening up the attributes to evaluate arbitrary JS expressions, there is potential for introducing performance regressions if people want to evaluate large expressions and we have to ship an "expression evaluator" to the frontend 🙂 .

[Niq1982]

You can use the @wordpress/interactivity in the same way as you would use Alpine.js. You could even import it as a JS module from a CDN without installing from NPM.

Can you point me to the bundle file in the package (or a bundle package) that should work without running any build processes? Because I wasn't able to find one.

Allowing arbitrary JS expressions to be evaluated might lead to folks (ab)using it to e.g. imperatively manipulate the DOM.

Even if you are allowed only to manipulate the context using the expressions? I completely understand your point on manipulating the DOM, but I don't see how that would be possible, if you limit the possibilities on strictly manipulating the context using only primitive values?

<div data-wp-context='{ "isOpen": false, "isConfirmed":false }'>
  <button type="button" data-wp-on--click="context.isOpen = true">Open<button>
  <!-- I would allow the access to the event in wp-on directive-->
  <dialog data-wp-on--close='context.isConfirmed = event.target.returnValue === "confirmed"' data-wp-bind--open="context.isOpen">
    <form type="dialog">
       <p>You sure?</p>
       <button type="submit" value="confirmed">Yes</button>
       <button type="submit">No</button>
    </form>
</div>
<!-- I also missed the possibility to do simple expressions in wp-text directive as well -->
<p data-wp-text='context.confirmed && "Confirmed"'></p>

Maybe this is just the preact way and I'll get used to it someday. But for now it feels a bit bloaty and overengineerish when you have to build an action for every possible expression. It's like having getters and setters for 20 class properties in PHP when all you do is set or get those properties. Yes, it might be really wise to do that in a large scale system or in a library/plugin that is going to be reused or extended, but in most web dev cases it's just unnecessary noise. 😁

I was really excited to hear about the Interactivity API, since at first I thought it would be something like Alpine.js. It would have been a groundbreaking improvement to enable anyone to write simple interactions straight to html or block templates, without having to run any build processes. I just can't see what's the point now, since there are more versatile and advanced tools available to write interactive front end, if you have to run a build process anyway. 🤷‍♂️

[alessandrotesoro]

Thanks @michalczaplinski however the example you provided doesn't work.

Is there any official documentation in regards to using the package outside of blocks?

Additionally when I tried using the package, via wp-scripts I'm getting:

Uncaught SyntaxError: Unexpected token 'export' (at interactivity.min.js?ver=6.5.2:2:34784)

And this from my js file (containing the exact same code in your example)

Uncaught TypeError: Cannot read properties of undefined (reading 'store')

Enqueuing the script from unpkg as a js module via wp_enqueue_script_module returns:

Uncaught TypeError: Failed to resolve module specifier "preact". Relative references must start with either "/", "./", or "../".

[michalczaplinski]

Apologies. The example was using the module from unpkg which doesn't work for some reason. I presume that this is because unpkg bundles modules themselves and builds them rather than using the built modules from the npm package.

Could you share how you used interactivity with wp-scripts? It should just work out of the box and you shouldn't need to install it from npm as @wordrpress/interactivity has shipped in 6.5.

I'm afraid that there isn't good documentation about using the Interactivity API without blocks at the moment but it's something we're going to work on! In the meantime, I'm happy to help you troubleshoot here 🙂.

[alessandrotesoro]

@michalczaplinski thanks I can see that your example using Vite is now working fine however with wp-scripts, it's not working.

webpack.config.js

const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
const path = require( 'path' );

module.exports = {
	...defaultConfig,
	entry: {
		'wcf-frontend': './assets/js/wcf-frontend.js',
	},
	output: {
		...defaultConfig.output,
		path: path.resolve( process.cwd(), 'assets/build' ),
	},
};

The file wcf-frontend.js has the exact same code as your example.

If I enqueue the asset via wp_enqueue_script_module without letting it go through wp-scripts. It works fine, so something in wp-scripts is causing the issue.

[cbirdsong]

I just can't see what's the point now, since there are more versatile and advanced tools available to write interactive front end, if you have to run a build process anyway

This! If you can't use the interactivity API by just adding it as a dependency on your script, then I'm not sure what the point of using it would be. Much like jQuery, the whole reason to choose it over something like Alpine would be to reuse JS that has already been sent to the client.