Taiga UI is an Open Source Angular UI library that helps developers build modern, reliable user interfaces. We recently shipped the fifth major release, bringing a ton of architectural improvements and new capabilities. In this article, we’ll take a deep dive into the highlights of version 5.0.0 and explain why you should plan your upgrade as soon as possible.

Fresh Minimum: Angular 19+

In this new major version of our libraries, we raised the minimum supported Angular version to 19 and above. This means we can take advantage of all the new features and improvements added since Angular 16 (the minimum supported version in the previous Taiga UI major). And the paradigm shift toward a signal-based style has changed a lot in our codebase.

Signal Inputs

All our hundreds of components and directives said goodbye to classic properties decorated with @Input() and switched to their signal-based counterpart — input. Previously, our code had a lot of getters that internally used a private class method decorated with @tuiPure for memoization. Here's a simplified example of that approach:

@Input({required: true})
fileName: string;

// Used in the template
// (potentially recalculated on every re-render)
get type(): string {
   return this.getType(this.file);
}

@tuiPure
private getType(file: string): string {
   const dot = file.lastIndexOf('.');

   return dot > 0 ? file.slice(dot) : '';
}

Now, with signal-based computed, getters are no longer needed, and we can write cleaner, more readable code without extra optimizations. computed takes care of memoization automatically.

file = input.required<string>();

type = computed(() => {
   const dot = file.name.lastIndexOf('.');

   return dot > 0 ? file.name.slice(dot) : '';
});

We’re sending the @tuiPure decorator off into honorable retirement: you were a good friend and helper for many years — thank you!

Signal viewChild(-ren) / contentChild(-ren)

In Taiga components, we frequently used the @ViewChild(‑ren) and @ContentChild(‑ren) decorators. You decorate a property in a component — and the requested DOM element, directive or provider gets automatically assigned to it. A significant limitation of this approach was that these elements only became available in the AfterViewInit and AfterContentInit lifecycle hooks. As a result, constructs like this could pop up in our codebase:

@Component(...)
export class AnyComponent {
   private contentReady$ = new ReplaySubject<boolean>(1);

   children$ = this.contentReady$.pipe(
       switchMap(() => this.childrenQuery.changes),
   )

   @ContentChildren('ref')
   childrenQuery!: QueryList<any>;

   ngAfterContentInit() {
       this.contentReady$.next(true);
   }
}

The contentReady$ stream notifies all its observers that it's safe to proceed. The trick of creating such a stream made the code slightly more declarative compared to directly manipulating all observers inside a hook. But it still produced its fair share of boilerplate.

Signal-based viewChild(-ren) and contentChild(-ren) are a real game-changer. You can practically forget about the AfterViewInit and AfterContentInit hooks, because signals created via viewChild and contentChild know when to update on their own, and all their subscribers automatically recalculate reactively. All those lines from the old approach are replaced by a single built-in one-liner.

Signals Over RxJS

Even though our team deeply respects RxJS and is confident it’ll be around for a long time, we genuinely fell in love with signals. We decided to make them the priority in our public API — not just because of their growing popularity in the Angular community, but because for many reactive tasks they’re a much better fit than RxJS, letting us provide better support and write more optimal, understandable code.

Here are just a few examples of changes from the new major version — the updated TUI_NUMBER_FORMAT and TUI_DATE_FORMAT.

// Before
inject(TUI_NUMBER_FORMAT) // Observable<TuiNumberFormatSettings>
inject(TUI_DATE_FORMAT) // Observable<TuiDateFormatSettings>

// After 
inject(TUI_NUMBER_FORMAT) // Signal<TuiNumberFormatSettings>
inject(TUI_DATE_FORMAT) // Signal<TuiDateFormatSettings>

To sum up the thought about the dawn of the “signal era” in the Taiga codebase: we don’t resist the new trends set by the Angular team. And most importantly, we don’t prevent our users from seamlessly harnessing the full power of signals when building applications with Taiga UI!

We’ve already seen the benefits of the signal-based style firsthand. Less boilerplate, better performance, dramatically fewer Change Detection bugs, and improved support for Zoneless applications!

New Esbuild + Vite Build Engine

Another important change driven by raising the minimum Angular version is the switch to the modern Esbuild + Vite build engine. This move not only improved our own Developer Experience (build time during local development was significantly reduced), but also allowed us to catch bugs in YOUR Esbuild applications (the default for all new Angular apps) before we even release our libraries.

And these aren’t just words — we’ve already fixed several esbuild incompatibility bugs related to circular dependencies (#12435 and #12438), as well as CSS selector specificity issues (#12544, #12543, #12553).

Control Flow

Before Control Flow appeared, the Taiga UI team had already been publishing the structural directive *tuiLet for many years, which allowed you to declare a local variable in a template. The local variable declaration approach was extremely popular. It has now been replaced by the new built-in @let syntax.

The Taiga *tuiLet directive is now gracefully retiring, making way for the built-in @let syntax — which, as a nice bonus, requires zero imports!

Shiny New Component Showcase

We’ve significantly reworked the design and content of our documentation. It now features improved navigation and a more intuitive interface.

I’d also like to remind you that the engine behind our documentation is a reusable solution published as the npm package @taiga-ui/addon-doc. It’s already actively used not only for Taiga UI docs, but also in other Taiga Family products: Maskito, Taiga Editor, Ng Morph, and Ng Draw Flow. This package keeps evolving and gaining new features (for example, a brand-new Table of Contents component was added in this release). You can always use @taiga-ui/addon-doc to build documentation for your own library!

Browser Bump

Here’s a little secret: the favorite part of every major release for Taiga UI maintainers is bumping the minimum supported browser versions. It unlocks new capabilities and features that we happily use in our libraries to write even cleaner and more reliable code.

Already in Taiga UI v4, we set a course for adding RTL support to our libraries. That’s right — we expanded our audience to include Middle Eastern and Central Asian products! With the new browser support, we got access to an even wider list of logical CSS properties, such as inset, padding-inline, margin-inline, and many others.

RTL support has become even easier to maintain, and the code is more robust (since it’s now handled by native logical CSS properties instead of our old fallbacks and workarounds).

We also got access to BigInt. It feels nice to finally have access to all JavaScript data types — at least by 2026! :D We immediately put this to use and added BigInt support to our @maskito/kit library in the Number mask and in our Taiga InputNumber component.

Angular Animations — Goodbye!

Starting with Angular 20.2, the @angular/animations package has been marked as deprecated. And the official Angular documentation now reads as follows:

You can replace all animations based on @angular/animations with plain CSS or JS animation libraries. Removing @angular/animations from your application can significantly reduce the size of your JavaScript bundle. Native CSS animations generally offer superior performance, as they can benefit from hardware acceleration.

And we responded promptly. In Taiga UI v5, we completely dropped the @angular/animations package: all existing animations have been rewritten using pure native CSS, and @angular/animations has been entirely removed from the dependency list of our packages! No more mandatory provideAnimations() just to get Taiga UI up and running.

The trickiest part was natively rewriting the logic around the former :leave mechanism. Currently, there’s no convenient CSS alternative for animating an element leaving the DOM without timers and boilerplate code. But my colleague found an elegant solution to this problem as well. The @taiga-ui/cdk library got a new Animated directive. Just slap this directive on any DOM element — when it appears or disappears, the element gets a CSS class tui-enter / tui-leave, and you can define any CSS animations for that class. All without code boilerplate and in the true Angular way!

It’s also great that we’re moving in the same direction as the Angular team. The Animated directive neatly anticipated the future syntax that the Angular team introduced very recently in their v21 announcement — animate.enter and animate.leave. Migrating from our solution to the built-in Angular syntax will be as simple as it gets — just replace the tuiAnimated directive on an element with animate.enter="tui-enter" and animate.leave="tui-leave" (and keep the CSS files unchanged).

A nice bonus: our Animated directive has been cherry-picked into the fourth major version of Taiga, so you can start gradually moving away from Angular animations in your app right now — even before you begin upgrading your Taiga UI version, and even if your app's Angular version is significantly older than 20.2. And when you upgrade Taiga to v5, @angular/animations will simply disappear from your node_modules.

Simplified Taiga UI Setup for Your Project

Inspired by the modern Angular naming conventions for DI utility functions (provideRouter, provideServerRendering, provideZoneChangeDetection, etc.), we decided to simplify the process of adding Taiga UI to your project. Now, to set up the DI tree, all you need is a single call to provideTaiga(), which automatically provides all the necessary dependencies and initial configurations for our components to work.

For you, it’s just one function call, but under the hood it takes care of automatic font scaling, dark/light theme setup, and other internal configurations needed for Taiga UI components to function correctly!

New Text Fields Are Now a Stable API

We kicked off the large-scale text field refactoring back in the previous major version. At that time, we moved all our old control versions into the @taiga-ui/legacy package (to ensure a smooth migration path for users to the new public API) and started rewriting each component from scratch using fresh design specs and modern Angular features (decomposition via host directives + signals).

The task turned out to be quite challenging and extremely labor-intensive, but the results will genuinely make you happy. The new text fields offer a declarative way to customize through HTML markup and a uniform public API across all types of controls. Once you understand the customization concepts for one type of text field, you can easily customize any other control — without even looking at the docs!

Another key feature of the new text fields is their openness. Everything you need is exposed, so you can bring even the wildest ideas to life. Just take a look at this InputDate example:

<tui-textfield>
  <label tuiLabel>Choose a date</label>
  <input tuiInputDate [formControl]="control" />

  <ng-container *tuiDropdown>
    <tui-calendar [markerHandler]="markerHandler" />

    <button
      tuiButton
      (click)="..."
    >
      Today
    </button>
  </ng-container>
</tui-textfield>

First, all the input parameters of the <tui-calendar /> component are fully at our disposal — no prop drilling like in the previous version of this control! Second, we can freely add any elements (even interactive ones!) to the calendar dropdown — for example, a "Today" button with a custom click handler!

And this applies to every type of text field (and there are over 15 of them!). With the release of the fifth major version, our large-scale text field refactoring is officially complete. Their public API is fully stabilized, and the previous generation of these controls has been permanently removed from the @taiga-ui/legacy package.

For those who prefer gradual changes in life and code, we cherry-picked all important fixes for the new text fields into the fourth major version, making the migration to the new major as smooth as possible. Before upgrading to Taiga v5, you can iteratively update your codebase, mixing old and new text fields, so the upcoming migration is as comfortable and painless as it can be.

Improved Icon Component

In the previous major release announcement, I mentioned that for icons we moved away from the old approach of using <svg /> with the <use /> tag in favor of CSS masks.

Back then, the new approach was implemented in the Icon component and brought numerous benefits: the ability to store icons on a CDN and render them without DOM manipulations or a sanitizer, automatic browser caching, and a simplified way to scale icons.

But we didn’t stop there and continued to develop this further. Starting with the fifth major version, this component can do significantly more:

• You can now control not only the icon size but also the stroke width of the icon’s content. This capability is demonstrated really well in this interactive documentation example.
• The updated component supports not only classic single-color icons but also multi-color and font-based icons! They’re managed through the @tui, @img, and @font prefixes, and the component figures out under the hood how to render the icon based on its type: via CSS mask, background-image, or font + content on the :before pseudo-element. You can see it in action in this example.

And Much More!

• Portals have been completely rewritten and streamlined into a single grid-based container. It’s now even easier to customize dialogs, simpler to manage notifications and their subtypes (screen position, number of simultaneous instances), and easier to create your own custom portal entities through new abstract classes and services.
• A new Popout service that simplifies displaying custom content in Picture-in-Picture mode or opening a piece of your application in an entirely new tab.
• We stabilized the use of the CloseWatcher web API in Taiga dialogs. Now, when a dialog is open on an Android device and the user taps the browser’s “Back” button, the dialog simply closes — instead of navigating to the previous route behind the open dialog.
• A revamped Accordion. We’re continuing the trend (that accompanies every Taiga major version) of minimal DOM element nesting in our components, which should make it easier for you to customize them and set native attributes like ARIA attributes or id — and now the accordion has joined the ranks of the “lucky ones.”
• Automatic font scaling is now enabled by default. Many users rely on iOS/Android system accessibility settings to increase the font size across all interfaces on their mobile devices — including web apps. Taiga components can read this system setting and adapt, making your interfaces comfortable for users with visual impairments.
• We dropped the use of our custom decorators — you’re free to build your application with any value of the TypeScript experimentalDecorators flag without worrying that Taiga UI components will stop working.
• We’re continuing to actively develop AI tooling support for working with Taiga UI components. Our MCP server now supports the new major version as well. We’re also closely watching the development of WebMCP to integrate its support into our documentation when the time comes.

And a huge number of other improvements and new features that you can find in the release notes.

How to Upgrade?

We did our best to make the migration to the new version as smooth as possible. To that end, we’ve prepared a bunch of migration scripts that will automatically analyze your code and fix most breaking changes — all with a single console command! And anything that was too complex to fix automatically via AST manipulations has been annotated with comments right in the code — complete with hints and links so you can easily finish the migration on your own or with the help of AI agents.

Detailed instructions for running the migration schematics and the necessary preparation steps are available in our upgrade guide.

If you run into any issues or bugs during the upgrade, don’t hesitate to open an issue or ask a question in our Telegram community. The Taiga team can’t wait for your feedback!

See You Soon!

To wrap up, let me just give you a little sneak peek at our future plans.

Very soon you’ll see revamped date picker components — our design team has already delivered fresh design specs with a more modern look for the calendars. During the rework, we plan to address the accumulated feature requests around their customization.

We’re also keeping a close eye on the development of signal-based forms. As of this writing, the new API is still rough around the edges and continues to undergo changes. As soon as it fully stabilizes, we’ll make sure Taiga controls support them.

Finally, one of our big goals for this year is to keep pushing the accessibility of our components forward! All Taiga components traditionally support keyboard navigation but accessibility is a broader topic and we plan to dedicate even more attention to it this year.

See you in upcoming articles and releases!

And a reminder: the easiest way to say thank you is to give us a star on GitHub.

What’s New in Taiga UI v5: A Modern Angular UI Kit was originally published in AngularWave on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week, Angular hit a major milestone: version 20! So it felt like the perfect moment to rewind and see how Angular has grown and changed over the past five years — that’s ten major versions!

But instead of a typical “what’s new” rundown, I want to take you through this journey from a different angle — through the eyes of someone who’s been maintaining a massive UI library for Angular — Taiga UI.

We’re going to skip over the buzzworthy features and focus on the little things that made a huge difference for us. So, buckle up — let me show you what it’s like to be in the shoes of a UI Kit developer!

A Quick Intro (and a Few Disclaimers)

I started working on Taiga UI in June 2021. At that point, we were still on Angular 9, using the legacy View Engine, and the library had just hit its second major release.

Since then, a lot has changed. Taiga UI has gone through big refactorings — often triggered by Angular’s own upgrades. We embraced every meaningful update that opened new doors for UI component architecture.

This post skips over some big application-focused features (typed forms, SSR, hydration, etc.). Those are awesome for app developers, but in the context of a component library? Not as impactful. And conversely, things that might seem trivial to app devs made a world of difference for us.

So let me walk you through the standout changes from each version — but from the point of view of someone who’s been deep in the trenches building and maintaining a big Angular UI library.

Angular 10

Strict mode

Back then, I wasn’t sure if we really needed strict mode. Especially noImplicitAny rule, which instantly scolds you for writing JavaScript-like code.

But looking back now? It was absolutely essential. It helped us catch those classic hello, undefined! bugs early — and trust me, when you’re shipping a component library used in dozens of million-user apps, that’s not just a nice-to-have — it’s non-negotiable.

Moreover, strict mode didn’t just apply to only .ts files. It also made template type checks more robust.

Killer feature of Angular 10? No doubt — strict mode.

Angular 11

Hot Module Replacement (HMR)

Who doesn’t want to rebuild an Angular application faster during development? This was the first attempt at HMR in Angular.

Angular first introduced HMR support back in version 11. Yep, not in 2024 with Angular 19 like some might think — but four years earlier! The excitement in the community was real. Just check out the comments on the original feature request: there were over 10 highly upvoted messages pleading for it — stuff like “we need this feature ASAP!” and even dramatic threats like “I am leaving Angular ASAP!” 😄

Unfortunately, Angular’s first go at this didn’t quite land. Users ran into issues — like lost state and full page reloads. And so, the Angular team had to shelve the effort for better times — only in documentation of Angular 17 plans to bring HMR back reappeared on the roadmap.

Not every major Angular release left a warm and fuzzy memory. This one, for instance, definitely left a bit of a bad taste.

Webpack 5

But there was also something definitely good in this release — support for Webpack 5.

For most devs, that meant long-awaited support for Module Federation in Angular microfrontends. For us at Taiga UI, it also meant we could finally load file contents as plain strings in our documentation examples without needing extra tools like raw-loader or other workarounds — thanks to asset modules.

Angular 12

Ivy Everywhere

The new Ivy engine. Its first “real-world deployment” actually began back in version 9, but it was optional then and its future was still quite uncertain. With Angular 12 and the tagline “Moving Closer to Ivy Everywhere”, Ivy officially replaced the old View Engine (the legacy engine became deprecated).

For Taiga UI, this marked a huge shift. Starting with our third major release, we published our libraries fully Ivy-compatible. And finally, our users could stop taking long coffee breaks waiting for ngcc to finish compiling.

It might seem like a small thing, but we genuinely cared about our users’ time and developer experience!

Plus, we could finally remove over 100 magical @dynamic comments from the codebase and say goodbye to the relic that was entryComponents.

Ivy wasn’t brand new in 12, but this was the moment it became available for libraries.

Angular 13

Farewell, Internet Explorer

This wasn’t just a tech decision — it was a cultural shift. Once Angular dropped IE, so did we. And suddenly our codebase looked so much cleaner without all those if IE workarounds.

IE support was dead, and Taiga UI looked better than ever.

Angular 14

Standalone API

Despite all the positives Standalone API brought to the table, there was a bit of a catch. At Taiga UI, we love to decompose everything we can — really breaking everything down. What looks like one component is often a carefully composed collection of multiple components and directives. Using the old module-based API, that complexity was neatly tucked away inside a single import of a module. But once we moved to standalone components, this suddenly became a real concern.

For example, a seemingly simple component like a slider is actually a composition of several parts — in this case, one component and four directives.

Back in the days of the module-based API, that complexity was hidden from users. You just imported TuiSliderModule and Angular took only required entities. Unused parts? Tree-shaking would take care of them.

But with standalone components, this changed. Now, users needed to import every individual piece manually — which wasn’t great for DX. Tools like WebStorm started suggesting dozens of imports, and that quickly got annoying.

Our solution? We used TypeScript’s as const assertion to group all related parts into a single array. This way, the IDE would suggest importing just one named constant:

export const TuiSlider = [
   TuiSliderComponent,
   TuiSliderThumbLabel,
   TuiSliderKeyStepsBase,
   TuiSliderKeySteps,
   TuiSliderReadonly,
] as const;

Users only had to include TuiSlider in the imports array of their standalone component. To avoid confusion, we also adopted a naming convention — users should import entities without the Component and Directive suffixes.

This simple pattern solved our small problem and opened the door for a smooth migration to standalone components in Taiga UI.

Protected methods in templates

This might seem like a tiny change for application devs, but for library maintainers? It was a delicious win.

Taiga UI components have both public and internal APIs. Naturally, we really don’t want users poking around in the internals — we need freedom to refactor that stuff without breaking things. But until now, we had no choice. If we wanted to use a method in a template, it had to be public. That meant users could — and did — use those methods in unit tests and sometimes even in production code.

It tied our hands during refactors. We had to preserve backward compatibility for methods that were never meant to be used externally.

Thankfully, with this Angular upgrade, we could finally mark those methods as protected and still use them in templates. That lets us safely hide a lot of internal logic and clean up our public API surface. One small compiler change — huge DX payoff.

Optional injectors in embedded views

Big improvement for dropdowns and other “portal” components. Now we can pass injectors directly during initialization of TemplateRef:

viewContainer.createEmbeddedView(templateRef, context, {
   injector: injector, ​​// <-- new feature in Angular 14
})

Now ActiveZone (a DI entity for tracking user interaction with the page) is finally inherited automatically by nested data lists and dropdowns. Previously, users had to do it manually with extra directives in the template — which often led to mistakes.

Tracking user interaction area

inject()

The new inject utility quickly won our hearts. It offered a clean alternative to constructor-based dependency injection, opening up a fantastic way to use DI inside abstract classes — no more prop-drilling through child constructors! On top of that, it drastically improved DX, letting us build all sorts of helpers with DI baked right in.

Angular 15

Directive Composition API (aka Host Directives)

A true gem for UI Kit development!

The funny thing is, the Angular team themselves might not yet fully realize what a powerful decomposition tool they’ve built. There are only three uses of this feature in the entire Angular Material repo. Compare that to Taiga UI — over 90 and counting.

The use cases were so broad for us that we even dedicated a full article to it. Highly recommend checking it out — you might find some patterns useful for your own projects!

But…

• No built-in control for managing inputs from the host. We had to create our own utility tuiDirectiveBinding to handle it manually.
• Inputs and outputs aren’t exposed by default. In our experience, most host directives should expose everything unless explicitly hidden. Angular did the opposite, forcing us to forward every prop manually.
• Double matching errors. You’ll hit a runtime error if the same directive appears more than once on an element. There’s already a bug report for that — highly recommend upvoting it!

So while the feature isn’t flawless, it’s still a game-changer.

Angular 16

Async HostBinding using signals

Thanks to the new mechanism for converting observables into signals (via toSignal() from @angular/core/rxjs-interop), we can now do async host bindings with ease. We used to rely on our own solutions from ng-event-plugins — a bit hacky and not very intuitive. But now? It’s clean and transparent:

import {toSignal} from '@angular/core/rxjs-interop';

@Directive({
   host: {
       '[style.--tui-css-variable]': 'hostBindingValue()',
   },
})
export class SomeDirective {
   anyObservable$: Observable<any> = …;
   hostBindingValue = toSignal(this.anyObservable$);
}

Simplified controller pattern

All those complex Change Detection hacks we used in Taiga UI’s controller pattern? Gone. Now signals trigger change detection automatically when a controller’s input changes — no more manual nudges with ChangeDetectorRef. Less manual lifecycle juggling!

@Input({ required: true })

Sounds useful in theory for UI Kit components, but in practice, required inputs didn’t really catch on at Taiga UI. At the time of writing, we’ve only used it three times across the entire codebase. Why? Because we’ve always had a habit of providing meaningful default values for nearly every input property — so there’s rarely a need to mark anything as strictly required.

Input transforms

Now we can write boolean directives like this (using built-in transformations):

<input tuiAutoFocus />

And internally:

import {Directive, Input} from '@angular/core';
import {
   type BooleanInput,
   coerceBooleanProperty
} from '@angular/cdk/coercion';


@Directive({selector: '[tuiAutoFocus]'})
export class TuiAutoFocus {
   @Input({
       alias: 'tuiAutoFocus',
       transform: coerceBooleanProperty,
   })
   public autoFocus: BooleanInput;
  
   // [...]
}

It might not be groundbreaking, but it’s a super handy way to mimic the behavior of native boolean attributes.

DestroyRef and takeUntilDestroyed

Finally, we could say goodbye to our custom TuiDestroyService 👋

Angular 17

Signal-based inputs

This was when signals really became powerful.

Previously, we had to clutter component code with extra setters just to use an input property as a signal. Now, it’s all baked in.

Lifecycle hooks? Not so much anymore

In Taiga UI components, we’ve often relied on @ViewChild(-ren) and @ContentChild(-ren). As you know, access to those values only becomes available inside AfterViewInit or AfterContentInit, which led us to use patterns like this:

@Component(...)
export class AnyComponent {
   private contentReady$ = new ReplaySubject<boolean>(1);

   children$ = this.contentReady$.pipe(
       switchMap(() => this.childrenQuery.changes),
   )

   @ContentChildren('ref')
   childrenQuery!: QueryList<any>;

   ngAfterContentInit() {
       this.contentReady$.next(true);
   }
}

This pattern helped us make things more declarative, but still added a layer of boilerplate.

Now? Signals like viewChild and contentChild change the game. No more extra streams — signals automatically know when they’re ready and notify their dependents reactively. In most cases, we don’t even need ngOnChanges / ngAfterViewInit / ngAfterContentInit anymore.

And for those rare moments when we do need to interact with fully rendered DOM — for instance, embedding a full-featured chart using some third-party library — Angular now gives us the afterNextRender() hook.

Will lifecycle hooks disappear entirely? Probably not. But thanks to signals, you’ll be using them way less often. And it simplifies Angular for newcomers in a big way.

Angular 18

Fallback content in <ng-content />

Content projection is one of the core ways to make any Angular UI Kit component flexible. Thankfully, Angular’s design around it was smart from the start — with features like select and ngProjectAs baked in. If you want to dig deeper into the power of content projection, check out this article by my teammate — packed with real-world examples from Taiga UI.

And the evolution didn’t stop there. Angular 18 added support for fallback content in <ng-content>, so if nothing gets projected, you can now show a default instead. That’s a fantastic boost for building resilient, flexible components.

Form control events

import {FormControl, Validators} from '@angular/forms';


const control = new FormControl<string>('', Validators.required);
control.events.subscribe(event => {
   // ValueChangeEvent | PristineChangeEvent | TouchedChangeEvent | ...
});

Finally, we can subscribe to events like when a control becomes touched. Fun fact: we’d been tracking this feature request for years. The entire Taiga UI codebase has always been built around the OnPush change detection strategy — except for one traitor: FieldError.

That single component had to stay on the Default strategy because there was no reliable way to detect the touched state. Our team lead wrote back in 2018 on the feature request thread:

I’m with the guys above here, with my entire UI library using OnPush and that scoundrel FieldError component spoiling the party.

Well, not anymore!

New @let syntax

According to the Angular team announcement, the new @let syntax solves one of the most upvoted issues in the Angular community.

Before this was introduced, Taiga UI shipped our own structural directive — *tuiLet — which made it possible to declare local template variables. It caught on fast: over 6,000 usages across all our company projects!

Now, the Taiga version of *tuiLet is retiring with honors, stepping aside for the new built-in feature — which works out of the box, no imports needed. 🎉

Angular 19

Linked signals

Angular’s product and DevRel lead Minko Gechev provides a good description of the new feature:

You can think about it as “writable computed” in a way

I aim to keep things declarative when building signals, and computed syntax helps with that a lot. But every so often, I’d run into that annoying 1% edge case where my beautifully clean computed needed to manually update with some extra if-logic.

Creating a whole separate signal dependency just for that case? Not elegant. That’s where linked signals come to the rescue — they let us handle those exceptions without cluttering up our code.

Error on unused component imports

A really nice little addition. After refactoring, it’s so easy to leave behind unused imports. Sure, tree-shaking will clean them up during build, but having less clutter in your code makes maintenance so much easier — and now Angular points them out for you automatically.

HMR (again!)

It took four years and eight major Angular versions, but we finally got solid HMR support for templates and styles! 😀

Angular 20

It’s hard to judge something you haven’t had much time to try yet. Sure, Angular 20 brought a bunch of great improvements — stabilizing experimental features — but two things stood out to me in the changelog as a real gem.

Dynamic Components Levels Up

Since Angular 14, we’ve had a powerful and handy utility called createComponent that made creating dynamic components a whole lot easier. But back then, its features were pretty limited.

With Angular 20, everything changed!

Now it lets you specify bindings (input/output/two way binding) to dynamically created components and even apply directives (!!!). That’s a real game-changer for UI Kit development!

Typed host bindings

Angular docs has the following recommendation:

Always prefer using the host property over @HostBinding and @HostListener. These decorators exist exclusively for backwards compatibility.

The reasoning? Angular’s broader move away from decorators. The community has already seen modern alternatives to nearly every classic decorator — @Input, @Output, @ViewChild, and so on.

The problem? The host property had poor type checking, which made it far from a drop-in replacement. In practice, we ran into bugs that simply wouldn’t have existed if strong typing were in place.

Thankfully, Angular 20 fixes that. Full type safety has arrived for host bindings, making the docs’ long-standing recommendation finally safe to follow — and making our code safer and more maintainable in the process.

What’s Next?

What else could shake up the daily life of an Angular UI Kit developer in the next major releases? Dropping Angular animations!

The official Angular documentation already features a page titled “Migrating away from Angular’s Animations package”, which says:

Almost all the features supported by @angular/animations have simpler alternatives with native CSS. Consider removing the Angular Animations package from your application, as the package can contribute around 60 kilobytes to your JavaScript bundle. Native CSS animations offer superior performance, as they can benefit from hardware acceleration. Animations defined in the animations package lack that ability.

At Taiga UI, we jumped on this trend early — even before it was widely promoted — and started migrating away from Angular animations in favor of native CSS animations.

And guess what? It really works. Native animations turn out to be concise, straightforward, and totally capable of handling all the same scenarios Angular animations once covered.

The only real challenge? Replacing the :leave behavior in a clean, native way. There’s no great built-in alternative for that — unless you want to mess with timer’s delays and boilerplate. But thankfully, one of my teammates came up with an elegant solution, and now we have no blockers left.

Will Angular animations be deprecated in the next few major versions? Who knows — but I wouldn’t be surprised!

Final Thoughts

I’ll be honest with you — this entire article was one big experiment. I was curious to see what would surface if I really dug through my memory and tried to connect Angular’s changes with how they impacted our day-to-day work on a UI Kit.

It reminded me of that classic movie line: “Life is like a box of chocolates. You never know what you’re gonna get.” Same goes for Angular updates — you don’t always know what will turn out to be a hidden gem — or just unnecessary baggage.

But looking back gives us perspective. It helps us understand what truly matters and gives us a better shot at making smarter choices ahead.

I hope you enjoyed this walk through Angular’s evolution just as much as I did!

Now your turn: what was the biggest killer feature from the past 10 Angular versions for your projects?

Watching Angular Evolve: Taiga UI Kit Maintainer’s Perspective was originally published in AngularWave on Medium, where people are continuing the conversation by highlighting and responding to this story.

December 2023 marked a milestone in the evolution of the CSS mask property. All major browsers, in their latest versions, now fully support it — no vendor prefixes needed anymore. This means this feature is officially here to stay and has become an essential tool for every front-end developer. It’s time for developers to take it on board and leave any doubts behind!

In this article, I’ll quickly go over the key concepts behind this property and then dive into real-world examples based on my experience working with Taiga UI.

What is a mask in CSS?

The term “masking” has historically been used in many areas of life, often with completely different meanings. The kind of mask we’ll be talking about here comes from the world of design. In design, image masking is a popular technique that lets you hide or cut out parts of an image in any shape you want.

Let’s break it down with an oversimplified example.

Here’s a beautiful image generated by an AI using a prompt that included the words “taiga”, “sunset,” and “winter.”

And here’s the lovely logo of our Open Source product — Taiga UI.

It’s important to note that in the last image every area that’s not orange is actually a transparent background. If you’d rather see for yourself, go ahead and check the source file! Keep this in mind — it’s a key detail for everything we’re about to do next.

Let’s build a super simple web app. Inside the body tag, we’ll place just one single img tag, and for the src, we’ll use the image we generated earlier with the AI:

<img src="taiga-winter-sunset.jpeg" />

And in the linked CSS file, we add the following content (don’t worry, we’ll explore each line in detail soon):

body {
   background: mediumpurple;
}
 
img {
   mask-image: url(taiga-logo.svg);
   mask-repeat: no-repeat;
   mask-size: auto 100%;
   mask-position: center;
}

Here’s how it turns out:

Let’s start with the key property, mask-image. We applied an SVG image to it (to keep things simple in this article, I’ll sometimes mention the content passed to mask-image as just “mask”). In this example, the mask has only two types of areas: a transparent background and an orange tree-shaped logo.

The browser took all the non-transparent areas from the mask image — this opaque part defined the visible part of the original sunset picture. Everything else that was transparent got cut out — just like in a kids’ craft project with scissors. What’s more, notice that the parts of the sunset image that disappeared were genuinely removed — we can see the purple background we applied to the body tag.

Alright, now we’ve got the basics of mask-image. Let’s take a closer look at the other properties. Like many love stories say, “you don’t know what you’ve got till it’s gone.” So let’s test this out by removing all the properties except mask-image and see what happens:

img {
   mask-image: url(taiga-logo.svg);
}

We ended up with way too many trees… The issue is that we applied a tiny mask image (the original SVG logo is just 68x60 pixels) to a huge sunset picture. By default, the browser tries to fit in as many mask repeats as possible.

To control this behavior, we use the mask-repeat property. Let’s put it back:

img {
   mask-image: url(taiga-logo.svg);
   mask-repeat: no-repeat;
}

Here’s how it looks now:

The repeated trees are gone, but the size is definitely incorrect. This is where the mask-size property comes in. It takes two values: the width and height of the mask image. In this case, we want our logo to be displayed at full height, with the width stretching proportionally to maintain its original aspect ratio.

img {
 mask-image: url(taiga-logo.svg);
 mask-repeat: no-repeat;
 mask-size: auto 100%;
}

And now our image is almost perfect, but it’s stuck to the left edge. To fix this, we use the mask-position property, which can take up to two arguments: horizontal and vertical offsets. If you only provide one value, it’s applied to both axes.

Finally, we’ve broken down the solution in detail!

You can experiment with the examples we just discussed in this StackBlitz example:

We’ve covered the bare minimum you need to know about CSS masks. The theory described here is far from exhaustive. But if we were to dive deep into every theoretical aspect, this article would end up being no different from official documentation or many already existing tutorial articles.

The main goal of this article is entirely different — to share personal experience solving interesting challenges in UI Kit development using CSS masking. So, if you still find the syntax or core concepts of masking tricky, I’d personally recommend checking out Ahmad Shadeed’s article “CSS‑Masking”.

Now, let’s move on to real-world examples!

Fade

Too much text — it’s a problem we constantly deal with on the web. Even beginner developers know how to handle it using the CSS property text‑overflow. Just set it to ellipsis, and any overflowing content gets “chopped off” with a neat little … — that’s basic stuff.

But then your designer comes along and says, “No more ellipses in our design system. We want overflowing content to fade out smoothly.” Just like in the illustration below:

For a block with single-line text, the problem is solved quite easily:

.fade {
   mask-image: linear-gradient(to right, black 80%, transparent 90%);
}

We told the browser to use a linear gradient as the mask. From left to right, the first 80% is solid black, the last 10% is fully transparent, and the 10% in between (from 80% to 90%) creates a smooth transition from solid black to fully transparent.

In the current state of things, DevTools doesn’t offer convenient tools for debugging CSS masks. However, there’s a handy workaround: temporarily replace mask-image with background-image during development. This lets you visually see what the mask looks like — everything opaque stays, and everything transparent gets cut out.

This solution isn’t exactly groundbreaking — it’s covered in almost every CSS masking tutorial. But let’s make things more interesting.

Now the designer comes back with a new challenge: they want the fading effect to work not just for single-line text, but also for multiline content. For example, the first two lines of a long text should be fully visible, the third line should fade out gradually, and everything after that should be completely hidden.

The previous solution won’t cut it here. Instead, we’ll need a multi-layer mask. Yep, every element can have more than one mask, applied as layers. The syntax is simple — just add the properties for each layer, separated by commas.

.multi-line-fade {
   height: 3lh;
   overflow-y: hidden;
   mask-image:
       linear-gradient(black, black),
       linear-gradient(to right, transparent 80%, black 90%);
   mask-position:
       0 0,
       bottom right;
   mask-size:
       auto,
       100% 1lh;
   mask-repeat: no-repeat;
}

The first two style rules ensure that the text container doesn’t exceed the height of three lines, and anything beyond that is hidden. In the mask‑image property, we’ve listed two mask layers separated by a comma.

• The first layer is a gradient that transitions from black to black, essentially making it solid black across the entire area (simply using black wouldn’t work).
• The second layer is almost the same gradient we used earlier for single-line text, except the colors black and transparent are swapped (we’ll explain why later).

Next, using the mask-position and mask-size properties, we specify where and how these mask layers are positioned. The first layer covers the first three lines of text, while the second layer only applies to the last visible line (the third line).

But this setup still doesn’t work yet! The first mask layer completely covers all three lines, making the second layer useless. To fix this, we need to exclude the second layer from the first layer.

This is where the mask-composite property comes in. It has several possible values, but its main purpose is to define how the mask layers interact. By default (value add), the layers stack on top of each other, expanding the opaque areas. However, in our case, we need the exclude value. According to the documentation, “the non-overlapping regions are combined” — making it perfect for our needs.

Here’s why the second mask layer was designed this way: its first 80% is transparent, meaning it doesn’t overlap with the first layer. The remaining part of the layer is semi-transparent, which partially overlaps with the first layer and effectively partially “excludes” that area from the final combined mask.

Here’s the final solution for handling overflow in multiline text:

.multi-line-fade {
  height: 3lh;
  overflow-y: hidden;
  mask-image:
          linear-gradient(black, black),
          linear-gradient(to right, transparent 80%, black 90%);
  mask-position:
          0 0,
          bottom right;
  mask-size:
          auto,
          100% 1lh;
  mask-repeat: no-repeat;
  mask-composite: exclude;
}

I’m also sharing the final solutions as a StackBlitz example for you to experiment with yourself.

And if you’re looking for inspiration with an even more complex (but much more flexible) technical solution, I invite you to check out the Taiga UI Fade directive!

Sensitive

You’ve got a new task: develop a tool that can visually hide any part of content from the user. Something like this:

In banking apps, this feature is widely used to let users hide sensitive information (like account balances or bank details) when recording their screen or showing application’s details to someone in person. You might also have seen a similar feature in social media, used for spoiler text or images.

First, we’ll create a mask image. For this, we need a very simple SVG made up of random squares with varying levels of transparency.

<svg
   width="360"
   height="48"
   preserveAspectRatio="none"
   fill="black"
   xmlns="http://www.w3.org/2000/svg"
> 
   <rect opacity="0.2" width="24" height="24"/>
   <rect opacity="0.2" x="336" y="24" width="24" height="24"/>
   <rect opacity="0.35" x="120" y="24" width="24" height="24"/>
   <!-- [...] -->
   <rect opacity="0.2" x="264" y="0" width="24" height="24"/>
   <rect opacity="0.32" x="168" y="0" width="24" height="24"/>
</svg>

There are plenty of ways to create this kind of mask. You could generate a bunch of rect tags directly in your IDE, ask your designer to develop it in Figma, or just use our ready-made solution.

The key is that the final mask should look something like this (and remember — the crucial point is to use varying levels of transparency, not shades of gray!).

Then nothing stops you from inlining the resulting SVG directly into your CSS property.

.sensitive {
   background: currentColor;
   mask-image: url('data:image/svg+xml,<svg width="360" ...>...</svg>');
   mask-size: auto 100%;
}

Don’t worry — when you use this technique in different places, the browser won’t fetch the SVG each time. It takes care of caching automatically.

Also, note that we intentionally set the property background: currentColor — this makes the semi-transparent squares of the mask match the text color they’re covering.

And once again, success! Here’s a StackBlitz example for you to experiment with.

For anyone wanting more insights, feel free to dive into the source code of our Taiga UI Sensitive component!

Checkbox

It’s time to show you how to create customizable checkboxes without adding extra HTML elements — just by harnessing the power of CSS masks.

Over years of developing Taiga UI, we’ve always aimed to avoid unnecessary template nesting. Ignoring this principle makes it much harder to customize components, often leading to an overuse of public CSS variables — which isn’t the best approach.

Let’s start with a native <input type=”checkbox” /> and disable all built-in browser styling using appearance: none. Then, we’ll customize the look of the checkbox “box”:

input[type='checkbox'] {
   appearance: none;
   cursor: pointer;
   width: 2rem;
   height: 2rem;
   position: relative;
   overflow: hidden;
   box-shadow: inset 0 0 0 0.125rem lightgray;
   border-radius: 0.5rem;
}

Next, we’ll add behavior so that when the checkbox is checked, it smoothly fills with color. This is where the :checked pseudo-class comes in handy.

input[type='checkbox'] {
   /* [...] A chunk of the previously described styles */
   background: transparent;
   transition: background-color 0.3s;
}
 
input[type='checkbox']:checked {
   background: lavender;
}

All that’s left is to add the checkmark. We’ll use the :after pseudo-element along with our CSS masking skills.

input[type='checkbox']::after {
 content: '';
 position: absolute;
 inset: 0;
 background: #333;
 mask-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><path d="M14 5L7 12L3 8C3 8 4 7 5 7.5L7 9.5L11.5 5C11.5 5 13 4 14 5Z"/></svg>');
 transform: scale(0);
 transition: transform 0.3s;
}

input[type='checkbox']:checked::after {
 transform: none;
}

Using position: absolute + inset: 0, we positioned the :after pseudo-element to take up the full width and height of its parent. Then, we filled the entire pseudo-element with a solid black background. Using mask‑image, we cut out the shape of the checkmark with a simple inline icon. All the other lines of code are just for animating the checkmark’s appearance and disappearance smoothly.

Check out the result in action:

The Taiga UI implementation of the Checkbox component is based on the described approach but includes even more interesting techniques that go beyond the scope of this article. Be sure to take a closer look at it when you have time!

We’ll continue this journey soon

I hope this article has convinced you that CSS masking is a fascinating and powerful tool for any frontend developer. Mastering it can lead to some truly magical results!

This article only touches on a surface of CSS masking’s potential — you’ll find even more in our Taiga UI component library. But I don’t want to overwhelm you with too much information in one go (and, to be honest, I need a break to gather my thoughts for explaining the more complex examples).

If you enjoyed this article, I will gladly release a follow-up article where we’ll dive into additional CSS masking examples (like how and why we stack radial gradients for ProgressSegmented, the clever tricks behind the new Icon component, and the challenges of the complex Switch component).

Follow me to stay tuned for the next article!

In Plain English 🚀

Thank you for being a part of the In Plain English community! Before you go:

• Be sure to clap and follow the writer ️👏️️
• Follow us: X | LinkedIn | YouTube | Discord | Newsletter | Podcast
• Create a free AI-powered blog on Differ.
• More content at PlainEnglish.io

CSS mask powers was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Happy to announce that we’ve released the first stable version of Taiga 4.0 — our extensive component library for Angular. There are so many improvements that a single article can hardly cover them all. I’ll tell you about the most exciting ones.

A major release — a new milestone in our journey

In our team, we always consider major releases as a significant and responsible step: we don’t publish them too frequently, and the preparation time spans months or even seasons.

In December 2020, we had introduced our second major release, which marked the beginning of Taiga’s Open-source journey. The third major release was announced only in late summer 2022. And we started developing the fourth version of Taiga at the end of 2023, and we are announcing its first stable release only now.

Of course, between major releases, we don’t sit idle; we continue to release almost every week. For example, the second major version of Taiga UI had 99 minor releases. But the most interesting things always happen when breaking changes come…

Bumping the minimum required Angular version

In my previous articles, I already mentioned many times that authors of libraries for Angular face a significant challenge — the need to ensure compatibility of their libraries with applications written in older versions of Angular.

Yes, no matter how much we want to or how many resources we have, we cannot immediately start using the latest version of Angular to publish our libraries. If we upgrade to the most recent version, our users won’t be able to use our products until they upgrade to the same Angular version or higher. Since hundreds of production teams use our libraries, this is a luxury we cannot afford.

That’s why we stuck with Angular 12 for the entire third major version. It wasn’t easy for us: the framework team had moved far ahead during the last four years. But fortunately, we are finally upgrading to the 16th version of the framework.

What this means for you:

• If you already use a modern version of Angular in your applications, you don’t need to worry — everything will continue to work. However, if you’re using a version less than 16, it’s time to motivate your team to allocate time for updating Angular before migrating to the latest version of Taiga UI.
• You can finally forget about modules! In the new release, we’ve rewritten all our directives and components to be standalone, which should significantly improve tree shaking. Moreover, we’ve changed the naming rules and removed unnecessary postfixes. Reading the documentation about TuiButton? Then, just add TuiButton to your component imports (instead of TuiButtonModule or TuiButtonComponent). The code is simpler and cleaner!

What this gives us:

• Host directives are now available, opening up new possibilities for code decomposition and simplification. They eliminate the need for extra HTML nesting, transforming many components into just directives. This is great for your customization and will also allow us to move their styles into a separate package in the future, describe their public API through data-* attributes, and use the appearance of many simple components even without Angular. Who knows, maybe in the future, you will see Taiga components for React or even for projects written in vanilla JavaScript? Let’s dream about it together!
• We’ve used signals for the first time and simplified some code with their help. We will fully experience their power with the transition to Angular 17 when signal inputs, signal versions of two-way binding, and tools for working with template queries become available. But even our first experience with signals has greatly impressed us!

Bumping browser support

Every major release, we review the minimum versions of supported browsers. This allows us to remove a lot of workarounds from the codebase that exist only for legacy browsers. For you, this means that Taiga UI libraries become lighter and more stable (because we fully rewrite some codebase using native browser features).

In the current major release, we set higher minimum requirements for many browsers. Finally, without polyfills or fallbacks, we have access to browser APIs like ResizeObserver, Clipboard, VisualViewport, pointer events, and the incredibly useful beforeinput event for all our masked text fields.

The most recent list of supported browsers is now published as a library — @taiga-ui/browserslist-config.

New @taiga-ui/legacy library

With the fourth major release, we started publishing the @taiga-ui/legacy package, which acts as a transitional state for many outdated components before their full removal. All entities you find inside this package in the fourth major release will be removed in the fifth one. And during the preparation for a new major release, the package will once again be filled with outdated entities.

The motivation for creating this package is to simplify the migration to a latest major version. In most cases, the package includes components that already have modern equivalents in stable packages, but their migration process is too complex to be handled by automated migrations and requires manual efforts.

We hope it would be easier for you to migrate all the necessary components first (with the help of our automatic schematic migration) and then, at your own pace, remove the rest from the @taiga-ui/legacy package. But keep in mind, these components are no longer supported, so try to switch to the modern versions as quickly as possible.

Experiments have moved to stable packages

Users of our packages might have noticed a section in the documentation called “Experimental”. This section has been expanded with more and more directives and components from the @taiga-ui/experimental package.

Our team adopted this approach from the Angular team. For example, they publish the @angular/material-experimental package, whose root README contains the following phrase:

This package contains prototypes and experiments in development for Angular Material. Nothing in this package is considered stable or production ready. While the package releases with Angular Material, breaking changes may occur with any release.

Our strategy follows the same principles. The new @taiga-ui/experimental package allows users to see the direction of the next major release early on. Users can even start using this package in their applications and give us feedback if they wish. The important warning thing for these brave users — to remember that updating the experimental package should be done carefully, as the public API might change slightly at any time.

Most of the content from @taiga-ui/experimental will move to stable packages in the upcoming major release. The experimental package will remain empty until we start adding new entities to it during the preparation for the next major release.

Many of the new features described in this article were once part of this experimental package, but they have now moved to various stable Taiga libraries. Let’s dive into the details of each new feature!

Radio и Checkbox

Let’s start with checkboxes and recall their old public API.

Do you want to get a simple small square that shows a checkmark when clicked?

Import TuiCheckboxModule and use the following markup:

<tui-checkbox [(ngModel)]="value" />

Want the same checkbox but with text beside it, and clicking on the text also checks it?

Import the TuiCheckboxLabeledModule and use the following markup:

<tui-checkbox-labeled [(ngModel)]="value">
   Click on the text too
</tui-checkbox-labeled>

One more example:

It’s basically an enhanced version of the previous CheckboxLabeled component, but now it has an extra border and click/hover works across the entire block area.

Let’s recall the name of the module (from Taiga UI v3) — TuiRadioBlockModule, and the markup for this component now looks like this:

<tui-checkbox-block [(ngModel)]="value">
   An option
</tui-checkbox-block>

To give you a clear picture, let me remind you that the same situation happened with radio buttons. There were similar modules: TuiRadioModule, TuiRadioLabeledModule, and TuiRadioBlockModule, all with the same logic I just described.

And now, having fully explained the previous situation (the 3d major version of Taiga UI), let’s appreciate the elegance of the updated version of these components.

To create the most basic checkboxes and radio buttons, now import TuiCheckbox and TuiRadio:

<input
   tuiCheckbox
   type="checkbox"
   [(ngModel)]="value"
/>

<input
   tuiRadio
   type="radio"
   [(ngModel)]="value"
/>

Do you want to add clickable labels? You’ll love the new style since it’s very similar to the native one. Import TuiLabel, and then simply wrap the inputs above with a label tag (works in the same way for both checkboxes and radio buttons):

<label tuiLabel>
   <input
       tuiCheckbox
       type="checkbox"
       [(ngModel)]="value"
   />
   Label text
</label>

Do you want to replicate the behavior of the previous version of TuiCheckboxBlockModule / TuiRadioBlockModule ? Now there’s a unified solution for both! Import TuiBlock, and then simply apply this directive to the label tag:

<label tuiBlock>
   <input
       tuiCheckbox
       type="checkbox"
       [ngModel]="value"
   />
   Label text
</label>

All examples of the new API are also relevant for the new radio buttons.

Moreover, the Label and Block directives also work with the new Switch component.

<label tuiBlock>
   <input
       tuiSwitch
       type="checkbox"
       [ngModel]="value"
   />
   Label text
</label>

The new versions of Checkbox, Radio, and Switch have a consistent public API that’s easy to remember because it’s very close to the native syntax of similar built-in browser components. And no hidden DOM nesting!

SwipeActions

The experimental SwipeActions component has been moved to the stable @taiga-ui/addon-mobile package. Its concept is simple and familiar to almost everyone since it’s implemented in almost all popular email services (like Gmail). It helps to offer users a set of additional actions with a horizontal swipe on mobile devices. The new component handles most of the work for you, and you just need to declaratively describe the content of these actions through the template.

Technically, you need to wrap any content in <tui-swipe-actions /> and place a set of icon buttons next to it, which will appear when a swipe is performed:

<tui-swipe-actions>
   <div>
       Any content you like
   </div>

   <button
       appearance="destructive"
       iconStart="@tui.trash"
       size="s"
       tuiIconButton
       tuiSwipeAction
   ></button>
</tui-swipe-actions>

Sensitive

Our main package @taiga-ui/kit now includes an interesting directive — Sensitive. It allows you to visually hide any part of the content from the user. For example, this feature can be used to hide sensitive information, like balance or bank account numbers, when users record their screen or demonstrate a device screen to their friends.

The main advantage of this directive is that it is compatible with any native tag or custom Angular component. The only limitation is that the ::after pseudo-element should not be used on the hidden content. However, this limitation can be easily bypassed with additional html-nesting.

Skeleton

The most similar counterpart to the previous feature is the directive for creating skeletons.

A skeleton in web development is a temporary placeholder that takes the place of content that hasn’t been loaded yet, showing its approximate layout until the loading is complete. Visually, skeletons are usually gray with a small pulsating animation to indicate the loading state.

The new Skeleton directive can be applied to any native tag or Angular component of any shape or size. Then, through the magic of the CSS filter property, the directive turns any content into skeletons.

Segmented

The new Segmented component is a popular way to use buttons in app navigation. It is especially useful when trying to make the app look like a native mobile app.

Fade

Ellipsis at the end of a line is a popular way to show text overflow. If you’re looking for a different option, there’s the new Fade directive, which has finally moved to the stable @taiga-ui/kit package.

DropdownMobile

Although this component was duplicated in the third major branch, it was created during the active development of the new major release. So, it deserves to be mentioned in this article.

Our team has developed a new version of dropdowns for mobile devices. Often, classic desktop dropdowns feel too cramped on small mobile screens. That’s where the new TuiDropdownMobile directive from the @taiga-ui/addon-mobile package comes to the rescue.

You just need to attach the tuiDropdownMobile directive to the components like Select, MultiSelect, or ComboBox, and the directive will do the rest: on desktop, it will open the usual dropdown list, but on mobile devices, it will open the version shown in the illustration above.

@taiga-ui/layout library

Components don’t always contain a heavy amount of JavaScript code. Sometimes, a web developer just needs a g̶o̶o̶s̶e̶ ̶f̶a̶r̶m̶ good collection of ready-made templates to simplify the layout work. In the latest release, our @taiga-ui/layout package has been enhanced with useful components and directives for this purpose.

The new CardMedium and CardLarge components will help you develop such cards with minimal effort.

In the article, I’ve included just one type out of many possible variations. You’ll find many more interesting examples in the documentation.

The new Cell component is perfect for use in long lists with a lot of text content.

Finally, the new BlockDetails component, paired with the existing BlockStatus, will help you create great status pages in your application.

Icon

Before this major release, our approach with icons involved using a combination of <svg /> and <use /> tags. This approach worked fine but was overly complicated code-wise and had limitations. There were so many entities and preprocessing scripts needed for the icons that explaining how it all worked could fill an entire article.

In the new major release, the @taiga-ui/core package introduced a new Icon component, which has become the main way to work with icons in all other Taiga components. This new component displays icons through a CSS mask, opening up new possibilities:

• This allows icons to be hosted on a CDN and displayed without any need for DOM manipulations or sanitizers.
• A more straightforward approach to icon scaling. Just change the size of the component’s host, and the icon will scale automatically. The property vector-effect=”non-scaling-stroke” ensures that scaling happens without losing details or unnecessarily changing the line thickness.
• The browser automatically takes care of icon caching.

Updated InputPhoneInternational

Our InputPhoneInternational component finally stopped depending on a bunch of hard-coded constants that we never had time to update!

We no longer store information about hundreds of phone number patterns for different countries. Now, Google does this for us. Its developers maintain a library libphonenumber that stores phone number patterns for all countries worldwide and keeps them always up to date!

Even before we started working on Taiga’s fourth major release, we had already developed the @maskito/phone library. It uses a JavaScript port of Google’s library and the full power of Maskito to create a masked text field for any country’s phone number with just a few lines of code. Now, we’ve integrated this library into Taiga’s InputPhoneInternational component.

But that’s not all! Our public version of this component used to rely on low-quality raster images for country flags. Now, our tuiFlag pipe (it is used inside the InputPhoneInternational component) returns beautiful, high-quality vector images instead of *.png files!

Textfield

And last but not least, I will describe the most comprehensive code refactoring. It is not even finished yet and will keep going in future releases.

We redesigned the PrimitiveTextfield component, which serves as the foundation for all other Taiga’s text fields. The updated version is now called Textfield.

The main feature of the new component is its drastically changed API style. Textfield can now be defined and customized in a very declarative way through templates, rather than through tons of input properties like before.

Here’s the most basic example:

<tui-textfield
   iconStart="@tui.search"
   iconEnd="@tui.settings"
>
   <label tuiLabel>I am a label</label>
   <input
       placeholder="I am placeholder"
       tuiTextfield
       [(ngModel)]="value"
   />
   <tui-icon icon="@tui.bell" />
   <tui-icon tuiTooltip="I am a hint" />
</tui-textfield>

This code produces the following text field:

After refactoring of this component, we’re moving all previous generation text fields to the @taiga-ui/legacy package. We set a goal to create new alternatives for them, but with a similar API style as their base component Textfield. Some components (i.e. InputCard) have already been rewritten in the new style, while the rest will be completed in upcoming releases.

Wrapping Up

The fourth major release is already published. The described features are just a small part of all improvements — check out the release changelog for more details.

We put in a lot of effort to make updating easier for you. We wrote a bunch of schematics that automatically go through your entire project and fix most of the breaking changes.

If you’re using Angular CLI, you can run the migration scripts using this console command:

ng update @taiga-ui/cdk

If your project is based on Nx CLI, the command to run is:

nx migrate @taiga-ui/cdk

If you happened to stumble upon this article and want to give Taiga a try in your project, we’ve got a command to make getting started easier:

ng add taiga-ui

If you face any issues or bugs during the update, don’t hesitate to create an issue or ask for help in our Telegram community. The Taiga team looks forward to your feedback!

And just a reminder, the easiest way to say thanks is to star us on GitHub.

Introducing Taiga UI v4 was originally published in AngularWave on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today is Christmas, making it a perfect time to summarize the fruits of our labor over the year. In 2023, Taiga UI project had more than fifty releases, more than two thousand merged PRs and over five hundred closed issues.

Taiga UI is a powerful set of components for Angular, which is used in dozens of Tinkoff’s products. The project has been developed in Open Source for many years, gaining an audience worldwide.

In the article, I will continue our annual habit and briefly unpack the overall achievements related to Taiga UI over the past year.

More than 3 years in Open Source

For many years we’ve been developing our products publicly in Open Source. It’s important for us that users can always explore the source code and make their own amendments to enhance Taiga UI. In 2023, more than 20 external contributors submitted PRs of various complexity levels: from minor documentation adjustments to fixing serious bugs or even whole large features, such as BreakpointService or declarative dialogue routing.

Over the span of three years in Open Source, the number of contributors has exceeded the milestone of one hundred and fifty people! We can’t emphasize enough how much we value their contributions and welcome any improvements ❤️

This summer, a significant change took place in the history of Taiga UI. It has turned into something more than just a UI Kit. Taiga UI is now part of a whole family of products united under the common name of Taiga Family.

We have relocated to a separate GitHub organization where we have assembled the best technical solutions used for developing Taiga UI, including ng‑web‑apis, maskito, ng‑polymorpheus, ng‑morph, ng‑event‑plugins, and others. Among these, you will surely discover something useful for your Angular application or library. For more detailed information about each product, my colleague has written the following article:

Taiga UI: more than UI kit

We are pleased to see the growing public awareness of Taiga UI. In 2023, we gained 17% more stars on GitHub, and the number of downloads via npm exceeded 350,000. By comparison, in 2022, this number was slightly less than 200,000.

New mask for text fields

As 2022 came to a close, a remarkable event set a significant task for us in 2023. For years, the task of seeking an alternative to the text field masking library had been pending in the Taiga UI backlog. After many rounds of research and discussion, our team devised our own dedicated library for this task — Maskito.

At the beginning of this summer, the first stable major release was published. By that time, Maskito had expanded beyond being a single library to a full-fledged collection of libraries. The new development included the framework-agnostic package @maskito/core (a standalone and already sufficient package for initiating text field masking), the optional package @maskito/kit with a set of ready-to-use and configurable masks, and separate packages for popular JavaScript frameworks like React, Angular, and Vue.

If you’re interested in learning more about the development history of Maskito and seeing all its advantages in action, I’ve written about it before. Feel free to read more by visiting:

Maskito is a new collection of libraries for text field masking

We were uncertain until the last moment whether we had managed to create a flexible and user-friendly tool that would avoid the errors of its forerunners. The positive reaction from the community allayed our fears.

On June 21st, the widely-used framework Ionic made an announcement naming Maskito as the recommended masking solution in its components. And now, on the Ionic documentation page, you can always find the guide on how to use Maskito within your Ionic application.

The community expressed interest in the new product, and by the year’s end, the cumulative number of downloads on npm had exceeded 300,000. It was particularly encouraging to see that even large enterprises had adopted Maskito!

We have entirely migrated all the masked text fields from the Taiga UI library to the new mask, solving numerous legacy issues. However, we are not resting on our laurels! Maskito still has areas to grow, and we aim to evolve it further. Stay tuned for the second major release, which is just around the corner!

InputPhoneInternational and @maskito/phone

We have an amazing component that can be tweaked endlessly. No matter how much effort we put in or how many hours we dedicate to its design, adjustments will emerge sooner or later. It’s name is InputPhoneInternational.

The issue here isn’t about our laziness or shifting our focus elsewhere. It’s because this component is a masked text field for entering international phone numbers, and the patterns for international phone numbers have a history of changing and expanding over time.

For a long time, we stored the masks for the phone number formats of different countries as a constant in our repository. As expected, updating this constant wasn’t always done promptly, which caused quite a bit of trouble. Luckily, the primary advantage of Open Source came to our rescue — bug reports from the community. A significant number of issues like #3102 were raised.

We weren’t fond of constantly having to update the formats for phone numbers and wanted to shift the responsibility onto someone else. We found the perfect candidate — Google. The company has a library, libphonenumber, which contains the patterns for phone numbers from all countries around the world, and they’re always up-to-date! We realized immediately that it was exactly what we needed.

Sadly, the process turned out to be quite complicated. Before we could begin using it, we had to deal with a huge amount of data — the format was not at all suited for easily utilizing the data to construct masks for text fields. Consequently, we developed an additional package, @maskito/phone, which built upon Maskito and the libphonenumber-js package to offer a convenient API. It provides you with the opportunity to create a masked text field for a phone number from any country in just a couple of lines.

In September 2023, the development of the package was completed, and we made its first release. The package turned out to be convenient and flexible to use. For example, a library user can regulate the size of the bundle by choosing different sets of metadata (max, min, or mobile). You can read more about all the features of the new package in our documentation.

Very soon, in the Taiga UI 4.0.0 release, the new package @maskito/phone will be used inside InputPhoneInternational component, permanently eliminating the concerns about updating international phone numbers. Our users will simply need to update the version of the libphonenumber-js library.

Native mobile controls

Towards the end of 2022, we decided to implement the ability to use the native mobile controls in some of our input components. For instance, native dropdown lists or calendars.

The first such feature introduced for the Select component in October 2022. And by 2023, this feature was released across a whole list of our components: MultiSelect, InputDate, InputTime, InputDateTime, InputMonth. The public API of these new features may differ among components, but the core principle remains the same: the desktop version of the component uses stylized Taiga controls, while the mobile version invokes the native system tools. Different mobile platforms will style the controls according to their own design.

To demonstrate what the new feature looks like in practice, take a look at this example. If you open it on a desktop, you’ll see that the InputDate component, when focused, opens up a stylized Taiga calendar.

However, if you open the same example on an actual mobile device, clicking on the calendar icon will bring up the device’s native calendar, styled according to the operating system of the device.

Native controls have a number of advantages that custom analogs simply can’t match, no matter the effort. For example, native calendars and dropdown lists can extend beyond the boundaries of the browser window, which can be quite useful on smaller mobile devices. Moreover, such native controls will automatically be styled according to different operating systems, which means they integrate harmoniously with the device’s overall design and look familiar to the user.

If we set aside all the technical advantages, there is another meaningful point regarding the significance of this feature. In product development, there’s a commonly used “hack” in which a business, as a stopgap measure, postpones the development of a full-fledged iOS or Android application for their product; instead, they leverage their existing web application version, packaging it inside a native mobile app shell. This article will not delve into the merits or drawbacks of WebView. It’s important to note that smart use of this approach requires that the web version of a site should effectively mimic a native mobile application in both behavior and appearance. The use of native mobile controls can be a good solution within such a strategy, even though the component may retain its unique behavior on desktop platforms.

The instructions for implementing the feature are divided into two groups:

1. For text fields used for entering dates, times, and months, this is done through Dependency Injection configuration:

import {tuiInputDateOptionsProvider} from '@taiga-ui/kit';
// ...
providers: [tuiInputDateOptionsProvider({nativePicker: true})]

2. For components used for selecting items from a dropdown list, you simply need to place the native <select /> tag inside the already familiar <tui‑select /> or <tui‑multi‑select /> tags, and enhance it with the tuiSelect attribute. Following that, the codebase will automatically handle all the necessary magic.

<tui-select [formControl]="control">
   Character
   <select
       tuiSelect
       [items]="items"
   ></select>
</tui-select>

Editor: more features

For an extended period, the Editor component was developed within a monorepository along with other Taiga UI packages and had only a single page of documentation. But over time, this component began to feel cramped. Moreover, it no longer seemed right to call our vast wysiwyg just a “component.” The time has come for it to leave the parent nest and embark on a journey of its own…

Since June, the Editor has been residing in a separate repository, featuring its own distinct documentation and versioning system independent from the other Taiga packages. It is now officially known as the @tinkoff/tui‑editor package.

In 2023, our editor has been equipped with new and interesting features: it now supports native audio/video tags, and inside the editor you can embed a full YouTube player or even an iframe that can be adjusted in width with any content inside. And, of course, we don’t intend to stop here; we plan to continue enhancing the editor even further!

More components and new @taiga-ui/experimental

Until recently, in the development of Taiga UI, we aimed to focus on constructing atomic components, making a point of avoiding complex organisms. But in today’s world, the demand for web applications has skyrocketed, particularly for their mobile versions or even modern PWAs. Creating high-quality web applications rapidly has become extremely important. In light of these new trends, we have deviated from our previous rules and have begun to prepare ready-to-use popular mini “organisms” (or, as we call them within our team, “layout”-components).

This led to the creation of the TabBar and AppBar components, which embody the popular design pattern used in mobile applications for navigation between sections.

We also developed the BlockStatus component, which simplifies the creation of status pages. For instance, it’s useful for developing the infamous 404 page, present in almost every application. In the autumn of 2023, the @taiga-ui/experimental package was enriched with a variety of other useful layout components: Card, Cell, Title, and Surface.

The @taiga-ui/experimental package contains components that do not yet have a strictly defined public API; it can be changed, disregarding semantic versioning rules. In the upcoming major release, these components will be moved to stable packages, their public API will be finalized, and they will start to follow semantic versioning.

The new layout components in @taiga-ui/experimental are not the sole innovations within this package. It contains a plethora of updated and refined versions of existing components, along with some completely new features.

For example, take the updated Checkbox, Radio and Toggle components. The new versions have become attribute components and now can be directly used with native <input /> elements. In the next major release, the <tui-checkbox /> tag will be eliminated from the templates and will be replaced by <input tuiCheckbox type="checkbox" />. This means that the new component version will provide full access to all native input’s attributes, resulting in a lighter component and cleaner code structure. This achievement is thanks to the CSS mask property! Additionally, the new versions of the components can be optionally styled with just a single line of code to visually resemble the native iOS or Android system controls.

The Sensitive component has been introduced, which hides part of the content from the user’s view. For instance, in Tinkoff applications, such a feature is actively used to allow users to conceal their sensitive data — like balance amounts or bank account information — when recording their screen or showing something personally to their friends. The secret to the component’s success lies once again in the use of a CSS mask.

Using an ellipsis at the end is a common method to indicate that text has been truncated. If you’re looking for an alternative, there’s a new option — Fade component. Guess how this effect is achieved? Correct, once again, the implementation relies on the familiar CSS mask!

Are you weary of the constant mentions of CSS masks? This is only the tip of the iceberg! In 2023, this feature has become one of the key contributors to the @taiga-ui/experimental package. With just this single property, we’ve managed to refresh the ProgressSegmented component’s version by applying a mask on top of the ProgressBar component.

Delving deeply into the technical details of implementing so many elements with the CSS mask requires a separate article. If our team has the strength and time, and the readers show interest, then we will certainly prepare it, including all the details!

The CSS-mask has also been influential in the revamped version of the Button component. A redesign of the architecture for the new buttons has streamlined the component’s codebase without compromising on its past functionality.

The latest addition, but certainly not the least important, is the new component for handling icons — Icon. It renders icons through a CSS mask, introducing new opportunities:

• The possibility to store icons on a CDN and display them without any DOM manipulation or the need for a sanitizer;
• A more straightforward approach to icon scaling. Just merely change the dimensions of the host component — the icon automatically scales, and the use of the vector‑effect="non‑scaling‑stroke" property allows for this scaling without compromising detail or causing unwanted changes in line thickness.
• The browser automatically implements icon caching.

All of these improvements allow us to “retire” a significant part of the codebase, making the work with Taiga UI much more straightforward.

The upcoming release 4.0.0, Taiga Renaissance?

It has been over a year since the last major release of Taiga UI. We have deliberately avoided updating the Angular version for an extended period to preserve compatibility with your projects that rely on older versions of the framework. We refrained from making breaking changes for a long time, allowing you to seamlessly upgrade to the latest versions of our libraries. And for an extended period, we’ve continued to support some exceedingly outdated browsers.

Maintaining this approach is challenging and at times it can be counterproductive to the quality of our libraries. For this reason, the Taiga team is actively discussing the proposition of increasing the frequency of major releases (small ones every six months to a year, instead of massive releases every one and a half years) and the aspiration to match the support for the minimum version of Angular in our libraries to the same cycles promised by the framework’s core team.

As we look toward the beginning of 2024, a new fourth major release of Taiga is on the horizon. We plan to update the minimum supported browser versions, embracing more contemporary browser features, which in turn will make our libraries lighter and more reliable. We will upgrade to Angular version 15, which at last will grant us the opportunity to implement standalone components and the Directive Composition API. We will finalize the public API of our new experimental components and incorporate them into other stable packages.

You can start preparing for the forthcoming release right now: update Angular in your application to at least version 15+, and update Taiga to the latest release. Then, our schematics will handle a significant part of the concerns for you!

If all preparations are already complete, then it’s the perfect time to make yourself a cup of cocoa with marshmallows, sit in a comfy chair opposite a decorated Christmas tree, and fully immerse in the festive holiday spirit. Taiga UI team wishes everyone a Merry Christmas!

Taiga UI: 2023 Results was originally published in AngularWave on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are happy to announce that we have released our project Maskito to Open Source. The first stable major version is now available. Maskito is a collection of libraries to simplify the process of masking text fields with a convenient and flexible public API.

Maskito comes with several libraries. The main one is a zero dependency Typescript package. It is all you need to create a mask for your web application. There is also an optional package with configurable, ready-to-use masks. And of course there are libraries for modern web frameworks: you can use Maskito in React, Angular or Vue. Let’s dive into the details.

A bit of theory

The terms “mask”, “input or text field masking”, and other similar words are mentioned many times in the article. Let’s discuss the meaning of this term for the Web.

If it had a formal definition, it would sound something like this:

Mask is a programmatic constraint (defined by developer) which ensures that the user enters a value inside a text field according to predefined format.

It is important to make a distinction between the terms “masking” and “validation”. Yes, both processes have a similar purpose. However, masking helps the user to enter a valid value, and validation only checks if the final value is correct (it only returns a boolean answer as a result).

If such a nerd definition still does not clarify things, then read my previous article. It has a more detailed explanation of masking.

Uphill Battle to Create a Mask for Text Field

To get more understanding of this concept, I also propose to look into some examples of masked text fields: for time, date, number, phone or credit card.

In the next two sections I will write about the history of Maskito’s development and explain the reasons for some of our architectural decisions. If you are not interested in these topics and are looking forward to seeing Maskito in action, please skip to the “Anatomy of Maskito” section.

A bit of history

All the necessary theoretical concepts have been discussed, and now I’m ready to explain why it was necessary to create a new library. Some readers may notice that some similar solutions are already available in open source.

I feel it necessary to have a disclaimer. There are no perfect libraries, frameworks, or languages. There is no silver bullet for all tasks. You decide which tool is better for your new case. Similarly with masking libraries — there are several popular libraries, but unfortunately not all of them were perfectly suited for our tasks.

My team is developing the design system of fintech company Tinkoff. We are responsible for maintaining the Angular UI Kit, a collection of libraries with a set of components. It is an Open Source project called Taiga UI.

Among our components there are a lot of masked text fields: for phone, for dates, for time, and even a complex component to enter credit card. I have mentioned only the most popular components, our UI Kit includes significantly more examples of masked text fields.

The text-mask library has historically been used for all our masked components. It provides a good public API, flexible enough to fit our requirements. However, if the library had no drawbacks, then you would not be reading this article now, because we would continue to use text-mask. But here we are.

Unfortunately, the library support gradually faded away, bugs were fixed less and less intensively. There are still unresolved issues in the project repository (for example, #657 and #830), discovered more than five years ago by our own colleagues, who at that moment were already developing Taiga UI.

Long-lived bugs are not the only problem. The codebase becomes less up to date with modern standards every day. And the most tragic event happened in 2020 — author of this project announced that the library was no longer maintained.

For these reasons, the goal of finding an alternative solution for text field masking was given high priority in our project:

1. The above-mentioned long-lived bugs remained unresolved.
2. The library became the only dependency outsider in our project: it was published using the legacy module systems. In addition, its Angular package was released under the legacy “ViewEngine” (instead of the modern “Ivy” engine). All of this causes build time warnings, and sooner or later this could become a serious problem.

We started looking into other popular masking solutions — imaskjs, cleave.js, ngx-mask and InputMask. The main advantage of all these solutions is simplicity to use. If you need to create some kind of classic mask that is not overcomplicated with additional logic, then they solve the task well.

But problems occur when you need to create a more complex solution with its own special behavior. The libraries didn’t provide the same flexible public API as it was in our previous library text-mask. Moreover, they don’t have detailed documentation, and an in-depth understanding of the library is possible only through exploring the outdated source code.

We’ve communicated with other developers who used the above-mentioned libraries in their projects. They claimed that they had faced SSR or Shadow DOM errors, caret jumping issues and so on. In general, as I said before, there are no perfect solutions, different tasks require different tools.

Finally, the history of the text-mask library shows that even a popular library can be retired if it is supported only by a few maintainers. Long-lived library should be backed by a huge team or even an entire organization that will always be interested in its further development.

If the library is maintained for the needs of the company, you can rely on it, because even if the existing maintainers decide to change the project or quit their jobs, the company will simply replace them with other employees since it is important for them to support the development of the library for their own needs.

All of our subsequent research and team discussions led to the decision that we should create our own library for masking that would satisfy all our needs.

How it was developed

Before starting the development, we defined the main tasks we wanted to achieve:

1. The mask should support all user interactions with text fields: basic typing and deleting using the keyboard, pasting, dropping text in with the pointer, browser autofill, predictive text from mobile native keyboard.
2. Server-side rendering support.
3. The mask can be used not only with HTMLInputElement but also with HTMLTextAreaElement.
4. Our new project should consist of several libraries and the main one should be framework independent. For popular web frameworks, we should publish optional tiny packages.

The first task was done with the help of modern browser capabilities. We used the beforeinput and input events to control all the necessary cases.

The second task about SSR was solved in the following way: all our Cypress tests are run on an SSR application. If an error is caught during server-side rendering, the application stops serving and all tests start failing immediately. This approach does not allow us to catch all bugs, but several times this strategy has helped catch SSR issues before they were released.

Our Maskito library is ready to use. It is published to npm and can be used in your projects. For example, it is already actively used in the popular Taiga UI project (all its masked text fields were developed using Maskito) and is endorsed as the recommended masking solution by Ionic Framework.

Anatomy of Maskito

Maskito is a collection of libraries. The main one @maskito/core is a lightweight 3kb package with no external dependencies. The core library is sufficient to mask the input in a simple vanilla javascript application.

There is also an optional framework-agnostic package @maskito/kit. It contains a set of configurable, ready-to-use masks.

For modern JavaScript frameworks, we have released small packages: for React, Angular and Vue. They are called @maskito/react, @maskito/angular and @maskito/vue respectively. They provide a convenient way to use Maskito in the style of those frameworks.

Maskito in action

Now let’s explore the basic concepts of Maskito. Look into an oversimplified piece of code:

import {Maskito, MaskitoOptions} from '@maskito/core';

const element: HTMLInputElement = document.querySelector('input')!;

const options: MaskitoOptions = {
    mask: new RegExp('...'),
    preprocessors: [
        ({elementState, data}) => {
            return {elementState, data};
        },
    ],
    postprocessors: [
        ({value, selection}) => {
            return {value, selection};
        },
    ],
};

const maskedInput = new Maskito(element, options);

// Call it when the element is destroyed
maskedInput.destroy();

The main entity is the Maskito class, which is initialized with two arguments. The first is a reference to a native <input /> or <textarea /> element, and the second argument is the mask configuration.

After the class is initialized, native event listeners are enabled to control all user interaction with text boxes. The only thing the developer should care about is the need to clean up all listeners by calling the only public method destroy() of the class instance after the masked element is detached from the DOM.

You don’t need to worry about clean-ups if you use @maskito/react, @maskito/angular or @maskito/vue packages.

Let’s have a look at the configuration of the mask. In the code block above it is an object that implements the MaskitoOptions interface and is passed as the second argument to the Maskito class. Let’s learn the full power of mask configuration through an example. We will write a simple number input mask and iteratively improve it to demonstrate the power of Maskito.

The only required property is mask. It’s an expression that specifies the pattern which the final value of the text field should fit after all checks. It can be a classic regular expression, or it can be an array of mini-regular expressions. The last option is more complex, needed for masks with a fixed number of characters.

In the article, we will skip a more complex option of mask property. It is well described in the documentation, we will propose it as additional reading. For our task, an option with a simple regular expression is enough. The first version of mask for entering numbers is the following:

const maskitoOptions: MaskitoOptions = {
   mask: /^\d+(,\d*)?$/,
};

We’ve created a regular expression that specifies a pattern for entering a number with an optional fractional part that uses a comma as a separator.

Let’s complicate the task. Some users commonly use a comma as a decimal separator, while others might argue that the point is the more commonly used separator.

If we try to enter a point in the current version of the form, the form will reject it. This is unacceptable if we are trying to get the perfect UX. Of course, you can extend the regular expression to allow the decimal point, and let the user decide which separator to use. Let’s imagine that, according to our design system, the text field should only contain a comma. If a user tries to enter a point, it should be automatically replaced by a comma.

For this case we can use an optional field from the MaskitoOptions interface — preprocessors (array of preprocessors). The preprocessor allows the developer to add custom value mutations before the mask starts its work. After all preprocessors have finished their work, the new value is passed to the mask.

The preprocessor is a pure function. The first argument is an object containing the current state of the element (the elementState property): the value of the text field and the start/end positions of the text selection. Also, the first argument contains the data property with value from the same property of the native event that was fired after the user’s interaction with the text field (for example, if the user types from the keyboard, data will contain the new character typed). And the preprocessor expects an object with the same interface as the return value. The developer can change all these values or leave them the same. We can implement our task by replacing a point with a comma as follows:

import {MaskitoOptions} from '@maskito/core';

const maskitoOptions: MaskitoOptions = {
    mask: /^\d+(,\d*)?$/,
    // 0.42 => 0,42
    preprocessors: [
        ({elementState, data}) => {
            const {value, selection} = elementState;

            return {
                elementState: {
                    selection,
                    value: value.replace('.', ','),
                },
                data: data.replace('.', ','),
            };
        },
    ],
};

Note that the point is not only replaced inside the data property, but also inside the value property! This is explained by the fact that while mutating the data property is sufficient for most cases, there is only one rare case where an invalid dot can be inside the value as well. This is browser autofill. Modern browsers do not fire a beforeinput event for this, and only a single input event is fired after browser autofill.

Let’s make one last improvement to our mask for entering numbers and add the following behavior: if the user tries to insert a number with a lot of leading zeros at the beginning of the integer part, then discard the extra ones. For example, if a user enters the string 000.42, the value of the text field should become 0.42.

There is another optional property inside the MaskitoOptions interface that is perfect for our new goal. It is postprocessors (array of postprocessors). Similar to its preprocessor counterpart, a postprocessor is a pure function to modify the value of a text field to implement its own special logic. However, it is called after the mask has finished its work: after mask discards all invalid characters and ensures that the value of the text field matches the mask property.

The first argument of the postprocessor is the state of the element: the new value of the text field and the new positions of the text selection (after all validations and calibrations of the mask). As a return value, the postprocessor expects an object with the same interface as it received from the first argument, but allows to change the value of any of its properties. And the new version of the mask configuration looks like this:

import {MaskitoOptions} from '@maskito/core';

const maskitoOptions: MaskitoOptions = {
    mask: /^\d+(,\d*)?$/,
    preprocessors: [
        ({elementState, data}) => {
            const {value, selection} = elementState;

            return {
                elementState: {
                    selection,
                    value: value.replace('.', ','),
                },
                data: data.replace('.', ','),
            };
        },
    ],
    // 000000.42 => 0.42
    postprocessors: [
        ({value, selection}) => {
            const [from, to] = selection;
            const newValue = value.replace(/^0+/, '0');
            const deletedChars = value.length - newValue.length;

            return {
                value: newValue,
                selection: [from - deletedChars, to - deletedChars],
            };
        },
    ],
};

When using postprocessors, remember that this is the final step in validating and calibrating the value of the text field. You can make any changes you want, but at the end you must make sure that the final state of the element contains a valid value.

The postprocessor gives you a lot of flexibility, but as Uncle Ben said: “With great power comes great responsibility.”

In this article we have learned how to create a simple mask for entering numbers and we have become familiar with the basic concepts of Maskito! The final version of the example we’ve created can be further explored in the StackBlitz example:

Wrapping up

I have described only the core concepts of Maskito. But this is not all it is capable of. Maskito can do even more — you can read about it in the documentation.

If you like our new project, then star it on Github. And we always welcome your feedback! If you encounter any problems, then create an issue — we will do everything to fix it!

Maskito is a new collection of libraries for text field masking was originally published in IT-компании Тинькофф on Medium, where people are continuing the conversation by highlighting and responding to this story.

An old proverb says that everyone makes mistakes. It was relevant before and still relevant nowadays, people make them every day, and even a fluent filling out the forms cannot be completed without typos.

Good UI / UX helps the user to avoid mistakes. There are many approaches to validate a user’s input, but today I will tell you about creating a mask for the text field using JavaScript.

What is the mask?

Let us imagine that our web application has a text field for price. We want to allow the users to enter a number and reject any letters and other not-digit characters. Experienced readers can claim that HTML already offers <input type="number" /> for this goal. Let’s open our favorite browser Chrome and visit the documentation page of the this element. Any attempt to enter something except digits or dot/comma fails, and the input value does not change. The browser prevents any invalid key typing for this input type. It seems that we have already found a built-in solution, and it is time to finish this article.

But wait a minute! Let us open Firefox and repeat all actions. Unfortunately, this browser is not so strict and allows you to enter some invalid characters. It means that this input type does not work in Firefox, does it? Actually, no, it works, but … It warns users only on form submit via dropdown with a validation error.

Somebody can say that it looks like a bad joke by Firefox and claim that it is not effective and too late for good UX! And, of course, there are people who disagree with it. How many people — so many opinions. In this article, we will not decide who is right. Firefox demonstrates its own way of warning users about an invalid input, and Chrome prefers another approach — no worries, it will not be one of the Chrome vs. Firefox articles. The only thing that matters for this article is that Chrome demonstrates an example of input masking.

Mask is a programmatic constraint (defined by developer) which ensures that user enters value according to predefined format.

The previous example is just one kind of mask. There are an infinite number of different masks (even more complex!): time, date, phone, etc.

Rejection of invalid characters is not the only ability of a mask. It can also help the user to automatically insert some required characters. For example, it can add spaces between thousandths of a number (the number 10000 is more readable in this way, 10 000, isn’t it?) or automatically insert separators between a day/month/year in a date.

The mask can even guess the user’s intentions. For example, people from different countries can use different symbols as decimal separators: dot or comma. Let’s make an assumption that the dot is “your case”. A good mask inserts a “valid” decimal separator (dot) even if the user presses a key with an “invalid” one (comma).

Input masking is more about UX enhancement than data validation. Even an inexperienced hacker is capable of bypassing any frontend web application. Therefore, additional final data validation on the backend is always required!

Mask ingredients

We need to dive into the list of events that can be emitted by <input /> or <textarea /> to figure out how to control what the user inputs into the text field. Let’s discuss the main ones:

Keydown event is emitted every time any key is pressed on the keyboard. It contains a useful key property that stores information about the entered value. And most importantly, the event can be canceled via event.preventDefault!

It seems that such an event is perfectly suitable for input masking and completely satisfies all necessary requirements. But there are two drawbacks:

• System keys and combinations also trigger keydown events. It causes a number of issues for our task. For example, the user will copy the value of the input via Ctrl + C, and our mask gets a “false positive” signal. It takes a lot of effort to filter out the right events.
• The event cannot control the browser autofill and the selection of the suggested value from the native keyboard of the mobile device.

Moreover, if we use the keydown event for our task, we also have to listen to paste and drop events, which we will discuss a little later.

Keypress event is almost identical to the keydown event, but with one nice exception: it is fired only when a key that produces a character value is pressed down. keypress isn’t emitted by system keys that we don’t need and completely solves the first drawback of the keydown event.

But this event has another troublesome nuance. Official documentation page claims that this event is deprecated and is no longer supported by browsers. Yes, of course, you can open any modern browser and notice that this event is still running and works as intended, but it may cease to work at any time. Therefore, this event is no longer considered for input masking in this article.

Paste and Drop are important events for input masking, which are often unjustly neglected. The user can change the value of the text field not only by pressing keys from the keyboard but also by pasting from the clipboard and dropping the text into input by the cursor. Therefore paste and drop must be used if input masking is controlled via listening to the keydown event.

Change event is fired when the user modifies the element’s value. However, <input /> and <textarea /> elements emit this event not for each alteration to an element’s value. They wait until the text field loses focus after its value is changed. Let’s imagine that the user focuses on the input and tries to type the word “hello” — the text field will fire five keydown events and only one change (after blur). Despite the promising name and good browser support, this event is not suitable for our task.

Input event solves many of the issues of the previously mentioned “colleagues”. Here is a short list of event pros:

• The event is fired after each alteration to an element’s value, does not wait for the loss of focus (like a change event), and does not require other conditions.
• Pressing the system keys will not fire an event if they do not cause a change in the element’s value.
• It is watching all possible alterations to the text field: the event will be emitted on pasting text from the clipboard, on browser autofill, on dropping text into the input with the cursor, and even on selecting hints from the native mobile keyboard.
• Good browser support.

Unfortunately, there is a significant limitation to this event. It cannot be canceled via the preventDefault method, because the event notifies about a fact that has already happened. And the past cannot be changed, unless you have a vintage DeLorean!

Of course, we can save the element’s value and the position of its caret before each change. Of course, the saved data can be used to programmatically update the text field with the old value (to imitate the cancellation of the event). But this workaround can generate hard-to-maintain code.

There are many libraries on the Internet that make it easy to mask text fields. Most popular “mature” solutions use combinations of the described browser events with all the advantages and disadvantages.

But what if there was a need to create a new library in 2023… Would it repeat the experience of its predecessors? There is a trick up our sleeve that we have not discussed yet — the beforeinput event.

Modern mask recipe

Beforeinput is a “young” event that is perfectly suitable for textfield’s masking. In March 2017, it was presented to us by … Safari. Yes, this browser can not only bring tears to the faces of front-end developers, but sometimes be the first who delivers new features.

Chrome was the next to implement this feature, and other browsers later picked it up. The lagging big player was Firefox, which only provided support for the event in 2021. At the time of this article’s writing, beforeinput has good modern browser support and works for 94.59% of global clients.

Beforeinput event has a lot of advantages for our task:

• It fires only when you press keys that cause alteration to an element’s value.
• It supports all other ways to change the input besides keyboard interaction. The event has an inputType property, which can be one of the following values: insertText, insertFromDrop, insertFromPaste, deleteContentBackward, deleteContentForward, etc.
• It can be canceled via preventDefault.

It seems that the beforeinput event took all the best from the predecessors!

We’ve got a modern recipe for text field’s masking. Most of the value validation can be done in the beforeinput event, and in the input event you can make minor calibrations of the element’s value.

element.addEventListener('beforeinput', event => {
   switch (event.inputType) {
       case 'deleteContentBackward':
       case 'deleteContentForward':
       case 'deleteByCut':
           return handleDelete(event);
       case 'insertLineBreak':
           return handleEnter(event);
       case 'insertFromPaste':
       case 'insertText':
           return handleInsert(event);
       // ...
       // Many other cases
       // ...
   }
});

Let me emphasize an important thing. If you need to cancel the beforeinput-event (for example, to programmatically update the input with the desired value), then the subsequent input-event will also be canceled after it. This behavior is logically expected.

Sometimes we want to report what happened to external observers. A good example is the Angular framework — it has its own form tools that rely on the fact that an input event will fire every time the value of the input changes. The issue has many solutions, one of them being to execute element.dispatchEvent(new InputEvent(…)) after canceling the beforeinput event and then programmatically updating the text field.

Maskito libraries

We applied the revealed formula for creating masks in our new Maskito project. It is a collection of libraries written in Typescript. The main @maskito/core library is built without any external dependencies, which allows it to be used in any vanilla JavaScript project.

Maskito has a library @maskito/kit — a set of ready-made configurable masks. We also created a separate optional package, @maskito/angular, in case you want to use development in your Angular project. Read more about all the features of Maskito in the documentation. And in the next article I will describe our new libraries in more detail, and we will analyze some real code.

GitHub - taiga-family/maskito: Collection of libraries to create an input mask which ensures that user types value according to predefined format.

Maskito is already published to npm with zero-major versions and is ready to use. We are conducting final tests and fixing bugs in order to publish the first major version very soon. Keep the library in your notes! We hope you will find it useful in your next project!

More content at PlainEnglish.io.

Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord.

Interested in scaling your software startup? Check out Circuit.

Uphill Battle to Create a Mask for Text Field was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Developing a progress indicator is one of the simplest tasks for the frontend-developer. All you need is basic knowledge of HTML and CSS. JavaScript is used just to calculate the percentage of task completion.

However, this simplicity is deceiving. The Internet is teeming with a plethora of community solutions proposing to build the progress indicator with nested div-containers and CSS to spice things up. Steer clear of these solutions! Those are almost a crime against humanity since they worsen template semantics and violate accessibility.

In this article, I will show how in Taiga UI we developed Angular components: ProgressBar and ProgressCircle.

Developing ProgressBar

Task formulation

There is a built-in HTML tag <progress />. MDN claims:

The <progress> HTML element displays an indicator showing the completion progress of a task, typically displayed as a progress bar.

The important thing is that each browser differently renders this HTML tag. We require such a progress indicator which looks the same way on all browsers.

Wrong solution / De/IVious solution

The first idea which springs to one’s mind might be the superficial one: “Let us not use the built-in HTML tag at all. It is not fancy and looks different in each browser”. This idea cultivates another wrong solution within the community. The proposal revolves around creating two <div/>-containers: the first container is the progress tracker, and the second one is the progress indicator. The following step is to customize the containers and change the width of the progress indicator via JavaScript (from 0 to 100%).

The simplified version of this wrong solution is the following. The HTML file contains the two mentioned containers:

<div class="track">
  <div class="indicator"></div>
</div>

The CSS-file:

.track {
  position: relative;
  background-color: grey;
    
  width: 300px;
  height: 20px;
}

.indicator {
  position: absolute;
  top: 0;
  left: 0;
  height: 100%;
  width: 50%; /* change it via JS */
  background-color: yellow;
}

It does work visually. But that is only visually. However, what if a visually impaired user (e.g., cannot distinguish colors or is blind) decides to visit the website and doesn’t see the progress indicator?

In such cases, people use screen readers. These programs read out loud everything important that is happening on the screen to the user. Nevertheless, in the case of the ‘div’ solution the screen reader will not be able to comprehend this type of progress indicator. It will “see” only two <div />-containers filled in with different colors and will not pronounce it to the user.

This proposed solution not only worsens HTML semantics but also violates the accessibility of our web application. Of course, we can help the screen reader detect the progress indicator: we can set role=”progressbar” and also add aria-valuenow, aria-valuemax and aria-valuemin on the outer container. However, there is no need to reinvent the wheel and overcomplicate basic notions!

Improving DIV solution

There is a popular approach which can correct the accessibility of the previous solution. We can put visually-hidden native <progress /> HTML tag inside our custom progress component. Then we should pass attributes value and max to it and leave everything else as it was in the previous solution.

There are several approaches to visually hiding an HTML container but leaving it detectable for screen readers. Usually, it is sr-only CSS-class. For example, popular CSS frameworks such as Bootstrap and Tailwind CSS have such classes.

Warning! Do not use display: none, height: 0 and width: 0. They hide content not only visually but also for screen readers. Read more about this in the article “CSS in Action: Invisible Content Just for Screen Reader Users”.

After it, the progress indicator is not only visually fancy but also does not violate the accessibility principle. For example, the built-in Mac OS screen reader pronounces it as «n-percentage progress indicator» (where n — 100 × value / max).

Despite the progress, we are still not content with the template’s semantics! Moreover, we should create many @Input()-properties in our component to pass all required attributes to injected native <progress />-tag without any mutations. For now, it is only value and max, and who knows, maybe tomorrow we will need to add id or one of data-* attributes. As a result, our component carries attributes, which are of no use!

Our solution with Angular attribute component

We propose a solution which requires no extra HTML tags. All we need to do is to extend the native <progress />-element. Whenever we extend any native HTML element, the official Angular documentation recommends creating a component that uses an attribute selector with this element. This practice is actively used in our UI-Kit library Taiga: for example, button, link and label components.

Let’s create a TypeScript file with our attribute component:

import {
  ChangeDetectionStrategy,
  Component,
  HostBinding,
  Input
} from '@angular/core';

@Component({
  selector: 'progress[tuiProgressBar]',
  template: '',
  styleUrls: ['./progress-bar.component.less'],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TuiProgressBarComponent {
  @Input()
  @HostBinding('style.--tui-progress-color')
  color?: string;
}

The Less file includes some less-mixins.

The following one clears all built-in customization from the browser:

.clearProgress() {
    -webkit-appearance: none;
    -moz-appearance: none;
    appearance: none;
    border: none;
}

And this one helps to customize the progress tracker:

.progressTrack(@property, @value) {
    @{property}: @value; // Edge | Mozilla

    &::-webkit-progress-bar {
        @{property}: @value; // Chrome | Opera | Safari
    }
}

The last mixin helps to customize the color of the progress indicator:

.progressIndicatorColor(@color) {
    color: @color; // Not Chromium Edge

    &::-webkit-progress-value {
        background: @color; // Chromium Edge | Chrome | Opera | Safari
    }

    &::-moz-progress-bar {
        background: @color; // Mozilla
    }
}

Finally, apply all created mixins to :host-element of our component (reminder: it is a native <progress /> on which our attribute component was applied).

:host {
    .clearProgress();
    .progressIndicatorColor(var(--tui-progress-color, currentColor));
    .progressTrack(background-color, grey);

    color: yellow;
}

That’s all! We developed a nice Angular attribute component which is wrapped around a native <progress /> element. The color of this indicator can be set via the CSS color-property, or via the input property of the component (for example, if we want to create a complex gradient color). In the code, the component declares in the following way:

<progress tuiProgressBar value="60" max="100"></progress>

You can see the component in action on the showcase of our project Taiga UI. The final source code is available on GitHub.

Developing ProgressCircle

Unfortunately, the creation of the ProgressCircle component from only native <progress />-element is not possible. We need some extra template tags.

And here the state of things is the same, curious Internet users might stumble upon various frivolous solutions which propose to create a circular progress indicator from div-containers which have been rounded using border-radius: 50%. Also, such solutions use a significant amount of JavaScript.

Yet, since we are in the ‘no-div club’, this task can be resolved without appeals to div-s. We will use svg-tag <circle />. Moreover, we will use as little JavaScript as possible. Less preprocessor and CSS variables help us with it.

Let’s create a TypeScript file of our future component:

import {
    ChangeDetectionStrategy,
    Component,
    HostBinding,
    Input,
} from '@angular/core';

@Component({
    selector: 'tui-progress-circle',
    templateUrl: './progress-circle.template.html',
    styleUrls: ['./progress-circle.style.less'],
    changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TuiProgressCircleComponent {
    @Input()
    value = 0;

    @Input()
    max = 1;

    @Input()
    @HostBinding('style.--tui-progress-color')
    color: string | null = null;

    @Input()
    @HostBinding('attr.data-size')
    size: 'm' | 'l' = 'm';

    @HostBinding('style.--progress-percentage')
    get progressPercentage(): number {
        return this.value / this.max;
    }
}

The HTML file contains:

<progress
  class="hidden-progress"
  [value]="value"
  [max]="max"
></progress>

<svg class="svg" height="100%" width="100%" aria-hidden="true">
  <circle
    class="track"
    cx="50%"
    cy="50%"
  ></circle>

  <circle
    class="progress"
    cx="50%"
    cy="50%"
  ></circle>
</svg>

And the last step — the creation of the LESS file. We will use many features of Less: mixins, Maps, and built-in Math functions.

Firstly, let’s create map constants which store values for the different sizes of circular indicators (there are 4 sizes in our project, but for the sake of the code’s simplicity we will leave only 2). It is worth noting that Safari does not support rem-units inside svg-elements. However, it supports em-units. Therefore, we set font-size: 1rem for the host element to use em-units inside it.

@width: {
    @m: 2em;
    @l: 7em;
};

@track-stroke: {
    @m: 0.5em;
    @l: 0.25em;
};

@progress-stroke: {
    @m: 0.5em;
    @l: 0.375em;
};

The process of progress filling happens due to setting of stroke-dasharray and recalculations of the stroke-dashoffset. Look into the article “Building a Progress Ring, Quickly” to understand how it works. Our solution is just an improved version of what was suggested by its author. Create a mixin which calculates the state of the progress indicator for different components’ sizes:

.circle-params(@size) {
  width: @width[ @@size];
  height: @width[ @@size];

  .track {
    r: (@width[ @@size] - @track-stroke[ @@size]) / 2;
    stroke-width: @track-stroke[ @@size];
  }

  .progress {
    @radius: (@width[ @@size] - @progress-stroke[ @@size]) / 2;
    @circumference: 2 * pi() * @radius;
    
    r: @radius;
    stroke-width: @progress-stroke[ @@size];
    stroke-dasharray: @circumference;
    stroke-dashoffset: calc(@circumference - var(--progress-percentage) * @circumference);
  }
}

Finally, apply our mixin on host-element and add some cosmetic improvements:

:host {
    display: block;
    position: relative;
    color: yellow;
    transform: rotate(-90deg);
    transform-origin: center;
    font-size: 1rem;

    &[data-size='m'] {
        .circle-params(m);
    }

    &[data-size='l'] {
        .circle-params(l);
    }
}

.track {
    fill: transparent;
    stroke: grey;
}

.progress {
    fill: transparent;
    stroke: var(--tui-progress-color, currentColor);
    transition: stroke-dashoffset 300 linear;
}

.hidden-progress {
    .sr-only(); // see this mixin in the chapter with ProgressBar
}

.svg {
    overflow: unset;
}

That is all! You can see the component in action on the showcase of our Taiga UI project. The final source code is available on GitHub.

💡 Tip: You can now deploy your newly created semantic components to a platform such as Bit so they can be reused across all of your projects. With Bit, you’ll have independent versioning, tests, and documentation for your components, making it easier for others to understand and use your code. This would let your team reuse and collaborate on components to write scalable code, speed up development, and maintain a consistent UI. Find out more here.

Wrapping up

There are no absolutely correct solutions in the frontend-development. The same functionality can be implemented in different ways. But there are superficial and lazy solutions, which deliver the final product by sacrificing convenience and optimization. I have shown what mistakes can be made if you want to create progress indicators: poor semantics and neglected accessibility.

In this article, I have shown my point of view on these components. I don’t claim that my solutions are the best ones in the field. And still, during the development of those, I took all mentioned problems into consideration, ensured compatibility with all modern browsers and got simple solutions with a minimum usage of JavaScript.

Build apps with reusable components, just like Lego

Bit’s open-source tool help 250,000+ devs to build apps with components.

Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.

→ Learn more

Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:

→ Micro-Frontends

→ Design System

→ Code-Sharing and reuse

→ Monorepo

Learn more

• How We Build Micro Frontends
• How we Build a Component Design System
• How to reuse React components across your projects
• 5 Ways to Build a React Monorepo
• How to Create a Composable React App with Bit

How to Build Semantic Progress Indicators in Angular was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.

Undoubtedly, software developers are creative and pretty busy people — they do not have enough time to take care of routine tasks. However, machines can do all the monotonous tasks and, occasionally, even more effectively than humans. That is why everything should be automated to a large extent.

Hi! My name is Nikita. I am a frontend developer from Taiga UI. It is an Angular UI-Kit library that is actively used in the “Tinkoff” company. I will speak about solving one of such routine tasks in our project by writing a Github App in Node.js from scratch.

Problem statement — Lost in the forest of screenshots

In our project, we actively write screenshot tests using the framework Cypress.

After committing all code changes and opening pull request, a new Github CI Workflow runs every test. It saves our upcoming releases from introducing new bugs into our awesome UI-Kits components. If any test fails, all screenshots are attached as the zip-archive artifact to this workflow. The developer can download it and look into the screenshots. Unfortunately, we do not live in the perfect world where developers never make mistakes, and tests sometimes fail. Developers should download the archive and compare screenshots with “before” and “after” states. If there are too many tests, such simple action becomes an exhausting task. As I mentioned, this can be automated!

Cypress offers an official paid tool — Dashboard, which costs an arm and a leg. I bet that all developers need their limbs, so an alternative is unofficial, but a somewhat popular tool — Sorry Cypress. This open-source solution proposes almost the same dashboard but with lower prices and the possibility of hosting the entire infrastructure on your servers.

Even though this bootleg alternative is a better option, we still decided to write a simple Github bot.

How Github App works

To cut a long story short, the Github App is a set of callback-functions. They are called when the watched webhook-event is triggered in the repository. A list of all events is available on this Github Doc page. The callback-functions usually make Github API requests, leading to the creation of new commits, branches, files, and other changes in the repository.

We can monitor the necessary webhook-event and send the required API requests using only vanilla Javascript. However, it is much simpler to use community-approved solutions, which provide some abstraction over the vanilla JS. We will use the popular framework Probot for writing Github Apps.

You can initialize a new app using cli-commands. It is well described in the framework’s documentation and will not be repeated here. We recommend using a Typescript template during the app’s creation: strict typing prevents you from making random mistakes.

Listening to repository events

Our bot should listen to only three types of events: when the workflow begins (1), completes (2), and closes the pull request (3). Open the generated by cli index.ts file and add the following code:

Reminder: do not forget to give permissions to the bot to monitor workflow_run and pull_request events on the Github App’s settings page.

In the code, each callback-function to the repository event takes a context argument. This context contains much helpful information about the “watched” event. For example, it is the selector-function to get the name of the workflow that triggered the given webhook-event:

The context.payload also contains other required information: the id of the workflow run, the name of the branch on which this workflow was triggered, the number of the opened pull request, and a lot of other information.

Using the Github API

The framework Probot uses Node.js module @octokit/rest. It helps to use Github REST API methods via context.octokit…. See the list of all available methods here.

Our bot requires the following methods to create comments on pull requests:

• context.octokit.issues.createComment (create a new PR’s comment).
• context.octokit.rest.issues.updateComment (edit an already existing PR’s comment).

Do not be confused that we use methods from the issue object. Pull request is the same issue containing code. Github docs claims: “Every pull request is an issue, but not every issue is a pull request”. Therefore, all issue’s methods are applicable to the pull requests as well.

To download artifacts with screenshots of failed tests, we use the following methods:

• context.octokit.actions.listWorkflowRunArtifacts (a list of meta-information about the all artifacts of a given workflow).
• context.octokit.actions.downloadArtifact (downloading an artifact-archive by its id).

So, we have screenshot files and an understanding of how to create comments. Github’s comments support Markdown, and Markdown allows to insert images as base64 strings. It seems that it is a home stretch… but it is not. The Markdown’s version used by Github does not support this feature. You can insert an image into a Github’s comment only by an external link.

But this problem can be solved too. You can upload the required file (which we plan to attach to the failed tests’ report) to a separate repository branch and access it later via https://raw.githubusercontent.com/…. The code will be as follows:

After the PR’s closing, uploaded images can always be deleted. @octokit/rest library has API methods for it.

Deployment

Deployment is a compulsory part of every application life. The official documentation of the Probot framework offers detailed tutorials on how to deploy Github App using popular services. We deployed our Node.js application to Glitch. This platform provides free hosting, and the limitations of a free account are negligible for a simple application like a Github bot.

The final source code of our bot can be found on this Github repository:

GitHub - Tinkoff/argus: GitHub App for screenshots tests in CI

We already actively use it in our project. The repository with the application was named Argus (a many-eyed “all-seeing” giant in Greek mythology). It was developed much more resounding than described in this article, but the application’s core was described above.

Wrapping up — Getting out of the woods

The development of a Github App is easy. It requires neither deep knowledge of the programming language nor framework. You should just look through the list of the repository webhooks-events and look into Github REST API methods to find the necessary ones and apply them for your task.

In this article, we have built a Github application that watches workflows with tests. If any tests fail, the bot downloads artifacts, finds screenshots with the differences between the “before” / “after” states and then attaches them as a comment to the PR.

We deployed the code as a Github bot called Lumberjack. It is already actively following our Taiga UI project. But the bot has configurable parameters, and you can easily customize it for your project. Just invite it to your repository and show workflow to watch.

«Bots should work, developers should think»: Writing Github App with Node.js was originally published in IT-компании Тинькофф on Medium, where people are continuing the conversation by highlighting and responding to this story.

Disclaimer: this article is not written by experienced front-developer. The purpose of this paper is to help the author to reproduce successful implementation of web workers (dedicated and shared ones) in angular 8.

Introduction

As you know, Javascript is a single thread programming language, and it means that it can handle only one task at a time (you can read more about it here). If user executes the function which produces heavy calculations, he/she can’t interact with SPA until finishing the execution (your application will be just frozen). I hope there is no need to explain why it is not excellent UX.

The web workers can help us to solve the problem.

“Workers run in another global context that is different from the current window” — MDN web docs.

Web worker is a script which executes in separate thread (without interrupting javascript call stack!) and then return the result of calculation to UI. There are different kinds of web workers, but only dedicated and shared ones will be discussed in this article.

«A dedicated worker is only accessible from the script that first spawned it, whereas shared workers can be accessed from multiple scripts.

[…]

If SharedWorker can be accessed from several browsing contexts, all those browsing contexts must share the exact same origin (same protocol, host, and port)».

MDN web docs

Description of task example

It is no secret that all new concepts are easier to learn with examples. Let’s imagine that you are front-end intern and you have got a training task to write an app which will calculate the sum of all numbers from 1 to 2 billion. Additionally, your boss has said to include timer of application’s lifespan (which will be updated every second).

Firstly, you launch your IDE and create new angular app.

ng new largeNumberFactorial

In your app.component.ts you wrote this heavy function, rxjs timer and created some properties:

// app.component.ts
 import { Component } from '@angular/core';
 import {timer} from 'rxjs';
 
 @Component({
   selector: 'app-root',
   templateUrl: './app.component.html',
   styleUrls: ['./app.component.css']
 })
 export class AppComponent {
   heavyComputationsStatus = 'no tasks yet';
   appLifespan$ = timer(0, 1000);
 
   launchHeavyFunctionJSThread(): void {
     let result = 0;
     for (let i = 1; i < 2000000000; i++) {
       result += i;
     }
     this.heavyComputationsStatus = 'Calculations (inside component) were finished with id ' + Math.round(Math.random() * 100);
   }
 }

Let’s create a simple template.

<!--app.component.html-->

<div>

  <h1>Lifespan of application</h1>

  <p>{{appLifespan$ | async}}</p>

  <div>

    <button

      (click)="launchHeavyFunctionJSThread()">

      Count (JS thread)

    </button>

  </div>

  <p>{{heavyComputationsStatus}}</p>

</div>

After running this version of app, you can notice that clicking on button interrupts the timer (if you are a lucky owner of powerful computer, just increase number of iterations in function to notice it).

Dedicated worker

It is time for dedicated worker. Angular team with new version 8 introduces the possibility to generate new web workers from your Angular CLI (you can read about it here).

ng generate webWorker dedicatedWorker

It creates dedicated-worker.worker.ts. In this separate file you should insert all your heavy calculations. The worker communicates with your app component using postMessage function and listening to ‘message’ event.

// dedicated-worker.worker.ts

/// <reference lib="webworker" />

addEventListener('message', ({ data }) => {

  let result = 0;

  for (let i = 1; i < 2000000000; i++) {
    result += i;
  }

  const heavyComputationsStatus = 'Calculations (inside component) were finished with id ' + Math.round(Math.random() * 100);

  postMessage(heavyComputationsStatus);

});

Then, create worker only once in ngOnInit of your component and subscribe to getting event “message” from the worker. Don`t forget to destroy your worker in ngOnDestroy (it is meaningless for the app component, but was implementing for demonstration).

// app.component.ts
 import {Component, OnDestroy, OnInit} from '@angular/core';
 import {timer} from 'rxjs';
 
 @Component({
   selector: 'app-root',
   templateUrl: './app.component.html',
   styleUrls: ['./app.component.css']
 })
 export class AppComponent implements OnInit, OnDestroy {
 
   heavyComputationsStatus = 'no tasks yet';
   appLifespan$ = timer(0, 1000);
   dedicatedWorker: Worker;
 
   ngOnInit(): void {
     this.dedicatedWorker = new Worker('./dedicated-worker.worker', { type: 'module' });
 
     this.dedicatedWorker.onmessage = ({data}) => {
       this.heavyComputationsStatus = data;
     };
   }
 
   ngOnDestroy(): void {
     this.dedicatedWorker.terminate();
   }
 
   launchHeavyFunctionJSThread(): void {
     let result = 0;
     for (let i = 1; i < 2000000000; i++) {
       result += i;
     }
     this.heavyComputationsStatus = 'Calculations (inside component) were finished with id ' +
       Math.round(Math.random() * 100);
   }
 
   askDedicatedWorker(): void {
     this.dedicatedWorker.postMessage({});
   }
 }

And updated template:

<!--app.component.html-->

<div>

  <h1>Lifespan of application</h1>

  <p>{{appLifespan$ | async}}</p>

  <div>
    <button
      (click)="launchHeavyFunctionJSThread()">
      Count (JS thread)
    </button>

    <button
      (click)="askDedicatedWorker()">
      Count (worker)
    </button>
  </div>

  <p>{{heavyComputationsStatus}}</p>

</div>

Run your app. Clicking on button which posts message to worker doesn’t freeze our application!

Shared worker

You showed your result to the chief, he was satisfied, but in reply he asks you to add another feature: add button which will send result of calculations to other open tabs of your application in the browser.

Implementing shared worker is the most appropriate tool for this task. Unfortunately, at this moment (relevant for the summer 2019) shared worker doesn’t have the same Angular CLI support.

Firstly, you should create your shared worker’s logic by creating shared-worker.worker.js inside your root folder «assets».

//shared-worker.worker.js
 
 connections = [];
 
 self.onconnect = connectEvent => {
   const port = connectEvent.ports[0];
 
   port.start();
   connections.push(port);
 
   port.onmessage = messageEvent => {
     connections.forEach(connection => {
       connection.postMessage(messageEvent.data);
     });
   }
 };

Secondly, you should declare typings of SharedWorker constructor.

npm i @types/sharedworker

Then find this file “index.d.ts” in “node_module@types/sharedworker” and copy it to the root directory of your app (“src/app”) as “typings.d.ts” (don’t ask me why it is necessary but it does; it is the most «black box» part of shared web workers for me).

Thirdly, add creation of shared worker in ngOnInit of app component, subscribe to get new messages from this worker and define function to post messages from component to worker. Final version of .ts file.

// app.component.ts
 import {Component, OnDestroy, OnInit} from '@angular/core';
 import {timer} from 'rxjs';
 
 @Component({
   selector: 'app-root',
   templateUrl: './app.component.html',
   styleUrls: ['./app.component.css']
 })
 export class AppComponent implements OnInit, OnDestroy {
 
   heavyComputationsStatus = 'no tasks yet';
   appLifespan$ = timer(0, 1000);
   dedicatedWorker: Worker;
   sharedWorker: SharedWorker.SharedWorker;
 
   ngOnInit(): void {
     this.dedicatedWorker = new Worker('./dedicated-worker.worker',
       { type: 'module' });
 
     this.dedicatedWorker.onmessage = ({data}) => {
       this.heavyComputationsStatus = data;
     };
 
     this.sharedWorker = new SharedWorker('/assets/shared-worker.worker.js');
     this.sharedWorker.port.onmessage = ({data}) => {
       this.heavyComputationsStatus = data;
     };
     this.sharedWorker.port.start();
   }
 
   ngOnDestroy(): void {
     this.dedicatedWorker.terminate();
   }
 
   launchHeavyFunctionJSThread(): void {
     let result = 0;
     for (let i = 1; i < 2000000000; i++) {
       result += i;
     }
     this.heavyComputationsStatus = 'Calculations (inside component) were finished with id ' +
       Math.round(Math.random() * 100);
   }
 
   askDedicatedWorker(): void {
     this.dedicatedWorker.postMessage({});
   }
 
   askSharedWorker(): void {
     this.sharedWorker.port.postMessage(this.heavyComputationsStatus);
   }
 }

Final version of template

<!--app.component.html-->
 <div>
 
   <h1>Lifespan of application</h1>
   <p>{{appLifespan$ | async}}</p>
 
   <div>
     <button
       (click)="launchHeavyFunctionJSThread()">
       Count (JS thread)
     </button>
     <button
       (click)="askDedicatedWorker()">
       Count (worker)
     </button>
     <button
     (click)="askSharedWorker()">
       share
     </button>
   </div>
 
   <p>{{heavyComputationsStatus}}</p>
 
 </div>

Finally, run your app. Open some new tabs of your application. Press any button to execute heavy calculations on any page. After finishing it, press “share” button and look at other open tabs. The last line of every page will have the same string message (with the same id)!