[refactor/change] Avoid duplicated NetJSONGraph class name
⚠️ warning: not suited for new contributors.
At the moment we have two classes with the same exact name: NetJSONGraph.
This is very confusing and makes the code harder to read. It would be great to clarify the difference between these two classes, find a better name for both and/or simplify the code if possible.
Hey! I’ve been reviewing the code and noticed that two different classes are named NetJSONGraph, which makes it hard to distinguish their roles. One acts as the main entry point (handling UI, config, events), and the other handles core logic like parsing and rendering. To improve clarity, maybe we could rename them to something like NetJSONGraphMain and NetJSONGraphCore. Happy to help refactor if needed!
Hey! I’ve been reviewing the code and noticed that two different classes are named
NetJSONGraph, which makes it hard to distinguish their roles. One acts as the main entry point (handling UI, config, events), and the other handles core logic like parsing and rendering. To improve clarity, maybe we could rename them to something likeNetJSONGraphMainandNetJSONGraphCore. Happy to help refactor if needed!
Hi @Ayaan005-sudo, thank you for your interest in contributing to this project. However, I must point out that this is not a good first issue to get started for contributing.
There's not much conceptual difference between NetJSONGraphMain and NetJSONGraphCore, it's still ambiguous to me.
Hi @nemesifier,
I understand this might not be marked as a good first issue, but I’ve spent time studying both NetJSONGraph classes and I’d like to help clarify their roles — especially since the naming makes it hard to distinguish their responsibilities.
I’m still a beginner, but I’ve gone through the code in detail and here’s what I’ve understood:
NetJSONGraph in netjsongraph.js — Entry Point / UI Controller
This class acts as the main orchestrator. It sets up configuration, GUI, rendering utilities, and delegates core logic to NetJSONGraphCore. Key responsibilities:
-
constructor(JSONParam, config):- Instantiates
NetJSONGraphCoreviathis.graph = new NetJSONGraphCore(JSONParam) - This means all parsing and rendering logic is handled by the core class.
- Initializes config via
initializeConfig() - Sets config on core graph
- Calls
setupGraph()andinitializeECharts() - Returns the core graph instance
- Instantiates
-
initializeConfig(config):- Sets up rendering mode (
mapRenderorgraphRender) - Binds lifecycle hooks (
onInit,onRender, etc.)
- Sets up rendering mode (
-
setupGraph():- Sets prototype of
NetJSONGraphRenderto core utils - Initializes GUI (
NetJSONGraphGUI) - Sets rendering utilities and event system
- Sets prototype of
-
initializeECharts():- Initializes ECharts engine with canvas or SVG renderer
-
Lifecycle Hooks:
onInit,onRender,onUpdate,afterUpdate,onLoad- These manage loading states, GUI setup, metadata rendering, and mode switching (map ↔ graph)
This class is focused on UI orchestration, config management, and rendering setup, while delegating actual graph logic to the core.
NetJSONGraphCore in netjsongraph.core.js — Core Logic Layer
This class handles the actual graph logic, including:
- Parsing NetJSON/GeoJSON data
- Setting up force-directed layouts
- Drawing nodes and links
- Managing simulation ticks
- Providing accessors like
getNodeById,getLinkById - Handling rendering via
draw(),drawNodes(),drawLinks(),tick()
It’s the engine behind the graph — responsible for transforming data into visuals.
Suggestion
Earlier I had suggested names like NetJSONGraphMain and NetJSONGraphCore, but after digging deeper into their roles, I think something like NetJSONGraphUI (for the entry point) and NetJSONGraphCore or GraphEngine (for the logic layer) might be even clearer. Happy to go with whichever naming convention the team prefers — just wanted to share what I’ve learned.
Thanks!
@Ayaan005-sudo I insist that this is not a good first issue to get started with contributing. Leave this to more experienced contributors.