require(["esri/linkChart/LinkChartProperties"], (LinkChartProperties) => { /* code goes here */ });
import LinkChartProperties from "@arcgis/core/linkChart/LinkChartProperties.js";
esri/linkChart/LinkChartProperties
Properties that contain source information, layout configurations and other settings for a Link chart.
Constructors
-
Parameterproperties Objectoptional
See the properties for a list of all the properties that may be passed into the constructor.
Property Overview
| Name | Type | Summary | Class |
|---|---|---|---|
The name of the class. | Accessor | ||
Additional settings for chronological and organic link chart layouts. | LinkChartProperties | ||
The link chart layout algorithm used to position entities and relationships on the link chart. | LinkChartProperties | ||
Object that defines instructions on the visualization of nonspatial link chart data. | LinkChartProperties | ||
Url pointing to a resource containing featureSet as PBF reference containing a serialized representation of the internal entity table. | LinkChartProperties |
Property Details
-
layoutSettings
PropertylayoutSettings LayoutSettings |null |undefinedreadonly -
Additional settings for chronological and organic link chart layouts.
-
layoutType
PropertylayoutType Stringreadonly -
The link chart layout algorithm used to position entities and relationships on the link chart. Link chart layouts fall into different categories depending on how they organize entities and relationships in the link chart.
- Chronological layouts arrange entities and relationships using time. Entities with time properties, called event entities, and relationships with time properties, called event relationships, will be arranged on one or multiple timelines in the order that they occurred. The entity type or relationship type must have a time property and the layer must be time enabled for an entity or relationship to be considered an event.
- Organic layouts consider the link chart as if it were a mechanical system. The entities repel each other like two magnets aligned with the same poles facing each other, while they are attracted to each other by the relationships that join entities together. The algorithm iteratively reviews and places entities and evaluates the forces until equilibrium is reached. Settings allow you to customize how entities are placed. These layouts allow you to visualize entities in clusters that emphasize how they are connected.
- Hierarchical layouts attempt to orient the majority of the relationships from the bottom to the top in which the origins for the relationship are positioned at the bottom and destination entities are positioned at the top. The algorithm attempts to limit the number of places in which the lines representing relationships cross each other. Relationships are not allowed between entities at the same level in the link chart.
- Tree layouts arrange entities and their relationships as in nature, where the tree starts from the trunk and all branches move out from that point. In the link chart, the root entity is the starting point, the entities related to the root entity are then lined up in a row next to the root entity, from left to right in this example. Radial layouts are a particular form of tree layout where the root of the tree is placed in the center of a circle and the entities to which it is related are positioned in a circle around the root.The algorithm identifies the entity associated with the smallest network topology index and uses it as the root entity.
Layout Type Layout Category Description basic-grid Basic This layout arranges entities in a regularly spaced lattice pattern, where the size of the grid depends of the number of entities chronological-mono-timeline Chronological This layout arranges all events in a single time line. By default, the direction of time is left to right and events that overlap in time are arranged vertically. chronological-multi-timeline Chronological This layout creates individual time lines for each entity related to an event. Event entities are placed between the time lines. Relationships are drawn between a time line and the connected event entity. Relationships connecting events that have both a start and end time, also called durative events, will have a right angle. The portion along the time line represents the duration of the event. The layout will arrange entities and relationships depending on the type of event. geographic-organic-standard Organic This layout arranges spatial entities geographically using their geometry. Spatial entities in which the entity has a null geometry and nonspatial entities are displayed on the link chart, but their placement and arrangement are determined using the organic-standardlayout. The basemap defined in the WebLinkChart is used by default as a backdrop to provide spatial context.hierarchical-bottom-to-top Hierarchical This layout is arranged similarly to tree layouts. However, an attempt is made to orient the majority of the relationships from the bottom to the top in which the origins for the relationship are positioned at the bottom and destination entities are positioned at the top. The algorithm attempts to limit the number of places in which the lines representing relationships cross each other. In contrast with the tree layouts, relationships are not allowed between entities at the same level in the link chart with this layout. organic-community Organic This layout finds communities, which are groups of entities that are closely related to each other. An organic-standardlayout is then used to arrange the communities. The attraction forces along relationships between entities of different communities are relaxed so that different communities are more spread out.organic-standard Organic This layout considers the link chart as if it were a mechanical system. The entities repel each other like two magnets aligned with the same poles facing each other, while they are attracted to each other by the relationships that join entities together. The algorithm iteratively reviews and places entities and evaluates the forces until equilibrium is reached. This layout allows you to visualize entities in clusters that emphasize how they are connected. radial-node-centric Tree This layout arranges entities and their relationships as in nature, where the tree starts from the trunk and all branches move out from that point. In the link chart, the root entity is the starting point, positioned at the left. The entities related to the root entity are lined up in a row to the right of the root entity, from top to bottom in this example. Any entities related to those items that aren't present in the link chart are added as another row closer to the bottom, and so on. The algorithm identifies the entity associated with the smallest network topology index and uses it as the root entity. tree-right-to-left Tree This layout places the root entity for the tree in the center of a circle. All leaf entities for the tree are positioned around the outer edge of the circle. Entities at each level of hierarchy in the tree are arranged in concentric circles between the root entity and the outer circle. Known Limitation
The layouts that are currently supported are those listed in the table above.
Possible Values:"basic-grid" |"chronological-mono-timeline" |"chronological-multi-timeline" |"geographic-organic-standard" |"hierarchical-bottom-to-top" |"organic-community" |"organic-standard" |"radial-node-centric" |"tree-right-to-left" |"hierarchical-top-to-bottom" |"organic-fusiform" |"organic-leaf-circle" |"tree-top-to-bottom" |"radial-root-centric" |"tree-bottom-to-top" |"tree-left-to-right"
- Default Value:"organic-standard"
-
nonspatialDataDisplay
PropertynonspatialDataDisplay NonspatialDataDisplay |null |undefinedreadonly -
Object that defines instructions on the visualization of nonspatial link chart data. Link charts can contain both spatial and nonspatial records. Spatial records are entities with geometry and relationships that connect two spatial entities (both the relationship origin and destination entities have geometry). Nonspatial records are entities without geometry (even if they are a member of a spatially enabled entity type) and relationships that have at least one endpoint with no geometry.
-
Url pointing to a resource containing featureSet as PBF reference containing a serialized representation of the internal entity table.
Method Overview
| Name | Return Type | Summary | Class |
|---|---|---|---|
Adds one or more handles which are to be tied to the lifecycle of the object. | Accessor | ||
Returns true if a named group of handles exist. | Accessor | ||
Removes a group of handles owned by the object. | Accessor |
Method Details
-
Inherited from Accessor
-
Adds one or more handles which are to be tied to the lifecycle of the object. The handles will be removed when the object is destroyed.
// Manually manage handles const handle = reactiveUtils.when( () => !view.updating, () => { wkidSelect.disabled = false; }, { once: true } ); this.addHandles(handle); // Destroy the object this.destroy();ParametershandleOrHandles WatchHandle|WatchHandle[]Handles marked for removal once the object is destroyed.
groupKey *optionalKey identifying the group to which the handles should be added. All the handles in the group can later be removed with Accessor.removeHandles(). If no key is provided the handles are added to a default group.
-
hasHandles
InheritedMethodhasHandles(groupKey){Boolean}Inherited from Accessor -
Returns true if a named group of handles exist.
ParametergroupKey *optionalA group key.
ReturnsType Description Boolean Returns trueif a named group of handles exist.Example// Remove a named group of handles if they exist. if (obj.hasHandles("watch-view-updates")) { obj.removeHandles("watch-view-updates"); }
-
Inherited from Accessor
-
Removes a group of handles owned by the object.
ParametergroupKey *optionalA group key or an array or collection of group keys to remove.
Exampleobj.removeHandles(); // removes handles from default group obj.removeHandles("handle-group"); obj.removeHandles("other-handle-group");