JavaScript is required

Quick start

This page is the high-level starting point for relation-graph.

If you are new to the project, the easiest way to understand it is:

  1. Choose the package that matches your platform.
  2. Render a graph container with a clear width and height.
  3. Load graph data.
  4. Register interaction events if needed.
  5. Move on to layout, styling, and instance APIs as your graph grows.

For framework-specific code, use the platform pages linked below.

1. Choose your platform

relation-graph supports several frontend integration styles:

Platform Recommended package / entry Quick start page
Vue 3 @relation-graph/vue Vue3 quick start
Vue 2 @relation-graph/vue2 Vue2 quick start
React @relation-graph/react React quick start
Svelte @relation-graph/svelte Svelte quick start
HTML / Web Components relation-graph-webcomponents HTML / Web Components quick start

If you already know your framework, go directly to that page.

If not, read the rest of this page first to understand the common model.

2. The shared integration model

No matter which platform you use, the overall workflow is very similar:

  • Create a container with an explicit size.
  • Render the graph component inside that container.
  • Prepare node and line data.
  • Load data by either:
    • setJsonData(...) for one-shot graph initialization, or
    • addNodes(...) + addLines(...) for incremental updates.
  • Apply layout and viewport operations such as centering and fit-to-screen.
  • Listen to events such as node click, line click, or editor-related interactions.

The biggest platform difference is not the graph model itself, but how you access the graph instance and reactive state:

  • Vue 3 / React / Svelte use RGProvider + RelationGraph + hooks-style access.
  • Vue 2 uses RGProvider + RelationGraph + graphStoreMixin.
  • HTML / Web Components uses DOM events and the onReady callback to expose the graph instance.

3. A practical startup path

For most new projects, this is the simplest way to get working fast:

Step 1: Start with a small graph

Use a tiny dataset with:

  • 1 root node
  • 2 to 5 child nodes
  • a few basic lines

This helps you validate:

  • package installation
  • rendering
  • event binding
  • layout behavior
  • viewport sizing

Step 2: Use one-shot initialization first

If you are just trying to display a graph, setJsonData(...) is usually the fastest entry point.

It is a good default when:

  • your data arrives as a whole payload
  • you are building a read-only graph view
  • you want to validate layout quickly

Step 3: Switch to incremental APIs when building an editor

If your graph will support:

  • editing
  • dynamic insertion/removal
  • workflow-like operations
  • canvas tools or whiteboard behaviors

then move to granular APIs such as:

  • addNodes(...)
  • addLines(...)
  • update / remove APIs
  • runtime option updates via instance methods

This is usually more stable than repeatedly rebuilding the whole graph.

4. Container size matters

A common source of confusion is that the graph viewport depends on its parent container.

Before debugging layout or zoom behavior, confirm that the graph parent has a real size, for example:

  • full page height
  • fixed pixel height
  • responsive panel height inside a dashboard

If the parent size is unstable or collapses to zero, the graph will not behave as expected.

5. Common data loading patterns

relation-graph usually fits one of these three patterns:

Pattern A: One-shot display

Use setJsonData(...).

Best for:

  • documentation demos
  • detail pages
  • read-only graph views
  • first integration tests

Pattern B: Incremental graph building

Use addNodes(...), addLines(...), and related APIs.

Best for:

  • editors
  • whiteboards
  • workflow designers
  • graph applications with frequent updates

Pattern C: Initial render data

Use initialData where supported by the framework package.

Best for:

  • initial page rendering
  • SSR-friendly flows
  • clean first paint with known graph data

6. Events and runtime control

Once the graph is visible, the next step is usually interaction:

  • node click
  • line click
  • viewport movement
  • editing state
  • selection state

All platform packages expose ways to react to these events, but the exact syntax depends on the framework.

At runtime, you will usually work with a graph instance to do things like:

  • update options
  • load or replace data
  • center the graph
  • zoom to fit
  • create or switch layouts

The platform-specific quick start pages show the exact access pattern for each environment.

7. Which page should you read next?

Use the page that matches your current goal:

8. Recommended first milestone

If you want a realistic first success case, aim for this:

  • render a graph on screen
  • load a small dataset
  • click a node and log its id
  • center and fit the graph
  • confirm the layout works in your framework

After that, move on to:

  • custom node content
  • editing features
  • advanced layout rules
  • larger graph data

That path is usually the fastest way to go from “it installs” to “it works in my application”.