DEV Community: Ayelet Dahan

Practicing my RxJS (no subscription nesting)

Ayelet Dahan — Fri, 12 Feb 2021 08:49:28 +0000

I've been listening to the @AngularShow recently, and specifically to their great episodes about RxJS operators. So far two of promised four episodes have been released (one and two) and they have given me motivation to improve some especially complex bit of piping we have in our application.
The goal of this exercise was to reduce a group of subscriptions I had in my code to a single subscribe. It guarantees that all decisions about the code's flow are made in a single place, or at least, as a single flow of decisions.

Background

Content Note: I reduced some of the complexity of the real project for the sake of this post, but the general ideas are kept intact.

The app loads data from two API endpoints. The first endpoint fetches the structure of the app and the second endpoint fetches the specific values to be placed over the structure. The structure, once loaded, never changes, but the values will keep going back and forth over the API. Because the structure is static, it is kept in the StructureService memory while the dynamic values are kept in a store (ngxs, in case you're wondering).

Now here's where it starts getting interesting. There are a couple of pages in the module where the user can "land" and we always need to have the values and the structure available as soon as possible. So to keep thing DRY, we call both loading actions directly in the module's constructor.
I'll just say that I was really exited to find that I can make full use of dependency injection in the module's constructor. You can read more in Ben Nadel's post about this.

A world of Observables

We have two main observables:

structureComplete$ - a void observable that completes after structure data is stored in the service.
valuesState$ - the values from the store.

The `valuesState` from store

const valuesState$: Observable<Values> = this.store.select(ValuesState)

The store loads and fires its first values immediately with the default of null, so we need to skip that and wait for some meaningful content from the endpoint. For that we're going to use the skipWhile filter. I know that when the data loads successfully, the values will never be null, so that's what I check for.

const valuesState$: Observable<Values> = this.store 
  .select(ValuesState)
  .pipe(skipWhile((values) => values !== null));

The `structure` complete

The first page that is shown to the user will probably have the structureComplete$ observable still alive, so we'll concat the structure with the values.

const valuesPendingStructure$ = concat(
  this.structureService.structureComplete$ as Observable<unknown>, // to prevent the need of mapping
  valuesState$
).pipe(skipWhile<Values>((v) => !v)); // skip the 'structureComplete'

I banged my head around this for a while, because I really don't need any data from the structureComplete$ observable. I just want to know it ... completed, and the information is safely stored in the service. All I really care about, once it's done, are the values. I know the structure is in place, but I have to keep watching the values.

The Observable<unknown> calms TypeScript's nerves and lets the valuesPendingStructure$ variable have the type of Observable<Values>. The skipWhile<Values>((v) => !v) enables us to skip the first value emitted, which comes from the structure completing.

Putting it all together

As I mentioned before, There are several pages which look at the structure observable, and while the first page to look at structureComplete$ will likely find it still loading, later pages will already see it complete and cannot subscribe to it. For that purpose I added a small isReady getter to the structure service which defaults to false, but sets to true at the same time the observable completes and the structure is stored. To decide which of the values observables should I use, I added the iif condition observable.

// Choose one of two options
// if structure is ready, get down to business
// if it isn't, wait for loadComplete$ and then hand over the values
const values$ = iif(() => this.structureService.isReady, 
  valuesState$, 
  valuesPendingStructure$)
);

The iif operator can act both as an observable creator and as a pipe operator. In this case, we're using it as an observable creator, based on the value of isReady. If the structure has already loaded, subscribe directly to the values from the store. If we're still waiting for the structure to load, we'll use the observable that's waiting for it before switching to the values.

That's it. We can now subscribe to a single observable and always get the most up-to-date values

$values.pipe(takeUntil(this.destroy$)).subscribe({
  next: values => {
    // ...
  },
  error: error => {
    // Inform the user something went wrong
    // log the error for debugging/improving
  }
});

Two important things to remember:

We have lots of observables here, and we should always make sure to unsubscribe at some point. I really like the destroy$ pattern which completes once when the page destroys and gives us a great reference point to unsubscribe.
All these observables, something is bound to go wrong. Make sure to always have an error handler on your subscription, so you can inform the user that something went wrong.

A small final note

As usual, while writing my posts, I had to break multiple time to continue working on this and other tasks. During some of those breaks I kept changing and improving the code, as well as discovering bugs and fixing them. I'm sure there are better ways to do this. For example, I think I can avoid having the structureComplete observable and use the original HttpClient observable.

