Discussed in #227
Originally posted by sethrubenstein February 20, 2024
We at Pew Research Center have been early adopters of the new interactivity api in the development of our new blocks-first digital publishing platform. We're approaching the interactivity api systemically, converting wherever possible our front end JavaScript to use the interactivity api and extending a interactiveNamespace attribute to all interactive blocks, allowing editors to create rich interactive apps on the front end by connecting a series of blocks together. The driver of this concept is a suite of primitive form input blocks we have built:
prc-block/form-input-textprc-block/form-input-checkboxprc-block/form-input-radioprc-block/form-input-autocompleteprc-block/form-input-passwordprc-block/form-captcha- And we have added interactive directives to
core/button
All with directives and stores that in most cases point to or store a value in another blocks interactive store via the 'interactiveNamespace` attribute. This concept allowed us to rapidly create dynamic interactive blocks that power:
- 2 different variants of mailchimp forms
- a complete FSE compatible FacetWP facet blocks system, built with core/query enhanced pagination support in mind.
- a FSE compatible user accounts system built with blocks. Login forms, registration forms, reset passwords all powered by this suite of form blocks.
We have a number of other smaller interactive blocks.
What I think is most interesting is this concept of allowing blocks to be dropped into other blocks and allowing the user to effectively select from which parent block it will receive its interactivity. This allows for a systemic approach to the interactivity api, and with it an approach that treats some blocks more like a library of React components which is a powerful use case.
To demonstrate this I would break the concept down a little into two parent blocks that do A and B thing respectively when clicking on a button block inside. I'll go over how to quickly give interactivity to core/button block using filters and the WP_HTML_Tag_Processor. Then I'll go over the basic concepts of having action handlers and callbacks in parent blocks that do different things using the same inner block.
Here are some links to some of these interactive blocks as examples to get an idea of the concept:
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/form-input-text/src/render.php
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/core-button/core-button.php#L156
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/mailchimp-select/src/view.js
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/mailchimp-select/src/view.js
Discussed in #227
Originally posted by sethrubenstein February 20, 2024
We at Pew Research Center have been early adopters of the new interactivity api in the development of our new blocks-first digital publishing platform. We're approaching the interactivity api systemically, converting wherever possible our front end JavaScript to use the interactivity api and extending a
interactiveNamespaceattribute to all interactive blocks, allowing editors to create rich interactive apps on the front end by connecting a series of blocks together. The driver of this concept is a suite of primitive form input blocks we have built:prc-block/form-input-textprc-block/form-input-checkboxprc-block/form-input-radioprc-block/form-input-autocompleteprc-block/form-input-passwordprc-block/form-captchacore/buttonAll with directives and stores that in most cases point to or store a value in another blocks interactive store via the 'interactiveNamespace` attribute. This concept allowed us to rapidly create dynamic interactive blocks that power:
We have a number of other smaller interactive blocks.
What I think is most interesting is this concept of allowing blocks to be dropped into other blocks and allowing the user to effectively select from which parent block it will receive its interactivity. This allows for a systemic approach to the interactivity api, and with it an approach that treats some blocks more like a library of React components which is a powerful use case.
To demonstrate this I would break the concept down a little into two parent blocks that do A and B thing respectively when clicking on a button block inside. I'll go over how to quickly give interactivity to
core/buttonblock using filters and theWP_HTML_Tag_Processor. Then I'll go over the basic concepts of having action handlers and callbacks in parent blocks that do different things using the same inner block.Here are some links to some of these interactive blocks as examples to get an idea of the concept:
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/form-input-text/src/render.php
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/core-button/core-button.php#L156
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/mailchimp-select/src/view.js
https://github.com/pewresearch/prc-block-library/blob/develop/blocks/mailchimp-select/src/view.js