Wp-calypso: FSE Plugin: How might we track Block Pattern Insertion

[ianstewart]

When someone adds a Block Pattern to their post or page …

… how might we track Block Pattern Insertion to measure success of particular patterns?

cc @obenland @iamtakashi @alaczek @boonerang @davemart-in

[davemart-in]

@mtias should this be done in core, or just on WP.com?

[mtias]

Core wouldn't do any tracking. At most it might provide hooks if there's no way for plugins to interact with patterns.

[ianstewart]

@obenland you looked into adding an hook or filter, correct? Are there other ideas we might try?

[obenland]

I thought about adding a pattern-specific redux action that we could subscribe to, but I realize that could be a hard sell.

[ramonjd]

So where is the most appropriate place to track this stuff? And it is expected that we track on wp-admin as well?

As far as I can tell we're tracking insertions on WordPress.com here: https://github.com/Automattic/wp-calypso/blob/4537033c6794449ce0a10b69d72daf5fa658d553/apps/wpcom-block-editor/src/wpcom/features/tracking.js#L119

We could try to base things off that for now.

Or is there a hook that folks think we can use if we add it to FSE?

[obenland]

The place you linked to is the most appropriate IMO.

The last time I looked there wasn't a good way to track patterns. The only way was to grep its (translated) name out of a notification. Not sure if that has changed since.

[ramonjd]

A relevant Slack thread p1593597130479300-slack-CRNF6A9DX

[ramonjd]

@roo2 is taking a 👀

🙇

[roo2]

hmmm I can see a few options for tracking this:
IMHO I think it's best if we can add a new event to gutenberg that is only used for tracking block pattern insertions.

Block pattern insertion events

hmmm so here's the code in gutenberg that triggers the events that we can listen to.
https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/components/inserter/hooks/use-patterns-state.js#L35
It takes the blocks that make up the block pattern and raises acore/block-editor:insertBlock event with the individual blocks passed in as an array. Unfortunately, block patterns don't pass on any distinguishing characteristics such as the block pattern name, only the individual blocks that make up the pattern 🤔.

Listening to the existing createSuccessNotice event

As @obenland mentioned, a translated notification is also raised that includes the block name __('Pattern %s inserted'), pattern.title

hmm it would be possible to listen to core/notices:createSuccessNotice and grep for block pattern names (which we can get from core/block-editor:settings.__experimentalBlockPatterns)

            const { __experimentalBlockPatterns } = registry.select( 'core/block-editor' ).getSettings();
            const blockPatternNames =  __experimentalBlockPatterns?.map( ( pattern ) => pattern.name );

Actually inserting a Block Pattern block

One way to allow for tracking block patterns is to change the way block patterns are inserted.
Currently, if you insert the "Two columns of text" block pattern, the isnertBlock event is called with:

[
  { 
    name: 'core/columns',
    innerBlocks: [ {
      name: 'core/column',
      ...
    }, {
      name: 'core/column'
      ...
    } ]
    ...
   }
]

But we could change it to actually insert a "Two columns" block, similar to inserting a reusable block.

{
  name: 'a8c/two-columns-with-text',
  type: 'block-pattern'
  innerBlocks: [ {
     name: 'core/columns'
     innerBlocks: { ... }
  } ]
}

This would allow us to intercept calls to insertBlocks and track insertions for blocks with a type of block-pattern with a different event https://github.com/Automattic/wp-calypso/blob/4537033c6794449ce0a10b69d72daf5fa658d553/apps/wpcom-block-editor/src/wpcom/features/tracking.js#L119

The a8c/two-columns-with-text block would then be added to the editor, similar to how a reusable block works

Another way is to raise a new redux event

We could add a redux event to the gutenberg inserter just for tracking purposes e.g.

core/block-editor:insertBlockPattern

this would not trigger any actual state changes in the editor but could be intercepted for tracking

Which approach is best:

I think it's best to add a new redux event to gutenberg, this way is quite safe while still easy to understand and unlikely to break in the future. what do you think @obenland?

[ramonjd]

Thanks for looking into this @roo2 ! Which would be easier/more maintainable from your perspective?

I can see a few options for tracking this

Do folks have a preference for one suggestion or another?

I could be wrong, but relying on output from createSuccessNotice seems like it'd be setting us up for future bug fixing when the notice texts change or are translated differently.

[roo2]

hmmmm I think that raising a new redux event just for block patterns is the best compromise, It doesn't require any functional changes to the editor so is quite safe and also it's relatively straightforward to understand and clean. I'm just looking at what's a good store and event name now.

The other approaches are a bit extreme, listening for the successNotice doesn't require core changes but is really quite hacky/fragile. And changing the way block patterns are represented in the editor seems a bit risky in terms of potentially unknown complexity or bugs.

[roo2]

Raised this issue in Gutenberg to kick of discussion about adding a new hook

https://github.com/WordPress/gutenberg/issues/23812

[talldan]

As mentioned in comments, (https://github.com/WordPress/gutenberg/issues/23812#issuecomment-657801080, https://github.com/Automattic/wp-calypso/issues/40614#issuecomment-606760459) code wouldn't be added to core just for the sake of tracking.

I think the goal is possible already using a store subscription to the block editor store and listening for changes to a selector like getBlockOrder. That selector will return a value that only changes when the blocks are inserted, removed or re-ordered. The client ids returned by that selector are unique, so you should be able to determine which blocks are new, and then look up details for those inserted blocks using another selector.

Not straightforward, but it's a way forward.

[apeatling]

@talldan This would still be at the individual block level. I'm not sure how you would be able to determine if these blocks compromise an actual block pattern?

[apeatling]

This has been addressed with https://github.com/WordPress/gutenberg/pull/25165. The pattern data is now available so can be used however third parties see fit.