@dalehurwitz This buffering could be handled by dispatching actions and collecting them in another epic. No need to leave the pipeline and make a bunch of variables.
I'm trying to decipher your epic and can't understand what it's doing. There's no reason to ever call epic(action$, .... etc) in another epic. Just dispatch an action (that no reducer uses) and be done with it.
export default (action$, state$, { ajax }) => action$.pipe(
ofType(MY_ACTION),
concatMap((action) => {
return ajax.post(/api/...)
.pipe(
switchMap((payload) => {
return of(SUCCES_ACTION(payload));
}),
catchError(() => of(ERROR_ACTION)),
));
}),
);@bram_hautekiet_twitter That's a tough one. I've solved it a few different ways.
To transmit SUCCES_ACTION at the end of all these data calls, there are a few ways:
- Have the thing calling
dispatchfirst send the number of items, then start theMY_ACTIONlistener and count how many outputs you get. Make sure to account for any errors. - Set a
bufferUntilanddebounce. This is more complicated, but it's automatic; although, you might still need to mark the source of the data in your action. - There are other ways with
publish, but I don't want to get into those unless you really need it. I used this to find out when all downloads were complete when different components were outputting those downloads.
Since it's not obvious, here's the solution for the second option:
action$
.pipe(
ofType('MY_ACTION'),
bufferUntil(
action$
.pipe(
ofType('MY_ACTION'),
debounceTime(YOUR_TIMER_VALUE)
)
),
)
1 reply
@fisherspy Not being able to apply pipe to combineLatest sounds like an RxJS bug.
I think I remember Jay saying something about v2 not having ActionObservable anymore. But it looks like you're using it for TypeScript types right?
I don't use TypeScript, so I'm not sure nor have I moved to RxJS v7; although, there are definitely others here who have.
ofType, manually filtering on action.type etc, it all properly filters the correct action.. ..but I end up with the "..but unknown!!" errors
It seems like a lot of issues today are related to TypeScript, RxJS 7, and Redux-Observable 2.
I usually answer many of the questions here, but I'm not versed in any of the new stuff nor have I used TypeScript or any recent RxJS or Redux-Observable.
In the past, most questions revolved around "how do I do X in Redux-Observable" which are easy for me to answer. These ones require more knowledge of the technical side of things.
Has anyone gotten the new tech working in their projects?
Im trying to migrate to rxjs 7 and redux-observable v2. The simplest epics are easy to migrate, but I'm having trouble with race. For example this code:
const waitForGetStuffObservable = race<Stuff.ResponseAction | Stuff.ErrorAction>(
action$.ofType(StuffActionType.RCV_GET_STUFF).pipe(mapTo(Stuff.createResponseAction())),
action$
.ofType(StuffActionType.ERR_GET_STUFF)
.pipe(mapTo(Stuff.createErrorAction(createServiceError({}), q)))
).pipe(take(1))My own attempt is this:
const waitForStuffObservable = race(
pipe(ofType(StuffType.RCV_GET_STUFF), mapTo(Stuff.createResponseAction())),
pipe(ofType(StuffType.ERR_GET_STUFF), mapTo(Stuff.createErrorAction(createServiceError({}), q)))
).pipe(take(1))But I just get an error that UnaryFunction is not assignable to ObservableInput. Any idea how to fix this?
1 reply
Hi everybody, does anyone know why the console.log() is not being printed on the console?
I am new to redux-observable and I am trying to understand how it does work.
Does it have to be with an action that is not being called, If so, how could I call that action in order to execute this console.log()?
Thanks for your help!!
const getEpic$: Epic<SetOptions, SetOptions, RootState> = (action$, state$) =>
action$.pipe(
ofType(setOption.type),
withLatestFrom(state$),
switchMap(([action, state]) => {
console.log('why is not getting into here?', { action, state });
})
);
@ChristherNand
Epics are functions that return observables, not observables themselves. Put a tap(console.log) before ofType(setOption.type). That will help debug if you're seeing any actions. If you are, then move it down a step until it stops firing.
That should help you debug.
hi, question about the Epic signature, for TS code.
the signature is:
export declare interface Epic<
Input extends Action = any,
Output extends Input = Input,
State = any,
Dependencies = any
> {and I am force to have the Output action to derived from Input action.
why is that?
why do I limited to it?
@Sawtaytoes Hi, log worked before
ofType(), but it did not after
@ChristherNand I'd check 2 things. In Redux Devtools, make sure the action is getting dispatched. If not, then that's step 1. If it is getting dispatched, make sure the value passed to ofType is correct.
Most-likely, your value isn't getting dispatched because you've got something preventing it from being dispatched. Can you share the code where you're dispatching it?
Hi, this might be a stupid question, but having trouble implementing a debounce search function using redux-observable.
My current setup is something like this every time the query changed it will dispatch an action, the action will be piped down an epic like follow. Note that the search(action.payload.query) is an action creator
export const onSearchChangedEpic: Epic<AllActions> = (action$) =>
action$.pipe(
filter(isOfType("QUERYCHANGED")),
debounce((action) => {
// Dispatch an action immediately if the query is empty.
if (action.payload.query.length === 0) {
return EMPTY;
}
return timer(500);
}),
map((action) => {
if (action.payload.query.length === 0) {
// Clear search results.
return resetResults();
}
return search(action.payload.query);
})
);The expected result is when I stop typing for a period (500 ms) a search() action will be piped, but what happen is the debounce timer will always reset when i type. So if I type 5 character, it will debounce for 5 time (2500 ms) before piping out a search result
Is there anything i can do to get the expected behaviour? ( when I stop typing for a period (500 ms) a search() action will be piped)
1 reply
QueueScheduler usage in redux-observable@2 with rxjsw@7. We do some heavy subject usage in our codebase (some ReplaySubject(1) in deps, among others), although we avoid at maximum explicit subscribes and try to leave everything for the global subscription. Nonetheless, it seems QueueActions are pilling up and clogging memory heavily. We checked and it seems subscriptions are not leaking (all subjects's observers, including internal redux-observables subjects, are constant in number), but QueueAction, and observeOn's OperatorSubscribers instances makes our memory usage skyrocket, and these actions are not freed. Most of it seems to be references in _teardowns. Removing queueScheduler usage on redux-observable makes the problem disappear, but it may be triggered by something we do. Does anyone have experience with this kind of issue? If not, I may try to prepare a self-contained repro to open an issue
