DEV Community: Jennifer Wadella

5 things I don't want to see on your resume as a hiring manager

Jennifer Wadella — Tue, 09 Nov 2021 23:01:33 +0000

As a Director of Angular Development at a consulting company, I review a lot of resumes. And because a lot of my clients are desperately hiring and need my expertise, I review a lot MORE resumes. I see a lot of things that I consider "red flags" on resumes of engineers with "6+ years of experience" that make me think they really don't know what they're doing. So here are 5 things that will make me chuck a resume into the reject pile almost immediately.

1. "Experienced in using Text editors like Espresso, eclipse, Text Wrangler, Sublime Text, Atom, NetBeans, XAMPP, Notepad and Notepad++."

Hun, you're a software dev. I really hope you know how to use an editor. I also hope you're very opinionated on the editor you prefer; it tells me a lot about your experience and ability to produce code if you're picky about your tooling. Unless you prefer Dreamweaver, in which case I might only trust you to update my myspace page.

2. Acronym Abuse

There are reasonable, well-used acronyms that are in a developers vocabulary, like CSS, and then there are weird things that NO one says, like "Responsive Web Design (RWD)". If you have a bunch of acronyms that aren't ever used or are made up, I'm going to bin a resume for that.

3. "Implemented a Service to Make API calls" aka "I implemented the thing the way it was supposed to be implemented"

In Angularland, we love our Service classes. And I'm going to guess with no actual statistical data that making API calls is the most predominant use-case for people writing Services. Don't tell me in a bullet point "I used x thing the way it was intended to be used", because that's the bare minimum. Also, if you're going to insist on a bullet point like that, make sure it's technically accurate.

"Implemented HTTP requests using RxJS Observable library to handle multiple values over time."

Phrases like this make me 🧐

Tell me instead how you refactored a Service to handle a new feature request or improved performance.

And a shoutout to one of my favorite resume rejection "I did the thing" bullet points ...

"Used Es6 arrow functions to map the Json data"

4. Buzzword lumping - "Created Typescript reusable components and services to consume REST API's using Component-based architecture provided by Angular 2."

There are so many things wrong with this bullet point I don't even want to finish reading this resume, let alone interview this candidate. TypeScript doesn't have components, components are typically a construct of frameworks like Angular or React. If you're going to apply for a role regarding a Framework know whats a feature of the framework, and what's a feature of a language, and make sure I know you know from your resume. Also, I reaaaaally hope you're always thinking about whether a component should be reusable or not, it's a pretty core part of what front-end engineers do now, so this isn't the flash of brilliance you may think it is.

5. Bad Grammar

I'm already assuming half the resumes that hit my inbox are copy-paste grabs written by catfishers, so don't end up in the reject pile by making grammar mistakes. If you're going to make a bulleted list of what you did on a project, make sure the tenses match.

Bad:

Worked with NPM commands and using Package.json for managing dependencies and dev-dependencies of Node.js applications.
Extensively involved in upgrading the existing system from Angular 7 to Angular 8.
Responsible to work with 3-tiers UI, Business Layer and Data Access Layer

Good:

Worked with NPM commands and using Package.json for managing dependencies and dev-dependencies of Node.js applications.
Was extensively involved in upgrading the existing system from Angular 7 to Angular 8.
Was responsible for working with 3-tiers UI, Business Layer and Data Access Layer

I'd like to make a note that as a manager, I'm currently heavily leaning towards preferring to hire excited junior devs looking for their first shot, vs. a "mid-level" engineer that has likely bounced from company to company without ever having written actually quality code, or invested in growing their own skillsets. Tell me about your projects, how they provided value to an end user, and how you used tech to help deliver that value. Or if you're playing buzzword bingo to get past a first line of recruiters, slip me an easter egg in there to let me know like "proficient in vanillaJS" or "implemented comcastifyjs". ;)

Using Starship to Track Current NPM Registry

Jennifer Wadella — Sat, 26 Jun 2021 16:34:09 +0000

I will be forever grateful to Jason Lengstorf for introducing me to Starship! It's a super fast, highly-customizable shell that comes with some great features out of the box. The default will show you your current directory, branch if you're in a repo, current package version, and current Node version. My setup looks like this:

As a consultant, and even more so as a DIRECTOR of consultants, I spend my days hopping between client code bases, node versions, internal NPM registries, and my own personal content creation. As someone who never has enough hours in a day, I'm always looking for ways to improve my processes and keep myself from trolling myself unintentionally.

The number one thing that gets me every time is not realizing when I'm on an internal client NPM registry and try to do an npm install.😬 I use npmrc to create registry profiles and quickly switch between them, but with my chaotic days I don't usually remember which profile I have set!

Thankfully, you can create custom modules in Starship to customize your command prompt needs! I created a custom module to always show me which registry I'm currently using.

// ~/.config/starship.toml

[custom.npmrc]
disabled = false
command = """
NPMREGISTRY=$(command npm config get registry)
if [[ "$NPMREGISTRY" =~ "clientregistrynamespace" ]]; then
    NPMREGISTRY_SYMBOL=""
else
    NPMREGISTRY_SYMBOL=" "
fi
echo "registry $NPMREGISTRY_SYMBOL"
"""
when = "true"
style = "bold blue"

If you're not a bash scripting pro (I certainly am NOT), I'll walk you through what's going on here. This is code in my custom config toml file for Starship. Most of this configuration is based on how Starship returns information about different Modules, and bash scripting is done in the "command" option. You can see more about how to configure current Modules or create your own commands on their website.

I'm running the command npm config get registry and converting the output of the command to a string variable for comparison with the $. The command spits out https://registry.npmjs.org/ or whatever registry you're currently on. A custom registry url might look something like https://npm.clientregistrynamespace.com. I'm checking to see if my clients registry name is in the command output - if it is, I'm returning a symbol representing that client, and if it isn't I'm returning an NPM icon from Nerd Fonts.

Now I can always see what registry I'm on!

