At this point, our Angular app is working great, and data is coming back quickly thanks to our materialized view. We aren’t fetching the credit card information, however, so our feature isn’t quite complete. We’ll complete it in this chapter, which will give you the opportunity to learn more about how to design a complex Angular app. You’ll see how embracing a component-based design, along with the Angular’s asynchronous nature, makes it easy to keep code organized and maintain a good user experience in the face of added complexity (namely, fetching the credit card information from a third party).
Up to this point, our Angular app looks like a Rails app written in JavaScript. You could think of our components as controllers and our templates as views. This is because we aren’t taking full advantage of Angular’s features. Angular components can be smaller, more focused, and have more intelligence than Rails views and partials. One thing we can do with this extra intelligence is fetch data from more than one source at the same time. Instead of collecting all the data and rendering a view—as we would in a classic Rails application—we can render data as it comes in. This makes our UI more responsive and provides a better user experience, especially if one of our sources of data is slow.
You’ll learn about how to do that in this chapter, along with a few other tidbits of working in an Angular codebase. We’ll split up our existing CustomerDetailsComponent into a hierarchy of subcomponents. We’ll also fetch the credit card information from a third party and populate the UI with data as it becomes available. We’ll look at how Bootstrap’s progress bar UI component can be used to give the user feedback that this process is happening.
Asynchronous code can be confusing, however, especially with multiple requests in flight at once. You also might not be as familiar with observables—the underlying technology Angular uses to manage asynchronous behavior—so let’s first look at how that works.