Custom Path Separators
LTree paths can use any separator, not just dots
Slash-separated Paths
Separator Configuration
Flexibility
Separator Options
- Dot notation: 1.2.3(default) -treePathSeparator="."
- Slash paths: root/auth/login-treePathSeparator="/"
- Windows paths: C:\Users\Bob-treePathSeparator="\\\\"
- Pipe separated: company|dept|team-treePathSeparator="|"
- Double colon: a::b::c-treePathSeparator="::"
- Arrow notation: root->child->leaf-treePathSeparator="->"
Use Cases
- URL-like structures
- File system paths
- Namespace hierarchies
- Custom business logic
Implementation Note
⚠️ Important: You must set the treePathSeparator property
						on the Tree component when using custom separators! Default is "." (dot).
The separator is used for:
- Calculating node levels automatically
- Finding parent-child relationships
- Determining hasChildren property
- Tree expansion/collapse logic
Automatic Metadata Calculation
Tree automatically calculates level, parentPath, and hasChildren
Minimal Data
What Gets Calculated
Automatic Features
Auto-Calculated Properties
- level: Depth in hierarchy (path segment count)
- parentPath: Path of parent node
- hasChildren: Whether node has child nodes
Benefits
- Reduces data payload size
- Prevents inconsistencies
- Simplifies data preparation
- Always accurate calculations
Performance Note
For large datasets, consider pre-calculating these values on the server to improve client-side performance.
Pre-calculated Metadata
Optimize performance by providing level, parentPath, and hasChildren
Enriched Data
Manual Optimization
Performance Benefits
When to Pre-calculate
- Data already available: When server/database already has these values
- Very large datasets: 15,000+ nodes for noticeable benefit
- Frequent re-renders: When tree re-renders often
- Server-side rendering: For better initial load performance
Database Examples
PostgreSQL with LTree:
SELECT
  id,
  path,
  name,
  nlevel(path) as level,
  subpath(path, 0, -1) as parent_path,
  EXISTS(SELECT 1 FROM table t2
         WHERE t2.path <@ table.path
         AND t2.path != table.path) as has_children
FROM table
ORDER BY path;Performance Impact
Pre-calculation provides minimal performance gain - typically 10-50ms on very large datasets (15k+ nodes). The main benefit is when data is already calculated server-side.
LTree Path Structure
Understanding the hierarchical path system
Path Visualization
Path Examples
LTree Concepts
LTree Benefits
- Efficient queries: Find children/ancestors quickly
- Unlimited depth: No artificial hierarchy limits
- Sorting friendly: Natural lexicographic order
- Database compatible: Works with PostgreSQL LTree
Path Rules
- Use dots to separate levels
- Start numbering from 1
- Keep paths short for performance
- Use consistent numbering scheme
Windows File System Structure
Real Windows paths with backslash separator
Windows File Tree
Debug Info
Data Structure
Implementation
Windows File System Features
- Real paths: Actual Windows file paths
- Backslash separator: treePathSeparator="\\"
- Mixed types: Drives, folders, files
- File metadata: Size, type information
Path Examples
- C:- Drive root
- C:\\Users- System folder
- C:\\Users\\Bob- User folder
- C:\\Users\\Bob\\Documents\\Report.pdf- File
Implementation Notes
- Escape backslashes in JavaScript strings: use \\\\in strings for single\\
- Set treePathSeparator="\\\\"property for backslash separator
- Sort by type (drives, folders, files)
- Handle deep nesting naturally
Data Structure Comparison
Choose the right approach for your use case
Approach Comparison
| Approach | Data Size | Performance | Use Case | 
|---|---|---|---|
| Minimal Data | Smallest | Excellent (< 15k nodes) | Simple trees, most use cases | 
| Pre-calculated | Larger | Always optimal | When available from source | 
| Custom Separators | Variable | Good | URLs, file paths, namespaces | 
| PostgreSQL LTree | Optimized | Excellent | Database-driven applications | 
Performance Analysis
Best Practices
Performance Guidelines
- Auto-calculation: Excellent for < 15k nodes
- Pre-calculated metadata: Always preferred when available from source
- Performance penalty: Only ~10-50ms on very large datasets (15k+ nodes)
- Database queries: Use LTree for complex hierarchies
- Real bottleneck: Usually rendering, not calculation
Migration Path
- Start simple: Use minimal data structure
- Measure if needed: Performance is rarely an issue
- Pre-calculate when available: Use server data if already computed
- Optimize for 15k+ nodes: Only then consider dedicated optimization
Common Patterns
- File browsers: Slash-separated paths
- Organizations: Dot notation with pre-calculation
- Menus: Minimal data with auto-calculation
- Categories: PostgreSQL LTree for complex queries