RecursiveGroupLayoutData

Specifies custom data for the RecursiveGroupLayout.

Inheritance Hierarchy

RecursiveGroupLayoutData

Examples

The following example shows how to create a new instance of RecursiveGroupLayoutData and use it with an RecursiveGroupLayout:

Creating an instance of RecursiveGroupLayoutData

// Create layout data for both the RecursiveGroupLayout and the layout that's being run
const recursiveGroupLayoutData = new RecursiveGroupLayoutData()
// Use Orthogonal layout for group node contents
recursiveGroupLayoutData.groupNodeLayouts.constant = new OrthogonalLayout()

const organicLayoutData = new OrganicLayoutData()
const orthogonalLayoutData = new OrthogonalLayoutData()
// Configure the other layout data objects ...

// Wrap both into a CompositeLayoutData
const layoutData = new CompositeLayoutData(
  recursiveGroupLayoutData,
  organicLayoutData,
  organicLayoutData
)

// Run the layout - The top-level layout will be done by an OrganicLayout
graphComponent.graph.applyLayout(
  new RecursiveGroupLayout(new OrganicLayout()),
  layoutData
)

In many cases the complete initialization of RecursiveGroupLayoutData can also be done in a single object initializer:

Using an object initializer for easy creation of RecursiveGroupLayoutData

// Create layout data for both the RecursiveGroupLayout and the layout that's being run
const recursiveGroupLayoutData = new RecursiveGroupLayoutData({
  // Use Orthogonal layout for group node contents
  groupNodeLayouts: new OrthogonalLayout()
})

const organicLayoutData = new OrganicLayoutData()
// Configure the organic layout data ...
const orthogonalLayoutData = new OrthogonalLayoutData()
// Configure the orthogonal layout data ...

// Wrap all three into a CompositeLayoutData
const layoutData = new CompositeLayoutData(
  recursiveGroupLayoutData,
  organicLayoutData,
  orthogonalLayoutData
)

// Run the layout - The top-level layout will be done by an OrganicLayout
graphComponent.graph.applyLayout(
  new RecursiveGroupLayout(new OrganicLayout()),
  layoutData
)

Another fairly useful way of using RecursiveGroupLayout is to just do a top-level layout and leave the contents of the group nodes alone. This can be done by using NULL_LAYOUT as the layout algorithm for group nodes:

const layoutData = new RecursiveGroupLayoutData()
layoutData.groupNodeLayouts.constant = RecursiveGroupLayout.NULL_LAYOUT

graphComponent.graph.applyLayout(
  new RecursiveGroupLayout(new OrthogonalLayout()),
  layoutData
)

Type Details

yfiles module: view-layout-bridge
yfiles-umd modules: view-layout-bridge
Legacy UMD name: yfiles.layout.RecursiveGroupLayoutData

Constructors

RecursiveGroupLayoutData

()

Creates a new instance of RecursiveGroupLayoutData which helps configuring RecursiveGroupLayout.

ParametersOptions Overload

options - Object
A map of options to pass to the method.

groupNodeLayouts - ItemMapping<INode,ILayoutAlgorithm>: The mapping from group nodes to the ILayoutAlgorithm used for their child nodes. This option sets the groupNodeLayouts property on the created object.
nodeHalos - ItemMapping<INode,NodeHalo>: The mapping from nodes to their NodeHalo. This option sets the nodeHalos property on the created object.
sourceSplitIds - ItemMapping<IEdge,Object>: A mapping from edges connecting to group nodes to source split ids. This option sets the sourceSplitIds property on the created object.
targetSplitIds - ItemMapping<IEdge,Object>: A mapping from edges connecting to group nodes to target split ids. This option sets the targetSplitIds property on the created object.
sourcePortConstraints - ItemMapping<IEdge,PortConstraint>: A mapping from edges to their source PortConstraint. This option sets the sourcePortConstraints property on the created object.
targetPortConstraints - ItemMapping<IEdge,PortConstraint>: A mapping from edges to their target PortConstraint. This option sets the targetPortConstraints property on the created object.
sourcePortCandidates - ItemMapping<IEdge,ICollection<PortCandidate>>: A mapping from edges to a collection of their source port candidates. This option sets the sourcePortCandidates property on the created object.
targetPortCandidates - ItemMapping<IEdge,ICollection<PortCandidate>>: A mapping from edges to a collection of their target port candidates. This option sets the targetPortCandidates property on the created object.
nodePortCandidateSets - ItemMapping<INode,PortCandidateSet>: A mapping from nodes to their PortCandidateSet. This option sets the nodePortCandidateSets property on the created object.
abortHandler - AbortHandler: The AbortHandler used during the layout. This option sets the abortHandler property on the created object.
partitionGridData - PartitionGridData: The partition grid layout data. This option sets the partitionGridData property on the created object.
groupNodePartitionGrids - ItemMapping<INode,PartitionGridData>: A mapping from group nodes to the PartitionGridData used for their content. This option sets the groupNodePartitionGrids property on the created object.

