Creating generic blocks for state control and display?

[TristanvWyk]

Hi Everyone! I recently started making use of the interactivity API as part of a custom theme we are developing. I've loved what it has to offer so far but I've been struggling to maintain a DRY approach to development. I'm fairly new to WordPress and web development in general so it's likely that this issue stems simply from a gap in my own knowledge, but I've scoured the official documentation as well as this and other forums and haven't been able to find a direct solution to my predicament. I'm hoping someone here can shed some insight on what approach I should be taking for something like this.

The Problem:
I haven't found a way to share values across blocks that doesn't require both blocks to be locked into that particular namespace. For example, I recently put together a simple selector block and selector group that allows users to select an option within the group much like a radio button. This is a block I would like to use in various different contexts, such as selecting product variations in woo or having an option from one selection group restrict the options in another.
Locking the store to a single namespace doesn't seem correct as it will need to interact with the state of other stores. In certain instances they are wrapped in an accordion or tab group which also have their own interactivity namespaces, meaning I can't always rely on the parent to implement the functions and such.

I'm having a similar issue with an Incrementor block I made that accepts a minimum and maximum number and allows a user to select a value between those two numbers. The minimum and maximum need to be controlled by values in another store, but the value selected in the block should also be accessible to other stores that might want to make use of it. This is the current case for a custom woo commerce variable product page.

In summary the question is "What is the best approach for creating generic controller blocks that can be interfaced and interface with other store states?" Ideally in a way that is reusable and modular.

Current "Working" Solution:
At the moment, I've implemented the means for these generic elements to accept a callback method from a foreign store that wants to make use of them. The callback will listen for a change in context in the generic block and essentially update the foreign block's store to match and/or adjust any parameters of the Generic block. This implementation gets messy really quickly and feels more like a work around than an actual solution.

Any assistance or advice would be greatly appreciated, Hopefully I'm leaving this in the right place.

[luisherranz]

You can access context or state from other namespaces using:

