Proposal: Block Collections about blockly-samples HOT 4 OPEN

But, what you propose sounds like indexing of blocks by a tag, so why not just use an object of key -> array of blocks.

An object like {key, [blocks]} is indeed the basic idea. The proposal just adds some utility functions to make things easier.

Using utility functions allows us to save information about where the block is stored to the block. We need to know where the block is stored so that when we dispose of the block we can remove it from all collections. If it gets left in a collection we'll get detached nodes :/

So addBlockToCollection, removeBlockFromCollection, and removeBlockFromAllCollections are just to make it so you don't have to think as much when you dispose of your block.

from blockly-samples.

@BeksOmega How do you feel about moving this to samples?

Rachel and I discussed and we don't think this belongs in core-

1. It's doable as a plugin right now using events
2. The main use case you laid out, procedure blocks, are going to have their own management system thanks to the shared procedures API / procedure maps

from blockly-samples.

I would have use for such collections and see workspace analysis performance as the main benefit. But I'm not sure if it should be part of Blockly or be left to projects to add if needed. Updating collections could be handled outside Blockly by a workspace event listener.

from blockly-samples.

So, wrt to solution 1 above, if you are just iterating through plain old JS objects (ie. not DOM) then it should be perfectly fine performance wise, even when the block count reaches 1k or more. Performance problems usually only surface when DOM (or other non-JS API) interactions are involved.

But, what you propose sounds like indexing of blocks by a tag, so why not just use an object of key -> array of blocks.

from blockly-samples.