Properties

abortHandler

: AbortHandler

Gets or sets the AbortHandler used during the layout.

Remarks

An AbortHandler can be used to gracefully stop or cancel a running layout and offers options for automatically doing so after a predetermined time.

An AbortHandler configured or set here overrides the one on LayoutExecutor.

Examples

The most common use case would be to just configure the AbortHandler here, e.g. to set timeouts for a graceful stop or canceling the running layout:

layoutData.abortHandler.stopDuration = TimeSpan.fromSeconds(10)
layoutData.abortHandler.cancelDuration = TimeSpan.fromSeconds(30)layoutData.abortHandler!.stopDuration = TimeSpan.fromSeconds(10)
layoutData.abortHandler!.cancelDuration = TimeSpan.fromSeconds(30)

If there's already an AbortHandler instance that's pre-configured or will be used in a different place to, e.g., cancel the layout when the user presses a button, you can also set one explicitly:

layoutData.abortHandler = abortHandler

groupNodeLayouts

: ItemMapping<INode,ILayoutAlgorithm>

Gets or sets the mapping from group nodes to the ILayoutAlgorithm used for their child nodes.

Remarks

The specified layout is applied to the content of the group node. To arrange the top level elements the core layout algorithm is used.

The core layout is also applied to group nodes if there are no groupNodeLayouts defined at all. Importantly, this must be distinguished from the case that the mapping is defined but null is mapped with a group. Then, RecursiveGroupLayout handles this group node non-recursively. The group node and its content is arranged using the ILayoutAlgorithm instance specified for the nearest ancestor of the group node which is associated with a layout algorithm.

Examples

The layout algorithms for individual group nodes can be specified in various ways, depending on which option is the most convenient. The easiest way would be to set the same layout algorithm for all group nodes:

Using the same layout algorithm for all group nodes

layoutData.groupNodeLayouts.constant = new OrthogonalLayout()

For scenarios where only some group nodes should have a specific layout algorithm the mapper is usually the best option. However, due to RecursiveGroupLayout's handling of individual group node layout's as described above, this can be a bit complicated to specify since the IMapper<K,V> by default returns null.

So when only the mapped group nodes should have a layout algorithm applied to their contents a new Mapper<K,V> would have to be created:

const mapper = new Mapper()
mapper.defaultValue = RecursiveGroupLayout.NULL_LAYOUT
mapper.set(groupNode1, new OrthogonalLayout())
mapper.set(groupNode2, new HierarchicLayout())
layoutData.groupNodeLayouts = mapperconst mapper = new Mapper<INode, ILayoutAlgorithm>()
mapper.defaultValue = RecursiveGroupLayout.NULL_LAYOUT
mapper.set(groupNode1, new OrthogonalLayout())
mapper.set(groupNode2, new HierarchicLayout())
layoutData.groupNodeLayouts = mapper

In cases where all group node's contents should be laid out, most of them with the coreLayout and only some customized, the predefined IMapper<K,V> can be used as is:

layoutData.groupNodeLayouts.mapper.set(groupNode1, new OrthogonalLayout())
layoutData.groupNodeLayouts.mapper.set(groupNode2, new HierarchicLayout())

If the desired layout algorithm for a group node can be readily inferred from the node itself, the delegate is usually the easiest to use:

Specifying custom layout algorithms for group node contents with a delegate

// Determine the layout for the group node from a property in the Tag object
layoutData.groupNodeLayouts = (groupNode) => {
  switch (groupNode.tag.layoutStyle) {
    case 'hierarchic':
      return new HierarchicLayout()
    case 'organic':
      return new OrganicLayout()
    case 'orthogonal':
      return new OrthogonalLayout()
    case 'none':
    default:
      return RecursiveGroupLayout.NULL_LAYOUT
  }
}// Determine the layout for the group node from a property in the Tag object
layoutData.groupNodeLayouts = (groupNode: INode): ILayoutAlgorithm => {
  switch (groupNode.tag.layoutStyle) {
    case 'hierarchic':
      return new HierarchicLayout()
    case 'organic':
      return new OrganicLayout()
    case 'orthogonal':
      return new OrthogonalLayout()
    case 'none':
    default:
      return RecursiveGroupLayout.NULL_LAYOUT
  }
}

