Echarts in Angular

Varad Shirsath — Sun, 21 Dec 2025 05:48:25 +0000

ECharts and Angular Integration Guide

Hey👋- Hope you're having an awesome day!

So, we are going to discuss how to use the echarts in angular and how to achieve the proper tree-shaking through imports. We can either directly use the echarts library or we can use the ngx-echarts wrapper.

When to use ECharts Directly vs. ngx-echarts Wrapper

Direct ECharts Usage (No Wrapper)

Pros:

Full control over initialization and lifecycle
No abstraction layer overhead
Direct access to all ECharts APIs

Cons:

Manual resize handling required
More boilerplate code
You handle memory cleanup directly

ngx-echarts Wrapper

Pros:

Handles Angular lifecycle automatically
Built-in resize observer
Less boilerplate
Better integration with Angular patterns

Cons:

Additional abstraction layer
Less control over specific scenarios
Dependencies on wrapper updates

Recommendation: Use direct ECharts for custom dashboards requiring fine-grained control; use ngx-echarts for standard applications.

Proper Imports and Tree-Shaking

❌ INCORRECT (Includes Everything)

import * as echarts from 'echarts';  // Bundle: ~700-900 KB

This imports the entire ECharts library regardless of what you use, resulting in massive bundle sizes.

✅ CORRECT (Tree-Shakable)

import * as echarts from 'echarts/core';
import { BarChart, LineChart } from 'echarts/charts';
import { 
  GridComponent, 
  TooltipComponent, 
  LegendComponent, 
  TitleComponent 
} from 'echarts/components';
import { CanvasRenderer } from 'echarts/renderers';

// Register only what you use
echarts.use([
  BarChart, 
  LineChart, 
  GridComponent, 
  TooltipComponent, 
  LegendComponent, 
  TitleComponent,
  CanvasRenderer
]);

Bundle Size Comparison:

Before (incorrect): ~900 KB
After (correct): ~80-100 KB
Savings: 91% reduction 🚀

Why echarts.use() is Critical

The echarts.use() function registers only the components you need. Without it:

Larger bundles: Everything gets included
Slower load times: Users download unnecessary code
Poor optimization: Tree-shaking cannot work effectively

Think of it like ordering a whole library when you only need one book.

TypeScript Type Support

To get IDE autocomplete for chart options while maintaining tree-shaking:

import type { EChartsOption } from 'echarts/types';

const option: EChartsOption = {
  xAxis: {
    type: 'category',
    data: ['Mon', 'Tue', 'Wed']
  },
  yAxis: {
    type: 'value'
  },
  series: [
    {
      data: [120, 200, 150],
      type: 'line'
    }
  ]
};

Important: Use import type (not just import) to ensure the type is stripped during compilation and doesn't end up in your bundle.

Happy coding! 🎉

Service Levels in Angular

Varad Shirsath — Sat, 20 Dec 2025 07:05:12 +0000

Understanding Service Levels in Angular! 🚀

Hey👋- Hope you're having an awesome day!

So, we're diving into something that always confuses people when they're starting with Angular - Services. I know, I know... services can feel like this mysterious box where you throw code and hope it works the way you expect. But trust me, once you understand the different levels where services live, everything starts to click.

So here's what I want to talk about: What are the different levels where we can use services in Angular? And more importantly, why does it even matter?

Let's break it down.

Root-Level Services: The Global MVP 🌍

Alright, so when you use the Angular CLI to generate a service - you know, that ng generate service command - Angular gives you this by default:

@Injectable({
  providedIn: 'root'
})
export class UserService { }

What's happening here? Angular is saying: "Hey, I'm going to create ONE single instance of this service and share it across your entire application."

Think about it like a shared resource. Imagine your app is a hotel, and this service is like the front desk. No matter which guest (component) walks up, they're talking to the same front desk person. There's only one person, and everyone gets the same information from them.

Why would you use this?

Perfect for things like:

Authentication Service - You want to share login state across all components
Configuration Service - Global app settings that don't change
HTTP/API Service - A single point for all backend communication
State Management - Shared data that multiple components need

This is your go-to for most services. It's simple, efficient, and prevents you from creating unnecessary instances.

Component-Level Services: Keep It Local 🏠

Now, what if you want a service that's only used by one component? Or what if each component should have its own separate copy of the service?
That's where component-level services come in:

@Component({
  selector: 'app-shopping-cart',
  templateUrl: './shopping-cart.component.html',
  providers: [CartService]
})
export class ShoppingCartComponent { }

Here's the thing: Every time this component is created, a brand new instance of CartService is created just for that component.

Back to our hotel analogy - this is like having a private caretaker for each guest room. Room 101 has their own caretaker, Room 102 has a different one. They don't share information.

When would you actually need this?

Form State - Each instance of a form component keeps its own data
Component Specific Logic - Data that should never leak to other components
Multiple Instances - When the same component appears multiple times on a page, each needs independent behavior

For example, imagine you have a ProductFilterComponent that appears on multiple pages. Each one needs to remember its own filters independently. Component-level services are perfect for this!

Module-Level Services: The Middle Ground ⚖️

Okay, so you're probably working with standalone components in modern Angular, but if you're using modules, there's also a module-level option:

@NgModule({
  declarations: [...],
  imports: [...],
  providers: [AuthGuardService]
})
export class AdminModule { }

What's the deal here?
It depends on whether the module is eagerly loaded or lazy-loaded:

Eagerly Loaded Module:
If your module loads when the app starts, the service behaves like a singleton across the whole app. It's pretty much the same as providedIn: 'root'

Lazy-Loaded Module:
Here's where it gets interesting! When Angular lazily loads a module (like a route that only loads when you visit it), it creates a completely separate injector. This means the service gets a new instance just for that module.

So if your app has an "Admin Dashboard" that only loads when an admin logs in, you could have an AdminService that only exists in that context. It's clean, efficient, and keeps unrelated code separate.

// Routes configuration

const routes: Routes = [
  { path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) }
];

In this scenario, the AdminService lives only within the lazy-loaded admin module. Once the module is unloaded, the service instance is gone too.

So... Which One Should You Use? 🤔
Real talk? It comes down to your app's architecture and how you want data to flow.

Ask yourself these questions:

Is this service needed everywhere? → Use Root-Level ✅
Is this service only used by one component? → Use Component-Level ✅
Is this service scoped to a specific feature module that lazy-loads? → Use Module-Level ✅

The secret sauce is understanding how Angular's Dependency Injection system works under the hood. When you know how the injector resolves dependencies - how it searches up the component tree, how it handles hierarchies - that's when you'll know exactly where to put your services.

The Bottom Line 💡
Services in Angular are just well-organized pieces of code that handle specific jobs. The level at which you provide them determines who gets access and how many copies exist.
Pick the right level, and your app stays maintainable and performant. Pick the wrong level, and... well, let's just say debugging gets fun. 😅

Key takeaways to remember:

Root-level = One instance, shared everywhere
Component-level = New instance per component
Module-level = Depends on eager vs. lazy loading