If you have any additional thoughts on how this could be made better, I'd appreciate a comment!

Opinion: absolute; When you shouldn't use position: absolute

Ayelet Dahan — Wed, 09 Dec 2020 07:44:48 +0000

In General

I was reviewing code of my colleague the other day, and we got into a discussion about how best to position an elements in a header.

To center the text in one of the elements, my colleague chose to position: absolute that element, setting the header wrapper element as position: relative. It worked, but it looked hacky to me.

I am a firm believer of being declarative and explicit. It makes maintenance easier and I think it is better for accessibility.

The Details

Space was sparse as we were looking at the mobile version. There were no clear guidelines from the designer, so we each had our view of what should happen.

The structure of the header was supposed to be:

[Logo] ........ [Page Title] ........ [email]

The Logo has a fixed size and ratio (say 40x40px) and should be left aligned.
The Page Title changes based on the page being rendered, and should be always centered.
The email was variable in the sense that different users would have different lengths of an email. me@cnn.com would be shorter than yourcousinesworkaddress@theguardian.co.uk. Email should be right aligned.

My colleague chose to make the Page Title element absolute, spanning the whole width of the page. With a long enough title, all sections might overlap, so we'ed have to take care of that. Beside that technical challenge, I think this is not a good use for absolutely positioning elements.

I believe that we should use absolute positioning where that is exactly what is required - an element being positioned in a specific, absolute distance from its parent/root, regardless of any other elements that may exist around it.

Quoting Chris Coyier's article on CSS-Tricks Absolute, Relative, Fixed Positioning: How Do They Differ?:

The trade-off (and most important thing to remember) about absolute positioning is that these elements are removed from the flow of elements on the page. An element with this type of positioning is not affected by other elements and it doesn’t affect other elements. This is a serious thing to consider every time you use absolute positioning. Its overuse or improper use can limit the flexibility of your site.

My suggestion

Use display: grid. The grid lets us define the exact structure for each of the blocks as well as overlap and internal alignment.
Originally I thought we can use display: flex, but the alignment didn't pan out too well. Maybe we didn't dig around enough?

I'd love to hear your thoughts!

Do you agree that position: absolute should be used only where it is explicitly required? Have you seen other abuses of absolute positioning?

Angular HTTP Interceptor

Ayelet Dahan — Mon, 22 Jun 2020 20:53:23 +0000

Why would you want to setup an HTTP Interceptor? Not sure, but I can tell you that I used it to solve a few different problems, out of which I'll discuss in this post:

Adding an authentication header
Handling 401 Unauthorized

Bonus: Unit Tests the interceptor (In the next post).

But first, what's an interceptor?

... transform the outgoing request before passing it to the next interceptor in the chain ... An interceptor may transform the response event stream as well, by applying additional RxJS operators on the stream.

Or, in human speak, If you need to make changes or decisions to any request or response - this is where you want to do it.

Add an interceptor to your project

In your app.module.ts (or what ever you called the root of your project) you should have this code:

import { NgModule } from '@angular/core';
import { HTTP_INTERCEPTORS } from '@angular/common/http';
import { TokenInterceptor } from './auth/token.interceptor';
import { AppComponent } from './app.component';

@NgModule({
    declarations: [AppComponent],
    imports: [ ... ],
    providers: [
        {
            provide: HTTP_INTERCEPTORS,
            useClass: TokenInterceptor,
            multi: true
        }
    ],
    bootstrap: [AppComponent]
})
export class AppModule {}

What's going on here? We're "providing" the app with a tool.

The HTTP_INTERCEPTORS is a symbol - a key - to lock our interceptor into position. It lets the system make sure where we want to provide something.
The TokenInterceptor is our class we're about to implement.
Finally, multi: true means we can provide multiple interceptors, chained, as opposed to overriding each other. In this specific app we only have one interceptor, but if we ever want to add another one, we're ready to go.

The basic interceptor

import { Injectable } from '@angular/core';
import { HttpRequest, HttpHandler, HttpEvent, HttpInterceptor } from '@angular/common/http';
// Note: these are only the initial imports. Add more as needed.

@Injectable()
export class TokenInterceptor implements HttpInterceptor {

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    return next.handle(request);
  }
}

