Hey I am trying to figure out a way to handle error and api call inside an redux epic, I have checked at this doc:
https://redux-observable.js.org/docs/recipes/ErrorHandling.html
I don't have any error, but nothing happens the code seems looping
/**
* Request the JSON guide to the API
* and then dispatch requestGuideFulfilled & requestGameTask actions
*
* #param action$
*/
export function requestGuide(action$) {
return action$.ofType(REQUEST_GUIDE)
.mergeMap(({id}) => fetchJsonp(`${API_URL}/guide/${id}/jsonp`)
.catch(error => requestGuideFailed(error))
)
.mergeMap(response => response.json())
.mergeMap(json => requestGuideFulfilled(json))
.map(json => requestGameTask(json))
}
export function manageRequestGuideError(action$) {
return action$.ofType(REQUEST_GUIDE_FAILED)
.subscribe(({error}) => {
console.log('Error',error)
})
}
Any Idea ? Thank you !
[UPDATE]: I have an error even on the fetching:
You provided an invalid object where a stream was expected. You can
provide an Observable, Promise, Array, or Iterable.
There are a number of issues, so I'll try and elaborate as best I can. To be frank, RxJS is not easy. I would encourage you to spend some solid time learning the fundamentals before using redux-observable, unless of course you're just experimenting in your free time for fun and you like pain lol.
It's also critical to not bring in things like redux-observable unless you really need complex side effect management. Somewhat unfortunately, the docs currently only have simple examples, but redux-observable is really intended to make complex stuff like multiplex websockets, elaborate time-based sequencing, etc much easier at the expense of needing to know RxJS really well. So I guess I'm saying is, if you do need redux, make sure you need redux-observable too or could get away with redux-thunk. It might seem funny that one of the makers of redux-observable sorta talks people out of using it, but I just see a crazy number of people using things like redux-observable/redux-saga for things that simply don't justify the complexity they bring. You know your needs best though, so don't take this as doctrine or be unreasonably discouraged <3
None of the code in this answer has been tested, so it may need minor corrections.
You provided an invalid object where a stream was expected. You can provide an Observable, Promise, Array, or Iterable.
This error is likely caused by .mergeMap(json => requestGuideFulfilled(json)). It looks like requestGuideFulfilled is an action creator, but the source isn't included here so I can't be sure. mergeMap aka flatMap expects you to return another stream (usually an Observable), so an action POJO would need to be wrapped in an Observable, like Observable.of(requestGuideFulfilled(json)) but in this case using mergeMap is unnecessary. It could have just been a regular map().
export function manageRequestGuideError(action$) {
return action$.ofType(REQUEST_GUIDE_FAILED)
.subscribe(({error}) => {
console.log('Error',error)
})
}
In redux-observable all Epics must return an Observable. This Epic is returning a subscription observable (the return value of subscribe()). This actually does produce an error, however due to a bug in RxJS it's been silently swallowed.
Instead you can use do and ignoreElements to create an Observable that listens for that action, logs that property out, then ignores it (never emitting anything itself). So it's "read only" basically.
export function manageRequestGuideError(action$) {
return action$.ofType(REQUEST_GUIDE_FAILED)
.do(({error}) => {
console.log('Error',error)
})
.ignoreElements();
}
The next and biggest issue is where you've placed your catch. It's important to learn about how using RxJS means we are chaining Observables together--"operators" basically take a source and return another Observable which will lazily apply some operation on data piped through them. This is very similar to functional programming with Arrays (e.g. arr.map().filter()) with two major differences: Observables are lazy and they have a time-dimension.
How operators work
So consider this Observable chain:
Observable.of(1, 2, 3)
.map(num => num.toString())
.filter(str => str !== '2');
.subscribe(value => console.log(value));
We create an Observable that, when subscribed to, will synchronously emit 1, then 2, then 3.
We apply the map operator to that source which creates a new Observable that, when subscribed to, will itself subscribe to source we applied it to: our Observable of 1, 2, 3.
We then apply the filter operatorto the Observable returned bymap. As you might have guessed,filterreturns a new Observable that, when subscribed to, will itself subscribe to the source we applied it to: our Observable of strings we mapped. Because thatmap` Observable itself was applied to a source, it too will then subscribe to its source, pulling in the first number and kicking off the map -> filter operation.
It may be helpful to store those intermediate Observables as variables, to demystify things a bit.
const source1: Observable<number> = Observable.of(1, 2, 3);
const source2: Observable<string> = source1.map(num => num.toString());
const result: Observable<string> = source2.filter(str => str !== '2');
Inner Observables
When we use operators like mergeMap, switchMap, concatMap, we are saying we want to map each value to another "inner" Observable who's values will be either merged, switched to, or queued (concat) after the previous inner Observable. These have different important differences, but there's lots of resources on them if you're unfamiliar.
In your case we're using mergeMap, which also has an alias of flatMap, which is the more widely known term used in functional programming. mergeMap will provide each value to your projection function and concurrently subscribe to the Observable you return for each. The values of each of those inner Observables are merged together.
In functional programming they more often call this flattening, instead of merging. So it may again be helpful to first consider this merging/flattening in the context of Arrays
Array.prototype.map
[1, 3, 5].map(value => {
return [value, value + 1];
});
// [[1, 2], [3, 4], [5, 6]] Array<Array<number>>
This resulted in an array of arrays of numbers Array<Array<number>>, but what if we instead wanted a single, flattened array? Enter flatMap.
Array.prototype.flatMap (stage 2 TC39 proposal)
[1, 3, 5].flatMap(value => {
return [value, value + 1];
});
// [1, 2, 3, 4, 5, 6] Array<number>
JavaScript arrays do yet officially have flatMap, but it's a stage 2 TC39 proposal as of this writing. It follows the same semantics as the typical flatMap: for each item in the array map it to another array provided by your projection function, then flatten each of those into a single new array.
With Observables, it's pretty much the same except again they are lazy and have a time dimension:
Observable.of(1, 3, 5).map(value => {
return Observable.of(value, value + 1);
});
// Observable.of(1, 2)..Observable.of(3, 4)..Observable.of(5, 6) | Observable<Observable<number>>
We mapped each number into their own Observable of two numbers. So a higher-order Observable Observable<Observable<number>> and probably not what we wanted in most cases.
Observable.of(1, 3, 5).flatMap(value => {
return Observable.of(value, value + 1);
});
// 1..2..3..4..5..6 | Observable<number>
Now we just have a stream of all the numbers. Perfect!
Error Handling
Putting together our understanding of operating chaining and Observable flattening, we come to error handling. Hopefully that primer makes this next part easier to grok.
If an error is thrown in any one of our chained Observables it will propagate through the chain in the same fashion as values do, but in its own "channel" basically. So we if we have an Observable chain a -> b -> c and an error occurs in a, it will be sent to b then c. When each Observable receives the error it can either handle it in some way, or choose to pass it along to whatever is subscribing to it. When it does, that subscription terminates and no longer listens for future messages from its source.
Most operators just pass along errors (while terminating), so if you aren't using a special error handling operator like catch the error propagates until it reaches your observer--the one you yourself passed to .subscribe(next, error, complete). If you provided that error handler, it's called, if not, it's rethrown as a normal JavaScript exception.
To finally get to your code, let's start with the end; what I think you actually want:
function getGuide(id) {
const promise = fetchJsonp(`${API_URL}/guide/${id}/jsonp`)
.then(res => res.json());
return Observable.from(promise);
}
export function requestGuide(action$) {
return action$.ofType(REQUEST_GUIDE)
.mergeMap(({id}) =>
getGuide(id)
.mergeMap(json => Observable.of(
requestGuideFulfilled(json),
requestGameTask(json)
))
.catch(error => Observable.of(
requestGuideFailed(error)
))
)
}
Now let's break it down.
Promise vs. Observable
First thing you'll see is that I abstracted out your fetchJsonp into the getGuide function. You could just as well put this code inside the epic, but having it separate will make it easier for you to mock it if you decide to test.
As quickly as possible I wrap that Promise in an Observable. Mostly because if we're choosing to use RxJS we should go all-in, especially to prevent confusion later. e.g. both Promise and Observable instances have catch methods so it's easy to cause bugs if you start mixing the two.
Ideally we'd use Observables instead of Promises entirely, as Promises cannot be cancelled (so you cannot cancel the actual AJAX request + JSON parsing itself), although if you wrap it in an Observable and unsubscribe before the promise resolves, the Observable will correctly just ignore what the promise later resolves or rejects.
Emitting multiple actions?
It's not 100% clear, but it appeared you intended to emit two actions in response to successfully getting back the JSON. Your previous code actually maps the JSON to the requestGuideFulfilled() action, but then the next operator maps that action to requestGameTask() (which doesn't receive the JSON, it receives the requestGuideFulfilled() action). Remember above, about how operators are chains of Observables, the values flow through them.
To solve this, we need to think think "in streams". Our getGuide() Observable will emit a single value, the JSON. Given that single (1) value we want to map it to more than one other values, in this case two actions. So we want to transform one-to-many. We need to use one of mergeMap, switchMap, or concatMap then. In this case, since our getGuide() will never emit more than one item all three of these operators will have the same result, but it's critical to understand them cause it often does matter so keep that in mind! Let's just use mergeMap in this case.
.mergeMap(json => Observable.of(
requestGuideFulfilled(json),
requestGameTask(json)
))
Observable.of supports an arbitrary number of arguments, and will emit each of them sequentially.
catching errors
Because our Observable chains are...well..chains hehe the values are piped between them. As we learned above, because of this where you place error handling in these chains is important. This is actually not very different between error handling with traditional exceptions, or even promises, but Promises do not have "operators", so people don't usually run into this confusion.
The catch operator is the most common, and it's pretty similar to the catch Promises have except you must return an Observable of the value you want, not the value itself. Observable.of is common here since most often we just want to emit one or more items sequentially.
.catch(error => Observable.of(
requestGuideFailed(error)
))
Whenever a error is emitted by the source we apply this operator to, it will catch it and instead emit requestGuideFailed(error) and then complete().
Because it emits an action on error, any operators we apply to the result of this .catch() **could also be operating on the value our catch emits.
getJsonSomehow()
.catch(error => Observable.of(
someErrorAction(error)
))
.map(json => {
// might be the JSON, but also might be the
// someErrorAction() action!
return someSuccessAction();
})
Although not unique to redux-observable (since redux-observable is mostly just a tiny library and a convention, using RxJS) you'll often see Epics follow a similar pattern.
Listens for an particular action
Then merges or switches that action into an inner Observable that performs a side effect
When that side effects is successful we map it to an success action
In case it errors we place a catch inside our mergeMap/switchMap but most often at the end of the inner chain, so that any actions we emit aren't transformed on accident.
You'll hopefully recognize that general pattern from the redux-observable docs:
function exampleEpic(action$) {
return action$.ofType(EXAMPLE)
.mergeMap(action =>
getExample(action.id)
.map(resp => exampleSuccess(resp))
.catch(resp => Observable.of(
exampleFailure(resp)
))
);
}
Applying that knowledge to our previous work:
getGuide(id)
.mergeMap(json => Observable.of(
requestGuideFulfilled(json),
requestGameTask(json)
))
.catch(error => Observable.of(
requestGuideFailed(error)
))
And that's about it, I think.
PHEW! Sorry that was so long-winded. It's entirely possible you knew some or all of this, so forgive me if I'm preaching the choir! I started writing something short, but kept adding clarification, after clarification. lol.
If you're struggling, definitely make sure using RxJS and redux-observable (or any complex middleware) is a neccesary complexity for your app.
Related
Suppose I have two completely independent pieces of code in two completely unrelated classes that subscribe to the same Observable in a service class.
class MyService {
private readonly subject = new Subject<any>();
public observe(): Observable<any> {
return this.subject.pipe();
}
}
class A {
constructor(private readonly service: MyService) {
service.observe().subscribe( async (value) => {
await this.awaitAnOperation(value);
console.log('Class A subscription complete', value);
});
}
}
class B {
constructor(private readonly service: MyService) {
service.observe().subscribe( (value) => console.log('Class B subscription complete', value));
}
}
The issue that I am now facing is that when the service emits an event, the log of class B will come before A, even though A subscribed first. What I need is that all methods are ran and finished before going to the next one. I know if A were to be synchronously than my question would be solved, but A does need to run an async operation AND Bcan only log after A has logged.
A and B are completely unaware of eachother and should be as well. In e.g. C# we can run an async method synchrnonously by using GetAwaiter().Wait(); and is not considered a bad practice since when it needs to run on the main thread. An equivalent TS/JS option would be nice.
EDIT
A subscribes before B. It is simply the chronological order of subscribing that should also execute. I know this is by default emitted in that sequence, but the fact remains that running a subscription method on a different thread would continue the main thread to the next subscription. This is what I need to avoid somehow.
I had a similar issue that I solved with an operator I called forkConcat. Instead of subscribing multiple times, I made multiple operators and chained them so that source$.pipe(operatorA) would happen and complete before source$.pipe(operatorB) started, and that would complete before source$.pipe(operatorC) started, and all three completed before dealing with the next value from source$.
My code looked like this...
source$.pipe(
forkConcat(
concat,
operatorA,
operatorB,
operatorC
) )
where forkConcat is defined as
import { merge, Observable, of } from 'rxjs';
import { concatMap, Operator } from 'rxjs/operators';
/*
Creates an operator that will fork several operators from the same input, and not proceed until all those things are done.
First Argument:
If those things should be done in turn, send concat as the first argument.
If each operator should be done in parallel, use merge (or undefined) as the first argument.
To return an array of each operators' final values per value received by forkConcat, use forkJoin.
You could also use combineLatest, etc.
All other arguments are operators.
*/
type Combiner<T> = (...array$: ObservableInput<T>[]) => Observable<T>;
export function forkConcat<T,R>(combiner: Combiner<T> = merge, ...arrayOperators: Operator<T, R>[]) {
return concatMap<T,R>((x) => {
try {
const x$ = of(x);
const o = arrayOperators
.filter(op => !!op) // ignore falsy arguments
.map(op => x$.pipe(op));
return o.length ? combiner(...o) : x$;
} catch (e) {
throw new ForkConcatError(x, e, combiner, arrayOperators);
}
});
}
class ForkConcatError<T> extends Error {
constructor(
readonly receivedValue: T,
readonly innerError: Error,
readonly combiner: Combiner<T>,
readonly arrayOperators: Operator<T, R>[]
) {
super(innerError.message);
}
}
It worked. But I've also got to tell you...
I threw it away
I slowly began to realize that the need for forkConcat was a sign that I should be doing things differently. I haven't seen your code but when you say they shouldn't know about each other yet one affects the other, I highly suspect you should consider the same. If, instead of global/shared variables, you had global/shared subjects and observables where the one that emitted to B was...
source$.pipe(
concatMap(x => concat(
of(x).pipe(
operatorA,
ignoreElwments()
),
of(x) // B should receive the same value A did.
)
)
... then you wouldn't have this issue and your code would be cleaner.
In my case, I went a different route. I made a State interface, and then instead of passing source values through my operators, I passed {source: Source, state: State} objects. This way, there was no longer any global variables at all! Every operator could be a pure function (or pure function plus side effects) using only the combined value/state pairs emitted into them. State errors were much harder to make! To use this tactic, start thinking of your A and B as operators (that don't know about each other) instead of subscribers (that don't know about each other) and your future self will likely be happier.
But just in case I'm wrong about that advice, you now have forkConcat.
You can do that by combining the two Observables using switchMap rxjs operator. it will be guarantied that the second Observable B will not started unless the first one A is done.
Here a good example to this scenario in the section addressed "Combining Observables in series":
https://blog.danieleghidoli.it/2016/10/22/http-rxjs-observables-angular/
I am trying to avoid the following:
switchMap(([action, state]) =>
from(TodosDB.getAll()).pipe(
map(
(todos) => onQueryTodoDone({ items: todos }),
catchError((err) => of(onQueryTodoFail({ error: err })))
)
)
),
to something more linear like like we do with combineLatestFrom in ngrx.
So far I tried to do the below. But the promise does not seem to work.
withLatestFrom(
from(TodosDB.getAll())
),
and
withLatestFrom(
from(TodosDB.getAll()).pipe(
map((todos) => onQueryTodoDone({ items: todos }))
)
)
Any ideas how to deal with this scenario without nesting pipe map in a switchMap?
PS: this might be obvious to you but I don't know much and I looked up on the internet and found withLatestFrom but not sure what I am missing.
EDIT: this is the best I got so far:
switchMap(([action, state]) =>
forkJoin([of(action), of(state), TodosDB.getAll()])
),
map(
([action, state, todos]) => onQueryTodoDone({ items: todos }),
catchError((err) => of(onQueryTodoFail({ error: err })))
),
The above is better but I have no idea if that can cause issues later. But hopefully I was able to communicate the idea. Which is append a promise result to the piped observable keep it's original structure
[Observable<Actions>,Observable<State>,Observable<FromPromise>]
Joining a few dots here and taking a bit of a guess I would say the problem stems from TodosDB.getAll returning a Promise.
With a promise based function you want to lazily evaluate it, as such a function is executed immediately when it is called, unlike an observable based function which requires a subscription.
This is why the switchMap based solutions work, because the body of the switchMap is not evaluated until the source emits.
In your shortened version using withLatestFrom, there is no lazy evaluation, the getAll call is probably evaluated once and once only when the effect is set up.
You can use the defer operator to convert your promise based function to one that behaves more appropriately with the rxjs observable based operators.
withLatestFrom(defer(() => this.getAll())), // use of defer
map(([[action, state], todos]) => [action, state, todos]), // refine the shape of the data to your requirements
...
Stackblitz: https://stackblitz.com/edit/angular-ivy-qkwqyw?file=src%2Fapp%2Fapp.component.ts,src%2Fapp%2Fapp.component.html
Note: The concatLatestFrom ngrx operator also looks like it may be of use but I couldn't get it to work how I wanted.
I am struggling to understand the difference between the flatMap and concatMap in rxJs.
The most clear answer that I could understand was that here difference-between-concatmap-and-flatmap
So I went and tried things out by my self.
import "./styles.css";
import { switchMap, flatMap, concatMap } from "rxjs/operators";
import { fromFetch } from "rxjs/fetch";
import { Observable } from "rxjs";
function createObs1() {
return new Observable<number>((subscriber) => {
setTimeout(() => {
subscriber.next(1);
subscriber.complete();
}, 900);
});
}
function createObs2() {
return new Observable<number>((subscriber) => {
setTimeout(() => {
subscriber.next(2);
//subscriber.next(22);
//subscriber.next(222);
subscriber.complete();
}, 800);
});
}
function createObs3() {
return new Observable<number>((subscriber) => {
setTimeout(() => {
subscriber.next(3);
//subscriber.next(33);
//subscriber.next(333);
subscriber.complete();
}, 700);
});
}
function createObs4() {
return new Observable<number>((subscriber) => {
setTimeout(() => {
subscriber.next(4);
subscriber.complete();
}, 600);
});
}
function createObs5() {
return new Observable<number>((subscriber) => {
setTimeout(() => {
subscriber.next(5);
subscriber.complete();
}, 500);
});
}
createObs1()
.pipe(
flatMap((resp) => {
console.log(resp);
return createObs2();
}),
flatMap((resp) => {
console.log(resp);
return createObs3();
}),
flatMap((resp) => {
console.log(resp);
return createObs4();
}),
flatMap((resp) => {
console.log(resp);
return createObs5();
})
)
.subscribe((resp) => console.log(resp));
console.log("hellooo");
I have used that playground here playground example
Questions
1)
From my understanding the use of flatMap should mix the outputs so that the console logs are like (1,3,2,4,5). I have tried more than 30 times and always come on the same row (1, 2, 3, 4, 5)
What am I doing wrong or have undestood wrong?
2)
If on createObs2() and createObs3() you remove the comments and include the code with multiple emitted events then things get messy. Even if you change to concatMap it messes things and results come mixed. Multiple numbers that I expect only once come multiple times. The result can be (1, 2, 33, 3, 2, 22, 3, 33, 4, 5, 4, 3, 4, 5) Why this happens?
How I test the example on playground. I just remove only 1 letter from the last console.log("hello"). Only one change for example console.log("heloo") and is then observed and project is compiled again and output printed in console.
Edit: The reason I have gone to flatMap and concatMap was to find a replacement for nested subscriptions in angular using the http library.
createObs1().subscribe( (resp1) => {
console.log(resp1);
createObs2().subscribe( (resp2) => {
console.log(resp2);
createObs3().subscribe( (resp3) => {
console.log(resp3);
createObs4().subscribe( (resp4) => {
console.log(resp4);
createObs5().subscribe( (resp5) => {
console.log(resp5);
})
})
})
})
})
Your test scenario is not really sufficient to see the differences between these two operators. In your test case, each observable only emits 1 time. If an observable only emits a single value, there is really no different between concatMap and flatMap (aka mergeMap). The differences can only be seen when there are multiple emissions.
So, let's use a different scenario. Let's have a source$ observable that simply emits an incrementing integer every 1 second. Then, within our "Higher Order Mapping Operator" (concatMap & mergeMap), we will return an observable that emits a variable number of times every 1 second, then completes.
// emit number every second
const source$ = interval(1000).pipe(map(n => n+1));
// helper to return observable that emits the provided number of times
function inner$(max: number, description: string): Observable<string> {
return interval(1000).pipe(
map(n => `[${description}: inner source ${max}] ${n+1}/${max}`),
take(max),
);
}
Then let's define two separate observables based on the source$ and the inner$; one using concatMap and one using flatMap and observe the output.
const flatMap$ = source$.pipe(
flatMap(n => inner$(n, 'flatMap$'))
);
const concatMap$ = source$.pipe(
concatMap(n => inner$(n, 'concatMap$'))
);
Before looking the differences in the output, let's talk about what these operators have in common. They both:
subscribe to the observable returned by the passed in function
emit emissions from this "inner observable"
unsubscribe from the inner observable(s)
What's different, is how they create and manage inner subscriptions:
concatMap - only allows a single inner subscription at a time. As it receives emissions, it will only subscribe to one inner observable at a time. So it will initially subscribe to the observable created by "emission 1", and only after it completes, will it subscribe to the observable created by "emission 2". This is consistent with how the concat static method behaves.
flatMap (aka mergeMap) - allows many inner subscriptions. So, it will subscribe to the inner observables as new emissions are received. This means that emissions will not be in any particular order as it will emit whenever any of its inner observables emit. This is consistent with how the merge static method behaves (which is why I personally prefer the name "mergeMap").
Here's a StackBlitz that shows the output for the above observables concatMap$ and mergeMap$:
Hopefully, the above explanation helps to clear up your questions!
#1 - "use of flatMap should mix the outputs"
The reason this wasn't working as you expected was because only one emission was going through the flatMap, which means you only ever had a single "inner observable" emitting values. As demonstrated in the above example, once flatMap receives multiple emissions, it can have multiple inner observables that emit independently.
#2 - "...and include the code with multiple emitted events then things get messy."
The "things get messy" is due to having multiple inner subscription that emit values.
For the part you mention about using concatMap and still getting "mixed" output, I would not expect that. I have seen weird behavior in StackBlitz with observable emissions when "auto save" is enabled (seems like sometimes it doesn't completely refresh and old subscriptions seem to survive the auto refresh, which gives very messy console output). Maybe code sandbox has a similar problem.
#3 - "The reason I have gone to flatMap and concatMap was to find a replacement for nested subscriptions in angular using the http library"
This makes sense. You don't want to mess around with nested subscriptions, because there isn't a great way to guarantee the inner subscriptions will be cleaned up.
In most cases with http calls, I find that switchMap is the ideal choice because it will drop emissions from inner observables you no longer care about. Imagine you have a component that reads an id from a route param. It uses this id to make an http call to fetch data.
itemId$ = this.activeRoute.params.pipe(
map(params => params['id']),
distinctUntilChanged()
);
item$ = this.itemId$.pipe(
switchMap(id => http.get(`${serverUrl}/items/${id}`)),
map(response => response.data)
);
We want item$ to emit only the "current item" (corresponds to the id in the url). Say our UI has a button the user can click to navigate to the next item by id and your app finds itself with a click-happy user who keeps smashing that button, which changes the url param even faster than the http call can return the data.
If we chose mergeMap, we would end up with many inner observables that would emit the results of all of those http calls. At best, the screen will flicker as all those different calls come back. At worst (if the calls came back out of order) the UI would be left displaying data that isn't in sync with the id in the url :-(
If we chose concatMap, the user would be forced to wait for all the http calls to be completed in series, even though we only care about that most recent one.
But, with switchMap, whenever a new emission (itemId) is received, it will unsubscribe from the previous inner observable and subscribe to the new one. This means it will not ever emit the results from the old http calls that are no longer relevant. :-)
One thing to note is that since http observables only emit once, the choice between the various operators (switchMap, mergeMap, concatMap) may not seem to make a difference, since they all perform the "inner observable handling" for us. However, it's best to future-proof your code and choose the one that truly gives you the behavior you would want, should you start receiving more than a single emission.
Every time the first observable emits, a second observable is created in the flatMap and starts emitting. However, the value from the first observable is not passed along any further.
Every time that second observable emits, the next flatMap creates a third observable, and so on. Again, the original value coming into the flatMap is not passed along any further.
createObs1()
.pipe(
flatMap(() => createObs2()), // Merge this stream every time prev observable emits
flatMap(() => createObs3()), // Merge this stream every time prev observable emits
flatMap(() => createObs4()), // Merge this stream every time prev observable emits
flatMap(() => createObs5()), // Merge this stream every time prev observable emits
)
.subscribe((resp) => console.log(resp));
// OUTPUT:
// 5
So, it's only the values emitted from createObs5() that actually get emitted to the observer. The values emitted from the previous observables have just been triggering the creation of new observables.
If you were to use merge, then you would get what you may have been expecting:
createObs1()
.pipe(
merge(createObs2()),
merge(createObs3()),
merge(createObs4()),
merge(createObs5()),
)
.subscribe((resp) => console.log(resp));
// OUTPUT:
// 5
// 4
// 3
// 2
// 1
Is the takeUntil will manage the subscription of the mergeMap when destroyed$ is emitted in the following code? In other words, is the mergeMap leak a subscription?
combineLatest([
this.selectedCustomerId$.pipe(
-->mergeMap<--(customerId => invoicesService.getInvoices(customerId)
),
this.configuration$
]).pipe(
takeUntil(this.destroyed$)
).subscribe([invoices, configuration] => this.displayInvoices(invoices, configuration));
Thanks!
Yes, there will be no memory leakage.
To understand that you need to understand how pipe works -
Without calling subscribe - there is no subscriptions, doesn't matter what operators you have put it, what pipe does, is it creates a new observable, which, while subscribing to, subscribe to the source observable, and while unsubscribing, it unsubscribe to the source observable.
Even though you have two pipes here - the "un-subscription" will bubble up. i.e. when destroyed$ emits the combine latest subscription will end, than, each of the combineLatest parameters subscription will end, than response of the pipe in which you used the mergeMap will end, which means the return value of the mergeMap will end too.
I hope it wasn't too complicated of an explanation, the short version is that when using pipe everything is connected so when you unsubscribe it unsubscribes all sources.
Language: Typescript 3.5x
Environment: Angular 8.x, RxJS 6.x
I'm trying to figure out how to get rid of a chain of promises that looks (simplified) like this:
ClassA.methodA1 is called
-methodA1 does an if/then check and if true, calls ClassB.methodB1
--methodB1 calls a different function and combines the results with a parameter passed to it, and ultimately calls ClassC.methodC1
---methodC1 does some validation and then calls ClassD.methodD1 if valid
----methodD1 makes an async call (to a DB) and waits for it to finish before returning back the value it received (an ID).
When methodA1 receives the id, it calls ClassA.methodA2 and passes that Id in as a parameter
The method called by methodD1 is outside my control, and returns a Promise. I can't change that. However, I need methodA1 to wait until methodD1 is complete, and it receives the ID - each intervening method simply passes that return value back up to its caller.
Even this simplified version smells. NONE of the intervening methods (methodB1 or methodC1, and there are actually 2 more in the real code) need to be async. The only reason they are currently is that I need everything to wait until methodD1 finishes before continuing. Each intervening method simply returns the Promise returned from the method it calls.
I refactored with async/await and while there is less code, it is still a series of methods that simply pass the return value they receive from a method call back up the chain, and it's still a bunch of unnecessary async/await on the intervening methods.
I refactored to RxJS Subjects and having methodA1 subscribe and then methodD1 call .next(id) when it is complete but this doesn't really feel any better. I potentially have several dozen similar flows across my app and it feels like going the Subject route is a lot of extra plumbing overhead and keeping straight which subscription response belongs to which subscription instance is going to be problematic.
My gut tells me that the Subject route is the right approach, but I was wondering if there was something I was missing that makes it cleaner. Is there some built-in mechanism to tag subscription responses to a given subscription instance so that the subscription code only processes the response to ITS call and then unsubscribes?
The only other approach I can think of, which is just plain UGLY is to pass my ClassA instance all the way down to ClassD and have ClassD call methodA2 when it receives the id from the DB. But this is even worse.
Is there something I'm missing? If so, what? Any guidance or a pattern reference is appreciated.
The only other approach I can think of is to pass my ClassA instance all the way down to ClassD and have ClassD call methodA2 when it receives the id from the DB. But this is even worse.
That's essentially a callback (with an instance receiving a method call, instead of a plain function getting called), is generally considered worse than simply returning promises.
Notice there is nothing wrong with your original approach, if only component D does calls to the database (which are asynchronous) and all the other modules depend on D because they do things that use the database, then the other modules naturally become asynchronous as well. The async (promise-returning) call being in a tail position seems like a coincidence then, and might change if the components are going to do multiple db calls in sequence.
However, there is another approach that you missed. It is applicable when all of your functions just do some combination/translation/validation of parameters, and in the end pass them into a different method. Instead of having B call C itself, it could simply return the validated parameters to A, and then let A call C directly. This will make B and C completely synchronous and unit-testable, and only A calls the asynchronous method of D.
Thanks for the input. While the chain of promises is a legitimate approach, it just felt wonky, harder to test and reason about. YMMV.
I ended up going a slightly modified route with RxJS Subjects. The difference from what I had before is that the Subjects, instead of being permanent and hard-coded, are dynamically created as needed and stored in a Map. Once they are no longer needed, they are deleted. By giving each a distinct name, I don't need to verify which response "belongs" to which subscription - it is all keyed off of the distinct name as the key of the map.
The only thing I don't like about this approach is having to pass the distinct name all the way down the chain, but I can live with that. Everything flows in one direction - "down" the chain - which is easier for me to reason about.
Here is the psuedo-code version of what I ended up with (all error-checking and class instantiation removed for brevity):
export class ClassA {
methodA1(param1){
if(someCondition){
const theKey = this.generateUniqueKey();
DispatcherInstance.subjects.set(theKey, new Subject<number>());
const sub = DispatcherInstance.get(theKey).subscribe( (dbId: number) => {
sub.unsubscribe();
DispatcherInstance.subjects.delete(theKey);
this.doNextStepWithId(dbId);
}
classBInstance.methodB1(param1, theKey);
}
}
}
export class ClassB {
methodB1(param1, theKey): void {
const result = this.methodB2();
classCInstance.methodC1(param1, result, theKey);
}
}
export class ClassC {
methodC1(param1, result, theKey): void {
if(this.validate(param1, result)){
ClassDInstance.methodD1(param1, theKey);
}
}
}
export class ClassD {
methodD1(param1, theKey: string): void {
db.someFunc(param1).then( (dbId: number) => {
DispatcherInstance.subjects.get(theKey).next(dbId);
});
}
}
export class Dispatcher {
const subjects: Map<string, Subject<number>> = new Map<string, Subject<number>>()
}