[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"example-markdown-content:en:load-tree-from-hierarchical-data":3},{"markdown":4,"isPaidExample":5,"isTruncated":5,"charLimit":6},"# Load a Left-to-Right Tree Directly from Hierarchical Data\n\n## What This Example Builds\n\nThis example renders a small hierarchy as a left-to-right tree with rectangular nodes and orthogonal connectors. The page is mostly a full-height graph canvas with a floating description window above it. Users can inspect the prepared tree, drag or minimize the helper window, open canvas settings, and export an image, but the example does not add example-specific node editing or branch-control logic. Its main point is narrower: the hierarchy is authored as nested `children` arrays instead of a manually flattened node-and-line dataset.\n\n## How the Data Is Organized\n\nThe dataset is declared inline as one `RGJsonData` object with `rootId`, a `nodes` array, and recursive `children` fields under each parent node. The `lines` array is intentionally empty, so the component hands a hierarchical tree shape to relation-graph instead of explicit edge records.\n\nThere is no preprocessing before `setJsonData()`. The example relies on relation-graph to recognize the nested tree and flatten it internally for rendering. In real applications, the same shape can represent organization charts, folder trees, product categories, bill-of-material structures, or approval chains. The description inside the example also states an important tradeoff: when direct tree data is used in this form, each connector is not styled individually inside the input payload.\n\n## How relation-graph Is Used\n\nThe demo uses the standard React provider pattern: `index.tsx` wraps `MyGraph` in `RGProvider`, and `MyGraph.tsx` reads the active graph instance through `RGHooks.useGraphInstance()`. The graph options configure a `tree` layout, set the origin to the left, use `treeNodeGapH = 150` and `treeNodeGapV = 20`, and keep the geometry plain with rectangular nodes, 100-pixel node width, orthogonal connectors, left-right junction points, and right-side expand-holder placement.\n\nThe graph instance API does most of the actual work. After mount, the component calls `setJsonData()` with the inline hierarchy, then `moveToCenter()` and `zoomToFit()` so the first render is already framed correctly. The only extra runtime utilities come from the shared `DraggableWindow` helper. That helper uses `RGHooks.useGraphStore()` to read the current canvas behavior, `graphInstance.setOptions()` to switch wheel and drag modes, and `prepareForImageGeneration()` plus `restoreAfterImageGeneration()` around a `modern-screenshot` capture flow.\n\nThere are no custom node, line, canvas, or viewport slots in this example, and there is no editing workflow. The SCSS file mainly contains empty selector scaffolding, so the final appearance stays close to relation-graph defaults rather than a custom skin.\n\n## Key Interactions\n\nThe first interaction is automatic rather than manual: the tree loads during `useEffect()` and the viewport immediately centers and fits to the content. After that, the graph behaves as a viewer.\n\nThe floating helper window is the main interactive overlay. Its title bar can be dragged, it can be minimized and restored, and its settings panel can change wheel behavior between `scroll`, `zoom`, and `none`, plus canvas drag behavior between `selection`, `move`, and `none`. The same panel can export the current graph as an image. The example does not add node click handlers, post-load expand or collapse rules, inline editing, or custom selection behavior of its own.\n\n## Key Code Fragments\n\nThis options block establishes the left-to-right tree geometry and the default node and line style.\n\n```tsx\nconst graphOptions: RGOptions = {\n    debug: false,\n    layout: {\n        layoutName: 'tree',\n        from: 'left',\n        treeNodeGapH: 150,\n        treeNodeGapV: 20,\n    },\n    defaultExpandHolderPosition: 'right',\n    defaultNodeShape: RGNodeShape.rect,\n    defaultNodeWidth: 100,\n    defaultLineShape: RGLineShape.StandardOrthogonal,\n};\n```\n\nThis inline payload shows the core data-shape pattern: the hierarchy is written directly with nested `children` arrays.\n\n```tsx\nconst myJsonData: RGJsonData = {\n    rootId: 'a',\n    nodes: [\n        {\n            id: 'a', text: 'a', children: [\n                {\n                    id: 'b', text: 'b', children: [\n                        {\n                            id: 'b1', text: 'b1', children: [\n```\n\nThis mount-time sequence hands the hierarchy to relation-graph and immediately fits the initial view.\n\n```tsx\nawait graphInstance.setJsonData(myJsonData);\ngraphInstance.moveToCenter();\ngraphInstance.zoomToFit();\n\nuseEffect(() => {\n    initializeGraph();\n}, []);\n```\n\nThis settings row proves that the floating helper can change live canvas behavior through `setOptions()`.\n\n```tsx\n\u003CSettingRow\n    label=\"Wheel Event:\"\n    options={[\n        { label: 'Scroll', value: 'scroll' },\n        { label: 'Zoom', value: 'zoom' },\n        { label: 'None', value: 'none' },\n    ]}\n    value={wheelMode}\n    onChange={(newValue: string) => { graphInstance.setOptions({ wheelEventAction: newValue }); }}\n/>\n```\n\nThis export flow prepares the graph canvas for capture, renders it with `modern-screenshot`, and then restores graph state.\n\n```tsx\nconst canvasDom = await graphInstance.prepareForImageGeneration();\nlet graphBackgroundColor = graphInstance.getOptions().backgroundColor;\nif (!graphBackgroundColor || graphBackgroundColor === 'transparent') {\n    graphBackgroundColor = '#ffffff';\n}\nconst imageBlob = await domToImageByModernScreenshot(canvasDom, {\n    backgroundColor: graphBackgroundColor\n});\nawait graphInstance.restoreAfterImageGeneration();\n```\n\n## What Makes This Example Distinct\n\nComparison data positions this example as a minimal baseline for direct hierarchical input. Its strongest distinguishing combination is a nested `RGJsonData` payload, an empty `lines` array, a plain left-to-right orthogonal tree, and almost no custom SCSS or slot rendering. The graph-specific logic also stays unusually narrow for a demo that still includes the shared floating utility window: one startup load sequence plus inherited viewer utilities.\n\nCompared with `tree-distance`, this example is about proving the direct hierarchical-input path rather than comparing runtime spacing strategies. Compared with `expand-gradually` and `open-by-level`, it keeps the hierarchy passively visible after initialization instead of layering branch-state logic, click-to-expand behavior, or depth resets on top of a flat nodes-and-lines dataset. Compared with `line-style1`, it removes explicit line records and custom node visuals, which makes it a cleaner starting point when the question is simply whether nested business data can be rendered as a tree without extra transformation first.\n\n## Where Else This Pattern Applies\n\n- Rendering an organization chart directly from a nested API response before introducing custom cards or editing.\n- Showing folder structures, product categories, or bill-of-material trees when the source data is already hierarchical.\n- Validating a left-to-right tree layout early in a project before deciding whether explicit line records are needed for per-edge styling.\n- Building a migration path where a plain hierarchical viewer comes first, and richer node templates or branch interactions are added later.\n",false,500,1782615419531]