groupNodePartitionGrids

: ItemMapping<INode,PartitionGridData>

Gets or set a mapping from group nodes to the PartitionGridData used for their content.

Remarks

Each recursively handled group node can get its own local PartitionGrid. The grid is then valid for the child nodes of the group and only visible for the layout algorithm that is responsible for the group's content. Thus, to properly consider the grid it is required that the responsible algorithm supports the partition grid structure.

In addition to the local partition grids it is also allowed to have a global grid which can be defined by using partitionGridData.

nodeHalos

: ItemMapping<INode,NodeHalo>

Gets or sets the mapping from nodes to their NodeHalo.

Remarks

NodeHalos allow to reserve space around nodes.

Examples

The easiest option is to reserve the same space around all nodes, by setting a constant NodeHalo:

Using constant space around all nodes

layoutData.nodeHalos.constant = NodeHalo.create(20)

Handling only certain nodes differently can be done easily by using the mapper property:

Using a mapper to set halos for certain nodes

// node1 only reserves space above and below
layoutData.nodeHalos.mapper.set(node1, NodeHalo.create(20, 0, 0, 10))
// node2 has space all around
layoutData.nodeHalos.mapper.set(node2, NodeHalo.create(25))
// all other nodes don't get extra space

In cases where the NodeHalo for each node can be determined by looking at the node itself it's often easier to just set a delegate instead of preparing a mapper:

Using a delegate to determine halos for all nodes

// Retrieve the space around the node from its Tag property
layoutData.nodeHalos = (node) => NodeHalo.create(parseFloat(node.tag))// Retrieve the space around the node from its Tag property
layoutData.nodeHalos = (node: INode): NodeHalo =>
  NodeHalo.create(parseFloat(node.tag))

nodePortCandidateSets

: ItemMapping<INode,PortCandidateSet>

Gets or sets a mapping from nodes to their PortCandidateSet.

Examples

The simplest way to define node port candidate sets is to use the same PortCandidateSet for all nodes, if suitable for the use case:

Defining the same port candidates for all nodes

// All nodes get only a candidate for the lower (South) side with capacity 10
const constantPortCandidates = new PortCandidateSet()
constantPortCandidates.add(
  PortCandidate.createCandidate(PortDirections.SOUTH, 10)
)
layoutData.nodePortCandidateSets.constant = constantPortCandidates

The same effect can be achieved with a delegate as well, however, a more useful way to use a delegate would be to decide whether a node should get a port candidate set based on some data at the node, e.g., found in its tag:

Defining port candidate sets with a delegate

// Create a PortCandidateSet with capacity 2 for the upper side (North) and capacity 1 for the lower side (South)
const pcs = new PortCandidateSet()
pcs.add(PortCandidate.createCandidate(PortDirections.NORTH), 2)
pcs.add(PortCandidate.createCandidate(PortDirections.SOUTH), 1)
// Specify the node port candidates for diamond nodes, i.e. for nodes with the string "diamond" in their tag
layoutData.nodePortCandidateSets = (node) =>
  node.tag === 'diamond' ? pcs : null// Create a PortCandidateSet with capacity 2 for the upper side (North) and capacity 1 for the lower side (South)
const pcs = new PortCandidateSet()
pcs.add(PortCandidate.createCandidate(PortDirections.NORTH), 2)
pcs.add(PortCandidate.createCandidate(PortDirections.SOUTH), 1)
// Specify the node port candidates for diamond nodes, i.e. for nodes with the string "diamond" in their tag
layoutData.nodePortCandidateSets = (node) =>
  node.tag === 'diamond' ? pcs : null!

If specific nodes should get a certain PortCandidateSet, it may sometimes be easier to use the mapper to set them:

Defining port candidate sets with a mapper

// Create a PortCandidateSet with capacity 2 for the upper side (North) and capacity 1 for the lower side (South)
const pcs1 = new PortCandidateSet()
pcs1.add(PortCandidate.createCandidate(PortDirections.NORTH), 2)
pcs1.add(PortCandidate.createCandidate(PortDirections.SOUTH), 1)
// Create another set with candidates for the left (West) and right side (East)
const pcs2 = new PortCandidateSet()
pcs2.add(PortCandidate.createCandidate(PortDirections.EAST), 4)
pcs2.add(PortCandidate.createCandidate(PortDirections.WEST), 4)
// Specify the port candidate sets for two specific nodes
layoutData.nodePortCandidateSets.mapper.set(node1, pcs1)
layoutData.nodePortCandidateSets.mapper.set(node2, pcs2)

