Effect on store of multiple blocks in same plugin

[AlphaZebra]

I am almost certainly missing something obvious, but I'm currently encountering a problem when I take two blocks that I implemented in separate plugins and put them both in a single plugin. In one block, I read a system value (in this case, username) and place it in the store. In the other block, I prefill a form field by placing the field inside a div that has the attribute data-wp-watch="callbacks.prefill". The prefill callback finds the form field by id, then sets the value of the field by accessing the username in the store.

This works as advertised when the two blocks are in separate plugins, but it appears that the callback doesn't happen when both blocks are in the same plugin. I'm not asking a specific code fix question here, but rather wondering if there's anything about the store (including obvious things that I'm too big a dolt to have understood) that would account for this.

Thanks for increasing my store (he he) of store knowledge...

[sirreal]

Will you share some code examples? That would help with debugging and understanding the issue.

[AlphaZebra]

Sure... Let's say I have two blocks, one called prefill and the other called textfield. The idea is that prefill grabs info about the current logged-in user and puts it in the store so that other blocks can use it in various ways. In this case, textfield is going to grab username as the value for an input field.

Both are straight out of the interactive block template. In the case of "prefill", the render.php file is:

<?php

// render.php 

 $current_user = wp_get_current_user();
 $my_login = $current_user->user_login;
 
	wp_interactivity_state('create-block', array( 'username' => $my_login ));
?>

<div data-wp-interactive="create-block">
	<p>Available in state store: <span data-wp-text="state.username"></span></p>

</div>

and the view.js is basically empty:

import { store, getContext } from '@wordpress/interactivity';

store( 'create-block', {
	
} );

For textfield, the render.php file is:

<div data-wp-interactive="create-block">
	<label for="something">Gimme gimme:</label>
	<div data-wp-watch="callbacks.prefill" >

	<input
		type="text"
		id="myInput"
		name="something"
		data-wp-on--change="actions.rename"
		required
	/>
	</div>

</div>

(and I should note that there's probably some far better way to do this. I couldn't find a way to place a store value into the "value" attribute of the tag, so the prefill callback finds the field by its id and just pokes in the value.

Here's what the view.js file looks like:

import { store, getContext } from '@wordpress/interactivity';

const {state} = store( 'create-block', {
	actions: {
		doOnChange: () => {
			const context = getContext();
			console.log( context );
		},
		rename: () => {
			const context = getContext();
			let x = document.getElementById("myInput");
			state.username = x.value;
		},
		
	},
	callbacks: {
		prefill: () => {
			const context = getContext();
			let x = document.getElementById("myInput");
			x.value = state.username;
			console.log( x.value );
			console.log( state );
		},
		
	},
} );

So, as two separate blocks, this works. If I'm logged with the username Robert, that's what shows up in the input field.

If I put them both in a new block, each as a subfolder of src/blocks, the blocks are there just fine and the prefill block notes that the username value stored in state is Robert. But the input field isn't filled in. Console log messages in the prefill callback don't appear in the console, making me wonder if the callback is actually getting called back.

I'm probably missing something obvious here, but any and all help/instruction/clarification is welcome. Obviously, I could leave them as separate blocks (and will for the time being), but ultimately there will be maybe a dozen blocks designed to work with each other and it would be a kindness to any future users, I think, to bundle them up as one plugin.

Thanks in advance...

(As I'm writing this, I'm wondering if I'm running afoul of directly altering the state. That seems like a probable antipattern, even if it does work with separate blocks... )

[sirreal]

I'm confused about the blocks and two separate blocks vs. a single block. There are a lot of moving pieces and a lot of overlapping language. For example, all of these use a single store named "create-block". That's fine, multiple blocks can do that, but there are a lot of places things can go wrong. For example, are both blocks on the page and are their JS viewScriptModule assets downloaded correctly?

Maybe it's best if we back up. Will you describe exactly what the store is expected to do?

Here are a few questions and notes on the code samples that may help:

• It's important to keep in mind that context is local. I see context being read, but I don't see any context directives.
• It also looks like the .value is being set directly on an element. Instead of using the data-wp-watch directive for that, how about using the data-wp-bind--value="state.username" directive on the element.

[AlphaZebra]

Hi -- thanks very much for having a look.

I have no idea why I didn't do this with data-wp-bind--value to begin with. There's a small possibility that I forgot it existed :-)

Doing it that way works both with separate blocks and with blocks combined into one plugin. So, problem solved (though there's a slight nag in the back of my mind because I don't see why my silly approach shouldn't also have worked--but it's not keeping me up).

[As an aside, I'm not really following what you're saying about multiple blocks using the same store... Maybe I'm missing what you're getting at, but I thought that the whole point was that multiple blocks would use state to see common (essentially global) data. No? ]

I also, while poking around, I ran across this discussion suggesting a data-wp-input directive. That would be exactly what I was looking for, I think, as I still need an on--change to move changed data in the input field into the store. Seems like the convo got quiet in July-- I wonder if there's any prospect for this being added.

In any case, I continue to be happy as a clam about iAPI, and thanks for the assist.

[sirreal]

Great! I'm glad it's sorted for you.

The concepts of state and context are quite confusing. If you're interested in a deeper understanding, I'd recommend reading the guide on Understanding global state, local context and derived state.