15 Common Angular Questions Answered

You’ve got Angular questions. We’ve got Angular answers.

Angular expert and Pluralsight author John Papa recently hosted two live events where he shared his tips and tricks for succeeding with the Angular framework. We’ve compiled some of the most popular questions here with John’s answers. If you’re trying to understand inputs and outputs, emitters or are just having trouble deciding between Angular and React, this is a good place to start.

It isn’t a war; it’s a choice. The Angular, React, Vue and Svelte (the newer kid on the block) web frameworks all solve different problems. And a lot of that choice comes down to development style. Angular provides more of a guided path, while React feels more “choose your own adventure.” Angular is extremely opinionated, React is less so and Vue is in the middle.

For example, one thing I’ve noticed when I go from Angular project to Angular project is how much similarity there is. It’s a lot easier for developers to hop in and out of different Angular projects without too much conceptual overload. With React, I’ve seen developers have to relearn things on occasion; one project may have used a different router or implemented something completely differently.

It all depends on where you’re looking. On social media, you’ll hear a lot of opinionated views about this framework or that framework, and you’ll see people wanting to use and talk about the newest, coolest thing. Just because React may be newer than Angular does not mean it’s necessarily being used more, especially in enterprise. What we see on the public web is very different from what I’ve seen working with large enterprises, where Angular is heavily used.

The first big rule of thumb is to load as little JavaScript and CSS as you can for the browser. If your app needs to load quickly, you want to reduce the amount of content going across the wire, reduce the amount of content that has to be parsed by the browser and improve the perceived performance.

For smaller apps, Angular is also going to be bigger because it comes with more out of the box. For larger apps, for each additional component you add in Angular, the additional overhead you gain is very small because you end up reusing a lot of the Angular framework features. (This is essentially the inverse of Svelte, where you don’t really get anything out of the box unless you add it, which allows it to keep a light weight and low overhead for smaller apps.)

All three. I use inputs and outputs for parent/child relationships when it’s just one parent and one child. If I know the parent is going to have a child and the child knows who its parent is, it’s a dead simple method.

If I need to communicate more across multiple components—for example, a parent who has a child, and that child has a child and that child has another child—I’m not going to pass values up and down the chain. In that case, I’m injecting a service.

If it gets crazier, and you’ve got components all over the app and have no idea how they’re related to each other, that’s when I get into a service using an RxJS subject to send messages.

Let’s say you’ve got a customer component, and it needs to talk to a customer details component—let’s say the customer component is at the “top” and has a list of customers, and the customer component is at the “bottom” and has the details for the specific customer. When you select a customer from the top, you want to tell this bottom component which customer was selected, and you need to pass it somehow. So the selected customer from the top gets passed to the bottom component as an input.

But now, once somebody modifies the customer component at the bottom, you want to tell the top component what happened. In this instance, I’ll use an output to emit and event to the top component that tells it what changed.

In short: Inputs are a way of going down through the component tree, and outputs are a way to emit events up the component tree.

In a scenario where we have two components that need to talk to each other—one being the parent and one being the child—an emitter is just a fancy word for something that sends an event from the child to the parent. You can name the event whatever you want, and it’s an event in the same way there would be a “click” event on a button, for example.

If I want to have one component talk to another and they’re not in a hierarchy—like a log-in component and a customer component—I would go ahead and use RxJS subjects.

This is a tricky situation. Ideally, you don’t want to rebuild your Angular application when you’re going from different environments. What you can put into .env files, you should, and for backend stuff that’s easy to do. For Angular, some developers use environment.prod or environment.dev, but the problem is you have to rebuild to get those.

One trick to avoid rebuilding is to have a URL that you use as a pre-loading option, like an app initializer, which works by providing you key information about environments you’ll need to run things before the app starts. Another way is to have your server embed certain environment flags when it launches index HTML.

To answer this, I first want to take this from a larger viewpoint and say that I feel forms on the web have done us a disservice over the last decade or so. HTML forms in any framework are painful. We have great inputs, but once you add in client-side validation, multiple field validation, and asynchronous validation—and then you start combining those with things like regex, required fields, numbers, types, domains, ranges and so on—you have a ton of stuff in your form without even having touched Angular yet.

When it comes to deciding between reactive forms or template driven forms, the main question to answer is whether you want the code for validation to be in your template or to be in the components and code itself. They both work well, so that’s the primary difference. 

The Angular team recommends reactive forms, and while I personally prefer template-driven forms because I find them more intuitive, my advice is that whichever one you pick, just pick one. Don’t use both in your application.

This extension pack for Visual Studio Code I wrote—called Angular Essentials—has a list of Angular Snippets I use frequently. Then by typing “a-”, you’ll get a preview of a variety of different snippets for things like directives, routing guards, interceptors, modules, NgRx tips, preload strategies, routing and more.

Material Design is a design pattern, and Angular Material is an implementation of that for Angular to be able to use it. It’s basically a design system you can use for styling, colors, fonts, spacing and UI. While I do like it, what I’d recommend for a company is that you don’t just take something like Angular Material or Bootstrap or Tailwind and use them as your only design system. Rather, you should use these tools as the basis for making your own design system.

I like Angular Universal. If you’re going public with your app, it essentially gives you server-side generated versions of your app that improves the launch speed—subsequently improving the experience for the customers that come to your website. It’s a tool you can use from the CLI.

Both. I start with Jamstack or a storage account because if my application doesn’t have a complex backend, why pay for a web server or API server? I’ll use Jamstack to host my code in storage and put my Azure functions as my API, and it’s extremely cheap and super fast. Azure Static Web Apps is a new and excellent player on the Jamstack scene. If I need more control or a backend, I would host a node server or an ASP.NET web API server in App Service with Azure.

If you use Karma as the test runner, you’ll probably want to use Jasmine with Angular because it’s out of the box. Jest is a new model for testing, and I really like it, so if you’ve got time to figure it out, it’s worth looking into. If you don’t have time, use Karma and Jasmine.

There are ways to lazy load single components, not modules, which I wrote about here. It’s definitely more involved than lazy loading modules with routes, but may be what you’re looking for if you’re only addressing single components. Another option would be to create web components, and Angular CLI has options to create those web components for you.

Click through for links to watch full recorded versions of John’s recent webinars, “Angular AMA with John Papa” and “Building in Angular from scratch.”