DEV Community: BAVITHRA GUPTHA

🛠 JavaScript Console Logging — Explained with Output

BAVITHRA GUPTHA — Sat, 10 May 2025 05:16:20 +0000

1️⃣ console.log()

console.log("Hello, World!");
console.log({ name: "Alice", age: 25 });

🧾 Output:

Hello, World!
{ name: "Alice", age: 25 }

2️⃣ console.table()

const users = [
  { name: "Alice", age: 25 },
  { name: "Bob", age: 30 }
];
console.table(users);

🧾 Output:

(index) name    age
0   Alice   25
1   Bob 30

✅ Easy-to-read tabular view of array/object data.

3️⃣ console.warn()

console.warn("This is a warning!");

🧾 Output:

⚠️ This is a warning!   // in yellow with a warning icon

✅ Highlights potential issues, but doesn't stop execution.

4️⃣ console.error()

console.error("An error occurred!");

🧾 Output:

❌ An error occurred!   // in red with an error icon and often a stack trace

✅ Ideal for actual problems that need fixing.

5️⃣ console.group() and console.groupEnd()

console.group("User Info");
console.log("Name: Alice");
console.log("Age: 25");
console.groupEnd();

🧾 Output:

▼ User Info
  Name: Alice
  Age: 25

✅ Collapsible groups help organize logs logically.

6️⃣ console.groupCollapsed()

console.groupCollapsed("API Response");
console.log("Status: 200 OK");
console.log("Data: {...}");
console.groupEnd();

🧾 Output:

▶ API Response
✅ Output is collapsed by default — neat and expandable.

7️⃣ console.time() and console.timeEnd()

console.time("Fetch Time");
setTimeout(() => {
  console.timeEnd("Fetch Time");
}, 500);

🧾 Output:

Fetch Time: 500.123ms

✅ Quickly measure how long operations take.

8️⃣ console.trace()

function a() {
  b();
}
function b() {
  console.trace("Trace log:");
}
a();

🧾 Output:

Trace log:
    at b (<anonymous>:4:11)
    at a (<anonymous>:2:3)
    at <anonymous>:6:1

✅ Helps track the function call path.

9️⃣ console.assert()

const isLoggedIn = false;
console.assert(isLoggedIn, "User is not logged in!");

🧾 Output (only if condition is false):

Assertion failed: User is not logged in!

✅ Logs only if condition is false — useful for testing assumptions.

🔟 console.clear()

console.clear();

🧾 Output:

Console cleared

✅ Clears previous logs — great for debugging fresh output.

🧠 BONUS: Styled Console Logs

console.log("%cStyled log!", "color: green; font-size: 18px; font-weight: bold;");

🧾 Output:

A green, bold, large "Styled log!" message in the console.

✅ Adds visual emphasis to key logs.

Microfrontend Architecture in a Real-World Application Using Angular

BAVITHRA GUPTHA — Sat, 10 May 2025 04:31:29 +0000

📌 By Bavithra Jagannatha Guptha
Senior Frontend Developer | Angular | Microfrontends | Accessibility Advocate

🔍 Project Focus
As part of a large-scale modernization initiative, our team rebuilt a legacy System using a microfrontend architecture powered by Angular.
This approach enabled us to:

Modularize the application
Improve scalability
Accelerate feature delivery
Maintain high accessibility standards

🏗️ Project Context
✅ Problem: Monolithic legacy app slowing development and deployment
✅ Objective: Build a scalable, maintainable solution enabling team autonomy
✅ Tech Stack: Angular, Webpack Module Federation, Azure DevOps, Docker

⚠️ Key Challenges
🔗 Tight coupling in the legacy architecture
🐌 Long deployment cycles
⛔ Difficulty enabling parallel team contributions
📉 Performance issues with large datasets

💡 Implementation Highlights

1. Defining Standard Contracts Between Microfrontends
A core concept in microfrontend architecture is the contract between microfrontends (MFEs). Each MFE must expose specific APIs, ensuring communication between them is smooth.

Here’s an example of a shared contract for a ClaimsService that can be consumed by other MFEs:

// claims.service.ts - Shared Service in a Shared Library
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable({
  providedIn: 'root'
})
export class ClaimsService {
  constructor(private http: HttpClient) {}

  getClaimsData() {
    return this.http.get('/api/claims');
  }

  submitClaim(claimData: any) {
    return this.http.post('/api/submit-claim', claimData);
  }
}

2. Shell Application Handling Routing and MFE Orchestration
In the shell application, we load the various MFEs dynamically. Webpack Module Federation allows us to expose and consume these MFEs in a modular way.

webpack.config.js in the Shell application:

javascript
Copy
Edit
module.exports = {
  name: 'shell',
  remotes: {
    auth: 'auth@http://localhost:4201/remoteEntry.js',
    dashboard: 'dashboard@http://localhost:4202/remoteEntry.js',
    claimsForm: 'claimsForm@http://localhost:4203/remoteEntry.js',
    claimsHistory: 'claimsHistory@http://localhost:4204/remoteEntry.js'
  },
  shared: {
    angular: { singleton: true }
  }
};

This setup allows us to load microfrontends like auth, dashboard, etc., from different ports at runtime.

Routing Setup in Shell Application (app-routing.module.ts):