We're not really doing anything here, but just to set the basics. Implementing HttpInterceptor means we need to implement the intercept function which gets a request and a handler for continuing the process. Later we'll see what we can do with it.

Add an authentication header

intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  request = request.clone({
    setHeaders: {
      'my-auth-token': `${this.getSessionToken()}`
    }
  });
  return next.handle(request);
}

You can't simply change the request. The request is a readonly object. But you can clone it, while overriding specific components. In our scenario, we're using the setHeaders property to add a token header to the request.

The function getSessionToken is not provided here and is up to you, as a developer to know how it is stored and how to retrieve it.

Handling backend `401 Unauthorized`

Every page of our application makes several XHR calls to the backend. At some point or other, for various reasons, the user's session may expire. Instead of showing the user a pile of error messages - at first sign of trouble (401) we redirect the user to the login page.

intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  request = request.clone({
    setHeaders: {
      'my-auth-token': `${this.getSessionToken()}`
    }
  });
  return next.handle(request).pipe(
    catchError((response: HttpErrorResponse) => {
      if (response.status === 401) {
        // Do something here
      }
      return throwError(response);
    }
  );
}

We've added a pipe after handling the request. This is our way of handling the response. catchError is an rxjs function which catches if an error is thrown by the observable. We check the response and "Do something" and then throw the response again. We throw the response so the caller of the request, further down the line, knows that something went wrong and can handle it gracefully, regardless of the interceptor's processing.

Now, why "Do something"? The answer is in a hint I gave earlier - each page makes several calls, and all or some may be throwing 401 errors, and we don't want all of them to "hit" the user at the same time. Enter throttleTime.

throttleTime is a sibling of debounce. While debounce waits for an action to stop happening, throttleTime lets the first action go through and then blocks for a given time. Let's setup a subject to "Do something" while "protected" by our throttle.

private throttleLogout = new Subject();
constructor() {
  this.throttleLogout.pipe(throttleTime(5000)).subscribe(url => {
    this.logout();
  });
}

intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  request = request.clone({
    setHeaders: {
      'my-auth-token': `${this.getSessionToken()}`
    }
  });
  return next.handle(request).pipe(
    catchError((response: HttpErrorResponse) => {
      if (response.status === 401) {
        // Call logout, but throttled!
        this.throttleLogout.next();
      }
      return throwError(response);
    }
  );
}

In the class constructor, we've initialized a simple void Subject which is piped through a throttleTime - once the first 401 is intercepted, the user is logged out and they aren't logged out again (due to 401) for another five seconds.

In the next post, I'll show you how we wrote unit tests to verify all this functionality.

Multi-lingual Chicken and Egg

Ayelet Dahan — Mon, 15 Jun 2020 07:06:33 +0000

A colleague uploaded this image to the company Slack

The claim was "Finally, it's sorted".

Being bi-lingual, I wanted to challenge that, as in my language, the word for egg appears lexicographically before chicken. Funnily enough, even the phrase itself exists, but the phrase reverses the order of the words - while in English the phrase is "What comes first, the chicken or the egg", in my language, the nouns are reversed.

What do you do when two parties disagree? Look at everyone else!
I found this website which translated the words for me into all the languages it had available (101).
I chose to include also a translation for "Hen", as "Chicken" is the meat you eat, while "Hen" is the animal which lays eggs. It will translate into a different word in many languages.

This site is also great because it lets you export the translations as a JSON or a CSV file! 😍

There isn't anything too exiting about the implementation. I grouped the words by languages and then for each tuple I sorted the items and counted "which came first".

This was the bottom line:

It is a little tight between the chicken and the egg, with the egg having one more win, but if you account for the egg vs. hen, the egg wins big time!

The world has said it's piece. The egg came first. 🥚

P.S.
You can find the source code here. You are welcome to code review it and improve it.

Cache with care

Ayelet Dahan — Wed, 03 Jun 2020 21:52:25 +0000

A while back, I wrote a small class that caches objects. That, in itself, is possibly quite enough for a post of its own. But today I ran into a problem with my caching which I didn't foresee.

The reason I created this little class was to have a simple way to manage the freshness of the data I get and store from the server. This is a useful in-between solution when WebSocket communication with the backend is not an option.

Let's start with

The code

and break it down:

class CachedObject<T> {
    private freshness: number;
    private expiry: number;
    private object: T;

