Hierarchical Structure Builder
JavaScript library for creating hierarchical structures
I'm working on a JavaScript library called Hierarchical Structure Builder.
The idea came from a very practical problem: I needed to model and populate a database with a flexible hierarchical "category → product" structure, but the more I worked with it, the more limitations I ran into.
In real applications, this kind of structure is rarely simple. It quickly becomes something like:
- multiple levels of nesting
- different sorting rules per level or per catalog
- the need to reuse or duplicate subtrees across different branches
- slightly different hierarchies depending on context (e-commerce views, admin views, etc.)
At some point I realized I wasn’t really building “categories and products” anymore — I was building a general system for hierarchical data management.
So I ended up creating a library that focuses on:
- defining and manipulating hierarchical structures without fixed constraints
- allowing arbitrary nesting depth
- reusing and duplicating subtrees across different hierarchies
- attaching custom rules (like sorting or transformation) at any level
- keeping the structure independent from domain-specific meaning
After that, I also noticed the abstraction goes much further than e-commerce. The same model can represent:
- departments and employees in a company
- writers and their works
- menus, navigation trees, permission systems, and more
In other words, once you remove the domain-specific meaning, it becomes a general-purpose tool for working with hierarchical relationships.
I'm curious how others approach this problem in their projects.
Do you:
- build custom tree logic each time?
- rely on existing libraries?
- or model hierarchical data in a completely different way?
Would love to hear different approaches and patterns people have found scalable.
7 Comments
I like that the project evolved from solving a category hierarchy into solving hierarchical relationships more generally.
That feels like an important shift. The value isn't tied to e-commerce anymore—it's giving developers a reusable abstraction they don't have to reinvent every time a project outgrows a simple tree structure.
Yeah, that shift was the main motivation behind it.
Once you remove the “category/product” framing, you realize how often hierarchical structure problems appear in completely different domains.
For example, I once considered applying a similar model to a document access system for different employee categories. In practice, it turned out that simpler manual checks were preferred in that context.
Interesting.
Your example made me think less about the hierarchy itself and more about what determines whether an abstraction keeps expanding into new domains or naturally reaches its boundary.
I don't think I can explain that line of reasoning properly in a thread without oversimplifying it.
If you're open to it, what's the best email to reach you on?
Thanks! I'd be happy to continue the discussion. Feel free to message me here on Indie Hackers — I think that's the easiest way.
I'd be happy to, but as far as I know Indie Hackers doesn't support direct messages.
Email is usually the easiest way to have a longer back-and-forth without cluttering the thread.
If you're still interested, what's the best email to reach you on?
You can reach me at alexeeff[dot]aalex2017[at]gmail[dot]com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.