DEV Community: Milan Barać

Shader: AI-Powered Tailwind Palette Generator

Milan Barać — Fri, 09 Jan 2026 12:03:31 +0000

Designing a good color palette is deceptively hard. While picking a single nice-looking color is easy, expanding that color into a usable, accessible, and consistent palette - one that works across light and dark UI, states, contrasts, and real-world screens - is where most attempts fail.
Shader was created to solve exactly this problem: an AI‑powered tool for generating high‑quality Tailwind CSS color palettes from virtually any base color, while respecting color theory, perceptual uniformity, and modern UI requirements.

1. Introduction

Tailwind CSS is unapologetically modern. It embraces the latest CSS capabilities and promotes a utility‑first approach that dramatically improves developer productivity. Instead of fighting abstractions, developers work directly with low‑level styling primitives that scale remarkably well in large applications.

Color plays a central role in this philosophy.

Tailwind ships with 22 predefined color palettes, each consisting of 11 shades ranging from 50 to 950. These palettes are well‑crafted and battle‑tested, but relying exclusively on them comes with a clear downside: after a while, every application starts to look the same.

Real products need identity. Brand recognition, emotional tone, accessibility, and hierarchy are all deeply influenced by color choices. To achieve full creative freedom, developers and designers need the ability to generate custom palettes that feel as refined and consistent as Tailwind's native ones - without requiring years of color theory experience.

That gap is exactly where Shader comes in.

Shader augments Tailwind's color system using AI and advanced mathematical color models to generate complete, production‑ready palettes from a single base color.

2. Naive palette generators problem

Many existing palette generators follow simplistic rules:

Linear interpolation in RGB or HSL
Uniform lightness steps
Fixed saturation curves

While these approaches may look acceptable at first glance, they quickly fall apart in real usage:

Some shades appear muddy or washed out
Others clip outside the displayable color gamut
Contrast ratios become unpredictable
Mid‑tones feel inconsistent
Dark shades lose chroma and identity

The root cause is simple: human color perception is not linear, and neither RGB nor HSL were designed for perceptual uniformity.

A serious palette generator must operate in color spaces that reflect how humans actually perceive differences in color. This is where the newer OKLCH color space excels, as it is both perceptually uniform and increasingly accepted as a modern standard in web color design.

3. Color theory foundations

Every high‑quality color palette generator must be built on solid color theory. Shader relies on several key concepts:

Color spaces

Instead of naive RGB interpolation, Shader operates in perceptually uniform color spaces (such as OKLCH‑derived models). These spaces allow Shader to control:

Lightness - how bright or dark a color appears
Chroma - perceived color intensity
Hue - the actual color family

This ensures that steps between shades feel even to the human eye.

Lightness curves

Tailwind palettes are not linear ramps. The transition from 50 → 100 behaves very differently from 700 → 800.

Shader models non‑linear lightness curves that mimic real Tailwind palettes, ensuring:

Soft highlights
Strong mid‑tones
Dense, usable dark shades

Chroma preservation

One of the hardest problems in palette generation is maintaining color identity in darker shades. Many tools simply desaturate as colors get darker.

Shader applies adaptive chroma scaling, preserving vibrancy where possible while avoiding oversaturation and clipping.

Hue damping and controlled rotation

In high-quality palettes, hue is not static across all shades. In Tailwind's native palettes, subtle hue rotations occur as colors move from light to dark - often warming highlights slightly and cooling shadows to preserve visual balance and contrast.

Naive generators lock hue to a single value, which often results in lifeless highlights and muddy dark tones.

Shader models controlled hue rotation with damping, allowing hue to shift gradually where it improves perceptual consistency, while preventing excessive drift that would break the color's identity. As shades approach darker values, hue movement is progressively reduced, ensuring that deep tones remain stable, recognizable, and usable in real UI contexts.

This approach mirrors the nuanced behavior found in hand-crafted Tailwind palettes and contributes to more natural, visually cohesive color families.

Gamut clipping

Not all theoretically valid colors can be displayed on real screens.

Shader performs intelligent gamut clipping, ensuring that all generated shades:

Render correctly on modern displays
Remain visually consistent across devices
Avoid sudden hue shifts caused by naive clamping

Harmonies

While many palettes are built around a single base hue, complex design systems often require a broader yet cohesive color range. Shader supports a wide set of classical color harmonies, allowing palettes to expand beyond a single hue while preserving balance and perceptual consistency.

Supported harmony types include:

Analogous - neighboring hues for smooth, unified color families
Complementary - opposing hues for strong, controlled contrast
Split-complementary - softened contrast with improved flexibility
Triadic - three evenly spaced hues for balanced vibrancy
Tetradic - two complementary pairs for rich, expressive systems
Quadratic - four evenly spaced hues for symmetrical color variety
Monochromatic - variations of a single hue through lightness and chroma

All harmony-based palettes are generated with the same perceptual constraints as single-hue palettes, ensuring consistent lightness curves, controlled chroma, and stable hue behavior across all derived colors.