partitionGridData

: PartitionGridData

Gets or sets the partition grid layout data.

Remarks

This property defines the top-level global partition grid. To define a local partition grid for each recursively handled group node use groupNodePartitionGrids. A top-level grid should only be registered if the layout algorithm responsible for the top-level hierarchy i.e. the core layout algorithm supports a PartitionGrid.

Note that if you use LayoutExecutor's configureTableLayout feature this property should not be used as it overrides the PartitionGrid set by TableLayoutConfigurator.

sourcePortCandidates

: ItemMapping<IEdge,ICollection<PortCandidate>>

Gets or sets a mapping from edges to a collection of their source port candidates.

Remarks

Port constraints allow to define where an edge can connect to its source node and allow fine control over port placement.

If all that is needed is to fix the source port in its location or on a node side, port constraints are easier to work with, since they are a slightly simpler concept.

Examples

Source port candidates are effectively a collection of possible port placements with different costs and the layout algorithm is free to choose the candidate that fits best into the overall layout, while also preferring candidates with a lower cost. To set the same candidate list for all edges, it's easiest to use the constant property:

Setting the same set of source port candidates for all edges

layoutData.sourcePortCandidates.constant = new List([
  // Prefer the center position and route the edge downwards if possible (no cost for this candidate)
  PortCandidate.createCandidate(0, 0, PortDirections.SOUTH),
  // Alternatively, use any position at the bottom border of the node, but with a higher cost
  PortCandidate.createCandidate(PortDirections.SOUTH, 1),
  // If that fails, use either the left or the right side
  PortCandidate.createCandidate(PortDirections.WEST, 2),
  PortCandidate.createCandidate(PortDirections.EAST, 2)
])

If certain edges need specific port candidates, it's usually convenient to use the mapper property:

Setting different source port candidates for certain edges

// edge1 should leave the source node preferably on the node side in flow direction,
// but can also use a fixed port location on the left of the node.
layoutData.sourcePortCandidates.mapper.set(
  edge1,
  new List([
    PortCandidate.createCandidate(PortDirections.WITH_THE_FLOW),
    PortCandidate.createCandidate(-0.5, 0.25, PortDirections.WEST, 1)
  ])
)

// edge2 should leave the source node anywhere on the upper side of the node
layoutData.sourcePortCandidates.mapper.set(
  edge2,
  new List([PortCandidate.createCandidate(PortDirections.NORTH)])
)

For cases when the desired configuration of port candidates can be readily created from the edge itself, the delegate is often the most convenient option:

Setting different source port candidates for each edge with a delegate

// Assuming a flowchart, the "yes" edge should leave the decision in flow direction,
// and the "no" edge may leave either left or right of the flow direction.
// This also ensures that the layout still looks natural if the layout uses different orientations.
layoutData.sourcePortCandidates = (edge) => {
  // Only handle decision nodes here
  if (edge.sourceNode.tag instanceof FlowChartDecision) {
    switch (edge.labels.get(0).text) {
      case 'Yes':
        return new List([
          PortCandidate.createCandidate(PortDirections.WITH_THE_FLOW)
        ])
      case 'No':
        return new List([
          PortCandidate.createCandidate(PortDirections.LEFT_IN_FLOW),
          PortCandidate.createCandidate(PortDirections.RIGHT_IN_FLOW)
        ])
    }
  }
  return null
}// Assuming a flowchart, the "yes" edge should leave the decision in flow direction,
// and the "no" edge may leave either left or right of the flow direction.
// This also ensures that the layout still looks natural if the layout uses different orientations.
layoutData.sourcePortCandidates = (
  edge: IEdge
): ICollection<PortCandidate> => {
  // Only handle decision nodes here
  if (edge.sourceNode!.tag instanceof FlowChartDecision) {
    switch (edge.labels.get(0).text) {
      case 'Yes':
        return new List([
          PortCandidate.createCandidate(PortDirections.WITH_THE_FLOW)
        ])
      case 'No':
        return new List([
          PortCandidate.createCandidate(PortDirections.LEFT_IN_FLOW),
          PortCandidate.createCandidate(PortDirections.RIGHT_IN_FLOW)
        ])
    }
  }
  return null!
}

