Include dynamically generated blocks in toolbox-search

[gonfunko]

Check for duplicates

• [ ] I have searched for similar issues before opening a new one.

Component

toolbox-search

Problem

No response

Request

Right now, the toolbox-search plugin only searches normal, pre-defined blocks. In particular, it does not include the dynamically generated variable and function blocks. It should be updated to do so.

Alternatives considered

No response

Additional context

No response

[admalledd]

I just ran into this, is there any guidance on how this might be achieved besides rewriting basically the entire plugin from scratch?

Our use case is we have "all the normal blocks" you expect, but also a custom category that our users can define their own custom procedures in for our system to use as a code-sharing/reuse mechanism. Currently our users have ~400 or so such custom functions defined.

Effectively, we have a custom block derived from procedures_callreturn, such that it has <mutation> and <comment> nodes. Below is such a reduced example shape of such a block we wish to search/index for:

<block type="or_crb_callreturn">
  <mutation name="CRB_Content_Function">
    <arg name="EID"></arg>
    <arg name="RID"></arg>
  </mutation>
  <comment>Define the ElementID and ReferenceID to Build Phrase</comment>
  <value name="ARG0"></value>
  <value name="ARG1"></value>
</block>

That we want users to be able to search on:

• The procedure name, here `CRB_Content_Function"
• The argument names, here EID and RID
• If at all plausible/possible, to also search within the comment

It is worth mentioning that the workspace-search pluigin does the first two just fine, and while I would like to include comments, but we can save that as a shared enhancement across both plugins.

The key challenge I am facing is that it doesn't seem the current way the toolbox-search plugin works is compatible with dynamic blocks in a few ways:

• it is searching block-types by instancing new blocks and iterating them.
  • Because of being block-type based, it only stores one instance/hit per type, and cannot store/remember/return anything about mutations or shadow/child blocks.
• It is building this search index at toolbox init/load time
  • This is causing issues on "how to even find all the blocks within the toolbox and their actual shapes?" This is perhaps personally the biggest challenge I have, that I cannot find a API-way to get what block-objects the toolbox has. I can get only after the toolbox loads, a list of ToolboxItems, that have a blockSvg node that is purely data, that isn't a block-object I can call .isShadow() on.
  • How could this plugin be changed to load at the end of toolbox-init? Or should we "just" rebuild the search index stuff on every search like workspace-search does, kinda?

[TannerGabriel]

I ran into the same issue today. The toolbox-search plugin now includes shadow/child blocks as well, since it uses full block information instead of just block type (see #2594).

@admalledd Have you made any progress on adding blocks to the search after init?

[admalledd]

1. That PR seems to still be doing a per-block-type index if I read the indexBlocks() function changes correctly. Just that now preserves the original toolbox shape. I am not sure without testing if it preserves mutations and indexes those correctly at all?
2. "Some event" needs to exist/hooked into trigger running the blockSearcher.initBlocks([...BlockInfo]) and friends. I have not spent any time on this, since I have no idea where to start.
3. Note, the toolbox_search.getAvailableBlocks() and initBlockSearcher() should probably be enhanced to a family of APIs with a default handling similar to current. IE:
4. plugin API function to clear the blockSearcher object
5. plugin API function to block(s) as passed in as args to process into blockSearcher cache
6. plugin API function to add existing toolbox (via ToolboxItemInfo or other container? hrm)
7. like other plugins, the "install into workspace" hooking, to let this plugin be a per-workspace thing instead.
8. Said hook provides sane-ish defaults to simply load all either all toolbox items, all blocks defined, or tries to do both, etc. Uses bools/true/false options to let plugin know "which" toolbox change events to listen to to self-update blockSearcher

The challenge with all the above, is difficulty for me knowing where to start, and finding time at $DayJob