4. AI‑assisted palette generation

Shader is not just a mathematical tool - it is AI‑augmented.

By learning from Tailwind's native palettes and thousands of well‑crafted color systems, Shader understands subtle patterns such as:

Where saturation should peak
How hue subtly shifts across shades
How contrast behaves in real UI contexts

This allows Shader to generate palettes that feel human‑designed, not mechanically generated.

Intelligent palette naming

Every generated palette receives a unique, human‑friendly name.

Shader uses a curated dataset of over 30,000 color names, learned and indexed to provide fast, meaningful palette naming that reflects the palette's visual character - without randomness or repetition.

5. Shader features

Shader provides a comprehensive set of tools for working with color in modern web applications:

Random color generator - discover unexpected starting points
Tailwind palette generator - create full 50–950 palettes
Direct color input - OKLCH, HEX, HSL, RGB, or visual selection
Fine color tuning - adjust lightness, chroma, hue and alpha (not needed for Tailwind CSS palettes)
Gamut clamping - safe output for real screens
Color harmonies - expand palettes intelligently
Mockup preview - see palettes in real UI contexts

Image color extraction - build palettes from photos

One‑click copy & apply - instant Tailwind integration

Palette export - ready for production use

All tools are designed to work together, forming a cohesive color workflow rather than isolated utilities.

6. Why Shader fits Tailwind perfectly

Tailwind's success comes from its opinionated consistency. Shader respects and extends that philosophy.

Generated palettes:

Match Tailwind's shade distribution
Drop directly into v3.x tailwind.config.js or v4.x CSS entry point picked up by .postcssrc.json
Maintain predictable contrast levels
Scale cleanly across components and states

The result is custom design identity without sacrificing Tailwind's ergonomics.

7. Conclusion

Shader provides a powerful, accessible, and free toolkit for generating and fine‑tuning Tailwind color palettes.

By combining:

Solid color theory
Perceptual color spaces
Advanced mathematical interpolation
AI‑assisted refinement

Shader goes beyond simple palette generation and delivers production‑ready color systems.

It augments Tailwind's 22 native palettes into a virtually infinite design space - allowing developers and designers to create applications that are both visually distinct and technically sound.

If color has ever been the weakest link in your UI workflow, Shader turns it into a strength.

Shader UI

Shader: AI-Powered Tailwind Palette Generator

NestJS + Prisma: Singleton Provider & Service with Extensions

Milan Barać — Fri, 06 Jun 2025 10:06:29 +0000

Prisma offers a slick, type-safe way to work with databases, and NestJS provides a robust structure for building modern backend apps. Together, they’re a great match — but only if Prisma is correctly initialized within NestJS’s lifecycle. A misconfigured Prisma provider can lead to subtle bugs or resource leaks, especially when custom extensions come into play.

1. Introduction

NestJS and Prisma are a natural fit for building modern, type-safe backend applications. NestJS brings structure, modularity, and a powerful dependency injection system, while Prisma provides a clean, auto-typed ORM with excellent developer ergonomics. Together, they offer an efficient and scalable development experience.

However, using Prisma effectively within a NestJS project requires more than just generating a client and injecting it into services. To avoid connection issues, memory leaks, or unexpected behavior — especially during development with hot reloading or when running in serverless environments — Prisma should be initialized as a singleton and properly integrated into NestJS’s lifecycle hooks.

A well-structured PrismaProvider class that implements OnModuleInit and OnModuleDestroy ensures the database connection is opened and closed at the right times. This pattern avoids repeated connections and supports safe shutdowns — crucial for production-grade apps.

On top of this, Prisma’s $extends API enables powerful customization through reusable extensions. Features like exists checks, soft delete support, and query scoping can be cleanly abstracted into custom extensions. But for these to be reliably available across your application, they must be bound to a single instance of the client — again reinforcing the need for a correctly managed singleton.

In this article, we’ll walk through how to:

Set up Prisma as a properly managed singleton provider in NestJS
Leverage OnModuleInit and OnModuleDestroy for lifecycle-safe initialization
Create and apply custom Prisma extensions like exists, softDelete, and scoped queries
Avoid common pitfalls that arise from improper initialization or multiple Prisma instances

Let’s dive in by first building a minimal PrismaProvider that plays nicely with NestJS’s lifecycle and sets the stage for custom extensions.

2. Prisma Extensions

Prisma’s $extends API unlocks a powerful way to modularize and reuse database logic across your application. Instead of repeating common patterns — like checking if a record exists or handling soft deletes — you can encapsulate them in clean, composable extensions. These extensions not only reduce boilerplate but also improve code clarity and consistency across your services. In this section, we’ll explore how to build custom extensions for exists checks, soft deletion — and how to cleanly attach them to your singleton Prisma client.

prisma.extensions.ts

import { Prisma } from '@prisma/client';