Sample Graphs

sourcePortConstraints

: ItemMapping<IEdge,PortConstraint>

Gets or sets a mapping from edges to their source PortConstraint.

Remarks

Port constraints allow to define where an edge attaches to its source node and can either restrict that to one of the node's sides, or to a fixed port position.

A more general concept which allows finer control over where ports are placed, are port candidates.

Examples

If all edges should exit their source node on the same side, you can simply set a constant constraint for all edges:

Setting the same port constraint for all edges

// All source ports should be on the bottom side
layoutData.sourcePortConstraints.constant = PortConstraint.create(
  PortSide.SOUTH
)

To change the constraints for individual edges, it's usually easiest to use the mapper:

Using a mapper to set different port constraints for certain edges

// edge1 should leave the source node on the left side, while keeping its exact port position (strong port constraint)
layoutData.sourcePortConstraints.mapper.set(
  edge1,
  PortConstraint.create(PortSide.WEST, true)
)
// edge2 should leave the source node downwards, but the port may be placed anywhere along that node border
layoutData.sourcePortConstraints.mapper.set(
  edge2,
  PortConstraint.create(PortSide.SOUTH)
)

If a PortConstraint can readily be created from an edge, using a delegate is often easier:

Using a delegate to set a different port constraint for each edge

// Source ports will be placed on the right side and use a property in the edge's tag
// to determine whether ports will stay fixed at their position.
layoutData.sourcePortConstraints = (edge) =>
  PortConstraint.create(PortSide.EAST, edge.tag.fixPorts)// Source ports will be placed on the right side and use a property in the edge's tag
// to determine whether ports will stay fixed at their position.
layoutData.sourcePortConstraints = (edge: IEdge): PortConstraint =>
  PortConstraint.create(PortSide.EAST, edge.tag.fixPorts)

Sample Graphs

sourceSplitIds

: ItemMapping<IEdge,any>

Gets or sets a mapping from edges connecting to group nodes to source split ids.

Remarks

Edges will be aligned with edges that connect to the same group node and have the same split id at their source (preferably) or target.

targetPortCandidates

: ItemMapping<IEdge,ICollection<PortCandidate>>

Gets or sets a mapping from edges to a collection of their target port candidates.

Remarks

Port constraints allow to define where an edge can connect to its target node and allow fine control over port placement.

If all that is needed is to fix the target port in its location or on a node side, port constraints are easier to work with, since they are a slightly simpler concept.

Examples

Target port candidates are effectively a collection of possible port placements with different costs and the layout algorithm is free to choose the candidate that fits best into the overall layout, while also preferring candidates with a lower cost. To set the same candidate list for all edges, it's easiest to use the constant property:

Setting the same set of target port candidates for all edges

layoutData.targetPortCandidates.constant = new List([
  // Prefer the center position and enter the node from the top if possible (no cost for this candidate)
  PortCandidate.createCandidate(0, 0, PortDirections.NORTH),
  // Alternatively, use any position at the top border of the node, but with a higher cost
  PortCandidate.createCandidate(PortDirections.NORTH, 1),
  // If that fails, use either the left or the right side
  PortCandidate.createCandidate(PortDirections.WEST, 2),
  PortCandidate.createCandidate(PortDirections.EAST, 2)
])

If certain edges need specific port candidates, it's usually convenient to use the mapper property:

Setting different target port candidates for certain edges

// edge1 should enter the target node preferably on the node side in flow direction,
// but can also use a fixed port location on the left of the node.
layoutData.targetPortCandidates.mapper.set(
  edge1,
  new List([
    PortCandidate.createCandidate(PortDirections.WITH_THE_FLOW),
    PortCandidate.createCandidate(-0.5, -0.25, PortDirections.WEST, 1)
  ])
)

// edge2 should enter the target node anywhere on the bottom side of the node
layoutData.targetPortCandidates.mapper.set(
  edge2,
  new List([PortCandidate.createCandidate(PortDirections.SOUTH)])
)

For cases when the desired configuration of port candidates can be readily created from the edge itself, the delegate is often the most convenient option:

Setting different target port candidates for each edge with a delegate