const routes: Routes = [
  { path: '', loadChildren: () => import('dashboard/Module').then(m => m.DashboardModule) },
  { path: 'login', loadChildren: () => import('auth/Module').then(m => m.AuthModule) },
  { path: 'claims-form', loadChildren: () => import('claimsForm/Module').then(m => m.ClaimsFormModule) },
  { path: 'claims-history', loadChildren: () => import('claimsHistory/Module').then(m => m.ClaimsHistoryModule) }
];

This approach ensures that each MFE can independently handle its routing logic, while the shell application orchestrates them.

3. Implementing Full CI/CD Pipelines with Azure DevOps
We set up Azure DevOps pipelines to automate the build, test, and deployment processes. Here’s an example of a simplified azure-pipelines.yml for the Shell application:

yaml
Copy
Edit
trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '16.x'
  displayName: 'Install Node.js'

- task: Npm@1
  inputs:
    command: 'install'
  displayName: 'Install Dependencies'

- task: Npm@1
  inputs:
    command: 'run build -- --prod'
  displayName: 'Build Angular Project'

- task: AzureWebApp@1
  inputs:
    azureSubscription: 'Your-Azure-Subscription'
    appName: 'your-web-app-name'
    package: '$(Build.ArtifactStagingDirectory)/**/*.zip'

This YAML file sets up a pipeline that installs Node.js, builds the Angular project, and deploys it to Azure.

4. Docker for Deployment
Each microfrontend and the shell application are containerized using Docker. Below is an example Dockerfile for the shell application:

Dockerfile
Copy
Edit
# Use official node image as base
FROM node:16

# Set working directory
WORKDIR /app

# Copy package.json and install dependencies
COPY package*.json ./
RUN npm install

# Copy the rest of the app code
COPY . .

# Expose the port
EXPOSE 4200

# Build the Angular app and serve
RUN npm run build --prod
CMD ["npx", "http-server", "dist"]

This Dockerfile builds the Angular app in production mode and serves it using http-server to run in a container.

🎯 Outcomes & Benefits
✅ Faster deployments: Reduced from weeks to days
✅ Decoupled development: Independent team workflows
✅ Boosted performance: Faster load and response times
✅ Improved UX/UI: Streamlined and accessible design
✅ Simplified maintenance: Cleaner, modular codebase

👏 Final Thoughts
Adopting a microfrontend architecture allowed us to reimagine how large-scale applications can be built and maintained. The shift empowered teams to move faster, scale safely, and focus on user experience.

💬 Have you adopted microfrontends in your project? I’d love to hear your thoughts and lessons learned!
🔗 If you'd like a code walkthrough or more technical insights, feel free to connect or message me.

Top 5 Mistakes Angular Developers Make

BAVITHRA GUPTHA — Sat, 10 May 2025 03:37:10 +0000

🚫 Top 5 Mistakes Angular Developers Make (and How to Avoid Them)

Angular is an incredibly powerful framework for building scalable and robust web applications. But even experienced developers can fall into certain common traps that can lead to performance issues, hard-to-maintain code, or just plain developer headaches.

Here are five common mistakes Angular developers (including myself at times 😅) make—and how you can avoid them.

1️⃣ Forgetting to Unsubscribe from Observables 🔁
One of the most overlooked mistakes in Angular is forgetting to unsubscribe from Observables, especially when using HttpClient, EventEmitters, or custom Observables.

Why it matters:
Unsubscribed Observables can cause memory leaks and unexpected behaviors.

Quick Fix:
Use the async pipe whenever possible, or use takeUntil with a Subjectin ngOnDestroy.

2️⃣ Abusing any like it owes you money 🧨
We all love quick solutions, and anygives you that feeling of freedom. But overusing any removes the biggest advantage of using TypeScript—type safety.

Why it matters:
It opens the door to runtime errors that TypeScript is supposed to prevent.

Quick Fix:
Define clear interfaces and types for your data structures. Your future self (and your teammates) will thank you.

3️⃣ Overusing ngOnInit like it’s a magic fix-all 🔄
It’s tempting to put all the logic in ngOnInit, but this turns your components into messy, bloated blocks of code.

Why it matters:
Mixing too many concerns in one place reduces maintainability and testability.

Quick Fix:
Move business logic to services, use other lifecycle hooks wisely, and follow separation of concerns.

4️⃣ Creating Massive Components 🏗️
When a component starts doing too much, it becomes a monolith—difficult to read, test, or reuse.

Why it matters:
Larger components increase complexity and introduce tight coupling.

Quick Fix:
Break down components into smaller, reusable units. Follow the Single Responsibility Principle.

5️⃣ Copy-pasting code like a Ctrl+C ninja 📋
We've all done it, especially under tight deadlines. But duplicating code leads to inconsistent fixes, bugs, and code bloat.

Why it matters:
Redundant code increases the risk of inconsistencies and inflates the codebase.

Quick Fix:
Abstract repeated logic into services, directives, or reusable components.

👨‍💻 Final Thoughts
Mistakes happen—but learning from them and building better habits is what makes us better developers. By keeping these pitfalls in check, you can write cleaner, more maintainable, and more efficient Angular applications.

💬 Have you made any of these mistakes before? What helped you overcome them? Share your experience in the comments!

🔁 If this was helpful, consider reposting to help others in your network.