export const existsExtension = Prisma.defineExtension({
  name: 'exists-extension',
  model: {
    $allModels: {
      async exists<T>(this: T, where: Prisma.Args<T, 'findFirst'>['where']): Promise<boolean> {
        const context = Prisma.getExtensionContext(this);
        const count = await context['count']({
          where,
          take: 1
        } as Prisma.Args<T, 'count'>);
        return count > 0;
      }
    }
  }
});
export const softDeleteExtension = Prisma.defineExtension({
  name: 'soft-delete-extension',
  model: {
    $allModels: {
      async softDelete<T>(
        this: T,
        where: Prisma.Args<T, 'update'>['where']
      ): Promise<Prisma.Result<T, unknown, 'update'>> {
        const context = Prisma.getExtensionContext(this);
        return context['update']({
          where,
          data: {
            deletedAt: new Date()
          }
        } as Prisma.Args<T, 'update'>);
      }
    }
  }
});

3. Singleton Prisma Provider

To fully harness Prisma in a NestJS project — especially when using custom extensions — you need a properly initialized singleton provider. Prisma’s client is designed to be reused across your application, and creating multiple instances can lead to duplicated connections, race conditions, or lost context for extensions.

A common pattern is to extend PrismaClient in a custom PrismaProvider that implements NestJS’s OnModuleInit and OnModuleDestroy interfaces. This ensures the client connects only once when the app starts and disconnects cleanly on shutdown.

To support extensions like exists, softDelete, or scoped queries, the singleton should expose a .withExtensions() method that returns an $extends()- chained version of the client. This allows you to separate core access (e.g., for migrations or internal use) from wrapped access where extended behavior is needed.

Here’s a quick breakdown of the pattern:

Use a static flag to ensure initialization happens only once, even across hot reloads.
Implement lifecycle hooks to manage connection state properly.
Provide a withExtensions() method that wraps the singleton with the desired extension chain.

This setup ensures your extensions are always attached to the correct Prisma instance, avoids unnecessary connections, and keeps your application behavior consistent and predictable.

prisma.provider.ts