// Assuming a flowchart, edges connecting to a terminal on the target side should enter that node either
// in flow direction (preferred) or from one of the sides.
// This also ensures that the layout still looks natural if the layout uses different orientations.
layoutData.targetPortCandidates = (edge) => {
  // Only handle terminal nodes here
  if (edge.targetNode.tag instanceof FlowChartTerminal) {
    return new List([
      PortCandidate.createCandidate(PortDirections.WITH_THE_FLOW),
      PortCandidate.createCandidate(PortDirections.RIGHT_IN_FLOW, 1),
      PortCandidate.createCandidate(PortDirections.LEFT_IN_FLOW, 1)
    ])
  }
  return null
}// Assuming a flowchart, edges connecting to a terminal on the target side should enter that node either
// in flow direction (preferred) or from one of the sides.
// This also ensures that the layout still looks natural if the layout uses different orientations.
layoutData.targetPortCandidates = (
  edge: IEdge
): ICollection<PortCandidate> => {
  // Only handle terminal nodes here
  if (edge.targetNode!.tag instanceof FlowChartTerminal) {
    return new List([
      PortCandidate.createCandidate(PortDirections.WITH_THE_FLOW),
      PortCandidate.createCandidate(PortDirections.RIGHT_IN_FLOW, 1),
      PortCandidate.createCandidate(PortDirections.LEFT_IN_FLOW, 1)
    ])
  }
  return null!
}

Sample Graphs

targetPortConstraints

: ItemMapping<IEdge,PortConstraint>

Gets or sets a mapping from edges to their target PortConstraint.

Remarks

Port constraints allow to define where an edge attaches to its target node and can either restrict that to one of the node's sides, or to a fixed port position.

A more general concept which allows finer control over where ports are placed, are port candidates.

Examples

If all edges should exit their source node on the same side, you can simply set a constant constraint for all edges:

Setting the same port constraint for all edges

// All target ports should be on the top side
layoutData.targetPortConstraints.constant = PortConstraint.create(
  PortSide.NORTH
)

To change the constraints for individual edges, it's usually easiest to use the mapper:

Using a mapper to set different port constraints for certain edges

// edge1 should enter the target node on the right side, while keeping its exact port position (strong port
// constraint)
layoutData.targetPortConstraints.mapper.set(
  edge1,
  PortConstraint.create(PortSide.EAST, true)
)
// edge2 should enter the target node from the top, but the port may be placed anywhere along that node border
layoutData.targetPortConstraints.mapper.set(
  edge2,
  PortConstraint.create(PortSide.NORTH)
)

If a PortConstraint can readily be created from an edge, using a delegate is often easier:

Using a delegate to set a different port constraint for each edge

// Target ports will be placed on the right side and use a property in the edge's tag
// to determine whether ports will stay fixed at their position.
layoutData.targetPortConstraints = (edge) =>
  PortConstraint.create(PortSide.EAST, edge.tag.fixPorts)// Target ports will be placed on the right side and use a property in the edge's tag
// to determine whether ports will stay fixed at their position.
layoutData.targetPortConstraints = (edge: IEdge): PortConstraint =>
  PortConstraint.create(PortSide.EAST, edge.tag.fixPorts)

Sample Graphs

targetSplitIds

: ItemMapping<IEdge,any>

Gets or sets a mapping from edges connecting to group nodes to target split ids.

Remarks

Edges will be aligned with edges that connect to the same group node and have the same split id at their source or target (preferably).

Methods

combineWith

(data: LayoutData…) : LayoutData

Combines this instance with the given layout data.

Remarks

This keeps the current instance unmodified and instead returns a new instance that dynamically combines the contents of all involved instances.

Parameters

options - Object
A map of options to pass to the method.

data - LayoutData: The LayoutData to combine this instance with.

Returns

↪LayoutData: The combined layout data.

Defined in

LayoutData

RecursiveGroupLayoutData

Examples

Type Details

Constructors

RecursiveGroupLayoutData

ParametersOptions Overload

Properties

abortHandler

Remarks

Examples

See Also

groupNodeLayouts

Remarks

Examples

See Also

groupNodePartitionGrids

Remarks

nodeHalos

Remarks

Examples

See Also

nodePortCandidateSets

Examples

See Also

partitionGridData

Remarks

sourcePortCandidates

Remarks

Examples

See Also

Sample Graphs

sourcePortConstraints

Remarks

Examples

See Also

Sample Graphs

sourceSplitIds

Remarks

See Also

targetPortCandidates

Remarks

Examples

See Also

Sample Graphs

targetPortConstraints

Remarks

Examples

See Also

Sample Graphs

targetSplitIds

Remarks

See Also

Methods

combineWith

Remarks

Parameters

Returns

See Also

Defined in