DEV Community: jayasooriya-s

Stop Hardcoding Routes: The Angular 19 Pattern That Will Save Your Sanity 🚀

jayasooriya-s — Mon, 02 Jun 2025 17:28:44 +0000

Ever found yourself doing Ctrl+F across 50+ files just to change one route? Yeah, me too. Here's how I fixed it once and for all.

Picture this: It's 2 AM, you're on your third cup of coffee, and your PM just dropped the bomb – "Hey, can we change all the /products routes to /inventory? Should be quick, right?"

If you've been there, you know the pain. You fire up your IDE, start the great hunt for hardcoded routes, and pray you don't miss any. There's got to be a better way, right?

Spoiler alert: There is. And it's going to change how you think about routing in Angular forever.

The Nightmare We All Know Too Well

Let's be honest – we've all written code like this:

// 😱 The route nightmare that haunts us all
viewProduct(id: string): void {
  this.router.navigate(['/products/details', id]); // Hardcoded disaster
}

editProduct(id: string): void {
  this.router.navigate(['/products/edit', id]); // Another one bites the dust
}

createProduct(): void {
  this.router.navigate(['/products/create']); // The trilogy of terror
}

Now imagine this scattered across 20 components. Then your client decides they want to rebrand "products" to "items".

RIP your weekend plans. 💀

The Game-Changer: Route Constants That Actually Work

After getting burned by this pattern one too many times, I developed a centralized approach that's been a lifesaver. Here's the magic:

// constants/routes.constants.ts
export const ROUTES = {
  PRODUCTS: {
    // For your route config (the boring stuff)
    ROOT: '',
    DETAILS_PARAM: 'details/:id',
    CREATE: 'create',
    EDIT_PARAM: 'edit/:id',

    // Navigation helpers (the good stuff)
    nav: {
      root: () => ['/products'],
      details: (id: string | number) => ['/products', 'details', id.toString()],
      create: () => ['/products', 'create'],
      edit: (id: string | number) => ['/products', 'edit', id.toString()]
    },

    // URL builders (for when you need actual strings)
    url: {
      root: () => '/products',
      details: (id: string | number) => `/products/details/${id}`,
      create: () => '/products/create',
      edit: (id: string | number) => `/products/edit/${id}`
    }
  }
} as const; // ← This 'as const' is crucial for type safety!

Angular 19 Standalone Routes: Clean AF

// products.routes.ts
export const PRODUCT_ROUTES: Routes = [
  {
    path: ROUTES.PRODUCTS.ROOT,
    canActivate: [authGuard],
    children: [
      { path: ROUTES.PRODUCTS.ROOT, component: ProductListComponent },
      { path: ROUTES.PRODUCTS.DETAILS_PARAM, component: ProductDetailsComponent },
      { path: ROUTES.PRODUCTS.CREATE, component: ProductFormComponent },
      { path: ROUTES.PRODUCTS.EDIT_PARAM, component: ProductFormComponent }
    ]
  }
];

Your Components Will Thank You Later

// 🎉 Look ma, no hardcoded routes!
viewProduct(id: string): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.details(id));
}

editProduct(id: string): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.edit(id));
}

createProduct(): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.create());
}

// For templates and sharing
getProductUrl(id: string): string {
  return ROUTES.PRODUCTS.url.details(id);
}

Different Types of Navigation: Master Them All 🧭

1. Simple Route Navigation

// Basic navigation without parameters
goToProducts(): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.root());
}

// Navigate with single parameter
viewUser(userId: string): void {
  this.router.navigate(ROUTES.USERS.nav.profile(userId));
}

2. Navigation with Query Parameters

// Navigate with query params
searchProducts(category: string, minPrice: number): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.root(), {
    queryParams: { 
      category, 
      minPrice,
      page: 1 
    }
  });
}

// Preserve existing query params
editProduct(id: string): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.edit(id), {
    queryParamsHandling: 'preserve'
  });
}

3. Navigation with Fragments and Extras

// Navigate to section with fragment
viewProductReviews(id: string): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.details(id), {
    fragment: 'reviews'
  });
}

// Navigate and replace current history
replaceCurrentRoute(id: string): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.details(id), {
    replaceUrl: true
  });
}

// Navigate with state data
navigateWithState(id: string, productData: any): void {
  this.router.navigate(ROUTES.PRODUCTS.nav.edit(id), {
    state: { productData, returnUrl: this.router.url }
  });
}

