Interactivity API should have a method to access root context when using wp-each directive

[sethrubenstein]

What I'm proposing is a new function in the api, getRootContext. This would return the context of the current elements root element, so one interactive element up.

Take this example of using wp-each directive:

<ul data-wp-context='{ "uniqueUrlSlug": "xyz", "list": [ "hello", "hola", "olá" ] }'>
  <template data-wp-each="context.list" >
    <li data-wp-text="context.item">
      <button data-wp--click="actions.onClick">Go to item</button>
    </li>
  </template>
</ul>

And consider this view.js

/**
 * WordPress Dependencies
 */
import { store, getContext, getElement } from '@wordpress/interactivity';

const { state, actions } = store('my-namespace/my-block', {
  actions: {
    onClick: () => {
      const context = getContext();
      // Create a new url using context from my room element, uniqueUrlSlug
      // When we examine context, it does not contain uniqueUrlSlug because the context is now local to the template `context.item` so only the list items would appear in context. 
    }
  }
});

What if there was a getRootContext function, that would return the context of the root element? This would be useful for more than just in wp-each, I could see myself using this to get the content of the interactive namespace one element up, and so on (without getting too ridiculous). This would allow a little more broader use of context vs global state. Ideally you would also be able to set the root element's context as well not just read.

[gziolo]

Out of curiosity, what’s the reason you can’t access context.uniqueUrlSlug from your example included? Why would data-wp-each change anything with how the context works? Before introducing a new API method that is going to cause confusion when used outside of data-wp-each, it would be good to revisit whether the current limitation can be removed and the way context works potentially unified across all child HTML elements.

[sirreal]

Merging the contexts (each and whatever other context is present) is exactly what I'd expect. It's surprising to me that isn't the case now, if I'm understanding correctly.

[DAreRodz]

👋 As explained in Working with local context, part of the Interactivity API's Core Concepts guide:

Local contexts can be nested, with child contexts inheriting and potentially overriding values from parent contexts.

The data-wp-each directive effectively acts like data-wp-context, creating a new context that, in this case, also includes a new property (item) with the specific list item. That means properties from parent contexts should be inherited.

---

The code snippet below is based on the opening post example. I tested it and seems to work as expected. 🙂

It can be easily tested by pasting its content into a Custom HTML block in a page/post/template with interactive blocks (so the Interactivity API is enqueued automatically).

I've made a couple of changes, like adding the data-wp-interactive directive with the appropriate namespace and moving the data-wp-text directive to a <span> element, in order not to overwrite the <li> content and get rid of the <button> element.

<ul
  data-wp-interactive="my-namespace/my-block"
  data-wp-context='{ "uniqueUrlSlug": "xyz", "list": [ "hello", "hola", "olá" ] }'
>
  <template data-wp-each="context.list" >
    <li>
      <span data-wp-text="context.item"></span>
      <button data-wp-on--click="actions.onClick">Go to item</button>
    </li>
  </template>
</ul>

<script type="module">
import { store, getContext, getElement } from '@wordpress/interactivity';

const { state, actions } = store('my-namespace/my-block', {
  actions: {
    onClick: () => {
      const context = getContext();
      console.log(`${context.uniqueUrlSlug}/${context.item}`);
    }
  }
});
</script>

[DAreRodz]

@sethrubenstein, regarding the code example you mention in #65770 (reply in thread), could it be that the browser dev tools do not show the inherited properties even though they exist?

The inheritance mechanism works with proxies. As you can see in the image below, the context object only contains choice, but the expanded, value, and choices properties are accessible too. 🙂

[sethrubenstein]

@DAreRodz That is exactly it. All this time and I didn't think I could access the root values because the console wasn't showing them 🤦‍♂️. Just tested this and I can access and set these values.

[sirreal]

Debugging the proxied values is tricky. I often use that spread trick.

It would be good to document this behavior at least. Are there things we could do to make it easier to work with?