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:
- Choose the package that matches your platform.
- Render a graph container with a clear width and height.
- Load graph data.
- Register interaction events if needed.
- 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, oraddNodes(...)+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
onReadycallback 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:
- I want framework-specific setup:
- I want to understand the graph model:
- I want to control layout and appearance:
- I want to respond to interactions:
- I want lower-level runtime control:
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”.