Navigation vs URLs: Know the Difference

Here's something that tripped me up initially:

Use `.nav` for Router Navigation

// ✅ For programmatic navigation
this.router.navigate(ROUTES.PRODUCTS.nav.details(id));
// Produces: ['/products', 'details', '123']

Use `.url` for Everything Else

// ✅ For templates, sharing, APIs, etc.
const shareUrl = ROUTES.PRODUCTS.url.details(id);
// Produces: '/products/details/123'

Real-World Magic ✨

Email Notifications That Actually Work

async sendProductAlert(productId: string, userEmail: string): Promise<void> {
  const productUrl = `${window.location.origin}${ROUTES.PRODUCTS.url.details(productId)}`;

  await this.emailService.send({
    to: userEmail,
    subject: '🔔 Product Update Alert',
    html: `<a href="${productUrl}">View Product Details →</a>`
  });
}

Social Sharing Made Simple

shareProduct(productId: string): void {
  const url = ROUTES.PRODUCTS.url.details(productId);
  const fullUrl = `${window.location.origin}${url}`;

  if (navigator.share) {
    navigator.share({
      title: "'Check out this amazing product!',"
      url: fullUrl
    });
  } else {
    navigator.clipboard.writeText(fullUrl);
    this.showToast('Link copied to clipboard!');
  }
}

Breadcrumbs Without the Headache

// In your component
homeUrl = '/dashboard';
productsUrl = ROUTES.PRODUCTS.url.root();

// Template usage
// <a [routerLink]="homeUrl">🏠 Home</a>
// <a [routerLink]="productsUrl">📦 Products</a>

Testing: No More Route Guessing Games

describe('ProductListComponent', () => {
  let component: ProductListComponent;
  let router: jasmine.SpyObj<Router>;

  beforeEach(async () => {
    const routerSpy = jasmine.createSpyObj('Router', ['navigate']);
    // ... setup code
  });

  it('should navigate to product details like a boss', () => {
    const productId = '123';
    component.viewProduct(productId);

    // ✅ Clear, predictable expectations
    expect(router.navigate).toHaveBeenCalledWith(
      ROUTES.PRODUCTS.nav.details(productId)
    );
  });

  it('should generate correct URLs for sharing', () => {
    const productId = '456';
    const expectedUrl = '/products/details/456';

    const actualUrl = component.getProductUrl(productId);
    expect(actualUrl).toBe(expectedUrl);
  });
});

Scale Like a Pro 📈

As your app grows, adding features becomes a breeze:

export const ROUTES = {
  PRODUCTS: {
    // ... existing product routes
  },

  ORDERS: {
    ROOT: '',
    DETAILS_PARAM: 'details/:id',
    TRACKING_PARAM: 'tracking/:trackingNumber',

    nav: {
      root: () => ['/orders'],
      details: (id: string) => ['/orders', 'details', id],
      tracking: (trackingNumber: string) => ['/orders', 'tracking', trackingNumber]
    },

    url: {
      root: () => '/orders',
      details: (id: string) => `/orders/details/${id}`,
      tracking: (trackingNumber: string) => `/orders/tracking/${trackingNumber}`
    }
  },

  CUSTOMERS: {
    ROOT: '',
    PROFILE_PARAM: 'profile/:id',
    ORDERS_PARAM: 'orders/:customerId',

    nav: {
      root: () => ['/customers'],
      profile: (id: string) => ['/customers', 'profile', id],
      orders: (customerId: string) => ['/customers', 'orders', customerId]
    },

    url: {
      root: () => '/customers',
      profile: (id: string) => `/customers/profile/${id}`,
      orders: (customerId: string) => `/customers/orders/${customerId}`
    }
  }
} as const;

Don't Make These Rookie Mistakes 🚫

1. Wrong Array Structure (Been There!)

// ❌ This will break your URLs
nav: {
  details: (id: string) => ['/products/details', id] // Nope!
}

// ✅ This is the way
nav: {
  details: (id: string) => ['/products', 'details', id] // Yes!
}

2. Forgetting Type Safety

// ❌ Missing the magic
export const ROUTES = {
  // routes here
};

// ✅ TypeScript will love you for this
export const ROUTES = {
  // routes here
} as const;

3. Inconsistent Naming