    /**
     * Object
     * @param expiry Number of milliseconds until expiration. Defaults to 10min
     */
    constructor(expiry: number = 10 * 60 * 1000) {
        this.expiry = expiry;
    }

    /**
     * Returns true if object is still fresh.
     */
    get isFresh(): boolean {
        return !!this.object && this.freshness + this.expiry > Date.now();
    }

    /**
     * Returns true if object is no longer fresh.
     */
    get isStale(): boolean {
        // convenience function
        return !this.isFresh;
    }

    /**
     * Force the instance to be stale
     */
    stale():null {
        return this.object = null;
    }

    /**
     * Gets the source object or null if the object has gone stale
     */
    get source(): T | null {
        if (this.isStale) {
            // cleanup and return null
            return this.stale();
        }

        return this.object;
    }

    /**
     * Sets the source object
     */
    set source(object: T) {
        this.freshness = Date.now();
        this.object = object;
    }
}

If you get the gist of it, feel free to skip on ahead to the next section where I talk about the problem I ran into.

First of all, you may have noticed I'm using generics. It's a very convenient choice because this way I don't really care what object I'm given to keep in the cache.

Next, we have three private properties:

freshness:number - the time the cache was last set.
expiry:number - the number of milliseconds I want this cache to stay alive.
object:T - whatever we may be storing.

The constructor takes an optional expiry value, but defaults to 10 minutes if no value was provided.

Next is the little brain of the cache, a getter function checking if the contents of our cache is still "valid" or "fresh". If the object is not defined we are obviously not fresh. Also if the expiry time is up, we are not fresh. The mirror image of isFresh is isStale, a convenience function for writing more readable code. If I want to perform a task if something.isStale(), it just looks nicer than !something.isFresh().

Next, I have a little function which simply "forces" the cache to become stale.

Finally, a pair of get/set functions to set and grab the source itself. Notice that when seting the source, we also reset the freshness of our cache.

The problem I ran into

It took quite a while from the time I developed this little cache to the time I got the bug reported, but it took the first system user about 10 minutes to come across it (I just gave you a little clue there). When I was testing the system, I played around with what ever feature or bug I was working on at the time, and constantly editing the code and refreshing. So I never got to the 10 minute mark. A real user, on the other hand, may play around with the system for quite some time - especially if they are a new user.

After 10 minutes of using the cached object, it would go stale, but the user of CachedObject had to figure this out for themselves, at expiry time. Internally, I know the time is running out for this object - but I didn't have any way to warn the system that time is about to run out!

So I setup an observable. Let's see what that looks like:

class CachedObject<T> {
    private freshness: number;
    private expiry: number;
    private object: T;

    private percentToStaleSubject = new Subject<number>();
    public percentToStale$ = this.percentToStaleSubject.asObservable();

    ...

We now have an internal Subject which knows how far are we from becoming stale. We also have an external public observable to this Subject so the external user can get these updates.

    /**
     * Force the instance to be stale
     */
    stale():null {
        this.percentToStaleSubject.next(100);
        return this.object = null;
    }

When the object becomes stale, the percentToStale automatically jumps to 100, regardless of its previous value.

    /**
     * Returns true if object is still fresh.
     */
    get isFresh(): boolean {
        return !!this.object && this.timeToExpire < this.expiry;
    }

    private get timeToExpire(): number {
        return Date.now() - this.freshness;
    }

I decided, while I'm at it, to add a little helper getter function timeToExpire to make the isFresh function a little more readable.

