Frontend Polish, Backend Foundations

Every project reaches a turning point. For SwitchMap, it’s moving from refining the frontend to laying the groundwork for a smarter, more capable backend.

Tooltip DOM Cleanup

When you attach HTML elements (rather than plain strings) to node.title or edge.title in vis-network, the library will insert them into the DOM for tooltips.
If you rebuild the graph (e.g., switching datasets or zones) without cleaning them up, these elements can remain in memory even if the graph is destroyed—leading to memory leaks over time.

Problem:
On each re-render, the previous tooltip DOM elements weren’t being removed. Even though the graph was rebuilt, old tooltips stayed in memory because they were still referenced in the DOM.

Fix:
Before rendering a new graph, explicitly remove any existing tooltip elements:

initialGraph.current?.nodes?.forEach((node) => {
  if (node.title instanceof HTMLElement && typeof node.title.remove === "function") {
    node.title.remove();
  }
});

Why it works:

• node.title and edge.title can hold HTMLElement objects if you pass them in.

• Even after the vis-network instance is destroyed, these elements might persist in memory.

• Calling .remove() ensures they are detached from the DOM and eligible for garbage collection.

General tip:
If you’re using vis-network with HTML tooltips, always clean them up before:

• Destroying a network instance (network.destroy()), or

• Rebuilding with a new dataset.

This small step can prevent slow performance and memory bloat during heavy graph interactions.

Improved Device Status Logic

Determining whether a device is “up” or “down” using SNMP data isn’t always straightforward. A common indicator is the device’s sysUptime—how long it has been running since the last reboot. However, simply checking if sysUptime exists and is positive isn’t enough to guarantee the device is currently online. Stale data from an old SNMP poll can cause misleading “up” statuses.

To improve accuracy, I updated the logic to mark a device as 🟢 (up) only if sysUptime is a valid number greater than zero:

<div style={{ fontSize: "2em" }}>
  {typeof device.sysUptime === "number" && device.sysUptime > 0 ? "🟢" : "🔴"}
</div>

While this stricter check reduces false positives, it doesn’t yet consider how recently the device was polled. A future improvement will be to factor in the timestamp of the last successful SNMP poll to ensure the data is fresh enough to trust or to display the last polled date and time in the UI. This will give users better context about device availability and enhance overall dashboard transparency.

Working with Temporary Repositories: Bringing Feature Work Back

Sometimes, you need to develop features in a temporary or separate repository—due to environment issues, experimental work, or other constraints. Later, you want to bring those changes into your main project repository.

Here’s a general approach to fetch and merge code from a temporary repo branch into your own repo:

1. Add the temporary repo as a remote:

remote add temp-repo <temporary-repo-url>

2. Fetch branches from the temp repo:

git fetch temp-repo

3. Check out the feature branch locally:

git checkout -b <branch-name> temp-repo/<branch-name>

4. Merge or rebase as needed into your main branch.

This method lets you easily integrate work done elsewhere, preserving your commit history and enabling manual conflict resolution.

In my case, after bringing the changes in, I manually compared files with the main SwitchMap repo to retain useful comments and minor logic tweaks before finalizing the merge.

Device Details Chart Component

On the Device Overview tab:

• Embedded the existing Topology component, scoped to the selected device, to show nearby connections.

• Displayed key metadata in a table.

• Added three charts — Uptime, CPU Usage, and Memory Usage — using a reusable chart component.

For now, these charts use mock data to allow UI development while backend support is still in progress. The component is future-proofed to work with any metric by simply changing props.

---

History Page Enhancements

I built a history page to visualize whether a device has been moved within the network over time:

• Fetched devices nested under zones via GraphQL, then flattened them client-side to associate each device with its zone.

• Auto-selected the first device on load.

• Added step line charts for SysName history and Zone history.

• Implemented search with autocomplete for device hostnames.

• Improved responsiveness and handled “no data” cases gracefully.

  

Backend Work in Progress

I began exploring how to add new OIDs for CPU and memory metrics in the poller, and this work is still in progress. Over the coming weeks, I’ll focus on several key backend improvements:

• Enhancing the poller to collect device-level time-series metrics.

• Adding a dedicated database table to store historical metric data.

• Updating the GraphQL schema to support storing and querying these metrics.

• Creating new API endpoints to serve data dynamically for frontend charts.

These backend foundations will turn the current mock-data charts into fully functional, real-time visualizations of device performance.