// ❌ Confusing mix
PRODUCTS: {
  nav: { /* navigation helpers */ },
  urls: { /* URL builders */ }, // Wait, is it 'url' or 'urls'?
}

// ✅ Consistent and clear
PRODUCTS: {
  nav: { /* navigation helpers */ },
  url: { /* URL builders */ },
}

Migration Strategy (AKA "How to Fix Your Mess")

If you're stuck with an existing codebase full of hardcoded routes:

Pick Your Battles - Start with your most-used feature (probably the one that changes most often)
Create the Constants First - Define your route structure before touching components
Replace Systematically - Use your IDE's find-and-replace, but test each change
Test Everything - Seriously, test every navigation path
Get Your Team On Board - Make sure everyone understands the new pattern

Pro tip: Use a regex search for common route patterns like ['/\w+ to find hardcoded navigation arrays.

The Bottom Line 🎯

This pattern has saved me countless hours and my sanity more times than I can count. Here's what you get:

✅ One Change, Everywhere Updated - Change a route in one place, done

✅ Type Safety - TypeScript catches route errors at compile time

✅ Better DX - IntelliSense shows you available routes

✅ Easier Testing - Predictable navigation patterns

✅ Future Proof - Easy to extend as your app grows

✅ Team Friendly - New developers immediately understand the pattern

This approach pairs beautifully with Angular 19's standalone components and modern DI patterns. Your future self will definitely thank you for this.

Want More Angular Magic? 🪄

If this saved your day, you might also like my other posts about cleaning up Angular code:

Follow me for more Angular tips that'll make your code cleaner and your life easier! 🚀

Have you tried this pattern? Got any horror stories about hardcoded routes? Drop them in the comments – misery loves company! 😄

Why NestJS stole my developer heart (and it’s not just the cat 🐱🔥). Dive into why I’m choosing structure, scalability, and sanity over pure flexibility. #NestJS #BackendDev #TypeScript #WebDevelopment

jayasooriya-s — Thu, 15 May 2025 17:50:35 +0000

jayasooriya-s

May 15 '25

🧠 Why I’m Choosing NestJS Over Express for My Next Project

#javascript #angular #nestjs #programming

Comments

2 min read

🧠 Why I’m Choosing NestJS Over Express for My Next Project

jayasooriya-s — Thu, 15 May 2025 17:48:18 +0000

🐱🔥 Okay, I’ll admit — the cat logo might’ve caught my eye. I didn’t choose NestJS because I like cats… but it helps.

But there’s a lot more that makes NestJS my top pick over Express.

I started as a React developer. It’s great — gives full flexibility and lets you build things fast. But when I worked on some enterprise apps, I found that Angular, though opinionated, provided better structure. It comes with everything built-in — and I started to enjoy that.

Especially the class-based approach, decorators, and how it pushes you to understand core OOP concepts. That mindset shift made me curious about trying something similar in backend development.

🚀 Then I discovered NestJS
NestJS felt instantly familiar — it’s like Angular but for the backend. You get modules, controllers, services, dependency injection, and TypeScript out of the box. No need to figure everything from scratch like in Express.

It’s structured, scalable, and comes with official support for things like validation, Swagger, logging, testing, and more.

✅ Why I prefer NestJS over Express now:

Opinionated structure makes it easier to scale
Cleaner with TypeScript and decorators
Comes with most tools I usually install manually in Express
Feels like a backend built for developers who care about maintainability

I’m not saying React is bad or Angular is better — both have their own strengths. But as we grow in our careers, it’s important to learn how different tools solve problems in different ways.

📝 Final thoughts
For my next project, I’m choosing NestJS over Express — not just for features, but for the structure and clarity it brings. In upcoming blogs, I’ll dive deeper into how I’m using NestJS in real-world development — from architecture to performance and testing.

Stay tuned 👀

Do you have OCD ?

jayasooriya-s — Mon, 12 May 2025 15:45:45 +0000

jayasooriya-s

May 8 '25

Say Goodbye to Messy HTML: How Self-Closing Tags Can Satisfy Your OCD 😌✨

#cleancode #html #react #frontend

Comments

2 min read

Say Goodbye to Messy HTML: How Self-Closing Tags Can Satisfy Your OCD 😌✨

jayasooriya-s — Thu, 08 May 2025 17:41:04 +0000

Ever feel uneasy seeing empty HTML tags that just sit there, open and awkward?
If your inner neat freak screams when code is not clean, you are not alone.
Whether you are a beginner or a pro developer, writing clean, readable HTML can feel oddly satisfying and it starts with something simple: self-closing tags.

In this blog, you will learn:

✅ What self-closing tags are

✅ When and how to use them

✅ Why they matter for readability, structure, and yes… even your developer OCD

✅ Bonus: How frameworks like React, Vue, and others treat these tags

🤔 What Are Self-Closing Tags?
A self-closing tag is an HTML element that doesn't need any content inside it, so you don't have to write a closing tag.

<img src="photo.jpg" alt="A sample photo" />

Here, <img /> doesn't need </img>. It's self-contained — and it's valid HTML5.

🚦 When Should You Use Self-Closing Tags?
Use self-closing tags only for elements that don’t have inner content, including custom components.

For example, if you create a custom component like <custom-tag /> without any child content or HTML, it should be self-closed for cleaner code. This applies to components that serve as placeholders or simple wrappers.

Tag	Purpose
`<img />`	Images
`<br />`	Line breaks
`<hr />`	Horizontal dividers
`<input />`	Input fields
`<link />`	Stylesheet links
`<meta />`	Metadata in the `<head>` section
`<source />`	Media sources for `<video>` or `<audio>`
`<area />`	Image maps
`<base />`	Base URL

🔴 Avoid using self-closing tags for elements that are meant to contain content:

<!-- ❌ Wrong -->
<p />   <!-- Not valid -->
<div /> <!-- Not valid -->

<!-- ✅ Correct -->
<p>Hello, world!</p>
<div></div>

🧠 Why Do Developers Love Self-Closing Tags?

<input type="text" />   // ✅ Required in JSX

🔍 SEO Tip
While self-closing tags don’t directly affect SEO, writing well-structured, valid HTML does.
Search engines like Google prioritize:

Semantic structure
Clean, well-formed HTML
Proper tag usage (especially in and content sections)

Using <meta />, <link />, and other self-closing elements correctly ensures your page is better optimized for crawling and indexing.
🎯 Final Thoughts: Let Your OCD Work for You
Self-closing tags might seem like a small thing, but they can make a big difference in your workflow. Cleaner HTML leads to:

Better readability
Fewer bugs
Easier maintenance

Next time you use an empty <img>or <br>tag, just make it self-closing , your code will look cleaner, and your inner neat freak (OCD) will be happy too

🛠 Bonus: Linter Rules
Mention how tools like ESLint or Prettier enforce correct self-closing tags.

JSX rule: "react/self-closing-comp"

🖼️ Banner generated using OpenAI Sora

🔧🚫 Stop Using ngIf and ngFor: Enforce Angular's New Control Flow with ESLint ✅

jayasooriya-s — Thu, 01 May 2025 10:34:26 +0000

Still typing *ngFor, *ngIf, and *ngSwitch out of habit? You’re not alone. After years of working with legacy Angular, my muscle memory made it hard to switch to the latest Angular control flow syntax. But with one simple trick, I finally made the shift—and it improved both my code and performance. In this post, I’ll show you how to ditch the old directives and get comfortable with Angular’s new control flow in no time

The Simple Trick? Let ESLint Do the Work for You
Instead of forcing myself to remember, I let ESLint catch me in the act.

Angular now supports ESLint rules that can warn or error when you use legacy structural directives like *ngFor, *ngIf, and *ngSwitch and instead suggest using the new control flow syntax @for, @if, @switch.

Before Eslint Rule:

After Eslint Rule:
After adding the rule code editor highligts the error

Solution: Add This ESLint Rule to Your Project
To make the switch easier, you can add the following rule to your eslint.config.js under the html rules section:

  {
    files: ["**/*.html"],
    extends: [
      ...angular.configs.templateRecommended,
      ...angular.configs.templateAccessibility,
    ],
    rules: {
      "@angular-eslint/template/prefer-control-flow": "error"
    },
  }

"@angular-eslint/template/prefer-control-flow": "error"

Once you add this rule, run ng lint to catch any instances of the old directives:

 12:37  error  Use built-in control flow instead of directive ngIf  @angular-eslint/template/prefer-control-flow
  16:15  error  Use built-in control flow instead of directive ngIf  @angular-eslint/template/prefer-control-flow

Benefits of Using the New Syntax
Switching to Angular’s new control flow syntax isn’t just about cleaner code—it’s also about performance improvements. The new directives are optimized to work faster, which can make a noticeable difference in larger applications.

Final Thoughts
Switching from *ngIf, *ngFor, and *ngSwitch to Angular’s new control flow syntax can be a tough habit to break—but with the right ESLint rules in place, the transition becomes effortless. You’ll write cleaner, more performant code without having to constantly remind yourself to use the new syntax.

Want to take it a step further? Combine this lint rule with a commit-stage linting setup to automatically prevent legacy control flow usage from making it into your codebase. In this related guide, I walk you through how to do exactly that:
👉 Maintain Code Quality Like a Big Tech Team Without Paying for Expensive Automation

By combining ESLint rules with pre-commit hooks, you ensure that your team consistently follows the latest Angular best practices—with zero manual effort.

🖼️ Banner generated using OpenAI Sora

🚨 Prevent Sensitive Data Exposure: How to Disable console.log in Production for React and JavaScript Apps 💻

jayasooriya-s — Mon, 28 Apr 2025 15:38:10 +0000

I have worked on a project for a while. During development, for debugging, I had added console.logs across the codebase, even though we had other options to debug. When the app was about to go live, I realized those console logs might expose some sensitive data — and my crazy way of debugging! What should I do now? In this blog, we are going to see how to fix this.

Leaving the console.log in production build is risky,They might accidentally leak user data, internal errors, API responses, or simply make your app look unprofessional. One approach is to remove all the console.log statements, but what if an issue arises and you need to test the application?

Instead of removing them completely, we can simply disable them in production. This way, we can still retain the option to debug during development without exposing sensitive information in the live app.

Solution 1 :
If you already add the consloe.log in your React Angular or any JS framework. Add the following code in Applications entry point.

if (process.env.NODE_ENV === 'production') {
  console.log = () => {};    // Disable console.log
  console.warn = () => {};   // Disable console.warn
  console.error = () => {};  // Disable console.error
  console.info = () => {};   // Disable console.info
}

How It Works:

process.env.NODE_ENV checks whether the app is in production mode or not.
If it's production, the code replaces console.log, console.warn, console.error, and console.info with empty functions (() => {}).

Why This Works:

Replacing console.log with an empty function changes its behavior: Instead of printing messages to the console, it does nothing.
This ensures that when you call console.log or any of the other methods in production, there won’t be any output, keeping sensitive information safe and making the app look cleaner.

This is a global change because the console object is a global object in JavaScript, meaning it's accessible anywhere in your code. When you override one of its methods, the change takes effect globally across the entire application. So, no matter where in your code console.log() is called, it will simply do nothing in production.

Key Points:

Global Effect: Once you replace console.log with an empty function, it applies everywhere in the code, so any console.log statement will not output anything to the console, no matter where it's used.
No Output in Production: This effectively stops any debug or info messages from appearing in production environments, keeping sensitive information safe and ensuring your app looks polished and professional.
No Performance Hit: The empty function does not take up resources, so it avoids the performance overhead of keeping unnecessary logging active in production.

Solutuon 2 :
If you are just starting your project, a better approach is to create a helper function or service specifically for debugging. This way, you can avoid directly using console.log and instead use a custom function that you can intercept at any point in your code.

// debugService.js
export const debugLog = (message) => {
  if (process.env.NODE_ENV !== 'production') {
    console.log(message); // Log only in development
  }
}

import { debugLog } from './debugService';

debugLog('This is a debug message');

Disabling or removing console.log statements in production is crucial for maintaining the security and professionalism of your application. By using the first approach, I have fixed my existing codebase, ensuring no console.log statements are exposed in production.

For new development, I am now using Solution 2, which provides more control and flexibility for debugging without compromising the integrity of the production environment

Maintain Code Quality Like a Big Tech Team — Without Paying for Expensive Automation

jayasooriya-s — Sat, 26 Apr 2025 13:42:24 +0000

When I started my career, I was focused on meeting deadlines rather than worrying about code quality. But as I transitioned to a tech lead role, I realized how crucial it was to architect the codebase in a way that was easy for everyone to understand and maintain. By using tools like Husky and Lint-Staged, I was able to automate code checks and enforce clean code practices, which helped keep the codebase scalable and maintainable as the team grew.

In this blog, I’ll share how small teams can maintain code quality without expensive solutions.

Husky & Lint-Staged: The Perfect Duo
Think of Husky and Lint-Staged like Leonardo DiCaprio and Martin Scorsese — when they team up, you get the best out of both. Similarly, Husky and Lint-Staged work together to bring the best discipline to your codebase. They help catch small mistakes early, enforce clean code, and automate formatting right when a developer tries to commit code.

This setup ensures that even in fast-moving teams, code quality doesn’t slip through the cracks. Simply install following package in your any Javascript ot Typescript project.
npm i lint-staged@12.3.2

Lint-Staged helps run linting (and other scripts) only on the files that are staged for commit.
Instead of linting the entire project — which can be slow and unnecessary — it targets only the files you actually changed.
This ensures faster linting and that only clean code gets committed, without slowing down your workflow.

Next, install Husky:

npm i husky

Husky allows you to manage Git hooks easily.
You can hook into Git events like pre-commit, pre-push, and commit-msg to run commands automatically.
In this setup, Husky will trigger Lint-Staged right before a commit, ensuring that only well-formatted, linted files enter the repository.

In short:

Lint-Staged → Focus on the changed files.

Husky → Automate the checks before a commit.

npx husky init
this will generate husky related configuration side the code base

{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev --turbopack",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "lint-staged": "lint-staged",
    "prepare": "husky"
  },
  "dependencies": {
    "husky": "^9.1.7",
    "lint-staged": "^15.2.10",
    "next": "15.3.1",
    "react": "^19.0.0",
    "react-dom": "^19.0.0"
  },
  "devDependencies": {
    "@eslint/eslintrc": "^3.1.0",
    "@types/node": "^20.16.11",
    "@types/react": "^19.0.0-rc.1",
    "@types/react-dom": "^19.0.0-rc.1",
    "eslint": "^9.13.0",
    "eslint-config-next": "15.3.1",
    "typescript": "^5.6.3"
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{css,md,json}": [
      "prettier --write"
    ]
  }
}

