Working SubGraphExpanderButton in Palette

GoJS
#1

I’m utilizing a palette to dynamically load nodes (from a master data model) that are related to whatever is selection by the user in my main diagram. I have a working solution that inflates nodes within the palette based on user selection - but I quickly ran into an organizational problem. I have too many nodes for the user to choose from. They need organization.

The nodes in the palette are logically grouped based on what type of relation they have to the selected node. Example: if the selected node represents a Process, my palette pulls in information related to the process via relation types such as “owner”, “inputs”, “outputs”, etc.

The UX I was designing toward was going to utilize GoJS Groups to containerize the related nodes by which relation type they were. So, the palette would contain a collapsed group called “inputs” and another one called “outputs”, etc, that the user could then expand, and pull from. I can create these groups… however I realized I cannot create a working “SubGraphExpanderButton” in the Palette.

Playing around with the “Macros.html” example, I realized I am able to pull the full group onto my diagram, at which point the SubGraphExpanderButton does properly function.

I am starting to assume this is impossible - given the samples such as the BPMN editor and the https://gojs.net/latest/samples/planogram.html sample both utilize external libraries to achieve this same sort of effect.

My question is - is it possible to expand or collapse Groups inside the palette?

#2

By default Palette.isReadOnly is true, and that is what prevents users from making changes to the nodes of that diagram. You could set that to false and set a bunch of other properties so that the palette allows the behaviors that you want and not the behaviors you don’t want to allow.
https://gojs.net/latest/intro/permissions.html

        $(go.Palette, . . .,
          {
            isReadOnly: false,
            isModelReadOnly: true,
            allowDelete: false,
            allowGroup: false,  // not needed if there's no CommandHandler.archetypeGroupData
            allowInsert: false,
            allowLink: false,  // not needed if all ports are not linkable
            allowMove: false,
            allowRelink: false,  // not needed if there are no Links
            allowReshape: false,  // not needed if the nodes are not reshapable
            allowResize: false,  // not needed if the nodes are not resizable
            allowRotate: false,  // not needed if the nodes are not rotatable
            allowTextEdit: false,  // not needed if all TextBlocks are not editable
            allowUngroup: false,  // not needed if no Groups are ungroupable
            . . .

You probably don’t need to set all of those allow... properties, depending on the nature of the node and group templates that you use in the Palette.

Another possibility is to replace the palette’s model each time you want to show a different subset of nodes.

Another possibility is to use multiple Palettes: https://gojs.net/latest/samples/planogram.html

#3

In my case, I didn’t want to utilize the Planogram-style solution, as there are ~20 or so types of relations already and likely to be more added in the future. The replacing technique I hadn’t thought to extend down to the individual types of relations, which is silly because it seems obvious after you pointed it out.

Setting “isReadOnly: False,” will work quite well for my case, I believe. The Palette already uses different Node & Group Templates, and whatever changes they might make in it wont’ be propagated back to the data model behind the scenes. At worst, they’ll just make their view of the palette wrong, which will be corrected next time they select whatever node they currently have selected.

As always, thank you Walter.