You can see other custom commands built by community members here: https://github.com/starship/starship/discussions/1252

Non-null Assertion Operator in Angular

Jennifer Wadella — Wed, 31 Mar 2021 21:45:39 +0000

If your team has been following best practices guidelines put out by the Angular team (& adopted by the community as a whole), you may have made the decision to implement Strict Mode for TypeScript in your codebase.



//tsconfig.json
{
  "compileOnSave": false,
  "compilerOptions": {
    ...
    "strict": true, //woooo strict mode
  },
  "angularCompilerOptions": {
    "enableIvy": true,
    "fullTemplateTypeCheck": true,
    "strictInjectionParameters": true
  }
}

You may have encountered a new error in Angular Property 'myClassMember' has no initializer and is not definitely assigned in the constructor.ts

If you weren't using a lot of (or any) of the flags for configuring stricter TypeScript parsing previously, you may see new "errors" like this as you code.

*Note, these are not "new errors caused by TypeScript" but instead "already existing potential errors in your codebase that the stricter TypeScript flags are now catching" - this is an IMPORTANT mental shift for your team to make. TypeScript is here to help us write better code and catch potential errors, not to make our lives as developers harder.

The "has no initializer and is not definitely assigned" error is due to the strictPropertyInitialization flag being set to true as a part of Strict mode, and is checking to ensure any class property declared is not null. In Angular, we are typically declaring properties on our classes when we encounter this error. The TypeScript compiler is reviewing our class members, and if it does not see our class member being given a value when it's declared or if our member is not given a value in the constructor function, it thinks that member is null, and rightfully so!

This is a common occurrence in Angular where we often initialize our members in the component's lifecycle hooks - which TypeScript is unaware of. TypeScript doesn't know that our ngOnInit function will run after the component is initialized.



import { Component, OnInit } from "@angular/core";

@Component({
  selector: "my-app",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"]
})
export class AppComponent implements OnInit {
  // defined when initialized
  public myInitiallyDefinedMember = "beep";

  // defined in the constructor method
  public myConstructorDefinedMember: string;

  // defined in the ngOnInit Lifecycle hook
  // will throw TypeScript error
  public myLifecycleDefinedMember: string;

  constructor() {
    this.myConstructorDefinedMember = "bop";
  }

  ngOnInit() {
    this.myLifecycleDefinedMember = "boop";
  }
}

Will throw the error:



Error in src/app/app.component.ts (16:10)
Property 'myLifecycleDefinedMember' has no initializer and is not definitely assigned in the constructor.

To let TypeScript know we're going to initialize myLifecycleDefinedMember in our component, we can use the Non-null Assertion Operator, or a !.



import { Component, OnInit } from "@angular/core";

@Component({
  selector: "my-app",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"]
})
export class AppComponent implements OnInit {
  ...
  // defined in the ngOnInit Lifecycle hook, 
  // now using the Non-null Assertion Operator
  public myLifecycleDefinedMember!: string;

  ngOnInit() {
    this.myLifecycleDefinedMember = "boop";
  }
}

The above example is an appropriate use-case, this does NOT mean:

To see how strict mode affects typings & assertions, open this StackBlitz example, and in the tsconfig.json file remove line 14 "strict": true.

Key Take Away

You should ONLY use the Non-null Assertion Operator when you know you will be setting a value for a component member. If there are instances where you aren't sure if a member has a value, it is better practice to use the optional operator.

Useful Tips for Debugging with Scully

Jennifer Wadella — Wed, 01 Jul 2020 16:04:51 +0000

So you're excited to pre-render your application pages and want to use Scully to do it. Yay! But you're getting frustrated because you're not getting helpful errors and the documentation isn't as robust as you'd like - we've all been there. Check out a few of my tips for debugging projects implementing Scully.

Basic Scully Debugging Tips

1. Join the Scully Gitter channel, and search for your issue to see if it's come up in the chat previously.

2. Watch the Scully repo to get updates on issues and their resolutions.

3. Save up your Scully questions and join the Scully Office hours, every Tuesday at 12:00PM Mountain time.

Scully is still a very new tool for the Angular community, and the brilliant creators behind it have full time jobs beyond supporting this project. The creators are very gracious with their time, and I've spent more than a few hours bothering Sander with issues I've run into, so I wanted to share some SUPER pro tips I learned from him.

PRO Scully Debugging Tips

1. Clone the Scully repo

I find it way easier to solve my issues or figure out what a config option should look like by having the repo open in VS Code and being able to quickly click through interfaces or do global searches.

2. Do incremental renders in Scully to test just the routes you're working with.

When you're working with dynamic routes, you may be creating and rendering hundreds of pages, which takes time. If you're writing a custom plugin and want to focus on just the routes using that plugin OR there's just one part of your Angular app that you need pages rendered for, there's a flag for that!

You can only render the routes you care about by using the baseFilter flag



npm run scully -- --baseFilter=/my-route

3. Understand HOW Scully is rendering the pages.

Under the hood, Scully boots up Puppeteer which serves the app you've compiled to the dist/your-project-name directory, and crawls those pages to copy the markup.

4. See what Scully sees when rendering your pages.

You can use the showBrowser flag to have Puppeteer launch the Chromium browser so you can see what's going on. This can be helpful if you think a JS error is blocking the page from loading, an http request might be failing, or ensuring your proxy file is working correctly (if you're using one).



npm run scully -- --showBrowser

5. Debug any potential issues with your Angular router code

When implementing Scully for a client recently, Scully would build the index.html page for the base path of the application, and then stop, no errors, no warnings. Scully uses the library GuessParser to determine the routes written in your Angular application.

You can use the showGuessError flag to show any errors that GuessParse throws.

When I ran



npm run scully -- --showGuessError

I was able to see the error about myGroupOfRoutes from GuessParser and tracked down the source - the original application routing code was trying to use the spread operator to create route arrays (ps, this isn't supported and probably won't be any time soon so don't do it!)

GuessParser cannot interpret the routes in this code:



const myGroupOfRoutes: Routes = [
    {
        path: 'home',
        component: HomeComponent,
    },
    {
        path: 'about',
        component: AboutComponent,
    }
];

const myOtherGroupOfRoutes: Routes = [
    {
        path: 'items',
        component: ItemsComponent,
    },
    {
        path: 'items/:id',
        component: ItemComponent,
    }
];

const routes: Routes = [
    {
        path: '',
        children: [
            ...myGroupOfRoutes,
            ...myOtherGroupOfRoutes,
            {
                path: '**',
                redirectTo: 'home',
                pathMatch: 'full'
            },
        ]
    },
];
export const routing: ModuleWithProviders = RouterModule.forRoot(routes);

I hope this helps you get Scully implemented in your project more quickly! Do you need help with Scully, pre-rendering Angular pages, or improving Angular application performance in general? Leave a note in the comments or shoot me an email!

Why You Should Be Using TransferState (& Scully) to Cache Your API Calls in Angular

Jennifer Wadella — Fri, 22 May 2020 17:14:06 +0000

Caching API calls that return largely static data and be a great way to improve application performance AND save $$$ by limiting server requests.

For example, an e-commerce site with products might benefit greatly from caching API calls to fetch lists of those products and re-deploying when new items are added. Caching an API call means making the HTTP request when we statically generate our application pages, and storing the results of that request locally, like in a json file, to be served from our CDN. This prevents the user from having to make the HTTP request to where ever the server it lives on is and wait for the response every time they view a page of our app!

There are added security benefits to this approach as well - we're not exposing our API in the browser at all!

TransferState in Angular

For caching data, Angular provides a TransferState API as a way to cache responses from HTTP requests and put them in a statically generated page.



// my-service.service.ts

import { TransferState, makeStateKey } from '@angular/platform-browser';

  constructor(private http: HttpClient, private ngState: TransferState) { }

  getVillagers(): Observable<Villager[]> {
    const villagersKey = makeStateKey('villagers');
    const cachedResponse = this.ngState.get(villagersKey, null);

    if (!cachedResponse) {
      return this.http.get<Villager[]>('http://acnhapi.com/villagers').pipe(
        tap((res) => this.ngState.set(villagersKey, res))
      )
    }

    return of(cachedResponse);
  }

There's quite a bit of setup work that goes into using it and configuring how to serve the application properly. (example here if you're curious)

Scully-flavored TransferState

I'm clearly a huge fan of Scully as a JAMstack tool, and their approach to caching is chefs kiss.

Scully has abstracted some logic around using TransferState to make it super simple for developers to cache API calls with their useScullyTransferState method.

The useScullyTransferState accepts 2 params, the key you want to store your data under, and an Observable of the original state of what you're working with. In the following example, our original state will be the GET request we're making with HTTPClient.

In my Animal Crossing Field guide application, I have a service file where I have all of my HTTP requests.

Here is my getVillagers request that returns a list of all villagers in Animal Crossing New Horizons, and YIKES there's 391! This large amount of data I'm requesting is very static and is the perfect use-case for caching those requests + limiting calls to the free 3rd party API I'm using.



// my-service.service.ts
  getVillagers(): Observable<Villager[]> {
    return this.http.get<Villager[]>('http://acnhapi.com/villagers')
  }

Let's use useScullyTransferState to cache the results of this call. First, import TransferStateService from Scully and inject it into our service.



// my-service.service.ts
import { TransferStateService } from '@scullyio/ng-lib';
...

constructor(
   private http: HttpClient, 
   private transferState: TransferStateService
) { }

  getVillagers(): Observable<Villager[]> {
    this.transferState.useScullyTransferState(
      'villagers',
      this.http.get<Villager[]>('http://acnhapi.com/villagers')
    )
  }

Now, rerun ng build, followed by npm run scully. You may notice something happening in your terminal output. Every page you are statically generating with Scully that has an HTTP request using the TransferStateService is getting a data.json file created for it.

Scully's doing a few really cool things for us.

If we're just in development mode, (vs. serving our generated static files), Scully will treat the API call as normal, the HTTP request will execute every time.
The magic happens when we serve our statically generated app files. When we run 'npm run scully' to generate our files, Scully will make the HTTP request for us then store the results in a data.json. This data.json file lives next to the index.html file in the directory of the page we generated, to be served from the CDN. Again, this prevents the user from having to make the HTTP request to where ever the server it lives on is and wait for the response!

To really be clear, any page statically generated by Scully that makes an HTTP request you've returned with the useScullyTransferState will cache the response of that request by storing it in a data.json file that is served on your static page. 🎉 🎉 🎉

Caveats

Before you go CACHE ALL THE THINGSSSSS, do consider how users are interacting with your application. If there's heavy modification of the data, like a to-do list, implementing API caching may not give you much in terms of performance boost or improved user experience.

Be aware that if you're using this approach, that same data.json file will be served until you generate a new build. If your API changes, new items are added, etc, those won't be reflected in the statically served data.json file until you run a new build. I call this out because if you're new to the JAMstack approach and don't have automated builds for every time your content (including data delivered by your API) changes, users may not be getting the latest data.

Understanding Multicasting Observables in Angular

Jennifer Wadella — Thu, 21 May 2020 19:45:20 +0000

Many times in Angular application development we'll have an Observable, and want to use the values from that Observable to do different things in the UI.

Let's imagine we're building this interface that shows information about a fish, and we want to show users a schedule of when that fish is available based on the hemisphere of the world selected.

In our component we'll get the response of an HTTP request to the animal crossing API. We're using HTTPClient which returns an Observable. We want to display data from that HTTP request in our UI so a user can see information about the fish, but we also want to display a custom built schedule based on that data and input from something else.

The API returns an object that looks something like this:

{
   "id":10,
   "fileName":"killifish",
   "name":{
      "name-en":"killifish",
      ...
   },
   "availability":{
      "month-northern":"4-8",
      "month-southern":"10-2",
      "time":"",
      "isAllDay":true,
      "isAllYear":false,
      "location":"Pond",
      "rarity":"Common"
   },
   "shadow":"Smallest (1)",
   "price":300,
   "priceCj":450,
   "catchPhrase":"I caught a killifish! The streams are safe again.",
   "museumPhrase":"Ah, the magnificent killifish! Did you know there are over 1,000 different species? My own favorite killifish species are the mangrove, which can live on land for weeks, breathing air! And the mummichog, the first fish ever brought to space. I wonder if the killifish you've brought me is related to either those intrepid explorers?",
}

We want to get the availability based on the hemisphere(northern or southern) the user cares about, and display the months during which that fish is available, by creating an array like this:

[
   {
      "month":"January",
      "available":false
   },
   {
      "month":"February",
      "available":true
   },
   ...
]

We might consider doing something like this (note we are using the Async pipe in our component template to subscribe to fish$):

// fish.component.ts 

  public fish$: Observable<Fish &{uiSchedule: Schedule}> ;
  public selectedHemi = new BehaviorSubject<'northern' | 'southern'>('northern');
  public displayedSchedule$: Observable<Month[]>;

  constructor(private route: ActivatedRoute, private acnhService: AcnhService) { }

ngOnInit(): void {
    this.fish$ = this.route.paramMap.pipe(
      switchMap((params: ParamMap) => {
        return this.acnhService.getFish(params.get('id')).pipe(map((res: Fish) => {
          return {
            ...res,
            uiSchedule: {
              // mapping function to generate array of months with key of 
              // whether month is available or not
              northern: buildSchedule(res.availability, 'northern'),
              southern: buildSchedule(res.availability, 'southern')
            }
          }
        }));
      }),
    )

    this.displayedSchedule$ = this.selectedHemi.pipe(
      withLatestFrom(this.fish$),
      map(([selectedHemi, fish]) => {
        return fish.uiSchedule[selectedHemi];
      })
    )
  }

// fish.component.html 
<mat-card *ngIf="fish$ | async as fish" color="secondary">
  <mat-card-header>
    <mat-card-title>{{fish.name['name-en']}}</mat-card-title>
    <mat-card-subtitle>{{fish.price | currency }}</mat-card-subtitle>
  </mat-card-header>
  <mat-card-content class="row">
    <div>
      <img src="{{fish.imageUrl}}" alt="{{fish.name['name-en']}}">
      <blockquote class="museum-phrase">"{{fish.museumPhrase}}"</blockquote>
    </div>
    <div>
      <mat-button-toggle-group name="hemisphere" [value]="selectedHemi | async" aria-label="Hemisphere" color="primary" (change)="selectedHemi.next($event.value)">
        <mat-button-toggle value="northern">Northern Hemisphere</mat-button-toggle>
        <mat-button-toggle value="southern">Southern Hemisphere</mat-button-toggle>
      </mat-button-toggle-group>
      <div class="table display-availability">
        <div class="month" *ngFor="let month of displayedSchedule$ | async"  [ngClass]="{'available':month.available}">
          {{month.month}}
        </div>
      </div>
      <div *ngIf="fish.availability.isAllDay;else limitedHours">
        <p>The {{fish.name['name-en']}} is available at all times</p>
      </div>
      <ng-template #limitedHours>
        <p>The {{fish.name['name-en']}} is available from {{fish.availability.time}}</p>
      </ng-template>
    </div>
  </mat-card-content>
</mat-card>

This will give us a displayedSchedule$ Observable with an array that displays either the northern or southern hemisphere schedule when the value of selectedHemi changes. Again, assume that we're using the Async pipe in our template to subscribe to this Observable because we want the tear down functionality of our Angular component to handle unsubscribing for us.