to automate the lint stage add npm run lint-staged inside the pre-commit file. then commit your changes

Once the isssues were fixed the lnit stage will allow to commit. your code

By adding ESLint rules and Test Rules in the lint-staged configuration,
we can easily enforce good coding practices and auto-formatting will help escape from unnecessary merge conflicts too.

DEV Community: jayasooriya-s

Stop Hardcoding Routes: The Angular 19 Pattern That Will Save Your Sanity 🚀

The Nightmare We All Know Too Well

The Game-Changer: Route Constants That Actually Work

Angular 19 Standalone Routes: Clean AF

Your Components Will Thank You Later

Different Types of Navigation: Master Them All 🧭

1. Simple Route Navigation

2. Navigation with Query Parameters

3. Navigation with Fragments and Extras

Navigation vs URLs: Know the Difference

Use .nav for Router Navigation

Use .url for Everything Else

Real-World Magic ✨

Email Notifications That Actually Work

Social Sharing Made Simple

Breadcrumbs Without the Headache

Testing: No More Route Guessing Games

Scale Like a Pro 📈

Don't Make These Rookie Mistakes 🚫

1. Wrong Array Structure (Been There!)

2. Forgetting Type Safety

3. Inconsistent Naming

Migration Strategy (AKA "How to Fix Your Mess")

The Bottom Line 🎯

Want More Angular Magic? 🪄

Why NestJS stole my developer heart (and it’s not just the cat 🐱🔥). Dive into why I’m choosing structure, scalability, and sanity over pure flexibility. #NestJS #BackendDev #TypeScript #WebDevelopment

🧠 Why I’m Choosing NestJS Over Express for My Next Project

🧠 Why I’m Choosing NestJS Over Express for My Next Project

Do you have OCD ?

Say Goodbye to Messy HTML: How Self-Closing Tags Can Satisfy Your OCD 😌✨

Say Goodbye to Messy HTML: How Self-Closing Tags Can Satisfy Your OCD 😌✨

🔧🚫 Stop Using ngIf and ngFor: Enforce Angular's New Control Flow with ESLint ✅

🚨 Prevent Sensitive Data Exposure: How to Disable console.log in Production for React and JavaScript Apps 💻

Maintain Code Quality Like a Big Tech Team — Without Paying for Expensive Automation

Use `.nav` for Router Navigation

Use `.url` for Everything Else