    /**
     * Gets the source object or null if the object has gone stale
     */
    get source(): T | null {
        if (this.isStale) {
            // cleanup and return null
            return this.stale();
        }

        this.percentToStaleSubject.next((this.timeToExpire / this.expiry) * 100);
        return this.object;
    }

Finally, I want the getter function to update the "percent to stale" subject.

The user of the cache can now subscribe to get updates when the cache is nearing its stale point. The usage code looks like this:

this.cachedObject.percentToStale$
    .pipe(
        filter(pExpire => pExpire > 80), // Make sure only to refresh if nearing expiry
        throttleTime(5000) // This can fire quite a few times. Wait before firing again
    ).subscribe(() => this.goFetch());

You may be wondering why I didn't use setTimeout or setInterval. It's a viable solution, I won't argue with you. My thinking was that I don't like timers just lying around in my system. I feel a timer should be something under your full control as a developer. On the other hand, the benefit of having the subject update only when the value is accessed makes sure we don't update the contents of the cache if nobody needs it right now.

Maybe I'll come around to changing this some day. Or maybe I'll discover there's some very trivial way to do this with rxjs.

Keep your URL clean

Ayelet Dahan — Thu, 21 May 2020 16:07:04 +0000

In our app we can set the filters of a page through the URL. This is especially helpful when the user wants to share complex filters with peers.

Once the user has navigated into the page, we store the filter settings in session and we don't need the URL parameters any more. More over, if the user changes her filter settings, we update the session, but if she reloads the page with the URL, it would take precedence over the session settings and would give her a bad experience.

The solution is to remove the filters while storing them in the settings. But... We can't just remove all the url params because there may be others that do not belong to the filters. We need to remove each parameter at a time.

Let's get down to code.

ngOnInit() {
  this.route.queryParamMap.subscribe(paramMap => {
    this.filter(paramMap, 'f1');
    this.filter(paramMap, 'f2');

    // ...

  });
}

We subscribe to all the query params when our component initializes. Every time the queryMap changes when we're on this page, our filters will update. Don't forget to unsubscribe onDestroy!

private filter(paramMap:ParamMap, key:string) {
  if (!paramMap.has(key)) {return;}

  const value = paramMap.get(key);

  // Perform filtering here
  // ...

  // Set filter to session here
  // ..

  this.removeParamFromUrl(paramMap, key);
}

I like doing all the negative checks at the entrance to the function and exit if no work is to be done. It saves us some nice levels of indentation, at the cost of a slightly less readable negative-condition.

Once we're done with all the filtering and the session work, we can now safely remove the parameter from our URL.

private removeParamFromUrl(paramMap: ParamMap, key: string) {
  if (!paramMap.has(key)) { return; }

  const queryParams = {};
  paramMap.keys.filter(k => k != key).forEach(k => (queryParams[k] = paramMap.get(k)));
  this.router.navigate([], { queryParams, replaceUrl: true, relativeTo: this.route });
}

The if statement when we enter the function is just to make sure that we're not trying to remove a parameter that doesn't exist. It wouldn't have any visual effect if we didn't have this protection, but it saves us some cycles. Just to be sure, I looked up the source code for ParamMap and behind the scenes it uses a pure object, so ~O(1) to check. I digress.

We create a new query param dictionary and place in it only the keys we want. Finally, we navigate to the new route with one parameter less.

Hold On!! This is terrible!

We loop over the param map ~O(n!).
We are calling the router to navigate again and again.

Let's see if we can make this a little better? We'll work backwards now, starting from removeParamFromUrl:

private removeParamFromUrl(paramMap: ParamMap, keysToRemove: string[]) {
    const queryParams = {};
    const keysToKeep = paramMap.keys.filter(k => !keysToRemove.includes(k));
    keysToKeep.forEach(k => (queryParams[k] = paramMap.get(k)));

    this.router.navigate([], { queryParams, replaceUrl: true, relativeTo: this.route });
}

Now we're getting an array of keys that we want to get rid of, instead of a single key each time. We iterate over the keys of paramMap and keep only those that are not in included.

If we want to finish up quickly here, we can have our subscription call removeParamFromUrl with all our filters:

ngOnInit() {
  this.route.queryParamMap.subscribe(paramMap => {
    this.filter(paramMap, 'f1');
    this.filter(paramMap, 'f2');

    // ...
    this.removeParamFromUrl(paramMap, ['f1', 'f2' ...]);
  });
}

private filter(paramMap:ParamMap, key:string) {
  if (!paramMap.has(key)) {return;}

  const value = paramMap.get(key);

  // Perform filtering here
  // ...

  // Set filter to session here
  // ..

  // We got rid of the local call to removeParamFromUrl
}

And we'd be done.

But let's make it just a little cleaner? Again, at the cost of some readability.

private filter(paramMap:ParamMap, key:string):boolean {
  if (!paramMap.has(key)) {return false;}

  const value = paramMap.get(key);

  // Perform filtering here
  // ...

  // Set filter to session here
  // ..

  // We got rid of the local call to removeParamFromUrl
  // And returning true if the filter was applied.
  // Notice that we returned `false` in the `if` above!
  return true;
}

Now we'll handle the list filters in ngOnInit:

ngOnInit() {
  this.route.queryParamMap.subscribe(paramMap => {
    const filterKeys = ['f1', 'f2' ...];
    const keysToRemove = [];

    // filter and apply keys for removal
    filterKeys.forEach(k => {
      // filter and remove key only if filtered.
      this.filter(paramMap, k) && keysToRemove.push(k);
    });

    this.removeParamFromUrl(paramMap, keysToRemove);
  });
}

Here we iterate over the keys to remove. We make use the boolean condition - if the filter returned true the key gets added to keysToRemove. If the filter returned false, the second part of the condition will not evaluate at all and the key will not be added.

A final note about Readability: The question of readability is often personal and may depend on your own experience and convenience. But most importantly - think of the engineers who will come after you and will have to read and change your code. Will a junior developer be comfortable reading this? Will they notice and understand the condition?

Being a senior developer isn't only about writing the most efficient code. It's also about writing code that others can understand and change easily.

Component open self in Dialog

Ayelet Dahan — Thu, 14 May 2020 21:41:25 +0000

I wanted to build a single component which I can show in two completely different environments inside the same app.

Inside a side-bar on a page (in-page).
In a dialog outside the page (in-dialog).

The component should also have some action buttons attached to it.

An expand button, which should only be available in-page.
A collapse button, which should only be available in-dialog.

Things got pretty complicated in my mind so I decided to start simple - just build the in-page component. Once that's all done and working, I can research further.

<!-- app-description.component.html -->
<div class="wrapper">
    <div class="description">
        {{ description }}
    </div>
    <div class="footer">
        <button mat-icon-button><mat-icon>fullscreen</mat-icon></button>
    </div>
</div>

/* app-description.component.ts */
import { Component, Input, ChangeDetectionStrategy} from '@angular/core';

@Component({
    selector: 'app-description',
    templateUrl: './app-description.component.html',
    changeDetection: ChangeDetectionStrategy.OnPush
})
export class DescriptionComponent {