But by doing this we're creating an additional subscription to fish$ when we subscribe to displayedSchedules, which means our Observable is being executed twice, quite unnecessarily. Not to mention rude, this awesome developer built a great free API indexing Animal Crossing stuff, and we're thoughtlessly hitting it twice? Ruuuuuude. (ps. how many of ya'll have been doing something like this without even realizing?)

How can we avoid this?

Instead of an Observable, we can use a Subject instead. Subjects can have multiple subscribers and only execute their context once. To convert an Observable to a Subject we can use the multicast operator.

The multicast operator is a bit of a bear to understand - it takes a selector as a parameter and according to the docs returns

"An Observable that emits the results of invoking the selector on the
items emitted by a ConnectableObservable that shares a single
subscription to the underlying stream."

A more palatable summary from the docs is

"A multicasted Observable uses a Subject under the hood to make multiple Observers see the same Observable execution. Multicast returns an Observable that looks like a normal Observable, but works like a Subject when it comes to subscribing. multicast returns a ConnectableObservable, which is simply an Observable with the connect() method.

The connect() method is important to determine exactly when the shared Observable execution will start. Because connect() does source.subscribe(subject) under the hood, connect() returns a Subscription, which you can unsubscribe from in order to cancel the shared Observable execution.

So let's pipe the multicast operator to source Observable fish$ with a new ReplaySubject (because we want late subscribers to get the value).

On the Subject of Subjects ...

subject - a special type of Observable that allows values to be multicasted to many Observers

behaviorSubject - a subject that can 'store' a current value that new subscribers will receive

replaySubject - a subject than can send old values to new subscribers

 this.fish$ = this.route.paramMap.pipe(
      switchMap((params: ParamMap) => {
        return this.acnhService.getFish(params.get('id')).pipe(map((res: Fish) => {
          return {
            ...res,
            uiSchedule: {
              northern: buildSchedule(res.availability, 'northern'),
              southern: buildSchedule(res.availability, 'southern')
            }
          }
        }));
      }),
      multicast(new ReplaySubject(1))
    )

... now we have nothing displaying in our UI? Why? We still have the async pipe subscribing to fish$, but fish$ is now a ConnectableObservable, and we must call the connect method on it to trigger our source observables execution.

// RxJS source code

function Multicast() {
   ...
   return <ConnectableObservable<R>> connectable;
}

export class ConnectableObservable<T> extends Observable<T>{
   ...  
   connect(): Subscription {
    let connection = this._connection;
    if (!connection) {
      this._isComplete = false;
      connection = this._connection = new Subscription();
      connection.add(this.source
        .subscribe(new ConnectableSubscriber(this.getSubject(), this)));
      if (connection.closed) {
        this._connection = null;
        connection = Subscription.EMPTY;
      }
    }
    return connection;
  }

  refCount(): Observable<T> {
    return higherOrderRefCount()(this) as Observable<T>;
  }
  ...
}

this.fish$.connect()

However, this means we must also remember to unsubscribe from that subscription created by the connect method, so doesn't that defeat the purpose of using the async pipe? Yep. Boo. BUT, fear not, gentle reader, we can use the refCount operator, instead of having to manage the connect method ourselves.

refCount makes the multicasted Observable automatically start executing when the first subscriber arrives, and stop executing when the last subscriber leaves.

RefCount returns an Observable that keeps track of how many subscribers it has, it will start executing when subscribers is more than 0, and stops when subscribers are 0 again. This means when we use our async pipe on fish$, the count will become 1, when we use our async pipe on displayedSchedule$ the count will become 2 and when our component is destroyed and the async pipes unsubscribe, the count will go back to 0.

Our final code looks something like this

    this.fish$ = this.route.paramMap.pipe(
      switchMap((params: ParamMap) => {
        return this.acnhService.getFish(params.get('id')).pipe(map((res: Fish) => {
          return {
            ...res,
            uiSchedule: {
              northern: buildSchedule(res.availability, 'northern'),
              southern: buildSchedule(res.availability, 'southern')
            }
          }
        }));
      }),
      multicast(new ReplaySubject(1)),
      refCount()
    )

In summary, when we have an Observable we'd like to use a source for various purposes without executing its context every time, we can use the multicast operator to take a Subject and use it to share the source execution of our source Observable. The multicast operator returns a ConnectableObservable type, on which we CAN use the connect method to create the subscription to our source Observable(the HTTP request to get a fish). A more manageable approach is to use the refCount operator which will count subscriptions and call the connect method to subscribe to the source Observable once the first subscription is created and run tear down logic when the subscription count returns to 0 (AKA all the subscriptions have been unsubscribed).

Rendering Static Pages from Dynamic Routes in Angular with Scully

Jennifer Wadella — Wed, 13 May 2020 14:27:31 +0000

JAMStack 101

As JavaScript applications grow in complexity and offer users robust features, performance becomes an increasing growing concern. JAMstack is an approach to building websites with performance in mind, regardless of the JS framework under the hood. The JAM in JAMstack stands for JavaScript, APIs, and Markup. Conceptually, this means the applications' functionality is handled by JavaScript, server side interactions utilize reusable APIs and the application pages are served as static HTML files, versus content that is injected into the page dynamically by JavaScript as is usual with single page applications.

What is Scully?

Scully was created with the intent of being the piece of the JAMstack puzzle Angular developers have been craving. Scully makes it easy to statically generate pages to be served for modern (v8 or v9) Angular applications.

Server Side Rendering

In order to serve content quickly, static application pages must be generated, served to the browser, and then be bootstrapped by the client. This allows applications to be painted in the browser faster, because we're not waiting on all of our JavaScript to load and then execute, with interactivity not far behind. When this happens on the server, this approach of pre-rendering and serving HTML pages is called server side rendering. Scully takes care of the generating static pages for us.

Getting Started with Scully

Let's take a look at implementing generating static pages with Scully on this example Restaurant Ordering application, Place My Order. This is a demo application where a user can search for restaurants based on city and state, choose a restaurant, and place an order from that restaurant. You can view the demo code on github here: https://github.com/tehfedaykin/pmo-starter

Add Scully to Your Project

To get started with Scully run in the root directory of your Angular application:

ng add @scullyio/init

This will install Scully, import the ScullyLibModule to your root app module, and generate the Scully config file (scully.{{yourApp}}.config.js) in your root directory.

Scully starts with the routing module of your Angular application to determine the pages to pre-render, then offers ways to specify other routes to render in the config file. This means if you don't have a routing module, or if you have no routes written, Scully will not render anything.

In the example Place My Order app, the router contains the following routes:

const routes: Routes = [
  {
    path: '',
    component: HomeComponent,
  },
  {
    path: 'restaurants',
    component: RestaurantComponent,
  },
  {
    path: 'restaurants/:slug',
    component: DetailComponent,
  },
  {
    path: 'restaurants/:slug/:order',
    component: OrderComponent,
  },
  {
    path: 'order-history',
    component: HistoryComponent,
  }
];

Prepare Application Code for Scully

To start using Scully, you must first run:

ng build

This will build your Angular application files and put them in the dist directory, unless you have a custom build directory output. Be aware that Scully will look for the compiled app files in the dist directory to do its magic.

Generate Pre-rendered Pages

Once you've built your latest code to the dist directory, run:

npm run scully

This will render the static pages of your app based on your app router and the Scully config file.

Let's take a look at the output and files generated:

No configuration for route "/restaurants/:slug" found. Skipping
No configuration for route "/restaurants/:slug/:order" found. Skipping
Route list created in files:
  ".../place-my-order/src/assets/scully-routes.json",
  ".../place-my-order/dist/static/assets/scully-routes.json",
  ".../place-my-order/dist/place-my-order/assets/scully-routes.json"

Route "" rendered into file: ".../place-my-order/dist/static/index.html"
Route "/restaurants" rendered into file: ".../place-my-order/dist/static/restaurants/index.html"
Route "/order-history" rendered into file: ".../place-my-order/dist/static/order-history/index.html"

Inside the scully-routes.json file we see a list of application routes:

[{"route":"/"},{"route":"/restaurants"},{"route":"/order-history"}]

Notice that the restaurants:slug routes aren't included, and we received a message telling us no configuration for these routes was found. Because these routes are dynamic, we need to give Scully a little help with how to render a page like restaurants/jennifers-tasty-brunch-cafe.

If our application had SEO goals of making our restaurant pages searchable so potential customers could find their new favorite brunch spot, we'd absolutely want to make sure we were statically generating them for search engines including meta information used by sites like Twitter, Facebook, and Linked In.

One way we could take this is my manually listing all the possible routes in the Scully config file.

exports.config = {
  projectRoot: "./src",
  projectName: "place-my-order",
  outDir: './dist/static',
  extraRoutes: [
    '/restaurants/jennifers-tasty-brunch-cafe',
    '/restaurants/Q39',
    '/restaurants/novel',
    '/restaurants/local-pig',
    '/restaurants/shio-ramen'
    ...

But this would get tedious in a hurry, and what if restaurant owners were allowed to submit their own restaurant to be included in our app? We wouldn't want to have to update our config file every time. Fortunately Scully provides great ways to handle custom situations.

Scully Plugins

The Scully authors created a plugin system that allows us to have more control over how Scully renders our applications, and even provided a few built in for us. <3

Using plugins will allow us to create dynamic routes and render those dynamic static pages instead of waiting for the page to load when the user navigates.

The built-in JSON plugin will help us do exactly this. To work the JSON plugin requires a route and a configuration obj with an API url and key to be used for the route, and will return a list of generated routes for the data returned by the url. This means we can use our API to create the list of routes.

In the Scully config file there is a routes prop that accepts the following routeConfig interface(*** I abstracted this a bit from the Scully source code so we can see what we need for using the JSON plugin):

interface RouteConfig {
  '[route: string]': {
    type: 'json';
    postRenderers?: string[];
    [paramName: string]: {
      url: string;
      property: string;
      headers?: HeadersObject;
      resultsHandler?: (raw: any) => any[];
    };
  };
}

To dynamically create our restaurant routes, we need to pass the route with the dynamic param, our API url, and the key we want from our data. The JSON plugin will map over the data response from the API url we pass it and return the key of each object, in this case 'slug'.

exports.config = {
  projectRoot: "./src",
  projectName: "place-my-order",
  outDir: './dist/static',
  routes: {
    '/restaurants/:slug': {
      type: 'json',
      slug: {
        url: 'http://www.place-my-order.com/api/restaurants',
        property: 'slug',
      },
    },
  },
};

However, my endpoint response looks like this, with my array of restaurant data nested inside a 'data' key:

{
  data: [
      ...restaurants
  ]
}

Scully provides an optional resultsHandler method we can use to map the response of our API to an array to be iterated over:

exports.config = {
  projectRoot: "./src",
  projectName: "place-my-order",
  outDir: './dist/static',
  routes: {
    '/restaurants/:slug': {
      type: 'json',
      slug: {
        url: 'http://www.place-my-order.com/api/restaurants',
        resultsHandler: (response) => response.data,
        property: 'slug',
      },
    },
  },
};

Now when npm run scully is run all of the /restaurants/:slug routes have been added to the scully-routes.json file and the files have been dynamically created in the dist/static dir! Yay!

Serving

To serve the statically generated assets run:

npm run scully serve

You'll be able to view your speedy app at http://localhost:1668/. Cheers!

Survival Strategies for New Remote Developers

Jennifer Wadella — Mon, 30 Mar 2020 14:09:05 +0000

There has been a continual drive towards remote work in the tech industry - commutes are awful, interruptions suck, and open office layouts are the actual worst. The remote lifestyle seems glamorous and appealing, and as a woman I sure love a thermostat set for MY body (amIright, ladies?), but there are considerations for whether remote working is a good fit for everyone. After all, there are no snow days when you work remote.

If you're new to the remote work life, here are some survival strategies for staying productive, happy, and fresh-smelling.

Strategy 1 - Establish & Maintain Boundaries

BOUNDARY - MAINTAIN OFFICE HOURS
Start and end your day at consistent times. At the end of the workday---leave your damn desk! Even if you’re going to continue being on the computer, move to a separate space to maintain the boundary between work and life.

BOUNDARY - TAKE A LUNCH BREAK
Eat your food, walk the dog, hit the gym, browse Reddit---breaks are good! Just make sure you schedule your breaks like you would taking a lunch break at an on-site job.

BOUNDARY - EXPLAIN BOUNDARIES TO FAMILY/FRIENDS
For some odd reason, when you work from home, your friends and family seem to assume that means you’re not “really” working and are available for everything from taking the kids to the park to helping move furniture. Having conversations about the realities of your work schedule is crucial to helping those in your life understand that even though you’re home, you’re actually working and can’t be interrupted.

Visual cues are very helpful in maintaining boundaries in your home. Ideally, have a separate office with a door that closes. If you can’t be in a separate room, use a light or “I’m working now” sign as a visual cue to help those in your home understand you’re not to be disturbed. Unless they’re a cat, in which case you exist solely to do their bidding. For the times that those in your life forget or ignore you’re working, it can be helpful to come up with a code phrase to say instead of an impulse to snap and cause hurt feelings.

## Strategy 2 - Avoid Remote Traps

TRAP - NOT SHOWERING
Shower. Every. Day.

They say dress for the job you want, you don’t want to be a smelly shut-in, do you? It can be easy to let hygiene habits slide when your bad hair can be hidden by that privacy cover on your laptop camera, but it’s a dangerous productivity hole to fall into. Just like a messy desk, a messy body isn’t optimal for doing your best work. Being clean and looking good gives a confidence boost that is much more than just at the surface level. The Sims had clean = happy right, and various studies show showers help alleviation depression, increase energy, and even lead to better sleep.

TRAP - DOING CHORES
Don’t do chores during your office hours. Chores will suck your work hours and corrupt your attention span. You can’t properly focus on your work if you’re watching to clock to change a load of laundry or trying to clean the bathroom while listening to a meeting via headphones. (This doesn’t mean don’t do chores ever, you better be sharing household management duties with your partner!)

TRAP - SLACK, SOCIAL MEDIA, AND OTHER DISTRACTIONS
If you often struggle with staying focused and find yourself wandering into internetbrowsingland while your code compiles, turn your browser into a concentration fortress with these website blockers and tools:

https://momentumdash.com/

Momentum is a a browser extension that shows a custom dashboard with a scenic photo when you open a new tab. I find myself almost habitually opening a new tab and typing “twitt” when my mind starts to drift, so when the momentum dashboard launches it’s a nice visual reminder to get my sh*t together and get back to work.

...

See the rest of my working remote tools & tips on the blog at Bitovi.com.

( cover photo illustration by Tyler Feder, if you work from home you know it's true.)

The Remote Company Checklist: Strategies for Effective Remote Team Management

Jennifer Wadella — Mon, 30 Mar 2020 13:58:43 +0000

Workers can only be as successful as their environment allows. If a company isn’t set up to support remote workers well, someones role as a remote worker may not work out long term. A company unused to managing remote employees may not have a process to assess performance because they are used to relying on seeing people in an office “doing work.”

Completely remote companies have solved how to support a remote team. If your company is new to working remote or only has a faction of remote workers, there are some considerations to be had. It might be helpful to try and align with our remote company checklist, a list of attributes a company needs to successfully manage remote teams.

The Remote Company Checklist

Have an Onboarding Process
Have Meetings Built to be Inclusive of Remote Workers
Have a Clear and Always-Available Task Management System
Are Effective Communicators
Have Documentation Around Tribal Knowledge
Have Appropriate Performance Evaluation Metrics in Place

Read more about how to implement this checklist in detail with tools & recommendations on our blog at Bitovi.com - https://www.bitovi.com/blog/the-remote-company-checklist-strategies-for-effective-remote-team-management

At Bitovi, we're a remote-first company. We pride ourselves on being technical experts, as well as experts in communicating, coaching, and mentoring in remote environments, and we have a history of successful projects to prove it. We love all things JavaScript, UX, front-end, and DevOps: if your team needs help in a remote capacity with getting a new project out the door, mentoring and coaching on best practices, or adding expertise and velocity to your team, please shoot us an email!

( cover photo from WOCinTechChat )

Angular Forms Several Ways: Reactive, Nested, Across Routes

Jennifer Wadella — Fri, 11 Oct 2019 23:45:11 +0000

Dealing with forms is rarely simple anymore. Many SaaS products offer highly customizable setups managed by complex and dynamic forms. Knowing how to use Angulars ControlContainer will give you more control, heh, over managing your forms.

ControlContainer

The ControlContainer is a base class for form directives that contain multiple registered instances of NgControl. We can use the ControlContainer to access FormControls, FormGroups, and FormArrays and manage a main form chunked across components.

A common situation is having a group of form controls, like an "address" groups of fields like "street", "city", "zip" that you use repeatedly across your application. To use bind a Reactive FormControl to the DOM we need access to that FormControl - and can use the FormGroup directive to pass a main FormGroup instance to nested components.

import { Component, OnInit } from '@angular/core';
import { FormBuilder, FormGroup, Validators } from '@angular/forms';

@Component({
  selector: 'app-span-form',
  template: `
  <form [formGroup]="sampleForm">
    <div class="form-group">
      <label for="name">First Name</label>
      <input name="first_name" formControlName="first_name" />
    </div>
    <div class="form-group">
      <label for="name">Last Name</label>
      <input name="last_name" formControlName="last_name" />
    </div>
    <div class="form-group">
      <label for="name">Email Address</label>
      <input name="email" formControlName="email" />
    </div>
    <app-address></app-address>
  </form>
  `,
  styleUrls: ['./span-form.component.less']
})
export class SpanFormComponent implements OnInit {
  public sampleForm: FormGroup;
  constructor(
    private fb: FormBuilder
  ) { }

  ngOnInit() {
    this.sampleForm = this.fb.group({
      user_name: ['', Validators.required],
      first_name: ['',Validators.required],
      last_name: ['',Validators.required],
      email: ['',Validators.required],
      street: ['',Validators.required],
      city: ['',Validators.required],
      state: ['',Validators.required],
      zip: ['',Validators.required]
    })
  }

}

Inside our reusable Address component we can access the sampleForm by injecting the ControlContainer class in our constructor - this will return the parent FormGroupDirective and allow us to access that control. From there we can use the formControlName for our FormControls as expected.

import { Component, OnInit } from '@angular/core';
import { ControlContainer } from '@angular/forms';

@Component({
  selector: 'app-address',
  template: `
  <form  *ngIf="ogFormGroup" [formGroup]="ogFormGroup">
    <h5>Address:</h5>
    <div class="form-group">
      <label for="name">Street Name</label>
      <input formControlName="street" />
    </div>
    <div class="form-group">
      <label for="name">City</label>
      <input formControlName="city" />
    </div>
    <div class="form-group">
      <label for="name">State</label>
      <input formControlName="state" />
    </div>
    <div class="form-group">
      <label for="name">Zip</label>
      <input formControlName="zip" />
    </div>
  </form>
  `,
  styleUrls: ['./address.component.less']
})
export class AddressComponent implements OnInit {
  public ogFormGroup;
  constructor(public controlContainer: ControlContainer) {
  }

  ngOnInit() {
    this.ogFormGroup = this.controlContainer.control;
  }

}

We can use the same approach in other situations, for example a form that's presented across multiple paths.

//parent component where form is initialized
import { Component, OnInit } from '@angular/core';
import { FormBuilder, FormGroup, Validators } from '@angular/forms';

@Component({
  selector: 'app-span-form',
  template: `
    <button routerLink="step-1">Step 1</button>
    <button routerLink="step-2">Step 2</button>
    <button routerLink="step-3">Step 3</button>
    <form [formGroup]="mainForm" class="form-ui">
      <router-outlet></router-outlet>
    </form>
  `,
  styleUrls: ['./span-form.component.less']
})
export class SpanFormComponent implements OnInit {
  public mainForm: FormGroup;
  constructor(
    private fb: FormBuilder
  ) { }

  ngOnInit() {
    this.mainForm = this.fb.group({
      user_name: ['', Validators.required],
      first_name: ['',Validators.required],
      last_name: ['',Validators.required],
      email: ['',Validators.required],
      address: this.fb.group({
        street: ['',Validators.required],
        city: ['',Validators.required],
        state: ['',Validators.required],
        zip: ['',Validators.required]
      }),
      favorite_color: ['',Validators.required],
      favorite_food: ['',Validators.required],
      favorite_season: ['',Validators.required],
      favorite_episode: ['',Validators.required]
    })
  }

}

In the child component we access the parent formDirective through the ControlContainer class and bind it to a new form directive in our component and include the formControls we want to present to the user.

// child component at nested route displaying part of main form:
import { Component, OnInit } from '@angular/core';
import { ControlContainer } from '@angular/forms';

@Component({
  selector: 'app-step1',
  template: `
    <h3>Step One of Our Sign-in Process</h3>
    <form [formGroup]="parentForm">
      <div class="form-group">
        <label for="name">Choose a User Name</label>
        <input name="user_name" formControlName="user_name" />
      </div>
    </form>
    <button [disabled]="!parentForm.controls.user_name.valid"
    routerLink="/signup/step-2">Next</button>
  `,
  styleUrls: ['./step1.component.less']
})
export class Step1Component implements OnInit {
  public parentForm;
  constructor(private controlContainer: ControlContainer) {
  }

  ngOnInit() {
    this.parentForm = this.controlContainer.control;
  }
}

Code demo here: https://github.com/tehfedaykin/ControlContainerExample

Cheers from a dairy farm 🐮in New Zealand!

Testing Loading States using RxJS operators

Jennifer Wadella — Thu, 05 Sep 2019 20:45:45 +0000

A very common pattern is showing some sort of loading visual while data is being fetched. In Angular we can elegantly build this using a reactive programming approach with RxJS - but how do we test it?

Let's say we are fetching a list of our cats names from a service and want to handle loading behavior while that request is made. We might do something like this:

import { Observable } from 'rxjs';
import { map, startWith } from 'rxjs/operators';

interface ResponseData<T> {
  data: Array<T>;
}
interface MappedData<T> {
  value: Array<T>;
  isLoading: boolean;
}

@Component({
  selector: 'cat-list',
  template: `
     <ng-container *ngIf="cats$ | async as cats">
        <div class="pending" *ngIf="cats?.isLoading; else loaded"></div>
        <ng-template #loaded>
            <div class="cat" *ngFor="let cat of cats.value">
            <p>Name: {{cat.name}}</p>
            </div>
        </ng-template>
    </ng-container>
`,
  styleUrls: ['./cat.component.less']
})
export class CatListComponent implements OnInit {
  public cats$: Observable<MappedData<Cat>>;

  constructor(private catService: CatService) { }

  ngOnInit() {
    this.cats$ = this.catService.getCats().pipe(
     map((res: ResponseData<Cat>) => {
      return {
        value: res.data,
        isLoading: false
      }
     }),
     startWith({
       value: [],
       isLoading: true
     })
  }
}

We're using the startWith operator to set our observable to initially have an empty array and and isLoading value of true. In our unit test, we'll make sure our UI is reflecting the loading state as we'd expect:

import { async, ComponentFixture, TestBed, fakeAsync, tick } from '@angular/core/testing';

import { CatListComponent } from './cat-list.component';
import { of, asyncScheduler } from 'rxjs';
import { CatsService } from '../catList/cats.service';

class MockCatsService {
  getCats() {
    return of({
      data: [{
        name: 'Sake',
        age: 10
      },
      {
        name: 'Butter',
        age: 15
      },
      {
        name: 'Parker',
        age: 7
      },
      {
        name: 'Kaylee',
        age: 2
      }]
    }, asyncScheduler);
  }
}

describe('CatListComponent', () => {
  let component: CatListComponent;
  let fixture: ComponentFixture<CatListComponent>;

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ CatListComponent ],
      providers: [{
        provide: CatsService,
        useClass: MockCatsService
      }],
    })
    .compileComponents();
  }));

  it('should create', () => {
    const fixture = TestBed.createComponent(CatListComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
    expect(component).toBeTruthy();
    fixture.destroy();
  });

  it('should show loading div while results are loading', fakeAsync((): void => {
    const fixture = TestBed.createComponent(CatListComponent);
    fixture.detectChanges();
    const compiled = fixture.debugElement.nativeElement;
    const loadingDiv = compiled.querySelector('.loading');
    expect(loadingDiv).toBeTruthy();
    fixture.destroy();
  }));

  it('should show cat divs when results have loaded', fakeAsync((): void => {
    const fixture = TestBed.createComponent(CatListComponent);
    fixture.detectChanges();
    tick();
    fixture.detectChanges();
    tick();
    fixture.detectChanges();
    const compiled = fixture.debugElement.nativeElement;
    const loadingDiv = compiled.getElementsByClassName('cat');
    expect(loadingDiv.length).toBe(4);
    fixture.destroy();
  }));
});

Because I want to first test the isLoading state I want to be able to see what the UI looks like before my getCats method, so I wrap my assertion in a fakeAsync function. This function creates a fake async zone where I can call a tick function to simulate the passage of time. By doing this I essentially can test my Observables as though they were synchronous.

I call tick and fixture.detectChanges for each "timer"; to trigger the component lifecycle like ngOnInit, when the observable is created, when the observable is subscribed to using the async pipe in the view, etc.

Show Me Your #coderclaws

Jennifer Wadella — Wed, 10 Jul 2019 15:14:41 +0000

Stylish people, show me your #coderclaws! (Thanks to Sarah Ownbey Chipps for the best hashtag ever)

**edit

For serious #nailinspo: