Gain insights into reactive programming with RxJS 7, explore data streams, error handling, and multicasting to build a recipe app, and learn to test and optimize reactive applications.

angular.tar.gz

angular04

angular05

angular06

coderun

angular04-copy

test

angular07

angular09

angular10

angular11

angular12

angular13

angular13-test

The reactive programming paradigm is designed to make working with asynchronous events and data streams convenient. 

This course teaches you about the reactive programming paradigm and when to choose it over others. You’ll learn to use new RxJS 7 features to create a recipe book web application that lets users browse and share recipes. In this context, you’ll learn about data streams, error handling, and how to combine streams and transform one data stream into another. You’ll develop an understanding of multicasting and caching streams, how to share data between components, perform bulk operations such as file uploads, and perform real-time updates. Finally, you’ll learn how to test a reactive application. To assess your knowledge, there’s a project, coding challenges, and assessments.

After this course, you’ll be able to determine the utility of the reactive paradigm for any application and have mastery over new RxJS 7 features to create robust reactive applications.

Reactive Programming with Angular and RxJS 7

#
# The replace strategy

We should be very careful about all the HTTP requests we send and the processes in our front-end application in general. It's amazing to work with streams—when they’re safe. So how can we fix this? What strategy should we choose?

The last example in the [previous lesson](https://www.educative.io/courses/reactive-programming-with-angular-and-rxjs-7/error-handling-patterns-rethrow-and-retry-strategies#Implementation-of-code-with-error) is picked from the recipe app. We retried getting the recipes after five seconds from each failure. Is this the right strategy? In our case, if we choose the rethrow or retry strategy, we'll block the display of the recipe list. We'll get a blank page. The user will wait for the request to get executed successfully in order to see the UI. This isn't correct. It's correct when we have processes in the background or processes that aren't related to the UI display. But if we raise requests in order to get results and display data in our UI components, then we should provide a replacement for that data to continue rendering the page.

That's why our case falls under the replacement strategy. In fact, we want to get the list
of recipes from the service, but if the service fails for whatever reason, we don't want the application to be frozen; we want to see a collection of zero elements (no elements), an empty table, or a list, and that's all. So what we're going to do is use `catchError` and return an empty observable, which is our fallback value.



Learn about error handling and the consequences of unhandled errors in the application.

Error Handling in Action

Getting Started

The Power of the Reactive Paradigm

RxJS 7—The Major Features

A Walk-Through of the Application

Fetching Data as Streams

Error Handling

Combining Streams

Assessment 1

Transforming Streams

Multicasting Essentials

Caching Streams

Sharing Data between Components

Bulk Operations

Processing Real-Time Updates

Testing RxJS Observables

Assessment 2

Conclusion

Error Handling in Action

The replace strategy