Blogs Archives - Streamhub.co.uk

In this post, we focus on how the system decides which transformation logic to apply for a given chart type. Two design patterns make this possible: Strategy and Factory. Together, they allow us to select and execute the correct transformation algorithm at runtime without introducing tight coupling or complex conditionals.

Strategy Pattern: Chart-Specific Data Transformations

The Strategy pattern allows us to define a family of algorithms (transformations), encapsulate each one, and make them interchangeable. In our chart module, each chart type has its own transformation strategy responsible for converting raw report data into a format suitable for the rendering library.

Structure

The implementation revolves around a contract interface that defines two key methods:

// Interface defining the strategy contract 
export interface IChartDataTransformer 
{  
  /**  
  * Determines if this transformer supports the given chart type.  
  * Each transformer checks if it can handle the visualization type.  
  */  
  supports(chartType: string): boolean;  
 
  /**  
  * Transforms raw report data into chart-specific format.  
  * Each transformer implements its own transformation algorithm.  
  */  
  transform(reportData: any, chartType?: string, report?: any): any; 
}

Each chart transformer implements this interface:

@Injectable({ providedIn: 'root' })
export class BarChartTransformer implements IChartDataTransformer {
  supports(chartType: string): boolean {
    // Returns true for bar chart type identifiers
  }

  transform(reportData: any): any[] {
    // Analyzes dimensions and metrics
    // Normalizes data structure
    // Applies color mapping
    // Enriches with metadata
    // Returns chart library-compatible format
  }
}

What Each Strategy Handles

Each transformation strategy encapsulates logic specific to a chart type. This includes:

Dimensional Analysis: Understanding how many dimensions and metrics are present, which affects grouping and series construction.
Data Normalisation: Converting the consistent API response into the structure expected by the specific visualisation library (e.g., row-based data for ag-Grid vs. series-based arrays for Highcharts).
Metadata Enrichment: Adding display labels, tooltip formatting, and contextual information derived from report metadata.

_{*Quick note:}_{At first glance, this example may appear to violate the Single Responsibility Principle. However, in practice, the transformer acts as an orchestration layer, delegating specific responsibilities to dedicated services. The example is simplified to keep the focus on the pattern rather than internal service composition.}

Benefits

Each chart type can evolve independently without impacting others.
Adding support for a new chart only requires implementing the interface—no changes to existing code.
Clear separation of concerns between transformation and rendering logic.
High testability: each strategy can be unit-tested in isolation using mock datasets.

Factory Pattern: Selecting the Right Transformer

While strategies encapsulate transformation logic, we still need a mechanism to select the correct strategy at runtime. This is where the Factory pattern comes into play.

The factory acts as a lookup mechanism that returns the appropriate transformer based on the chart type, without consumers needing to know about concrete implementations.

Structure

We use an injection token to collect all chart transformers, and a factory that receives them via dependency injection:

// Injection token for collecting all chart transformers
export const CHART_TRANSFORMERS = new InjectionToken(
  'CHART_TRANSFORMERS'
);

@Injectable({ providedIn: 'root' })
export class ChartDataTransformerFactory {
  constructor(@Inject(CHART_TRANSFORMERS) private transformers: IChartDataTransformer[]) {}

  getTransformer(chartType: string): IChartDataTransformer | null {
    // Searches for transformer where supports() returns true
    // This is the common method enforced by the interface defined earlier.
    return this.transformers.find(t => t.supports(chartType)) || null;
    // Returns null if no transformer found
  }
}

The factory is used by the main chart data transformer (which participates in the pipeline we’ll see in the next post):

@Injectable({ providedIn: 'root' })
export class ChartDataTransformer implements ReportTransformer {
  constructor(private chartFactory: ChartDataTransformerFactory) {}

  isApplicable(reportData: any): boolean {
    // Checks for visualization type presence
  }

  apply(reportData: any): any[] {
    // Gets transformer from factory
    const transformer = this.chartFactory.getTransformer(..);
    if (!transformer) {
      // Throws error if no transformer found
    }
    // Delegates to transformer's transform method
    // Remember, this is part of the contract defined earlier in strategy pattern.
    return transformer.transform(..);
  }
}

How It Fits Together

The factory leverages Angular’s dependency injection to receive all registered transformers via the custom token. It acts as a registry and lookup: it doesn’t create transformers itself—they’re registered elsewhere (we’ll cover that in a future post). The factory is completely decoupled from specific transformer implementations.

When no transformer is found for a given chart type, the system throws a descriptive error rather than returning null. This fail-fast approach ensures bugs are caught early and production errors are clearly identifiable.

Benefits

Decouples transformer selection from usage—consumers don’t need to know which transformer to use
Centralised logic for transformer selection—single point of control
Easy to extend with new chart types—just register a new transformer
Type-safe transformer selection through TypeScript interfaces
Strategies are unaware of each other; the factory is unaware of strategy implementation details

Conclusion

Pairing Strategy with a simple Factory keeps the chart transformation layer flexible and disciplined. Each chart type encapsulates its transformation logic behind a common interface, while the factory selects the appropriate strategy at runtime. This approach creates a fail-fast system that detects misconfigurations early and allows new visualisations to be added without modifying existing code.

Blogs Archives - Streamhub.co.uk

Architecting Scalable Chart Modules in Streamhub Analytics: Part II – Strategy & Factory Patterns

Strategy Pattern: Chart-Specific Data Transformations

Structure

What Each Strategy Handles

Benefits

Factory Pattern: Selecting the Right Transformer

Structure

How It Fits Together

Benefits

Conclusion

Ravindra Soman

Architecting Scalable Chart Modules in Streamhub Analytics: Part I

Problem Space & Design Goals

Technical Context

The Core Mismatch: Same Data, Different Library

Expectations

Why Naive Approaches Break Down

Core Challenges

1. Data Transformation Complexity

2. Extensibility and Maintainability

3. Shared State Interactions

4. Separation of Concerns

From Naive to Scalable: Direction of Evolution

Design Goals and Evaluation Criteria

Architectural Direction (High-Level)

Ravindra Soman

The Next Generation of Cross-Platform Measurement: Global Trends and Challenges

Audience De-duplication

Accurate Audience Targeting

Redefining TV and OTT Inventory

Lack of Standardised Measurement Framework

Need for Multiple Expertise and Knowledge

Industry-Wide Collaboration and Development

Australia – OzTAM

UK – Barb / CFlight

Japan

Life in the FAST lane

The ROI

What Next?

Anurag Gangras

Read more blogs:

The Quest To Unify Measurement: Adding Live + Cloud DVR viewing data

More services = need for better measurement

The Challenges

The market implications

For viewers:

For Ad sales:

For Editorial and Marketing:

How is Streamhub supporting?

Better measurement strategy

Next steps

OTT Measurement: Egta interview with Streamub’s CEO

Read more blogs:

Technical challenges behind Streamhub’s Audience Segment Builder

But, wait … First, what is an audience segment builder?

Simplified and intuitive UX is the key for an audience segment builder

The design of an Audience Segment Builder

Key Angular components

Challenges of marshalling and unmarshalling the query tree

Tony Broyez

Read more blogs:

Testing Library Blog Post

Read more blogs:

New Template for Blog Post – Don’t Duplicate

Related Articles

Stay Up to Date With The Latest News & Updates

Success!

Streamhub grows team and hires for Engineering and Marketing

Read more blogs: