Do you ever get that feeling when you’re working on a task, hit a wall with some problem, and something inside you whispers that there has to be a solution? When it seems like all is lost, like you’ve run into a fundamental limit of reality, but your refusal to accept it keeps driving you deeper into spec docs, 10-year-old GitHub threads, and articles from giants who’ve already blazed this trail and shared their findings? And then, after hours of intense brain-grinding, you add that final line of code, refresh the page, and there it is — the exact result you wanted, staring back at you from the screen? That rush of success is probably familiar to every engineer in some form or another. In those moments, I always want to share the win with my colleagues and, if it could help others, write an article about it. In this post, I’ve collected 3 such cases from our work where we came up with solutions that, as far as I know, are pretty unique and haven’t been fully documented before. I invite you to share in the joy of discovering a solution that seemed impossible!

Fixed inside a Scroll Container

For a warm-up, let’s take an easier task. One of my most popular CodePens is an example of a fixed block inside a scrolling container. People find it via Stack Overflow answers, so it’s an in-demand problem, so it might come in handy for you too.

I’ve been working on an Angular component library called Taiga UI for many years. Everything I’ll talk about in this article comes from there, but that’s just the backstory. We won’t need Angular or any of its specifics here. We’re talking pure CSS. Our library uses a custom scrollbar. While modern browsers let you tweak its appearance a bit, for full control over behavior and visuals, we need to place our own elements inside the container to act as the scrollbar. But how do you do that when absolutely positioned elements fly to the top on scroll, and fixed-position ones are pinned to the viewport?

Experienced devs will immediately think of position: sticky, but those elements take up space and only stick once you’ve scrolled the container past them. We’d need to compensate for their height somehow, but using negative percentage margins references the horizontal dimensions, when we actually need vertical ones. And that’s where the almost-forgotten in this post-Flexbox era float property comes to the rescue!

We want a block that covers the entire scrolling container while staying fixed during scroll. To do this, set inset: 0 and width: 100% / height: 100%. As you recall, percentage margins are based on the element’s horizontal size — and that’ll work perfectly here. Add float: left to make it “step aside,” and margin-right: -100% clears all the space it occupied for the rest of the container’s content:

.overlay {
  position: sticky;
  inset: 0;
  height: 100%;
  width: 100%;
  float: left;  
  margin-right: -100%;
  pointer-events: none;
}

Now you’ve got a container that acts fixed inside a scrollable block, and you can easily place anything in it — like buttons or toasts — without worrying about the main content.

Parameters for SVG

Now let’s pick something trickier. For displaying colorable icons, we use mask-image: fill the block’s background with the desired color, then cut it out along the icon’s shape using a mask. My colleague Nikita already wrote about all the cool things you can do with CSS masks — highly recommend reading it.

It’s a super simple approach that avoids DOM manipulation (and even nesting with ::before/::after), leverages the browser’s built-in caching, and works with cross-domain CDNs. Beauty everywhere — except you can’t control line thickness, since there’s no way to pass stroke-width. Or so I thought.

When asked yet again if we could tweak the pre-set stroke width in icons, I went to check how the spec for passing parameters to SVG is doing. Naturally, I didn’t remember where to find it or even its exact name, and while searching, I stumbled on an article with a genius idea:

https://kizu.dev/svg-linked-parameters-workaround/

If you’re too lazy to read it, the gist is: when setting viewBox and centering the image, you can make the mask height 100% but width any value from 100% and up, and the image looks identical. So what? Well, inside the SVG file’s own styles, those dimensions affect 100vw and 100vh. This lets you encode info via aspect ratio without changing the visual appearance. All that’s left is layering on a couple of calc() expressions so users can set line thickness via an intuitive — stroke-width variable:

stroke-width=”calc((100vw — 100vh) / 10)”

