Skip to content
Anas Chaabane
Back to work
01Data visualization · Vayetek

Truechart Plus

IBCS-compliant chart engines inside Power BI and Qlik

Role
Lead Full Stack Developer
Period
2026 — Present
Stack
React · TypeScript +4

Designed to streamline data visualization and teamwork, TRUECHART enhances IBCS clarity with real-time commenting, flexible pivoting, and planning features like splashing and scenarios—enabling insight, collaboration, and strategy in one place.

01The problem

Power BI and Qlik both expose an extension API, and both hand you the same hard constraint: your visual runs inside their update loop, on their data model, within their memory budget. A chart that renders comfortably in a standalone React app will stutter — or freeze the entire report — once it has to redraw on every cross-filter, every resize and every selection change.

The clients asking for these visuals are not asking for decoration. They want encodings the stock library cannot express: layered comparisons, custom hierarchies, domain-specific scales, over datasets in the tens of thousands of rows.

02Approach

Every visual is split into three layers. A data layer reshapes the host's data view into a flat, typed structure. A layout layer built on D3 computes scales, stacks and paths, and never touches the DOM. A thin React layer paints exactly what the layout layer produced.

Keeping D3 out of the DOM is the decision that makes the rest work. There is no double bookkeeping between two libraries that both want to own nodes, no orphaned SVG after an update, and the layout layer is testable without a browser.

  • Memoized layout computation keyed on the host's data revision, so a resize never recomputes scales
  • Canvas-backed rendering paths for series past the point where SVG stops being viable
  • A shared token layer so every extension inherits the report theme instead of hardcoding colour
  • Property-pane schemas typed end to end, so a formatting option cannot exist in the UI without a handler

03Leading the work

I lead a team of five-plus developers here: setting the architecture, reviewing every pull request, and clearing whatever is blocking someone before it eats a sprint. Review is where most of the performance work actually happens — the difference between a visual that redraws in 16ms and one that takes 400ms is usually four lines inside a render path.

Alongside that I refactored a legacy React codebase in the same product, cutting unnecessary re-renders by roughly 25% and making the interface measurably quicker to respond.

Outcome
  • Chart components delivered on schedule, with product managers and designers as partners rather than clients
  • 25% fewer re-renders across the refactored legacy React codebase
  • Sprint velocity up after taking on pull-request review and blocker-clearing for the team