Create API to restrict a block to be nested inside another.

[NeilFraser]

The break/continue block disables itself unless it is inside one of the loop blocks. The if-return block disables itself unless it is inside one of the procedure definition blocks. Local variable get/set blocks might disable themselves unless they are within a scope block.

We need an API so that a block can (at minimum) specify a list of block types which they must be inside of. This is not currently possible with connection type checking.

It's also possible that the API could be waaay more flexible: allowing for direct vs nested connection checking, having a list of specific blocks rather than block types, or disabling if the block is in a named block type, and so on. But beware of adding a bunch of extra unrequested features that get used by virtually nobody and that constantly break.

[BeksOmega]

I think this could be done using a custom connection checker. I know I discussed this with @mark-friedman somewhere when he was building his lexical scope plugin, but I couldn't find the issue/forum thread for the life of me :/

[mark-friedman]

I also have a sense that @BeksOmega and I discussed some connection checker stuff. Unfortunately, I'm afraid that I also don't remember (and can't find) the thread.

[SuperJumpBros]

I like this idea. I want to add a "go to x,y" feature to my blockly editor, while being inside a "run as sprite" block. This would add a lot of helpful tools to developers for restricting access of blocks. Please consider adding this idea at some point in the future.

[truongductri01]

@BeksOmega Is this still an ongoing discussion or have you figure out a way to deal with it? I am interested in this issue if you could help assign it to me.

[mark-friedman]

FWIW, I wrote this in a reply to a post in the Blockly group last year:
If the OP really did, for whatever reasons, want to dynamically prevent block connections they could presumably use a custom connection checker (probably by overriding the doDragChecks method) and control that checker dynamically. They could add methods to their custom connection checker class to add blocks that they want to protect and to turn the protection on and off (either for all blocks or for individual blocks, as desired).

Also note that there is some discussion between @BeksOmega and I about connection checking in PR #4798, where we go into the weeds a bit in discussing scoping in Blockly and other programming languages. That might even be the discussion that Beka and I were trying to recall above.

[BeksOmega]

@BeksOmega Is this still an ongoing discussion or have you figure out a way to deal with it? I am interested in this issue if you could help assign it to me.

I passed this back to the triage team to see if this is something we want to work on! But even if it is it'd need to go through a few rounds of design before it's ready to be worked on. So I've assigned you to something else in the mean time!

[maribethb]

If this is possible to do with a connection checker, then that would be our preferred solution instead of making the block definition more complicated. If you would like this behavior, please try implementing a custom connection checker, and if you run into roadblocks with that that make it seem impossible, please reopen this issue and explain why. Thanks!