import { Injectable, OnModuleDestroy, OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';
import { existsExtension, softDeleteExtension } from './prisma.extensions';

@Injectable()
export class PrismaProvider extends PrismaClient implements OnModuleInit, OnModuleDestroy {
  private static initialized = false;
  async onModuleInit() {
    if (!PrismaProvider.initialized) {
      PrismaProvider.initialized = true;
      await this.$connect();
    }
  }
  async onModuleDestroy() {
    if (PrismaProvider.initialized) {
      PrismaProvider.initialized = false;
      await this.$disconnect();
    }
  }
  withExtensions() {
    return this.$extends(existsExtension).$extends(softDeleteExtension);
  }
}

4. Extended Prisma Service

In the previous sections, we designed a PrismaProvider that manages Prisma’s lifecycle as a singleton and offers a .withExtensions() method to attach custom Prisma extensions like exists and softDelete.

However, to make this extended Prisma client seamlessly injectable and usable throughout your NestJS app, it’s helpful to introduce a dedicated PrismaService class. This class acts as a thin wrapper that inherits from the extended Prisma client instance returned by PrismaProvider.withExtensions().

By doing so, PrismaService:

Encapsulates the extended Prisma client as a proper injectable NestJS service
Abstracts away the need for consumers to manually call .withExtensions()
Provides a clean, type-safe Prisma client interface enhanced with all your custom extensions

The trick here is to create a dynamic class ExtendedPrismaClient that takes the singleton PrismaProvider and returns its extended client. Then, PrismaService extends this class and can be injected anywhere via NestJS’s DI system.

This glue layer improves code clarity and encourages consistent use of your extended Prisma client, making your database access both powerful and ergonomic.

prisma.service.ts

import { Injectable, Type } from '@nestjs/common';
import { PrismaProvider } from './prisma.provider';

const ExtendedPrismaClient = class {
  constructor(provider: PrismaProvider) {
    return provider.withExtensions();
  }
} as Type<ReturnType<PrismaProvider['withExtensions']>>;

@Injectable()
export class PrismaService extends ExtendedPrismaClient {
  constructor(provider: PrismaProvider) {
    super(provider);
  }
}

Using PrismaService for exists and softDelete:

user.service.ts

@Injectable()
export class UserService {
  constructor(private readonly prisma: PrismaService) {}

  // Check if a user exists by email
  async userExists(email: string): Promise<boolean> {
    return this.prisma.user.exists({
      where: { email },
    });
  }

  // Soft delete a user by ID
  async softDeleteUser(userId: number): Promise<void> {
    await this.prisma.user.softDelete({
      where: { id: userId },
    });
  }
}

3. Conclusion

Integrating Prisma with NestJS is straightforward at first glance, but improper initialization can lead to subtle, hard-to-debug issues like multiple database connections, memory leaks, or inconsistent extension behavior. Common pitfalls include creating multiple PrismaClient instances, ignoring lifecycle management, or incorrectly applying extensions without a stable singleton.

The optimal approach is to create a dedicated Prisma provider that acts as a singleton, managing connection lifecycle through NestJS’s module hooks. This ensures Prisma connects once, disconnects cleanly, and extensions are reliably attached to the same client instance.

To complement the singleton provider, a dedicated Prisma service acts as a clean, injectable interface that exposes the extended Prisma client throughout your NestJS application. This service abstracts away the complexity of managing extensions and lifecycle, allowing your business logic to access Prisma with all custom enhancements seamlessly. Together, the provider and service form a solid foundation for scalable, maintainable database interactions in NestJS projects using Prisma.

By adopting this pattern, you not only improve application stability and performance but also unlock the full potential of Prisma’s custom extensions — making your database access code cleaner, more maintainable, and robust.

Executing the Angular guards sequentially

Milan Barać — Fri, 06 Jun 2025 09:54:52 +0000

Angular runs multiple route guards in parallel by default — great for performance, not so great when guards depend on each other. If your authGuard needs to finish before permissionGuard runs, you're out of luck... unless you control the execution flow. In this article, we walk through a clean, reusable utility that forces guards to run sequentially, ensuring dependent logic behaves predictably — all without giving up type safety or Angular's DI.

1. Introduction

In Angular, when multiple route guards like CanActivate or CanMatch are assigned to a route, they are executed in parallel. While this works well in many cases, it can cause issues when guards have dependencies on each other — for example, when one guard must ensure authentication before another checks user permissions. In such scenarios, executing guards in sequence becomes essential. Fortunately, this behavior can be customized with a simple utility function that ensures guards run one after another, giving you more control over route access logic.

2. Solution 🧠

To address the challenge of dependent guard execution, a lightweight utility function can be introduced to chain guards sequentially. Instead of relying on Angular’s default parallel evaluation, this utility ensures that each guard runs only if the previous one has allowed navigation to continue. It works seamlessly with both CanActivate and CanMatch guards, preserving type safety and supporting async operations. With this approach, complex access control logic that depends on prior checks — such as authentication before permission validation — becomes predictable and maintainable.

2.1 Guard utility

The utility is designed to support both CanActivateFn and CanMatchFn, making it versatile enough to cover all standard routing guard scenarios in Angular. Whether you're guarding access to a route (CanActivate) or determining if a route should even match the URL (CanMatch), the same chaining logic applies seamlessly. This unified approach ensures consistent behavior and simplifies guard composition across your entire routing configuration.

guard.util.ts

import { inject, Injector, runInInjectionContext } from '@angular/core';
import {
  ActivatedRouteSnapshot,
  CanActivateFn,
  CanMatchFn,
  GuardResult,
  MaybeAsync,
  Route,
  RouterStateSnapshot,
  UrlSegment
} from '@angular/router';
import { from, isObservable, of } from 'rxjs';
import { switchMap } from 'rxjs/operators';

export function chainActivateGuards(...guards: CanActivateFn[]): CanActivateFn {
  return (route: ActivatedRouteSnapshot, state: RouterStateSnapshot): MaybeAsync<GuardResult> => {
    return chainGuards((guard) => guard(route, state), guards);
  };
}

export function chainMatchGuards(...guards: CanMatchFn[]): CanMatchFn {
  return (route: Route, segments: UrlSegment[]): MaybeAsync<GuardResult> => {
    return chainGuards((guard) => guard(route, segments), guards);
  };
}

function chainGuards<T>(applyGuard: (guard: T) => MaybeAsync<GuardResult>, guards: T[]): MaybeAsync<GuardResult> {
  const injectionContext = inject(Injector);

  return guards.reduce(
    (acc, guard) =>
      acc.pipe(
        switchMap((result) =>
          result === true ? runInInjectionContext(injectionContext, () => toObservable(applyGuard(guard))) : of(result)
        )
      ),
    of(true)
  );
}

function toObservable<T>(input: MaybeAsync<T>) {
  return isObservable(input) ? input : input instanceof Promise ? from(input) : of(input);
}

2.2 Guards

It’s best practice to declare each guard as an atomic, single-responsibility function that handles one specific check — for example, authentication, permission, or feature flag validation. This modular approach makes guards easier to maintain, test, and reuse. Then, you can compose these atomic guards in the desired sequence using the chaining utility, keeping your logic clear and flexible.

auth-activate.guard.ts

import { inject } from '@angular/core';
import { ActivatedRouteSnapshot, CanActivateFn, GuardResult, MaybeAsync, RouterStateSnapshot } from '@angular/router';
import { NotificationService } from '@shared/components/notification/notification.service';
import { AbilityFactory } from '@shared/factories/ability.factory';
import { AccountService } from '@shared/stores/account/account.service';
import { TokenRepository } from '@shared/stores/token/token.repository';
import { map, of, switchMap, take } from 'rxjs';

export const authActivateGuard: CanActivateFn = (
  route: ActivatedRouteSnapshot,
  state: RouterStateSnapshot
): MaybeAsync<GuardResult> => {
  const tokenRepository: TokenRepository = inject(TokenRepository);
  const accountService: AccountService = inject(AccountService);
  const abilityFactory: AbilityFactory = inject(AbilityFactory);
  const notification: NotificationService = inject(NotificationService);

  const subject = route.data['ability']?.subject;
  const denied = `Access denied to "${state.url}".`;

  const authCheck$ = tokenRepository.isLoggedIn$.pipe(take(1));

  return authCheck$.pipe(
    switchMap((isLoggedIn) => {
      if (isLoggedIn) {
        const abilityCheck$ = subject ? abilityFactory.checkAbility(subject).pipe(take(1)) : of(true);

        return abilityCheck$.pipe(
          map((canAccess) => {
            if (canAccess) {
              return true;
            } else {
              logWarning(denied, 'User has insufficient privileges.');
              showError('App.Forbidden');
              accountService.resetStores();
              return accountService.pointToForbidden();
            }
          })
        );
      } else {
        logWarning(denied, 'User is not logged in.');
        showError('App.LoginRequired');
        accountService.resetStores();
        return of(accountService.pointToLogin());
      }
    })
  );

  function logWarning(warning: string, details: string) {
    console.warn(`${warning} ${details}`);
  }

  function showError(error: string) {
    notification.error(error);
  }
};

company-activate.guard.ts

import { inject } from '@angular/core';
import { ActivatedRouteSnapshot, CanActivateFn, GuardResult, MaybeAsync, RouterStateSnapshot } from '@angular/router';
import { CompanySelectService } from '@layout/auth/content/organizations/company/company-select/company-select.service';

export const companyActivateGuard: CanActivateFn = (
  route: ActivatedRouteSnapshot,
  state: RouterStateSnapshot
): MaybeAsync<GuardResult> => {
  const companySelectService: CompanySelectService = inject(CompanySelectService);
  return companySelectService.selectCompany();
};

country-activate.guard.ts

import { inject } from '@angular/core';
import { ActivatedRouteSnapshot, CanActivateFn, GuardResult, MaybeAsync, RouterStateSnapshot } from '@angular/router';
import { CountrySelectService } from '@layout/auth/content/settings/country/country-select/country-select.service';

export const countryActivateGuard: CanActivateFn = (
  route: ActivatedRouteSnapshot,
  state: RouterStateSnapshot
): MaybeAsync<GuardResult> => {
  const countrySelectService: CountrySelectService = inject(CountrySelectService);
  return countrySelectService.selectCountry();
};

office-activate.guard.ts

import { inject } from '@angular/core';
import { ActivatedRouteSnapshot, CanActivateFn, GuardResult, MaybeAsync, RouterStateSnapshot } from '@angular/router';
import { OfficeSelectService } from '@layout/auth/content/organizations/office/office-select/office-select.service';

export const officeActivateGuard: CanActivateFn = (
  route: ActivatedRouteSnapshot,
  state: RouterStateSnapshot
): MaybeAsync<GuardResult> => {
  const officeSelectService: OfficeSelectService = inject(OfficeSelectService);
  return officeSelectService.selectOffice();
};

3. Implementation

To use the utility in your routing configuration, simply pass your guards in the desired execution order to either chainActivateGuards or chainMatchGuards. These helper functions ensure your guards run sequentially, respecting the flow you define. Here's how you might apply it directly in your Routes array:

organization-routes.ts

import { Routes } from '@angular/router';
import { authActivateGuard } from '@core/guards/auth-activate.guard';
import { companyActivateGuard } from '@core/guards/company-activate.guard';
import { countryActivateGuard } from '@core/guards/country-activate.guard';
import { officeActivateGuard } from '@core/guards/office-activate.guard';
import { RouteDataResolver } from '@core/resolvers/route-data.resolver';
import { chainActivateGuards } from '@core/utils/guard.utils';
import { CompanyListComponent } from './company/company-list/company-list.component';
import { OfficeListComponent } from './office/office-list/office-list.component';
import { WorkingHourListComponent } from './working-hour/working-hour-list/working-hour-list.component';

export const ORGANIZATIONS_ROUTES: Routes = [
  {
    path: 'companies',
    component: CompanyListComponent,
    canActivate: [authActivateGuard],
    data: {
      section: 'Organizations.Title',
      title: 'Organizations.Company.Title',
      subtitle: 'Organizations.Company.Subtitle',
      ability: {
        subject: 'Company'
      }
    },
    resolve: { url: RouteDataResolver }
  },
  {
    path: 'offices',
    component: OfficeListComponent,
    canActivate: [chainActivateGuards(authActivateGuard, companyActivateGuard, countryActivateGuard)],
    data: {
      section: 'Organizations.Title',
      title: 'Organizations.Office.Title',
      subtitle: 'Organizations.Office.Subtitle',
      ability: {
        subject: 'Office'
      }
    },
    resolve: { url: RouteDataResolver }
  },
  {
    path: 'working-hours',
    component: WorkingHourListComponent,
    canActivate: [chainActivateGuards(authActivateGuard, companyActivateGuard, officeActivateGuard)],
    data: {
      section: 'Organizations.Title',
      title: 'Organizations.WorkingHour.Title',
      subtitle: 'Organizations.WorkingHour.Subtitle',
      ability: {
        subject: 'WorkingHour'
      }
    },
    resolve: { url: RouteDataResolver }
  },
  { path: '', redirectTo: 'companies', pathMatch: 'full' }
];

4. Conclusion

Angular’s default behavior of running multiple guards in parallel can lead to unexpected issues when guard execution depends on the outcome of previous checks. By introducing the chainActivateGuards and chainMatchGuards utility functions, we gain precise control over guard sequencing, ensuring each guard only runs if all prior guards have allowed navigation to proceed. This simple yet powerful pattern enhances guard reliability and maintainability without sacrificing Angular’s reactive and asynchronous nature. Incorporating these chained guards into your Angular applications can greatly simplify complex authorization flows and improve the overall user experience.

One challenge when creating reusable guard utilities in Angular is managing dependency injection outside of class-based guards. Since standalone guard functions can’t use constructor injection, accessing services like authentication or notifications can be difficult. Fortunately, Angular provides a solution through the Injector and the runInInjectionContext function. By injecting the current Injector and executing logic within its context, guard functions can access Angular services using the inject() function — just like they would in a class. This makes it possible to build flexible utilities like chainActivateGuards and chainMatchGuards that execute guards sequentially while maintaining full access to dependency injection. The result is a clean, modular, and testable approach to composing guards with complex service requirements.

Angular Fullscreen

Milan Barać — Fri, 06 Jun 2025 09:45:42 +0000

In modern day web applications, the requirement to view certain contents in fullscreen mode is becoming pretty common. Sometimes, this need arises in contexts like image galleries, content editors, or other scenarios.

If you ever need to implement such a feature in Angular application, the easiest way to do this is by creating a directive to support fullscreen mode.

Let’s craft a versatile directive that can seamlessly attach to any HTML element, including the main HTML document. With its adaptability, this directive ensures compatibility with most modern-day browsers’ https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API.

Fullscreen directive

import { DOCUMENT } from '@angular/common';
import {
  Directive,
  ElementRef,
  EventEmitter,
  HostBinding,
  HostListener,
  Inject,
  Input,
  Output,
} from '@angular/core';

export interface FullscreenTransition {
  isFullscreen: boolean;
  element: Element | null;
}

@Directive({
  selector: '[fullscreen]',
  exportAs: 'fullscreen',
})
export class FullscreenDirective {
  private element!: HTMLElement;

  @Input()
  set fullscreen(element: HTMLElement | string) {
    if (element instanceof ElementRef) {
      this.element = element.nativeElement;
    } else if (element instanceof HTMLElement) {
      this.element = element;
    } else if (element === '') {
      this.element = this.doc.documentElement;
    } else {
      throw new Error(
        `Only type HTMLElement or string allowed, got "${typeof element}".`
      );
    }
  }

  get fullscreen(): HTMLElement {
    return this.element;
  }

  @HostBinding('class.fullscreen')
  get isFullscreen(): boolean {
    return this.isFullscreenEnabled();
  }

  @HostListener('document:fullscreenchange')
  private onTransition() {
    const isFullscreen = this.isFullscreen;
    const element = this.element;
    this.change.emit({ isFullscreen, element });
  }

  @Output()
  change = new EventEmitter<FullscreenTransition>();

  constructor(@Inject(DOCUMENT) private doc: Document) {}

  async enter() {
    if (this.fullscreen) {
      await this.enterElementFullscreen(this.fullscreen);
    } else {
      await this.enterDocumentFullscreen();
    }
  }

  async exit() {
    if (this.isFullscreen) {
      await this.exitFullscreen();
    }
  }

  toggle() {
    if (this.isFullscreen) {
      this.exit();
    } else {
      this.enter();
    }
  }

  private async enterDocumentFullscreen() {
    const elem = this.doc.documentElement;
    await this.enterFullscreen(elem);
  }

  private async exitDocumentFullscreen() {
    await this.exitFullscreen();
  }

  private async enterElementFullscreen(elem: HTMLElement) {
    await this.enterFullscreen(elem);
  }

  private async exitElementFullscreen() {
    await this.exitFullscreen();
  }

  private async enterFullscreen(elem: HTMLElement) {
    await ((elem as any).requestFullscreen?.() ||
      (elem as any).webkitRequestFullscreen?.() ||
      (elem as any).mozRequestFullScreen?.() ||
      (elem as any).msRequestFullscreen?.());
  }

  private async exitFullscreen() {
    await ((this.doc as any).exitFullscreen?.() ||
      (this.doc as any).webkitExitFullscreen?.() ||
      (this.doc as any).mozCancelFullScreen?.() ||
      (this.doc as any).msExitFullscreen?.());
  }

  private isFullscreenEnabled(): boolean {
    return !!(
      (this.doc as any).fullscreenElement ||
      (this.doc as any).webkitFullscreenElement ||
      (this.doc as any).mozFullScreenElement ||
      (this.doc as any).msFullscreenElement
    );
  }
}

Implementation of this directive is pretty straightforward.

Triggering the specific HTML element in fullscreen mode:

<div
  #fullscreen
  [fullscreen]="fullscreen"
  (change)="onFullscreenChange($event)"
>
</div>

Triggering the entire HTML document in fullscreen mode:

<div
  #fullscreen
  fullscreen
  (change)="onFullscreenChange($event)"
>
</div>

The HTML element bound to directive is getting a fullscreenCSS class, to allow further styling of the element, if needed:

@HostBinding('class.fullscreen')
get isFullscreen(): boolean {
  return this.isFullscreenEnabled();
}

Event changeemitter can be used to track fullscreen transition:

@HostListener('document:fullscreenchange')
private onTransition() {
  const isFullscreen = this.isFullscreen;
  const element = this.element;
  this.change.emit({ isFullscreen, element });
}

@Output()
change = new EventEmitter<FullscreenTransition>();

export interface FullscreenTransition {
  isFullscreen: boolean;
  element: Element | null;
}

onFullscreenChange(event: FullscreenTransition) {
  this.isFullscreen = event.isFullscreen;
}

Incorporating fullscreen functionality into Angular applications using a custom directive offers users a seamless and immersive experience. By leveraging the flexibility and compatibility of modern browsers, developers can enhance the usability of their web applications. With the provided directive and accompanying demo, implementing fullscreen mode becomes easy, empowering developers to create dynamic and engaging user interfaces.

This is the final result of the demo application:

Github project · Stackblitz example

Spring Boot Cassandra Pagination

Milan Barać — Fri, 06 Jun 2025 09:26:44 +0000

Getting paginated data from Cassandra database in Spring Boot application can be a huge challenge, if you want to do the things right.

DataStax Java driver supports data paging, up to some extent. Using the native paging support via cluster configuration might look like this:

// At initialization:
Cluster cluster = Cluster.builder()
    .addContactPoint("127.0.0.1")
    .withQueryOptions(new QueryOptions().setFetchSize(2000))
    .build();

// Or at runtime:
cluster.getConfiguration().getQueryOptions().setFetchSize(2000);

The fetch size can also be set on a statement:

Statement statement = new SimpleStatement("your query");
statement.setFetchSize(2000);

If not set, the fetch size defaults to 5000.

Result set iteration is done this way:

ResultSet rs = session.execute("your query");
for (Row row : rs) {
    if (rs.getAvailableWithoutFetching() == 100 && !rs.isFullyFetched())
        rs.fetchMoreResults(); // this is asynchronous
    // Process the row ...
    System.out.println(row);
}

Now comes the part which usually gives you a headache, if you want to allow your API service call to collect and return Pageable data.

Native DataStax Java driver allows saving and reusing paging state:

ResultSet resultSet = session.execute("your query");
// iterate the result set...
PagingState pagingState = resultSet.getExecutionInfo().getPagingState();

String string = pagingState.toString();
byte[] bytes = pagingState.toBytes();

The URL to the next page is passed as http://someservice.com/results?page=<...>. The state value can be deserialised later and used in a query:

PagingState pagingState = PagingState.fromString(string);
Statement st = new SimpleStatement("your query");
st.setPagingState(pagingState);
ResultSet rs = session.execute(st);

Now, if you want to allow the frontend application to render a nice pagination component like this, the native state exchanging mechanism simply won't be enough:

We need to keep track of paging state in terms of page, size and total properties, required by frontend application.

This problem can be bypassed by creating two simple utility Java classes. The first one serves as a class to contain paging states and total number of rows, while the second one does the actual pagination:

package com.acme.library.utils;

import com.datastax.driver.core.PagingState;

import java.util.HashMap;
import java.util.Map;

public class PagingStats {
    private Map<Integer, PagingState> states = new HashMap<>();
    private Integer total = 0;

    private PagingStats() {
    }

    private PagingStats(Map<Integer, PagingState> states, Integer total) {
        this.states = states;
        this.total = total;
    }

    public static PagingStats createStats(Map<Integer, PagingState> state, Integer total)
    {
        return new PagingStats(state, total);
    }

    public Map<Integer, PagingState> getStates() {
        return states;
    }

    public void setStates(Map<Integer, PagingState> states) {
        this.states = states;
    }

    public Integer getTotal() {
        return total;
    }

    public void setTotal(Integer total) {
        this.total = total;
    }
}

package com.acme.library.utils;

import com.datastax.driver.core.PagingState;
import com.datastax.driver.core.ResultSet;
import com.datastax.driver.core.Session;
import com.datastax.driver.core.Statement;
import com.datastax.driver.mapping.Mapper;
import com.datastax.driver.mapping.Result;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.PageImpl;
import org.springframework.data.domain.Pageable;

import java.util.*;

public class PagingUtil {

    private final static Logger log = LoggerFactory.getLogger(PagingUtil.class);

    /**
     *
     * Retrieve Page of database rows for the specified pageable param.
     *
     * @param mapper mapper
     * @param session session
     * @param select select
     * @param pageable pageable
     * @return Page
     * @param <T> T
     */
    public static <T> Page<T> getPage(Mapper<T> mapper, Session session, Statement select, Pageable pageable) {
        try {
            return getAll(mapper, session, select, pageable);
        } catch (Exception e) {
            log.error(String.format("Error getting pageable data: %s", e.getMessage()));
            return new PageImpl<>(new ArrayList<>(0), pageable, 0);
        }
    }

    /**
     * Retrieve paging stats with states and total
     *
     * @param session session
     * @param select select statement
     * @param size size
     * @return PagingStats
     */
    private static PagingStats getPagingStats(Session session, Statement select, Integer size) {
        // Prepare stats variables
        Map<Integer, PagingState> states = new HashMap<>();
        PagingState state = null;

        int n = 0;
        int total = 0;

        do {
            // Get the result
            select.setFetchSize(size).setPagingState(state);
            ResultSet result = session.execute(select);

            // Get stats values
            state = result.getExecutionInfo().getPagingState();
            total += result.getAvailableWithoutFetching();

            if(state != null) {
                states.put(++n, state);
            }
        } while (state != null);

        // Return stats data
        return PagingStats.createStats(states, total);
    }

    /**
     * Map data rows
     *
     * @param mapper mapper
     * @param session session
     * @param statement select statement
     * @return List
     * @param <T> T
     */
    private static <T> Result<T> mapRows(Mapper<T> mapper, Session session, Statement statement) {
        // Get paged results
        ResultSet results = session.execute(statement);

        // Return results
        return mapper.map(results);
    }

    /**
     * Get all paged data
     *
     * @param mapper mapper
     * @param session session
     * @param select select session
     * @param pageable pageable
     * @return Page
     * @param <T> T
     */
    private static <T> Page<T> getAll(Mapper<T> mapper, Session session, Statement select, Pageable pageable) {
        // Get paging stats
        PagingStats stats = getPagingStats(session, select, pageable.getPageSize());

        // Check for page validity
        int start = pageable.getPageNumber() * pageable.getPageSize();

        if (start > stats.getTotal()) {
            return new PageImpl<>(new ArrayList<>(), pageable, 0L);
        }

        // Prepare command parameters
        select.setPagingState(stats.getStates().get(pageable.getPageNumber()));

        // Get and map rows
        Result<T> rows = mapRows(mapper, session, select);

        // Return paged rows
        return new PageImpl<>(rows.all(), pageable, stats.getTotal());
    }
}

The star of the show is the getPagingStats(…) method, which prepares all potential states for a given Pageable parameter all at once, keeping track of total number of rows too.

Then, the getPage(…) method does the actual pagination, executing the given Select statement for the open Session and Pageable parameter.

The Select statement gets the exact paginated data by looking up the hashed state, depending on given Pageable parameter.

The paginated data are mapped from raw data to entity format using given Mapper<…>.

The PagingUtil class is used like this in repository layer:

private Mapper<Action> mapper = new MappingManager(session).mapper(Action.class);

private PreparedStatement findAllStmt = session.prepare("SELECT * FROM action");

private Page<Action> getPageFromSelect(BoundStatement select, Pageable pageable) {
    return PagingUtil.getPage(mapper, session, select, pageable);
}

public Page<Action> findAllPageable(Pageable pageable) {
    return getPageFromSelect(findAllStmt.bind(), pageable);
}

Service layer might look like this:

public Page<Action> findAllPageable(Pageable pageable) {
    return actionRepository.findAllPageable(pageable);
}

Then in REST controller:

/**
 * GET  /action/pageable : get all actions pageable.
 *
 * @param pageable the pagination information
 * @return the ResponseEntity with status 200 (OK) and with body all actions
 */
@GetMapping("/action/pageable")
@Protected
@Audited
@ApiOperation(value = "Get all actions paged", response = Action.class, responseContainer = "List", authorizations = { @Authorization(value = "token"), @Authorization(value = "secret"), @Authorization(value = "basic") })
public ResponseEntity<List<Action>> getAllActionsPageable(@Param Pageable pageable) {
    Page<Action> page = actionService.findAllPageable(pageable);
    HttpHeaders headers = PaginationUtil.generatePaginationHttpHeaders(page, "/action/pageable");
    return new ResponseEntity<> (page.getContent(), headers, HttpStatus.OK);
}

REST API call executed from frontend client can have this format:

http://someservice.com/results/api/action/pageable?page=4&size=10

with the following json response:

[
  {
    "id": 41,
    "name": "getAllRoles"
  }, 
  {
    "id": 42,
    "name": "getAllUsers"
  },
  ...
]

The response headers are used for sending paging data to a client:

Link:

</action/pageable?page=5&size=10>; rel="next",</action/pageable?page=3&size=10>; rel="prev",</action/pageable?page=31&size=10>; rel="last",</action/pageable?page=0&size=10>; rel="first"

Total:

311

These paging data can finally be used to update pagination component:

This utility has been tested with ~100k records and works blazingly fast.