Blocks: Fix BlockEdit hooks not working properly with context

[gziolo]

Description

Addresses the comment shared by @phpbits:

I can't find the changes where the blocks.BlockEdit were disabled on blocks inside the columns. I thought it's this one, would you mind pointing me to the right direction?

I've created this plugin : http://wordpress.org/plugins/block-options/ and the options I've added are not showing on the inner columns anymore. Thanks!

When introducing BlockEditContext the handling of blocks.BlockEdit hook regressed for the nested blocks. It was caused by the fact that most of the filters wrap BlockEdit block with additional logic. This made nested blocks to use the parent context which had isSelected obviously set to false when editing the child block. I'm not sure why it worked for all other blocks, maybe because isSelected was set to true for backward compatibility (I changed to false since we migrated all core blocks). This PR extracts Editblock to apply filters directly to it and leavesBlockEdit` block responsible to handle or contexts.

How has this been tested?

npm run test
Manual tests. Make sure you can see Advanced section for the nested blocks.

Types of changes

Bug fix (non-breaking change which fixes an issue).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[gziolo]

Should default to false since we migrated all core blocks to work with the block edit context.

[noisysocks]

👌 looks good. I don't see any regressions when clicking through the demo post.

[noisysocks]

This comment isn't relevant anymore.

[noisysocks]

@gziolo: This // comment here can be deleted. I see now how 'This comment isn't relevant anymore' can be mistaken as 'Ignore this PR review comment' 😄

edit: Never mind, it's been removed in #6352!

[gziolo]

I started #6352 just after merged this one because I realized this when pushing the button :)

All sorted out, thanks for catching 👍

[noisysocks]

Unrelated, but maybe we should deprecate focus and setFocus more formally, e.g. calling deprecated and removing the functionality in two minor versions.

const componentProps = {
    ...props,
    className,
    get focus() {
        deprecated( ... );
        return isSelected ? {} : false;
    },
    setFocus() {
        deprecated( ... );
    },
};
return <Component { ...componentProps } />;

[youknowriad]

I guess we didn't include those originally because there was no direct alternative. We did several releases since this change, I think we can just remove it on the next release or so.

[gziolo]

I will open a follow-up with those lines removed and scheduled to be included in 2.8 👍

[gziolo]

@phpbits, your issue should be now resolved 😃

[phpbits]

@gziolo Perfect! Waiting for the fixes to be uploaded on the repository :) I'm having issue with building the package locally.