Only show transforms to blocks that can be inserted on the root block; Order transforms by frecency;

[jorgefilipecosta]

Fixes: #6363
Part of a general polishing to get #6993.
Relates to: #7227

This PR makes sure we can only transform to blocks that can be inserted in the root block.
The transformations are also sorted by frecency (a heuristic used by the inserter) so items transformations should appear in the same order as they appear on the inserter.

Test block: https://gist.github.com/jorgefilipecosta/b958239761a24664685d5efc7ab48fa6
(can be pasted in the browser console)

How has this been tested?

Use a block that sets allowed blocks in the nested area (test block). Verify it is only possible to transform blocks to the allowed blocks (list and quote).
Test both single and multi-block transforms and verify the restriction applies to transforms rendered on the block toolbar and to transforms presented on the side menu.
Verify that if the allowed blocks restriction is applied via PHP filters, the transforms also respect it.
e.g:

add_filter( 'allowed_block_types', function( $allowed_block_types, $post ) {
	if ( $post->post_type === 'post' ) {
	    return $allowed_block_types;
	}
	return [ 'core/paragraph' ];
}, 10, 2 );

Verify the order blocks appear on the transformations list is the same as the order they appear on the inserted.

[jorgefilipecosta]

This PR was rebased, to contain the last changes to the transforms mechanism. It is ready for a look.

[ZebulanStanphill]

Any reason why this has not been merged yet?

[karmatosed]

@ZebulanStanphill right now this is waiting for a code review. Let's get it a milestone and see if we can get some 👀 on this. Thanks for championing it.

[noisysocks]

This is looking good! Love that we're re-using the logic that's already in the selectors. Thanks @jorgefilipecosta.

[noisysocks]

We can make it a little more explicit that this is a reverse sort by using orderBy.

const possibleBlockTransformations = orderBy(
	...,
	( block ) => itemsByName[ block.name ].frecency,
	'desc'
);

[noisysocks]

The inner parens () are no longer necessary here.

if ( ! hasStyles && ! possibleBlockTransformations.length ) {

[noisysocks]

Have you looked into using canInsertBlockType instead of getInserterItems? The latter takes reusable blocks into account which is unnecessary in this case because you can't transform a block into an existing reusable block. It's better that we do as little work as possible to keep the UI feeling responsive.

[jorgefilipecosta]

I have thought about this and it seemed getInserterItems was the best option.
We don't want just to know if a block can be inserted we want to know all the blocks that can be inserted so we can render the UI. We can not do a simple filter using canInsertBlockType inline because that would create a new array reference each time triggering unnecessary rerenders. So the alternative would be to create a new selector that just returns all the allowed blocks without the shared blocks. Besides the available blocks, we also need the frecency ( to sort the items ) and getInserterItems already provides it.
getInserterItems is cached and used in the inserter which is rerendered each time a block changes so I think each time we use the selector here we are just retrieving the value from the cache. If we had a specific selector we would not be able to share the cache.

[noisysocks]

Makes sense 👍 – thanks for explaining!

[noisysocks]

Hell yeah 🤙

[aduth]

Can we add a test case for this, and ideally an inline code comment explaining its purpose?

[aduth]

Do we expect settings to always be non-undefined?

• If yes, we don't need to incur Lodash's extra nullish check on settings.attributes, and instead express this as has( settings.attributes, [ 'align' ] )
• If no, then we have issues below where we assign a new settings.attributes on what we're arguing to be a potentially undefined settings object

[jorgefilipecosta]

Hi @aduth thank you for catching this. This change is in no way related to this PR. I noticed that during the most recent rebase a commit of other branch was added here (I probably missed some command) the commit was removed from here. But I will apply the feedback on the correct place #9338.