• state:

  const { state } = store( 'my-plugin', {
    state: {
      get derivedFromOtherStore() {
        // You can access the state of other stores
        const otherStore = store( 'other-plugin' );
        return otherStore.state.something ? 'yes' : 'no';
      },
    actions: {
      someAction() {
        const otherStore = store( 'other-plugin' );
        if ( otherStore.state.something ) {
          // You can also run other store actions
          otherStore.actions.someAction();
        }
      }
    }

• context: same idea, but using getContext

  const { state } = store( 'my-plugin', {
    state: {
      get derivedFromOtherStore() {
        // You can access the context of other namespaces
        const otherContext = getContext( 'other-plugin' );
        return otherContext.something ? 'yes' : 'no';
      },
    actions: {
      someAction() {
        // Or even modify it
        const otherContext = getContext( 'other-plugin' );
        otherContext.something = true;
      }
    }

To load the other stores, you need to load them first. So if you haven't loaded them yet, you'll need to import them.

// Statically
import 'other-store-module-identifier';

// Or dynamically when needed;
    store( 'my-plugin', {
      actions: {
        *someAction() {
          yield import( 'other-store-module-identifier' );
          const otherStore = store( 'other-plugin' );
          if ( otherStore.state.something ) {
            // You can also run other store actions
            otherStore.actions.someAction();
          }
        }
      }

If you export the stores in your modules, then you can also directly import them, without having to use store(...):

// Export the stores
export const { state, actions } = store( 'other-store', {...} );

// Then, import them in the other modules
import { state as otherState, actions as otherActions } from 'other-store-module-identifier';
// or dynamically
const { state, actions } = yield import( 'other-store-module-identifier' );

Let me know if that clarifies things for you or if there's anything that's not clear 🙂

[TristanvWyk]

Thank you, this does give me some new ideas. I'm still not quite sure how to ensure the two components remain decoupled, or at least ensure the generic one does. I would need to override the imported store to adjust values in the local one.

Lets say I have my quantity selector:

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

store("plugin/quantity-selector", {
    actions: {
        increment : () => {
            const context = getContext();
            context.value += context.step;
            //console.log("Quantity increased:", context.value);
        },
        decrement: () => {
            const context = getContext();
            context.value -= context.step;
        },
        onChange: ( event ) => {
            const context = getContext();
            const element = getElement();
            context.value = Math.min(Math.max(event.target.value, context.min), context.max);
        },
    },
});

This implements actions for changing the value stored in its context. I can't use a state value since there may be more than one quantity-selector on a page.

There is also an add-to-cart form wrapper that is suppose to be managing the state of the form. This block wraps the whole form, including the quantity-selector. Ideally, I'd like the form wrapper to handle implementing any methods used for updating or reading the quantity-selector. Based on what you've shown, I can call the context of the quantity-selector in the wrapper like so:

store( 'plugin/add-to-cart-wrapper', {
    state: {  
        get productQuantity() {
            const context = getContext("plugin/quantity-selector");
            return context.value;
        },
   }
   // rest of code

But the quantity-selector's context wouldn't be available since its inside the wrapper?
Like this:

<div class="form-wrapper">
  <div class="other-elements">
    <div class="quantity-selector"></div>
  </div>
</div>

Is there a way to get the context of a specific element other than having that element be the one calling a directive? That way I can use the value of the quantity-selector's context to derive the state of "productQuantity" in the form wrapper and share that value to other blocks in the form like the product-price's "total price" value.
Hopefully my example makes some amount of sense, as I said I'm still fairly new to the world of web dev.

[TristanvWyk]

Wait would it be possible to override the implementation of an imported store?
If I exported the store from the "quantity-selector" and imported it into the "form-wrapper" then redeclared an action for that store, would that allow me to change the way that action/callback/state behaves?
Something like this?

// Code in form wrapper's view.js
import { store, getContext, getElement } from '@wordpress/interactivity';
import { state as quantityState, actions as quantityActions } from 'plugin/quantity-selector-module-identifier';

quantityActions.incriment: {
    const context = getcontext();
    const productContext = getContext('plugin/add-to-cart-wrapper');
    productContext.quantity = context.value;
}

store( 'plugin/add-to-cart-wrapper', {
   // rest of code

I'm not sure what the exact syntax would be, but is that a workable solution?

Also what would the module-identifier be?

[sethrubenstein]

@TristanvWyk I think we have an approach that you might find useful. We globally register a interactiveNamespace attribute that we can then force to a specific block's namespace using render_block_data hook. We then add that to iAPI context and consume it in the store.

So for example, ensuring a facet-template data block enforces it's namespace for form-input-select user interface block.

/**
* Ensure facet-template blocks have the correct target interactivity namespace. 
*
* @hook render_block_data
*
* @param array    $parsed_block The parsed block.
* @param WP_Block $source_block The source block.
* @param WP_Block $parent_block The parent block.
* @return array The modified parsed block.
*/
public function hook_inner_blocks( $parsed_block, $source_block, $parent_block ) {
	if ( 'prc-platform/facet-template' === $parsed_block['blockName'] && ! empty( $parsed_block['innerBlocks'] ) ) {
		foreach ( $parsed_block['innerBlocks'] as $index => $inner_block ) {
			if ( 'prc-block/form-input-select === $inner_block['blockName'] ) {
				$parsed_block['innerBlocks'][ $index ]['attrs']['interactiveNamespace'] = 'prc-platform/facet-template';
			}
		}
	}
	return $parsed_block;
}

In the form-input-select's iAPI store, we look for the interactiveNamespace attribute which we call targetNamespace in context to move values higher up to the containing block https://github.com/pewresearch/prc-block-library/blob/e57724628190ddef952fce5d5e199701a737301b/src/form-input-select/view.js#L161-L230. This allows us to utilize form-input-select in a variety of applications while maintaining a consistent user interface component as a block.

[luisherranz]

But the quantity-selector's context wouldn't be available since its inside the wrapper?

There are many ways to do it. For example, you could move the context to the wrapper. After that, you could call an action from the wrapper itself.

<div
  class="form-wrapper"
  data-wp-interactive="plugin/add-to-cart-wrapper"
  data-wp-context='{ "quantitySelector": "value" }'
>
  <div class="other-elements">
    <div
      class="quantity-selector"
      data-wp-interactive="plugin/quantity-selector"
      data-wp-on--click="plugin/add-to-cart-wrapper::actions.increment"
    ></div>
  </div>
</div>

If you don't want the quantity-selector to be coupled with the namespace of the wrapper, you can use a generic namespace, like plugin/cart-data and plugin/cart-actions for example.

<div
  class="form-wrapper"
  data-wp-interactive="plugin/add-to-cart-wrapper"
  data-wp-context='plugin/cart-data::{ "quantitySelector": "value" }'
>
  <div class="other-elements">
    <div
      class="quantity-selector"
      data-wp-interactive="plugin/quantity-selector"
      data-wp-on--click="plugin/cart-actions::actions.increment"
    ></div>
  </div>
</div>

You can also remove the inner data-wp-interactive directive and let it inherit the one from the wrapper's namespace.

<div
  class="form-wrapper"
  data-wp-interactive="plugin/add-to-cart-wrapper"
  data-wp-context='{ "quantitySelector": "value" }'
>
  <div class="other-elements">
    <div
      class="quantity-selector"
      data-wp-on--click="actions.increment" <!-- This points to add-to-cart-wrapper::actions.increment -->
    ></div>
  </div>
</div>

<div
  class="form-wrapper"
  data-wp-interactive="plugin/another-add-to-cart-wrapper"
  data-wp-context='{ "quantitySelector": "value" }'
>
  <div class="other-elements">
    <div
      class="quantity-selector"
      data-wp-on--click="actions.increment" <!-- This points to another-add-to-cart-wrapper::actions.increment -->
    ></div>
  </div>
</div>

If you have more than one quantity-selector in each wrapper, you can assign them a uniqueId and use a map in the context.

<div
  class="form-wrapper"
  data-wp-interactive="plugin/add-to-cart-wrapper"
  data-wp-context='plugin/cart-data::{ "quantitySelectors": {} }'
>
  <div class="other-elements">
    <div
      class="quantity-selector"
      data-wp-interactive="plugin/quantity-selector"
      data-wp-context='plugin/cart-data::{ "id": "123" }'
      data-wp-on--click="plugin/add-to-cart-wrapper::actions.increment"
    ></div>
  </div>
</div>

store( 'plugin/add-to-cart-wrapper', {
  actions: {
    increment() {
      const { quantitySelectors, id } = getContext( 'plugin/cart-data' );
      const quantitySelector = quantitySelectors[id];
    }
  }
} );

You can also move the quantitySelectors property to the state and save only the ID in the context.

const { state } = store( 'plugin/add-to-cart-wrapper', {
  actions: {
    increment() {
      const { id } = getContext( 'plugin/cart-data' );
      const quantitySelector = state.quantitySelectors[id];
    }
  }
} );

You can also read attribute information, such as the ID from the wrapper, if you know its selector.

<form
  class="form-wrapper"
  data-wp-interactive="plugin/add-to-cart-wrapper"
  data-wp-on--submit="actions.submit"
>
  <div class="other-elements">
    <div
      class="quantity-selector"
      data-quantity-selector-id="123"
    ></div>
  </div>
</form>

const { state } = store( 'plugin/add-to-cart-wrapper', {
  actions: {
    submit() {
      const { ref } = getElement();
      const id = ref.querySelector( '.quantity-selector' ).dataset.quantitySelectorId;
      const quantitySelector = state.quantitySelectors[ id ];
    }
  }
} );

You can also use something like what Seth mentioned here and pass a namespace so that the quantity selector uses it in its actions.

Anyway, the possibilities are almost endless. It all depends on what you want to do, which parts you want to decouple from others, how you want to reuse your code, etc.

[luisherranz]

Wait would it be possible to override the implementation of an imported store?

Yes, but not in the way you've put it, but by calling store again. New calls to store on the same namespace are merged together.

// First module, executed first:
store( 'plugin/add-to-cart-wrapper', {
  actions: {
    increment() {
      // ...
    }
  }
} );

// Second module, executed after first:
store( 'plugin/add-to-cart-wrapper', {
  actions: {
    increment() {
      // new implementation, overrides the first one...
    }
  }
} );

You'd have to make sure that the enqueues are in the correct order in the HTML. A good way to do it would be to import the first module into the second one. To do this, make sure that the first module is a dependency of the second, so that it is added correctly in the import map.

// Second module: it import first module to make sure it is loaded:
import 'first-module-identifier';

store( 'plugin/add-to-cart-wrapper', {
  actions: {
    increment() {
      // new implementation, overrides the first one...
    }
  }
} );