.icon {
  mask-image: url(https://medium.com/...);
  mask-repeat: no-repeat;
  mask-position: center;
  mask-size: calc(100% + 10 * var(--stroke-width)) 100%;
}

Notice the division and multiplication by 10 — this allows for subpixel thicknesses, like 1.5px

Perfect Shrinkwrap

Let’s ramp it up. New features in modern CSS have solved one of the oldest UI problems — one that previously had no solution: tight wrapping, also known as shrink wrapping. It’s best shown visually:

A container with text expands to fit as much text as possible, but once it hits max width, words wrap to new lines. This creates useless empty space, especially noticeable if there are elements after the text:

The solution, however, is pretty intricate and wasn’t easy to discover. It started with a clever technique for calculating an element’s size in pure CSS using scroll-driven animations:

https://frontendmasters.com/blog/how-to-get-the-width-height-of-any-element-in-only-css/

Again, for those skipping the full article: CSS now lets you track an element’s position inside its container with a view timeline. Designed for changing styles based on scroll position, it also lets us store the container’s size in a CSS variable. Roughly: animation progress via view timeline gives the percentage of the container occupied by the tracked element. Set it to a fixed size like 1px, and simple math reveals the container size.

This unlocks tons of new tricks — already working in Chrome and Safari, coming soon to Firefox. With container and inline text (that wraps) sizes calculable, we can find the unused space left. Subtract that gap from the container’s max width and its right margin. This keeps measured elements stable, avoiding an infinite shrink/expand loop:

.inline {
  /* Measuring text */
  view-timeline: --inner-timeline inline;
}

.inline::before {
  content: "";
  padding-inline-start: 1px;
  margin-inline-end: -1px;

  /* Measuring container */
  view-timeline: --outer-timeline inline;
}

.container {
  animation: outer linear, inner linear;
  animation-range: entry 100% exit 100%;
  animation-timeline: --outer-timeline, --inner-timeline; 
  timeline-scope: --outer-timeline, --inner-timeline;
  
  /* Measuring the gap */
  --delta: calc(-1px / (1 - var(--outer)) * var(--inner));
  
  /* Shrinking the width */
  max-inline-size: calc(15rem + var(--delta));
}

.block {
  overflow: hidden;

  /* Compensating the gap */
  margin-inline-end: var(--delta);
}

We get extra space compensated as the result:

Conclusion

The world around us is changing at crazy speed. AI is breathing down our necks from all sides, with cries of “run just to stay in place” and all that jazz. But I love my work, do it with real pleasure, and eagerly await the next puzzle that brings the joy of discovery and overcoming the impossible. I hope you’ve shared in it today, even though I know most of us front-end devs aren’t huge CSS fans. Maybe someday this article will help some AI tackle these challenges, but the effort, the grind, the brain-wracking — that’s ours, and I’ll keep cherishing it.

CSS Challenges for 200 IQ was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

Morse code

Telegraph uses Morse code. It’s pretty easy for us to understand as it is just a binary sequence. The signal is discrete, meaning it is broken into segments of a particular duration. At every given piece it’s either a “bleep” or silence. We can use Boolean or just 1s and 0s for brevity. It follows the rules below:

• There are two symbols: dash and dot
• Dash is three 1s in a row
• Dot is a single 1
• They are separated by a single 0
• Letters are separated by three 0s
• Words are separated by seven 0s (we can see this as space being four 0s + three 0s of char end)

Each letter is represented by the sequence depicted in the table below. You can also see the signal grid, black square means 1, white square is 0.

Let’s take letter “H”. It maps to 4 dots. Dot is a single 1, which also should be separated with 0, so we’ll have 4 of 1s and 3 zeros in between: 1010101. Given that here’s what “HELLO WORLD” would look like:

10101010001000101110101000101110101000111011101110000000 = HELLO[end of word]

10111011100011101110111000101110100010111010100011101010000000 = WORLD[end of word]

This is a standard US Morse code table, but there are other versions. If we were to implement this code table in Angular, this would be a good candidate for an InjectionToken. With second parameter having factory function we can provide this implementation as default value. And projects can swap it for their Morse code table:

export const MAP = new InjectionToken<Map<string, readonly (0 | 1)[]>>(
  'Morse code dictionary',
  {
    factory: () => new Map([
      [' ', [0, 0, 0, 0]],
      ['a', [1, 0, 1, 1, 1]],
      // ...
    ])
  }
)

We want to allow users to type on a regular keyboard then encode letters into Morse code. After we pass them over an imaginary telegraph line we will decode them and print them on the screen. It all starts with a single fromEvent(document, 'keydown') and then we will branch the heck out of this Observable!

Encoding

We can encode every letter synchronously. Each letter would turn into an array of 0s and 1s instantly. But since we emulate an analog device which is based on duration of signals — we will designate a certain length to every unit.

Let’s make unit duration an InjectionToken as well so it can be customized!

It means that letters are translated into sequences that have duration. Because we want to preserve the order of emissions and never lose a character from previous emission, we will use concatMap operator. It is a member of the Higher Order Observables family of operators and we use it to map every value to an Observable. Whenever a new value comes (a user presses a key) — it waits for the previous Observable to complete (a sequence is played out) before proceeding to create the next sequence Observable. This way we can type really fast and we'll never lose a letter in transition.

For the sake of a demo let’s also make a simple service to send those sequences. We will use it to send letter with mouse and virtual on-screen keyboard:

@Injectable({
  providedIn: 'root'
})
export class MorseService extends Subject<readonly (0 | 1)[]> {
  constructor(
    @Inject(MAP) private readonly chars: Map<string, readonly (0 | 1)[]>
  ) {
    super();
  }
  
  send(char: string) {
    this.next(this.chars.get(char));
  }
}

Now we can make a token that translates letters into Morse code sequence. First we get our mapping table and unit duration from the DI, as well as the service from the snippet above. Next we map all keydown events from document to their corresponding sequences from the table. We merge those key events with emissions from the service and use concatMap to losslessly turn them into a stream of 0s and 1s. We end each character sequence with a space sequence (three 0s in a row):

export const MORSE = new InjectionToken<Observable<0 | 1>(
  'A sequence of Morse code', 
  {
    factory: () => {
      const chars = inject(MAP);
      const duration = inject(UNIT);
      const service$ = inject(MorseService);
      const keydown$ = fromEvent(inject(DOCUMENT), 'keydown').pipe(
        map(({ key }: KeyboardEvent) => chars.get(key)),
        filter(Boolean)
      );
	
      return merge(service$, keydown$).pipe(
        concatMap(sequence =>
          from(sequence).pipe(
            endWith(...SPACE),
            delayEach(duration)
          )
        ),
        share(),
      );
    }
  }
);

Note usage of from instead of of. When used with Arrays it would turn them into sequence, whereas of will make a single emission with an entire array.

There’s a custom operator in there — delayEach. It delays every emission from Observable, rather than an entire stream:

function delayEach<T>(duration: number): MonoTypeOperatorFunction<T> {
  return concatMap(x => of(x).pipe(delay(duration)));
}

Now we can listen to the incoming Morse code by injecting MORSE token and subscribing!

Decoding

Decoding is much more fun. We need to create an operator to compare values with a sequence. It must reset if a value does not equal to the digit in the corresponding sequence position, emit a letter after the whole sequence is finished, followed by three 0s indicating the end of a letter. Then it repeats the same pattern.

We terminate and restart the stream so emission indices match those of our sequence.

We also want to visualize it so let’s create a special module for characters. It will consist of a Component, Directive and a Service. Why do we need all those? For a good logic separation. We need to know what character we are working with. But we need it in both Component and Service. To avoid cyclic dependency we will create a Directive with single purpose — let us know the character:

@Directive({
  selector: '[char]'
})
export class CharDirective {
  @Input() char = '';
}

We can use the same selector for a Component. We will use it to send signals with mouse and to visualize our demo:

@Component({
  selector: '[char]',
  templateUrl: 'char.template.html',
  styleUrls: ['char.style.less'],
  providers: [CharService]
})
export class CharComponent {
  constructor(
    @Inject(CharService) readonly service: Observable<number | string>,
    @Inject(CharDirective) readonly directive: CharDirective,
    @Inject(MorseService) private readonly emitter: MorseService
  ) {}

  @HostListener('click')
  onClick() {
    this.emitter.send(this.directive.char);
  }
}

Now we need to implement actual decoding. Notice that CharService has the type of Observable<number | string>. It will emit decoding progress as numbers between 0 and 1 and the letter once the decoding is complete. We will later display decoding progress for each character in the demo app.

Service

Creating this service is the hardest part. I’m not gonna lie, it took me quite some time to figure this RxJS puzzle out. Biggest difficulty came from space character. It looks a lot like a character end sequence which is also a bunch of consequent 0s.

We will start by creating all the helper functions. Our service extends Observable and it will have a private internal stream based on Morse code Observable we created earlier:

@Injectable()
export class CharService extends Observable<number | string> {
  private readonly inner$ = this.morse$.pipe(
    // ...
  )

  constructor(
    @Inject(MORSE) private readonly morse$: Observable<0 | 1>,
    @Inject(MAP) private readonly chars: Map<string, readonly (0 | 1)[]>,
    @Inject(CharDirective) private readonly directive: CharDirective
  ) {
    super(subscriber => this.inner$.subscribe(subscriber));
  }
}

We need to know what sequence are we looking for. It has to be a getter and not a read-only property because at the construction time Directive input has not been processed yet:

private get sequence(): readonly (0 | 1)[] {
  return [...this.chars.get(this.directive.char), ...SPACE];
}

If it was a static string value and not an input we could have changed Directive to @Attribute instead of @Input and get its value in constructor. But then we will not be able to create them in *ngFor.

There’s one thing that we do not need and that is — recreating the Array everytime we request it. For this purposes we can use @tuiPure decorator from Taiga UI. We use it a lot in our library for lazy getters. This is a memoization pattern for delayed computation. After the value is requested for the first time we replace getter with a plain property containing the result. All we need to do is add decorator on top of the getter.

It works on methods too. It would check for arguments and if they all match arguments from the previous call it would just return the previous result, without calling the method.

We also need to check that value at particular index of the sequence matches the given value. This way we would check that our Morse code stream matches the sequence we are looking for:

private isValid(value: number, index: number): boolean {
  return this.sequence[index] === value;
}

Next we need a value that the service is going to emit. We want to know the progress of decoding and the decoded letter:

private getValue(index: number): number | string {
  return this.sequence.length === index + 1 
    ? this.char 
    : (index + 2) / this.sequence.length;
}

With all those helpers we can build internal stream:

private readonly inner$ = this.morse$.pipe(
  takeWhile(this.isValid.bind(this)),
  map((_, index) => this.getValue(index)),
  startWith(0),
  endWith(0),
  takeWhile(isNumber, true),
)

We have two takeWhile operators. First one terminates the stream if the sequence didn't match. Second is used to terminate if a letter went through (isNumber is a simple helper to check type).

Second argument for takeWhile lets value that broke the condition though as well.

Restarting the stream

Terminating and restarting the stream makes it easy for us to check that sequences match. It makes emission indices in sync with the sequence we are looking for. Once we matched the whole sequence and a character went through (second takeWhile) we can just restart. But if decoding failed (the sequences didn't match) — we need to wait for the new character. It means that we must wait for three consecutive 0s.

My initial thought on restarting failed decoding was to use repeatWhen. But the trick with repeatWhen is that its factory function is only called once upon first termination. Then it continues to listen to the Observable that it returned:

repeatWhen(() => threeZeroes$),

This means that it would work well for us only for the second and all forthcoming restarts. But at the first one, those three 0s indicating the end of the letter have already passed by the time we start to listen to this restart stream.

First, let’s add code to listen for three consecutive 0s. It’s a great case for scan which is a lot like reduce in Array but runs on the fly (RxJS operator reduce is the same but it is only triggered upon completion).

export function consecutive<T>(
  value: T,
  amount: number
): OperatorFunction<T, unknown> {
  return pipe(
    startWith(...new Array(amount).fill(value)),
    scan((result, item) => (item === value ? ++result : 0), 0),
    filter(v => v >= amount),
  );
}

We use startWith with three 0s to kickstart the stream. Then we add up the number of consecutive 0s and only let through 3 or more. We cannot use exactly 3 because then space character (which translates to seven 0s) would break all other letters.

Now we need to separate two takeWhile operators. We want first one to terminate some inner stream. This means we need a Higher Order Observable again and concatMap is here again to save the day:

private readonly inner$ = this.morse$.pipe(
  consecutive(0, SPACE.length),
  concatMapTo(this.morse$.pipe(
    takeWhile(this.isValid.bind(this)),
    map((_, index) => this.getValue(index)),
    startWith(0),
    endWith(0),
  )),
  takeWhile(isNumber, true),
  repeat(),
)

Now when inner stream is terminated by failed decoding three consecutive 0s will restart it. Space character causes multiple groups of three consecutive 0s but they all will wait for internal stream to complete and will be dismissed once space character restarts the whole stream through second takeWhile.

Demo

We got everything ready, now it’s time to create a demo app! It will listen to keyboard presses and display a virtual keyboard. Demo will also print received message on screen and each letter button will display decoding progress.

Since it’s a telegraph with Morse code it just wouldn’t feel authentic without the sound. And simple bleeps are easy to create with Web Audio API and OscillatorNode in particular. We can use my wrapper library @ng-web-apis/audio.

It’s a part of our open-source initiative Web APIs for Angular. Our goal is to build high quality lightweight wrappers for native Web APIs for idiomatic use with Angular. Check out what we have so far!

With it we can turn declarative Angular directives into Web Audio API node graph:

<ng-container waOscillatorNode autoplay frequency="523">
  <ng-container
    waGainNode
    gain="0"
    [gain]="morse$ | async | waAudioParam : 0.02"
  >
    <ng-container waAudioDestinationNode></ng-container>
  </ng-container>
</ng-container>

It would play a bleep for 1s and be silent for 0s by controlling the volume. Now let’s layout our keyboard and decoded output. It also makes sense to add «Clear» button:

<section>
  <button *ngFor="let char of chars" type="button" [char]="char">
    {{char}}
  </button>
</section>
<output>{{ output$ | async }}</output>
<footer>
  <button type="reset" (click)="reset$.next()">Clear</button>
</footer>

But how do we get the output$? By querying services from template! Did you know that Angular queries can reach for services and other instances from node injectors?

@ViewChildren(CharService)
readonly services: QueryList<Observable<string | number[]>>

Keep in mind they are unavailable until ngAfterViewInit hook!

We can compose output$ stream this way:

readonly reset$ = new Subject<void>();

readonly output$ = this.reset$.pipe(
  switchMap(() => merge(...this.services.toArray()).pipe(
    filter(x => !isNumber(x)),
    scan((result, char) => result + char, ''),
    startWith(''),
  )),
  startWith(''),
);

ngAfterViewInit() {
  this.reset$.next();
}

And we also want to indicate decoding progress. To do so we will add a simple span block to our CharComponent and control its height and color with these two streams:

readonly progress$ = this.service.pipe(
  filter(isNumber),
  map(value => value * 100),
);

readonly pending$ = this.service.pipe(
  filter(Boolean),
  map(isNumber),
);

And one last neat trick I wanted to show is controlling CSS transitions with the same token we create for UNIT duration! Since Angular moved to Ivy renderer we are able to bind to CSS variables, so lets use --duration in our styles and add this to our main component:

@Component({
  // ...
  host: {
    '[style.--tui-duration]': 'unit + "ms"',
  },
})
export class AppComponent implements AfterViewInit {
  constructor(
    // ...
    @Inject(UNIT) readonly unit: number,
  ) {}

  // ...
}

Everything is finished and you are welcome to try the final product!

Note: sound doesn’t work in embeds, click “Edit on StackBlitz” to open it in a separate tab to enjoy glorious Web Audio API 😉

Telegraph with RxJS was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, let’s explore ActiveZone directive — an approach we took in Taiga UI Angular components library. It employs two of my favorite Angular features: dependency injection and RxJS. We will also need a thorough understanding of native DOM events. However abstracted from plain JavaScript Angular might be, it still relies on good old Web APIs so it is important to grow your knowledge of vanilla front-end.

Outlining the task

Basic usage example can be a button with a dropdown menu:

<button 
  [dropdownOpen]="open"
  [dropdownContent]="template" 
  (activeZoneChange)="onActiveZone($event)"
  (click)="onClick()"
>
  Show menu
  <ng-template #template>
    <some-menu-component activeZone></some-menu-component>
  </ng-template>
</button>

Let’s assume menu is rendered in a portal and is not a direct descendant of button. We want to open and close menu by a click on the button. And if user clicks away or moves focus with a tab key — a dropdown must close.

To track user interactions we will keep an eye mainly on the following events: focusin, focusout and mousedown.

focus/blur events don't bubble, unlike focusin/focusout

Keyboard navigation can only occur on focusable elements, while mousedown can be triggered by user selecting some text inside a dropdown, for example or interacting with non-focusable elements on the page. So those 3 events cover nearly everything we care about. But there are some tricky corner cases we will explore down the line.

Focus loss happens after mousedown event as a default behavior. If you call preventDefault() on this event, focus will remain where it is.

To achieve our goal it makes sense to always know what is the current element user is interacting with. In Angular world this means having an Observable of an active element. A very important clarification: we want it to be synchronous. This means, if a developer calls element.blur() in some of their code, on the very next line we must already know that we left the zone. This makes our task tenfold trickier and soon you will know why!

Dependency Injection token

To be able to reach for active element Observable anywhere within our app, we will turn it into an InjectionToken. It is global by default and provides a handy factory option which we can use to construct our stream. It will be called once somebody first injects the token.

Let’s make a first draft. First we will create all the constants we need:

export const ACTIVE_ELEMENT = new InjectionToken(
  'An element that user is currently interacting with',
  {
    factory: () => {
      const documentRef = inject(DOCUMENT);
			const windowRef = documentRef.defaultView;
      const focusout$ = fromEvent(windowRef, 'focusout');
      const focusin$ = fromEvent(windowRef, 'focusin');
      const mousedown$ = fromEvent(windowRef, 'mousedown');
      const mouseup$ = fromEvent(windowRef, 'mouseup');

      // ... continue below ↓↓↓
    }
  },
);

Now let’s combine those Observables into an Element stream. Since focus loss naturally happens after mousedown event we will stop listening to focusout after mousedown and repeat it after mouseup. That is why we need mouseup$ stream — this way we isolate all mouse related activity from focus related:

const loss$ = focusout$.pipe(
  takeUntil(mousedown$),
  repeatWhen(() => mouseup$),
  map(({ relatedTarget }) => relatedTarget)
);

// ... continue below ↓↓↓

relatedTarget for the focusout event is an element that focus is about to be moved to or null if focus is going nowhere.

In terms of focus gain we just need to map focusin event to the target:

const gain$ = focusin$.pipe(map(({ target }) => target));

// ... continue below ↓↓↓

Mouse interaction is more complicated. On each mousedown event we check if something is currently focused. If not (activeElement equals to body) we simply map mousedown event to its target. If something is focused we start to listen to focusout event, expecting focus loss. We use mapTo to turn this event into the mousedown target as well. But if default action was prevented and focus remained where it was, we stop waiting for focusout event on the next frame (timer(0)):

const mouse$ = mousedown$.pipe(
  switchMap(({ target }) =>
    documentRef.activeElement === documentRef.body
      ? of(target)
      : focusout$.pipe(
        take(1),
        takeUntil(timer(0)),
        mapTo(target)
      )
    )
);

// ... continue below ↓↓↓

Next let’s merge all those streams together. Now we have an Observable of an Element user currently interacts with:

return merge(loss$, gain$, mouse$).pipe( 
  distinctUntilChanged(),
  share() 
);

We pipe the whole stream through distinctUntilChanged and share operators so there are no extra emission and subscriptions happening.

ActiveZone directive

Now that we have the stream, let’s make a simple directive. It would map the stream to boolean letting us know if user is currently interactive with a given area. It would also reach through DI for parent directive of the same kind and register itself as its child zone. This way we can handle nested dropdowns mentioned in the beginning of the article.

Let’s see how we can do this:

<button (activeZoneChange)="onActiveZone($event)">
  Show menu
  <ng-template #template>
    <!-- 
      "activeZone" injects parent directive "activeZoneChange"
      from the button above, even if template is instatiated
      in a different place in the DOM
    -->
    <some-menu-component activeZone></some-menu-component>
  </ng-template>
</button>

This DI nesting can be any levels deep, that’s how nested menus and dropdowns can still be parts of the topmost zone. Now let’s write the actual directive:

@Directive({
  selector: '[activeZone],[activeZoneChange]'
})
export class ActiveZoneDirective implements OnDestroy {
  private children: readonly ActiveZoneDirective[] = [];

  constructor(
    @Inject(ACTIVE_ELEMENT)
    private readonly active$: Observable<Element>,
    private readonly elementRef: ElementRef<Element>,
    @Optional()
    @SkipSelf()
    private readonly parent: ActiveZoneDirective | null,
  ) {
    this.parent?.addChild(this);
  }

  ngOnDestroy() {
    this.parent?.removeChild(this);
  }

  contains(node: Node): boolean {
    return (
      this.elementRef.nativeElement.contains(node) ||
      this.children.some(item => item.contains(node))
    );
  }

  private addChild(activeZone: ActiveZoneDirective) {
    this.children = this.children.concat(activeZone);
  }

  private removeChild(activeZone: ActiveZoneDirective) {
    this.children = this.children.filter(item => item !== activeZone);
  }
}

This directive has only one public method — contains which is used to check if an element is located within current zone or any of its children. Now let's add an @Output. Since Angular outputs are Observables we can simply use our stream and pipe it:

@Output()
readonly activeZoneChange = this.active$.pipe(
  map(element => this.contains(element)),
  startWith(false),
  distinctUntilChanged(),
  skip(1),
);

Every new active element is checked against our directive, the stream starts with false so that distinctUntilChanged will not let through subsequent false results. We also skip the starting value so it doesn't immediately emit.

Potholes and pitfalls

Where’s the fun in everything working from the get go? The code above is pretty clean and functional, however there are certain cases where it will fail. Let’s explore them and expand our solution to cover them all.

☹️ iframe

There’s a frustrating behavior when using iframe. Whenever you click it, mousedown event does not happen. This means that if we have some nested iframe on our page and user clicks it, we will not know that they left the active zone. Thankfully, a blur event is dispatched on window when we start interacting with an iframe. It makes sense — we left the window to work with a nested one.

During most of the focus events if you were to try and check document.activeElement you will find body there. However in this particular case, inside blur event callback active element is already the clicked iframe. So all we need to do is amend our stream by including this in the merge:

const iframe$ = fromEvent(windowRef, 'blur').pipe(
  map(() => documentRef.activeElement),
  filter(element => !!element && element.matches('iframe')),
);

Another case when activeElement is not body inside focusout event is when we leave the tab. We will use it later so our dropdowns won't close when we go to DevTools!

😫 ShadowDOM

When working with Web Components or just ShadowDOM in general, you might have multiple focusable elements inside. window will not know about focus transitions within the shadow root. document.activeElement will remain the same — the shadow root element. And that shadow root will have its own activeElement to track the real focused element. Moreover, the target of all our events will not be the real element. It will be the shadow root as well. However, real target will be exposed to us through composedPath method on event.

It will not work for closed shadow roots but it’s the best we can do

So we need a utility function to retrieve the actual target. To reach for activeElement within ShadowDOM we will also need a function to get DocumentOrShadowRoot.

Let’s add them both:

function getActualTarget(event: Event): EventTarget {
  return event.composedPath()[0];
}

function getDocumentOrShadowRoot(node: Node): Node {
  return node.isConnected ? node.getRootNode() : node.ownerDocument;
}

We need to check isConnected because nodes detached from DOM will return the topmost element in their structure as a root node. For detached nodes it returns false and we get their document.

Let’s add one more function to track focus within a shadow root:

function shadowRootActiveElement(root: Node): Observable<EventTarget> {
  return merge(
    fromEvent(root, 'focusin').pipe(map(({target}) => target)),
    fromEvent(root, 'focusout').pipe(map(({relatedTarget}) => relatedTarget)),
  );
}

Now that we have those helpers let’s rewrite our focusin handler:

const gain$ = focusin$.pipe(
  switchMap(event => {
    const target = getActualTarget(event);
    const root = getDocumentOrShadowRoot(target);

    return root === documentRef
      ? of(target)
      : shadowRootActiveElement(root).pipe(startWith(target));
  }),
);

If focus is moving inside a shadow root we start listening to those encapsulated focus events, otherwise we just return target as before. For the mousedown event it is enough to just use getActualTarget.

😭 Deletion and disable

Not every focus loss should be considered a departure from zone. When we explicitly call .blur() on a focused element — it's a good case to call leaving the zone. However, when you click a button and it becomes disabled, for example by triggering some loading process, Chrome would also dispatch focusout event. Same goes for a button that removes itself (or its container) on click. When this happens inside a dropdown, most likely we do not want to close it automatically.

As far as I know there’s no way to tell an element.blur() call from a blur event that was caused by element being removed from DOM.

Checking disabled is easy, but removal from DOM is a hard nut. Remember, we have to do it synchronously. We cannot just wait and check if element disappears in the next frame. This time, I'm afraid we will have to resort to a workaround. Taiga UI requires you to use Angular animations. And AnimationEngine knows what element is being removed. Unfortunately there's no way to reach it because it is not exposed. So we will have to use private API for this. This is bad. But there's nothing else we can do in Chrome. And this hasn't changed since the introduction of Angular animations. Let's make a stream of an element being removed:

const REMOVED_ELEMENT = new InjectionToken<Observable<Element | null>>(
  'Element currently being removed by AnimationEngine',
  {
    factory: () => {
      const stub = {onRemovalComplete: () => {}};
      const element$ = new BehaviorSubject<Element | null>(null);
      const engine = inject(ɵAnimationEngine, { optional: true }) ?? stub;
      const {onRemovalComplete = stub.onRemovalComplete} = engine;

      engine.onRemovalComplete = (element, context) => {
        element$.next(element);
        onRemovalComplete(element, context);
      };

      return element$.pipe(
        switchMap(element => timer(0).pipe(
          mapTo(null), 
          startWith(element)
        )),
        share(),
      );
    },
  },
);

Let’s break down what we’re doing here. We make a simple stub and optionally inject AnimationEngine with a fallback just in case. We substitute onRemovalComplete with our own method to notify the BehaviorSubject we created. Comment on onRemovalComplete reads:

// this method is designed to be overridden by the code that uses this engine

So we pretty much do what we’re supposed to. If AnimationEngine was exposed.

Then we add a simple switchMap to reset our stream back to null on the next frame.

Let’s add this new stream to our chain and write a utility function to check if we want to react to a particular focusout event or not:

const loss$ = focusout$.pipe(
  takeUntil(mousedown$),
  repeatWhen(() => mouseup$),
  withLatestFrom(inject(REMOVED_ELEMENT)),
  filter(([event, removedElement]) =>
    isValidFocusout(getActualTarget(event), removedElement),
  ),
  map(([{relatedTarget}]) => relatedTarget),
);

// ...

function isValidFocusout(target: any, removed: Element | null): boolean {
  return (
    // Not due to switching tabs/going to DevTools
    target.ownerDocument?.activeElement !== target &&
    // Not due to button/input becoming disabled
    !target.disabled &&
    // Not due to element being removed from DOM
    (!removed || !removed.contains(target))
  );
}

End result

That was probably a lot to digest. This is not something one comes up with instantly when given this task. Such things are built gradually. You can see this whole solution in action in the StackBlitz below, with all the mentioned corner cases:

Tracking user interaction area was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

Taiga UI is a huge Angular components library. We at Tinkoff were developing it closed-source for a couple of years before finally going public with a second major version. It’s been a year since our open source release and today I want to look back at this part of our journey and lay down some plans for 2022. Let’s go!

Open source

Over this time the community started to build up. One benefit for going open source on GitHub is contribution made simpler even for colleagues from different projects. The environment is familiar, no extra authentication or VPN required and the pipeline is clear.

We also spent quite some time to improve our processes utilizing many different tools to help us ship new versions safer and faster.

Taiga UI is a monorepo that includes several libraries and a demo application that we deploy using GitHub Pages. Now it is managed by NX tools that provide a lot of useful commands and increase speed of building and testing at both local development and CI/CD pipelines. If you plan on working with monorepos you should definitely try NX!

Whenever a Pull Request is created we need to be able to quickly checkout the changes. Reading code diff is great, but sometimes you just need to tinker with the new version, test it on mobile, different browsers and OS. Cloud services are perfect for this case, they allow you to deploy the code temporarily and access it with a link from any device. We chose Firebase to host it for us and a GitHub action posts a link to the deployment as a comment in the Pull Request. It works like a charm and speeds up code reviews a lot. Read this article to set it up on your repository!

Moreover, every PR runs a set of Cypress screenshot tests that iterates over the demo portal and compares current components with their reference from the main branch. Cypress has a commercial solution where you can easily access failed screenshots through a dashboard. But we created a little Github bot that stores failed screenshots in a temporary branch and posts them to the PR as a comment, updating it on every push. This makes identifying problems with the UI library fast and easy. We opensourced this bot so you can use it too, read this article going over it in detail!

There’s also a husky precommit hook with ESlint and Prettier fixing and formatting changed code on every commit with lint-staged which makes sure malformed code doesn’t even make it to the Pull Request. Combined with standard-version and strict commit messages it makes releasing and changelog generation a breeze. For a contributor the workflow is as smooth as:

fork → npm ci → npm start → code → commit → push

What’s new?

When 2.0 went public it already was pretty big. But over the course of 2021 we added and improved a lot of things. With ideas and help from the community we significantly expanded customization and localization capabilities. This would be very helpful for our own international projects too. Taiga UI today has over 10 languages for built-in texts, RTL support for most of the components and various formats for money and dates. We also provide “ng add” schematic to get you started smoothly with Taiga UI. Let’s look at the most notable additions to our 150+ components base this year!

New components

SheetDialog — mobile sliding dialog

Tree — a flexible component to display tree-like data structures

PdfViewer — a custom dialog to preview PDFs in an iframe

Carousel — a common UI pattern for slider of images

ArcChart — a new way to display numerical data

New add-on packages

Table — an interactive table component and related utilities

Editor — a rich text editor based on tiptap 2

Preview — a custom dialog to preview arbitrarily content such as images and documents

We’ve also added a bunch of helpful utils, tokens, services and directives, such as Pan, Swipe, DropdownHover and more and a night theme for all components:

What’s coming?

It was a productive year. We’ve grown a lot in infrastructure and content, we started to build community of users, most notably from cryptocurrency area as it seems from the screenshots that come with user questions 🙂 In the coming year we plan to expand our localization and internationalization options so that developers from across the globe can enjoy Taiga UI and use it in whatever project they are working on. Here’s a brief overview of what we plan to focus on in 2022:

• Improve and stabilize new Editor add-on package
• Make all native inputs accessible from the outside of Taiga UI controls so it’s easy to assign attributes and listen to native events
• Rework some of our internals to rely more on CSS and less on JavaScript which would reduce change detection cycles
• Utilize DI more for customization
• Drop dependency on global styles
• Create ComponentHarnesses for Taiga UI components so they can be easily tested
• Support different implementations of notifications, like we do now for dialogs
• Reduce tech debt such as old components waiting for refactor and outdated mask library
• Prepare for the next major release with Angular 13 and Ivy distribution

I hope you’re happy with Taiga UI and if you didn’t try it — please give it a shot! Feel free to open GitHub discussion or contact us over at Angular Discord. For Russian speaking users we have a Telegram chat. Our issues list is open for feature requests and bug reports. And it also always has some things for you to try and solve if you want to contribute!

Taiga UI: A year in Open Source was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our test case

Let’s assume our-component with the following structure:

<parent>
  <child *ngFor=”let child of children”>
    <ng-container 
      *ngTemplateOutlet=”template; context: { $implicit: child }”
    ></ng-container>
  </child>
</parent>

And let’s say we use it as follows:

<our-component 
  [children]=”children” 
  [template]=”template”
></our-component>
<ng-template #template let-child>
  <some-component [item]=”child”></some-component>
</ng-template>

We will also list parent component template to be:

<parent-header></parent-header>
<ng-content></ng-content>

And child would be similar:

<child-header></child-header>
<ng-content></ng-content>

That is probably as simple as we can get to explore everything relevant. With a single child the rendered DOM tree is rather straightforward:

<our-component>
  <parent>
    <parent-header></parent-header>
    <child>
      <child-header></child-header>
      <some-component></some-component>
    </child>
  </parent>
</our-component>

View tree

Angular application consists of views, rather than straight up DOM elements. This allows for directives on non-existent elements, such as ng-container and interchangeable dynamic pieces of layout, such as ng-template. This subject is mostly relevant for change detection propagation. Let’s color our rendered example so we can see how it is broken down in terms of Angular views:

This weird breakdown is caused by content projection that places tags declared in one view into ng-content spot of another. Hierarchy of those views looks like this:

So even though the some-component is inside the child component which is inside the parent component it is actually a part of the top level view. That means, if you call ChangeDetectorRef.markForCheck() inside some-component which marks parent views for change detection check — it would only affect the top level view. If your components use OnPush change detection strategy, host listeners inside some-component will not trigger change detection neither for child, nor for parent and not even for our-component. A little less important, but still peculiar is that parent and child views are parallel to each other for the same reason, although they look nested in the DOM.

It’s important to know that @HostBinding is exactly what it is called — a binding on the host and therefore it belongs to the parent view in terms of change detection.

DI tree

The Injector tree in this example is a bit closer to DOM. Inside DI tree, communication can be organized with Dependency Injection pattern. Let’s quickly review those so later we can spot why they won’t always work.

When we need to get some data from the component above, we can inject it in the constructor or with the inject function made possible with Angular 14. It’s a powerful tool because it traverses the tree upward to the root so you can use it at any level of nesting. No need to drill inputs through multiple components. In Taiga UI, an open-source library my team maintains, we use directives to control similar properties for multiple components. For example the size of input fields can be declared on the parent form.

Keep in mind with OnPush change detection strategy your child views will not be updated if parent data changes. You might consider the controller pattern described by my colleague Roman in this article.

Injecting parent also allows children to communicate both ways. They can call back parent methods, passing data as arguments. For example an Accordion component can have a mode when only a single item can be expanded at a time:

<accordion>
  <accordion-item>...</accordion-item>
  <accordion-item>...</accordion-item>
  <accordion-item>...</accordion-item>
</accordion>

Child items can communicate with parent to let it know that an item was clicked and expanded. Parent can then tell all its other children to collapse.

If you ever implemented ControlValueAccessor you remember that child NgControl would call NG_VALUE_ACCESSOR methods providing callbacks for updating control value, touched state, etc. This is a similar approach.

Another pattern made possible with DI is somewhat reverse injecting. When your parent needs to keep track of their children and for various reasons cannot use @ViewChildren/@ContentChildren, children can instead inject parent and “register” themselves with some callback and “unregister” inside ngOnDestroy. This is how we link multiple “zones” a user can interact with across the DOM in our ActiveZone directive which I explored in detail before.

Inconsistencies with DOM tree

Now we can examine cases where differences with the DOM tree might make these solutions impossible. Consider following template:

<parent-component>
  <child-component></child-component>
</parent-component>

This seems straightforward but what if we want to affect children from inside the parent view? Say parent template looks like this:

<div myDirective>
  <ng-content></ng-content>
</div>

As expected, it would result in following DOM tree:

<parent-component>
  <div myDirective>
    <child-component></child-component>
  </div>
</parent-component>

However since content is rendered before view, child-component is not a child of myDirective in DI tree and therefore cannot inject it. This is easy to understand since content is part of the parent view. And you cannot expect the child view to render before the parent.

Another situation where we can easily end up with a DOM tree different from a DI tree is when we use ng-template. Consider following parent component template:

<child-component [template]=”tmp”></child-component>
<ng-template #tmp>
  <div myDirective>Hey!</div>
</ng-template>

And let’s say child-component instantiates the template straight away. We would end up with DOM that looks like this:

<parent-component>
  <child-component>
    <div myDirective>Hey!</div>
  </child-component>
</parent-component>

Even though myDirective is inside child-component in the DOM tree, it is a direct descendent of parent-component in DI tree because that is where containing ng-template is declared. Sometimes you can remedy that by simply moving ng-template so the child-component tag is wrapping around it.

This is negated somewhat by the newly added injector option for ngTemplateOutlet in the later versions of Angular

Handling the difference

Sometimes we need to pass data from DOM parent to DOM child and back, regardless of DI structure. There are some native tools at our disposal made easy to use by Angular. They rely on CSS custom properties and custom DOM events. Let us have a look at examples from Taiga UI once again, to understand them better. Our text field form controls use the basic PrimitiveTextfield component with built-in input element enclosed inside. However sometimes you want to add some native attributes, such as inputMode or autocomplete to that element. In this case, you can use following layout:

<tui-input>
  <input tuiTextfield inputMode=”email” />
</tui-input>

This translates into the following DOM (simplified):

<tui-input>
  <tui-primitive-textfield>
    <input tuiTextfield inputMode=”email” />
  </tui-primitive-textfield>
</tui-input>

Now consider that PrimitiveTextfield is aware of a cleaner X icon. It knows whether it is visible or not. This affects padding on the right side of the native input tag, so that it does not overlay long text. But unlike the built-in element, input tuiTextfield is not under direct control of PrimitiveTextfield.

In Angular we can bind values to CSS custom properties. We can even add units with no hustle and it works in templates as well as in @HostBinding. CSS custom properties propagate DOM and even Shadow DOM, so it is very helpful if you build Web Components or use native style encapsulation in your Angular components.

This is how we pass that padding along:

@HostBinding(‘style.--padding.rem’)
get padding(): number {
  return this.hasCleaner ? 24 : 0;
}

Then we just declare padding-right: var(--padding) inside our native input. Sometimes this also helps us work around change detection, since it uses native CSS and propagates instantly. It only applies to styles so the usage is limited but if you work on low-level components it can often come in handy.

Custom events

Another way to pass data across are native custom events. You will not be able to initiate data going down the DOM tree, but a child can dispatch the event to send some data to its parents or even request it from them. Let’s explore an example. Say we have a tabs component:

<nav tabs>
  <a tab>Tab</a>
  …
</nav>

The tabs component keeps track of the active tab. In this case every tab can inject the parent wrapper and notify it that they became activated (with clicks or routerLink activation for example). But we might want to hide tabs in the “More” section if they overflow. We will use a structural directive so we can move tabs around. Our component would look like this:

<tabs-with-more>
  <a *tab>Tab</a>
</tabs-with-more>

And inside it would still have that nav tabs:

<nav tabs>
  <!-- we will have ngTemplateOutlets here for tabs -->
</nav tabs>
<button>
  More
  <!-- 
    we will have some dropdown logic here with 
    ngTemplateOutlets for overflown tabs 
  -->
</button>

Now individual tabs cannot inject `nav tabs`, because in DI tree they are not its children. What they can do instead is to dispatch `new CustomEvent(‘tab-activated’, { bubbles: true })` and with `@HostListener(‘tab-activated’)` its DOM parents can listen to that event and react accordingly. Don’t forget the `{ bubbles: true }` part to make it propagate up the DOM. Default is false.

A few tricks with events

You can control what parent reacts to this event. If you want your closest parent to react first, just listen to the event as usual. You can stop propagation if you do not want other parents to know about it or you can ignore the event and let somebody else handle it up the tree. But you can also have the topmost parent to react first by listening to this event in the capture phase.

This is made simple by the ng-event-plugins library that we’ve created. It extends built-in Angular event handling with several plugins. It allows you to write @HostListener(‘tab-activated.capture.stop’) and declaratively listen to the event in capture phase and stop propagation at the same time. I strongly recommend you to try this library, it improves DX so much that I cannot imagine writing Angular apps without it anymore. If you use Taiga UI, it is already included.

Another helpful thing to know about events is they are synchronous. While the detail property of a custom event is immutable, it can in itself be an object that you can mutate. This allows children to request data from parents. Imagine for the sake of example, that in our tabs component a tab needs to ask the parent if it is active or not. Here’s how we can do it:

element = inject(ElementRef).nativeElement;
active = false;

checkIfActive() {
  const detail = { active: false };

  this.element.dispatchEvent(‘is-active’, { bubbles: true, detail })
  this.active = detail.active;
}

Because event handling is synchronous — on the very next line from dispatching an event all parents have already reacted to it. Our tabs parent component can check if the tab is active or not and set the value to the detail.active. Then the tab component updates its internal state. That neat trick allows us to request data across the DOM tree, rather than the DI tree.

Summary

After you digest all this, you will have a meaningful knowledge of how DI, DOM and View trees vary in Angular. This topic is somewhat advanced, but I tried to make it practical. This is a useful toolset to have in the back of your mind when developing Angular apps, especially if you tend to go low level, like we need to do when building Taiga UI. An important lesson to take from here is that Angular is a framework built on top of JavaScript. While for the most part we are abstracted away from the real deal, knowledge of native behavior can be helpful. Deeper understanding of the whole web ecosystem will be helpful in advancing your career from Angular developer to a Frontend specialist.

DOM, DI and View: the trees of Angular was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

Web APIs for Angular

Roman and I started our open source journey with this project. It is a collection of tiny libraries, wrapping various native Web APIs from Canvas to Speech recognition, from IntersectionObserver to Web MIDI API and more. They all follow same key principles:

1. Minimum interference with how native JavaScript works, but
2. Easy consumption of these APIs in an Angular app in a natural way

This means declarative directives, DI, services and RxJS streams where in vanilla app you would have imperative methods, callbacks and manual class creations.

I have published an overview article of this project. There you can find brief descriptions of currently available libraries and credits for community contributions. While we don’t really have time for new adventurous additions anymore, like Gamepad API or WebXR API, this is an open source project and everybody can participate. And if we will need to use another Web API in our work, that would be a place where we first implement it.

Event manager plugins

Event manager is an obscure area of Angular, although it saw some traction as of late, thanks to our library being discussed on Twitter by multiple influencers in the Angular ecosystem. If you are interested in the mechanics of all this, I have written a couple of articles on the subject a while back. They are rather dated at this point, so the main idea is — you can augment Angular with custom event handling logic with DI token. So, for example, you can write (click.stop)="onClick()" and have it implicitly call $event.stopPropagation(). With time we have collected a set of plugins that range from quality of life improvements like the previous example to pretty vital things that you couldn’t really do in Angular before.

You can now listen to events in capture phase!

If you are using Taiga UI, those plugins are all enabled by default, but they are a separate library which you can easily add to any Angular project of yours. What they allow you to do is add modifiers to standard DOM events (and CustomEvents too) that would enable certain handling logic. And those modifiers can be combined together. I’ll give you an interesting example where this library really helped me out!

I had a component with a form, which I needed to be able to submit, but also to be able to reset to default values. The trick was, I need to be able to do that from a place that knows nothing about the underlying form. So I went for native type="submit" and type="reset" buttons. Once the form was submitted it would disappear from DOM (it was in a modal window). Due to the dynamic nature of this modal, Angular form directive that is responsible for preventing default form submit action was destroyed before it could handle the event. This caused a page reload (default submit action). Also, there’s was no way to reset form to the default values unless you do it manually and native reset action just clears all inputs inside the form.

So this is how my form looked like with the plugins:

<form
  (submit.capture.prevent.silent)="0"
  (reset.capture.prevent.stop)="onReset()"
  [formGroup]="form"
>

Let’s unwrap what this does. Submit event is listened to in the capture phase and we call preventDefault() on it so our page does not reload. We also sprinkle .silent in there so that change detection is not triggered one extra time upon submit. Then we listen to the reset event, once again, in the capture phase to be the first to react. We prevent native behavior so it does not clean our input tags and we also call stop. This makes the reset event not trigger in the bubbling phase at all so Angular never finds out and we can call onReset with our custom logic.

While this example is rather extreme, you can see how just a few words can save you from pretty tricky situations normally requiring bulky workarounds. This plugins library is dependency free, weighs less than 2KB gzip and works with any Angular version from 12 and above. It would most surely improve your DX with Angular so give it a shot!

Polymorpheus

This is one of my favorite Angular projects of all time because it allows for a very important paradigm shift. Angular has multiple ways to create dynamic content, with multiple ways to provide input to the process. You can just use interpolation, and for dynamic content you can use functions:

{{ showSelected(items.length) }}

showSelected(length: number): string {
  return length ? `${length} selected` : `Nothing is selected`
}

For something more complex (HTML, styles, directives) you can use ng-template + ngTemplateOutlet and pass context to provide some input:

<ng-template let-length>
  <strong *ngIf="length else empty">{{ length }} selected</strong>
  <ng-template #empty>Nothing is selected<ng-template>
</ng-template>

Finally, for something reusable across apps or something really complicated that you would like to properly isolate you can use ngComponentOutlet + dynamic components. Passing data gets even more complicated as the only way to do it would be through custom Injector.

What ng-polymorpheus does is abstract all this hustle away to allow you to think simply in terms of content and context.

It adds a universal outlet directive which you can use with primitives, functions, templates or components in the same way.

<strong *polymorpheusOutlet="content as text; context: context">
  {{ text }}
</strong>

In the example above, primitive values and results of functions called with context would display <strong>value_or_function_result_here</strong>. As for templates or dynamic components — they will be instantiated at that spot. This might not seem like a big deal at a glance, but once you learn to harness the power of universal content you will never have to worry about designers changing specs of your components to allow for more visual customization.

Maskito

While not tied to Angular, this separate project is also worth mentioning here. It is a framework agnostic input masking solution we developed and it is the most recent addition to the family. It provides a very flexible and transparent API to add masking to input and textarea inside your application, whether you use Angular, React, Vue or even vanilla JavaScript. It can work with components libraries without direct access to native input tags, it has got you covered on every possible user interaction — keyboard, virtual keyboard, autofill, drag and drop, copy and paste — you name it!

The only reason I only briefly mention it here is because I have already published an extensive article about Maskito benefits and why it is worth considering. Share it with your team lead if you ever face a decision on a masking solution for your project. If you are interested in more technical aspects of this library, Nikita Barsukov is better suited to give you an overview as Maskito lead developer. You can read his two part article here and here. You can also check out our extensive demo portal.

Honorable mentions

There are also some other libraries we maintain that I would like to mention. But in order to not overload this article I’ll do it briefly:

ng-morph

This library has made Angular schematics for Taiga UI breaking changes migration easy. It is a large set of tools for both global code base updates in your project and speeding up your work on Angular schematics manipulating with TypeScript AST safely.

You do not need to know how TypeScript works under the hood to transform your project. You can use simple ready functions for manipulating TS and NG entities. Moreover ng-morph adds several benefits in the process:

• You make changes in virtual file structure. So, you can check the new structure first, fix all the bugs and inconsistencies before saving changes in the real project structure. It is much faster than migrating a real project and reverting changes after checking
• You can write unit tests for your functions and scripts before using it in real projects or share with a lot of colleagues

ng-dompurify

Pretty sure you have seen «WARNING: sanitizing HTML stripped some content» before. With this tiny library you can extend Angular’s built-in sanitizing capabilities with an acclaimed dedicated library DOMPurify. For more information, you can read my old article which is still relevant. Note: ignore sections about styles sanitizing, Angular no longer does that.

@taiga-ui/cdk

You may not care for Taiga UI as a components library, but the foundational package is completely detached from visual style and is fully tree shakable. There are plenty of goodies that can help you build your own stuff, such as extensive abstractions over ControlValueAccessor, @tuiPure decorator or tuiMapper pipe for memoization, low level directives and services and a lot more.

Summary

All these libraries are developed and supported by our team at Tinkoff. They are backed by a huge commercial enterprise and are heavily used internally. This means you can rely on them still being maintained in the future. Go ahead and check them out and if you find some feature lacking or a bug — don’t hesitate to raise an issue at the corresponding GitHub repository. Please also consider giving them a star — that simple action helps us show management that our open source initiatives are relevant and worth doing. If you wish to contribute to open source, you can find an issue labeled “Contributions welcome” or “Good first issue” to help us improve the Taiga UI family!

Taiga UI: more than UI kit was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

We were no strangers to these troubles and at some point we decided to dedicate serious resources to our own solution. Today I would like to present it to you and explain why it is worth your attention.

What is Maskito and why should you care?

Maskito is a set of libraries for input masking with focus on both UX and DX. You can check out our extensive documentation portal. There you can find plenty of examples, as well as a detailed walkthrough of the API. The “Getting started” section will explain the basics and will quickly get you familiar with concepts and use cases. You can also read a more technical article by Maskito lead developer Nikita Barsukov.

Of course, Maskito is not the only solution you can find. But I believe there are certain things setting it apart from most alternatives available right now. Hence the ambitious title of this article. Let’s briefly explore why you should consider Maskito if you are looking for a masking solution for your project.

Backed by enterprise

Unlike many open source libraries that are maintained by individuals, Maskito is a product developed and used by one of the world’s leading fintech companies. We are seasoned open source authors getting paid for what we do so you can rely on timely support and continuous development.

Our team already has a stock of welcomed projects, especially in the Angular ecosystem, such as Taiga UI, ng-polymorpheus and Web APIs for Angular to name a few. We take them very seriously because they are not pet projects or hobbies (although we love them as if they were). Therefore you can expect our documentation to be easy to navigate, examples to be plentiful and communication to go effortlessly.

Framework agnostic

Whether you use React, Vue or Angular for your product or you rely on some other framework or even vanilla JavaScript — Maskito got you covered. Our main package is dependency free and can be used in any frontend application. And so are mask presets that we will cover below.

At the time of writing we have dedicated packages to use Maskito in React, Vue and Angular with comfort. Since the public API is rather succinct, it would be easy to expand support to other popular frameworks. Actual masking configuration is the same and can be shared across different projects and architectures with ease.

Environment agnostic

Maskito works in all modern browsers regardless of the environment you run it in. You can be using Web Components with Shadow DOM or employ SSR to improve your time to interactive and SEO — your inputs will not give you trouble by trying to access ‘window’ under nodejs or messing with encapsulated focus. It will also work properly on touch devices and virtual keyboards on both inputs and textarea elements. Clipboard interaction, undo/redo, text drag and drop or browser autofill are also covered by Maskito.

Our goal is to create a go-to masking solution for the web and the web is as diverse as it gets. If you face any issues with some specific configuration, please do not hesitate to raise an issue.

Quality code

Maskito is maintained by an experienced lead developer and a team of contributors with a history of delivering widely used versatile solutions and open source libraries. Multiple Google Developer Experts curate the project and make sure architectural decisions are well thought through and make sense in the long run.

All code is written in strict TypeScript and covered by tons of e2e tests and community contributions are thoroughly reviewed. We have tightly configured linters and automated pipelines we perfected for years on other projects to make sure technical flaws do not make it to the release. We use it in a multi million users business product. It is in our best interest that the caret does not jump all over your input fields.

Not just us

While we of course trust our solution and are happy with it, you might be wondering if it would suit your particular needs. We have a wide array of products with different browser and device usage, different specs and requirements. Our team consists of engineers that specialize in generalized solutions and flexible APIs. So we know there’s an endless pool of use cases and we are prepared.

But it is not just us — Ionic Framework, a multi platform UI solution with nearly 50k stars on GitHub has adopted Maskito as its official masking library recommendation. Their team did an investigation of existing alternatives and considered an option to develop their own mask. They decided Maskito would satisfy the needs of their extremely varied user base and added examples of masking their components to the documentation.

Ready to use

Maskito comes with a dedicated package of ready-to-use masks. We maintain a huge components library that has number formatting, credit cards, phones, dates etc. It is used in dozens of applications across our ecosystem, where additional masking is required for zip codes, IP addresses, serial numbers and so on. Once they are implemented and properly tested, all generally applicable cases are extracted and reused.

This is an ever growing collection of presets that you can take as-is and be sure they behave properly. You can contribute to it or raise a feature request for a particular solution at our GitHub repository. This makes Maskito as tiny or as comprehensive as you need it to be. Core package is only about 3KB gzip and every piece of presets is tree shakable so your bundle is in safe hands.

Summary

Maskito is free for both personal and commercial use and is released under Apache 2.0 license. I am really proud of what the team is doing and believe it to be the best solution for the task. I hope it can help you bring your ideas to life in a smooth way both for your users and developers. Check Maskito out and if you like it, support us with a star and help us spread the word. Happy masking everyone!

Maskito: a Holy Grail of input masking was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is it?

Web APIs for Angular is an open source initiative me and Roman started a long time ago. If you follow our tech writing, you know that we are devoted advocates of the Angular way of doing things. We love declarative idiomatic approach and try to promote it wherever it is applicable. So at some point we looked at Web APIs page on MDN and decided why don’t we make it easier to use those in Angular. I started with Web Audio API, because that subject fascinated me. We also noticed that with only the DOCUMENT token at our disposal it is not easy to work with other global objects, such as window or navigator in safe DI fashion. So we have created what would then become the most popular library of the set — @ng-web-apis/common, a collection of tokens for global objects. This made them easy to test and use in Server Side Rendering, thanks to a sister package @ng-web-apis/universal.

I have already written an article on why it is important. And also one on Web Audio API in Angular, as well as using it together with Web MIDI API. But I have never spoken about this initiative as a whole and there’s a lot of other very helpful libraries you might have missed when you had a need to use MutationObserver or Geolocation API in your Angular app. So with this article I would like to fill in the blanks and briefly showcase everything we have now.

APIs

With Common and Universal packages described in the article I linked above, and Web Audio and MIDI out of the way, our remaining packages are:

IntersectionObserver

This is our most popular library after the common package. It allows you to use IntersectionObserver in a natural Angular way. Mark element to be the intersection root by a dedicated directive, define parameters, such as threshold or margins. Then add a second directive to DOM elements you want to observe. Simple Angular output would emit intersection entries. Same thing can be done with a service and providing config with DI tokens.

ResizeObserver

Following the same approach of declarative directives + Observable service, this library adds such a vital missing feature as watching element size change in a performant way. These observer libraries outline our core principles well — wrap native APIs with minimal interference. Working with DOM means directives, events mean RxJS streams. Then we get benefits of using API in a comfortable way for a couple of kilobytes gzip.

MutationObserver

The last of the observers bunch. This API is rather old, first introduced over a decade ago. It follows the same principle of directives and service once again. But this time directive extends native MutationObserver class which makes it even smaller and showcases an interesting approach modern JavaScript opens up. Don’t worry about node.js and server side, since our dedicated universal package got everything covered. Keep it in mind for Jest testing too!

Geolocation

A contribution by Vladimir Potekhin who would later become a core member of our flagship project Taiga UI. This package gives you an Observable service to watch for your GPS location in an Angular app.

Canvas

This package adds directives to draw on HTMLCanvasElement in a similar way you declaratively describe graphics with SVG. It covers every 2D capability Canvas API has, such as paths, transforms, text and stroke/fill rules.

Workers

A contribution by Igor Katsuba whose project ng-morph has helped us make really complex breaking change migrations automatic (read about it here, here and here). The workers package allows you to use Web Workers in Angular in a familiar fashion using RxJS event streams.

Payment Request

Historically the first open source project by Roman. It is a declarative way to set up payment requests with directives that you can use on a basket component at a checkout of your e-commerce app.

Permissions

A contribution by Dmitry Efimenko. A tiny package with a service that allows you to query for permissions in RxJS streams.

Speech

Speech synthesis and speech recognition APIs in one package. You have a text-to-speech configurable directive and a service to recognize speech using RxJS operators.

Storage

Using Web Storage API with Observables.

Moving to Taiga Family

We started this initiative to explore the open source landscape as our personal project. Of course since it was very helpful, we quickly adopted those libraries in our work. Over the course of recent years we have had less and less time to dedicate to them. Especially to the more niche ones like Web Audio API, the biggest and the most complex one to date. Libs remained in View Engine publication with Angular 9, when Angular 16 was already out. The most reasonable thing to do was to move them all into an nx monorepo to easily maintain dependencies versions. But that was not something we had time to do on our own as many other projects had our attention. I couldn’t just ask my colleagues to do this in their spare time either. Given some of these libraries are vital parts of our products, we decided to move this initiative under the Taiga Family organization so our whole team could help during work hours. For the end user the only thing that changes would be the license switch from MIT to Apache 2.0. That and better, timely support. It remains open source and you are very welcome to contribute. New major versions will be released to indicate the license change and every library would be updated to Ivy publication which is good news, considering ngcc is phased out. Make sure to raise an issue at our new monorepo if you face a problem with any of our libraries, old repositories will be switched to read only.

Web APIs for Angular was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

View is template of your component. This means it doesn’t exist in directives.

Content is what your component (or directive) is wrapped around. For components you need to add ng‑content tag in your view to preserve content. Otherwise it is replaced with view upon render.

💡 Performance tip: even if ng‑content is hidden with *ngIf and detached from DOM, it is still rendered. And it still goes through change detection cycles. If you need lazy content initialization you need to use templates.

ViewChild and ViewChildren

When you create component, you might need access to some parts of its template. @ViewChild decorator allows you to do so and more. First, you need to provide selector. You can mark item with a string in the template: <div #ref>...</div>. And then query it with a decorator: @ViewChild('ref')

This is a template reference variable and we will discuss it in detail later.

It could also be class if you aim at a component or a directive: @ViewChild(MyComponent)

It can even be an injection token: @ViewChild(MY_TOKEN)

Real strength though comes with the second argument — an options object. First option is trivial: static: boolean. It tells Angular whether some child always exists or present with a condition. static: true means it can be queried in ngOnInit. static: false means it is not available until ngAfterViewInit. Default value is false.

<div #static>
    I'm a static child
</div>
<div *ngIf="true" #dynamic>
    I'm not a static child
</div>

Note that even static queries are resolved only in ngOnInit. So technically they are undefined for some time. It is a good practice to reflect that with proper type so you do not try to accidentally access it in a constructor. Hence a question mark in type in examples above.

Second option is read. First argument tells Angular where to look and read tells it what to look for. We can get everything from target injector - be it a service, a token or a component instance.

By default, @ViewChild retrieves a component when we query it. The most common use for read option is to get ElementRef instead:

@ViewChild(MyComponent, { read: ElementRef })
readonly elementRef?: ElementRef<HTMLElement>

Quite often though you don’t need @ViewChild at all. In a lot of cases you can just use template reference variable and pass it straight to the callback:

<input #input type="text" [(ngModel)]="model">
<button (click)="onClick(input)">Focus input</button>"

// Notice that it's HTMLElement not ElementRef here in this case
onClick(element: HTMLElement) {
    element.focus();
}

You can think of template reference variables as kind of closures in template in this case. The reference is there, but it only exists in a closed circuit where it is needed. It helps you keep component’s code clean.

Template reference variable targets component when it’s on one and an HTML element when it’s not. It can also target directives, that’s what exportAs is for in @Directive decorator:

@Directive({
  selector: '[myDirective]',
  exportAs: 'someName',
})
export class MyDirective {}

<div myDirective #ref="someName">...</div>

Sometimes you need to query multiple items of the same kind. In this case you can use @ViewChildren. You can mark many items in template with the same reference and retrieve a whole collection. All advices above are applicable here too, except the type would be QueryList<T> and static is not available for lists. This allows you to go over every item when you need to. Consider an example with tabs component. Instead of horizontal scroll you want to hide extra tabs into "More" button. See the demo below utilizing @ViewChildren to do the job:

ContentChild and ContentChildren

A handy way to customize component is to use content. In Angular, similar to native Web Components, you can wrap your component around some DOM elements and project them into component view. This is what built-in tag ng‑content is for. And while in most cases you will just project all content in one place, you can define what content goes where. ng‑content has an optional attribute select. It is a lot like selector for directives or components and supports the same syntax. This means you can hook to tag names, classes, attributes and combine them any way you like. You can always leave single ng‑content without selector. Everything that did not match slots with selectors will go there.

An important thing to keep in mind is this: even though content seems to appear in your component view it is actually part of the parent view and follows its change detection cycle. It means that if content element gets marked for checking due to subscribed event for example, your component view will not be checked. Because technically it is parallel to content and this is not how change detection propagates in Angular. Since your component might be dependent on its content children you need to make sure changes to content will not go unnoticed.

changes: Observable<void> from QueryList is a handy way to keep your component up-to-date with content changes.

You can query content the same way you query view. Angular has @ContentChild and @ContentChildren decorators for this purpose. The syntax isthe same as with their view counterparts.

Below you can find an example of a dropdown menu where items are passed as content to a wrapping component. This allows you to hook into events like clicks or key presses, sparing component this logic. And component can implement navigation logic.

One thing in syntax that differs is @ContentChild also has descendants: boolean to be able to query children nested inside other components (but not from their views):

<!-- @ContentChild('child', { descendants: true }) -->
<my-component>
  <another-component>
    <div #child>...</div>
  </another-component>
</my-component>

This wraps it up for this Angular feature. There’s quite a lot you can do with it, make sure to practice to be able to spot where it can help you design robust, maintainable components!

The magic of ContentChild, ViewChild and Template References was originally published in pineopticone on Medium, where people are continuing the conversation by highlighting and responding to this story.

Web Audio API is a rich multimedia feature modern browsers have. It allows us to process audio signal and build amazing applications from fun games to complete digital audio workstations. But working with complex reusable code structures within its original paradigm is difficult. Let’s take a look at basic echo effect example:

Everything happens within AudioContext. The graph consists of a source node that is linked to AudioDestinationNode. It also has a feedback loop of DelayNode to introduce a delay and GainNode to control how fast echo fades. This loop connects to destination too.

Settings this up consists of 3 steps:

1. Creating nodes
2. Configuring parameters
3. Linking the graph together

With any complex processing block this quickly gets tedious, especially if we want to control the parameters live. This is an imperative approach. We write a set of commands that are executed in order which changes our program state.

This reminds me a lot of drawing with Canvas API. We can manually draw shapes by consecutive commands giving coordinates. There’s another way to draw shapes, even very complex ones, which is SVG — Scalable Vector Graphics. Let’s try to build our own “SVG” for Web Audio API — a declarative XML based way to compose nodes graph, alter parameters and easily reuse code!

Preparation

We will base our solution on native Web Components. As a proof of concept, let’s create a simple volume control:

Here’s how this graph would look like when our components are ready, with HTML5 audio tag as custom component acting as a source:

To be able to link all of those nodes together we are gonna use the Dependency Injection pattern. It’s pretty simple in a nutshell. Parents provide dependencies for children and children can inject a dependency which will be requested from the closest parent who has it.

For our demo we will use custom DOM events. Because they are synchronous, scoped and it would take just a few lines to implement. I saw this pattern on Justin Fagnani talk and it would work well for our case.

Since Web Components extend native HTML elements and there is no multiple inheritance in JavaScript — we will make a mixin:

provide method will take a Map of token keys and provider values. It would listen to a custom event “inject” and if a requested token is present in a given map, it would stop propagation and assign the value from the map to the event.

And inject method will take a token, dispatch a custom event and return the result.

Web Components

Our volume control has 4 components.

1.Topmost component is Context. All web components have a connectedCallback method which is called when they are initialized. We will call provide with a map of AudioContext as token and new AudioContext() instance as value. This would allow all children to inject the same audio context:

2. Source node will extend HTMLAudioElement. In its connectedCallback it would inject context and create a new MediaElementAudioSourceNode instance. It would put it as AudioNode into the map this element provides:

3. Gain is a little more complex because it has a parameter. We will create a private property with GainNode. In connectedCallback we will inject the parent AudioNode and connect it to our GainNode. We will also provide GainNode as AudioNode for all the children:

Web components have a static getter that returns an array of possible attributes you can change. In this case it would be gain. When the gain attribute is changed we parse it as float and update AudioParam.

Don’t forget, it’s a proof of concept so we will ignore param automations for now.

4. Destination component is very simple. We just inject the parent AudioNode and AudioContext and connect the node to the destination:

Now all that’s left to do is register our Web Components:

Result

You can check out this custom control here:

Web Components driven Declarative Web Audio - Proof of concept

Once you start AudioContext you will see an input slider wired to the custom volume control. Native HTML5 audio controls are located below, both are functional.

While this might not look like much, it outlines the concept. With relatively little code we can convert all Web Audio API features to be used as web components. I’m a very visual person. To me this is so much cleaner and so much easier to understand than vanilla Web Audio API. And I know a lot of musicians are like me too. They are used to build processing chains out of physical blocks, connecting them to one another. So this approach makes sense for the target audience.

I’m an Angular enthusiast so while I created this Proof of Concept with plain JavaScript, I have made a total conversion of Web Audio API to declarative Angular directives:

GitHub - ng-web-apis/audio: This is a library for declarative use of Web Audio API with Angular

If you are interested in Angular, check out this article covering the library, and this follow up about Web MIDI API. With these two libraries I’ve made a browser based Guitar Hero-like game to play with real synthesizer. It also has karaoke mode to sing along and see how well you matched the pitch. You are welcome to give it a shot:

Jamigo.app

I hope it was an interesting angle. Declarative approach can make complex tasks much more manageable and easier to wrap your head around.

More content at plainenglish.io

Declarative Web Audio API was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.