    @Input() description: string = '';

}

Nothing fancy. Now to the real question. How can I reuse my code and not create the same template twice, which would force me to maintain two templates?

My rule of thumb is that in 99.9% of the cases (that's 999 out of 1000), a question you have has already been asked and probably answered. The harder question is - can you find the aforementioned question and answer?

For this case, I came close. I found this post - Send data to a TemplateRef MatDialog on StackOverflow. And it gave me an idea.

After some tinkering, I arrived at this result:

<!-- app-description.component.html -->
<ng-container *ngTemplateOutlet="wrapper; context: { $implicit: description }"></ng-container>

<ng-tempalte #wrapper let-data>
    <div class="wrapper">
        <div class="description">
            {{ data }}
        </div>
        <div class="footer">
            <button 
                (click)="openDialog()"
                mat-icon-button>
                    <mat-icon>fullscreen</mat-icon>
            </button>
        </div>
    </div>
</ng-template>

OK, let's talk about what's going on here.

ng-container is quite the Swiss army knife. It can take any template and plug it in where you want it. It is very useful when you want to build markup like you build code - keep the main short and descriptive, and have the details in sub sections.
*ngTemplateOutlet structural attribute renders the template in question.
context is a microsyntax of ngTemplateOutlet which lets you define properties for the scope of the template.
$implicit is the template's way of applying a value to property without specifying it directly by name.
let-data defines a local property data in the template's scope. We could have named it anything, but because we're going to use this same template for a dialog, this name specifically comes in very handy, as it's the property with which data is injected into a template.

/* app-description.component.ts */
import { Component, Input, ChangeDetectionStrategy, ViewChild, TemplateRef} from '@angular/core';
import { MatDialog } from '@angular/material/dialog';


@Component({
    selector: 'app-description',
    templateUrl: './app-description.component.html',
    changeDetection: ChangeDetectionStrategy.OnPush
})
export class DescriptionComponent {
    @ViewChild('wrapper') template: TemplateRef<any>;

    @Input() description: string = '';

    constructor(private dialog: MatDialog) {}

    openDialog() {
        this.dialog.open(this.template, { data: this.description });
    }
}

Now, on the code side of things, we're using ViewChild to get a hold of the same template we created for the ng-container and feeding it into the dialog when it opens.

The last part I wanted to add in was to toggle between expand and collapse buttons, depending on the state of the component.

<!-- app-description.component.html -->
<ng-container *ngTemplateOutlet="wrapper; context: { $implicit: description }"></ng-container>

<ng-tempalte #wrapper let-data>
    <div class="wrapper">
        <div class="description">
            {{ data }}
        </div>
        <div class="footer">
            <button
                *ngIf="!isDialogOpen"
                (click)="openDialog()"
                mat-icon-button>
                    <mat-icon>fullscreen</mat-icon>
            </button>
            <button 
                *ngIf="isDialogOpen"
                (click)="openDialog()"
                mat-icon-button>
                    <mat-icon>fullscreen_exit</mat-icon>
            </button>
        </div>
    </div>
</ng-template>

So now we have two buttons, one appears when isDialogOpen is true and the other when false. Here is the code for it:

/* app-description.component.ts */
import { Component, Input, ChangeDetectionStrategy, ViewChild, TemplateRef} from '@angular/core';
import { MatDialog } from '@angular/material/dialog';


@Component({
    selector: 'app-description',
    templateUrl: './app-description.component.html',
    changeDetection: ChangeDetectionStrategy.OnPush
})
export class DescriptionComponent {
    @ViewChild('wrapper') template: TemplateRef<any>;

    @Input() description: string = '';

    // Used to hide the "Open Dialog" button when component is loaded inside the dialog
    public isDialogOpen: boolean = false;

    constructor(private dialog: MatDialog) {}

    openDialog() {
        const dialogRef = this.dialog.open(this.template, { data: this.description });

        dialogRef.afterOpened().subscribe(() => (this.isDialogOpen = true));
        dialogRef.afterClosed().subscribe(() => (this.isDialogOpen = false));
    }
}

Honestly, I'm not completely sure how come this works, as I wouldn't expect the dialog instance to have the same component scope as the in-page component.

Even more so, I expected that the in-page component would react to the change of the boolean and hide the button as well (which I didn't mind too much) - but it didn't! It stayed where it was, while the dialog component had the collapse button.

I hope to research the reasons for this in the future (or, discover the hard way that something isn't working as expected). In the meantime, I seem to have satisfied my requirements.

MaterialTab styled as a textbox

Ayelet Dahan — Wed, 13 May 2020 21:55:36 +0000

We have several material-tabs on one of the pages in our app. For the user's convenience, we wanted one of the tabs to look a bit input taking up the whole space.

Just placing a form-field with a textarea didn't provide too much magic.

First, the real textbox inside had to take up the whole tab space, or as much as possible of it. Thankfully, the tabs height it fixed and defined in rems, so just playing around with height of the text area brought us near enough.

.mat-form.field textarea {
    height: 11rem;
}

To give the text area all the space it needs, we wrapped the form-field with a parent and set a class summary with settings to get it to cover all the space available:

.summary {
    display:flex;
    flex-direction: column;
    height: 100%;
}

Next, we wanted to have the background of the whole tab set to a color, so it stands out as a different component/entity. A simple background-color gives us a nice shade.

.summary {
    ...
    background-color: rgba(134, 144, 149, 0.25);
}

Finally, we had to get rid of that pesky bottom border (underline) so it's seamless to the user. I say pesky, but really, it was my fault. I was sure there's a border setting somewhere. Looking through the source code for Form Field I couldn't find any styling applied to a border. Inspecting the Angular Material's Form Field Overview page, I grabbed the line itself and discovered it is an independent elements.

mat-form-field-underline takes care of the bottom line at "rest", while mat-form-field-ripple is used when hovering over the component or when it is focused (.mat-form-field.mat-focused). The underline is set using background-color so I eliminated it using transparent.

.mat-form-field.no-underline {
    .mat-form-field-underline,
    .mat-form-field-ripple {
        background-color: transparent;
    }
}

Notes

A note about the source code - be sure to check the version you are using in your own project and choose the right branch on the library. Changes may be subtle but important.

Another note about material component styling - There are various scss files and the rules you are looking for may be in any of them, but the general guideline I've picked up so far is *-theme.scss files hold the colors and typography, while the *component*.scss holds the structural styling._

A final note about overriding code from inside a library (that isn't publicly exposed through the docs - it's risky. The source code can change in the next version and break your app.

P.S.

Some of you keen eyed readers (who've reached this far) may have noticed that the resize element is still available. I'm telling myself that's OK because it gives the user a small hint that this is an input component and not just a strangely colored tab. To remove it use resize: none. It is supported in all the latest browsers.