B. const loadData$ = createEffect(() => this.actions$.pipe(ofType(load), switchMap(() => fetchData())));
C. const loadData$ = createEffect(this.actions$.pipe(ofType(load), switchMap(() => fetchData())));
D. const loadData$ = createEffect(() => this.actions$.pipe(ofType(load), map(() => fetchData())));
Solution
Step 1: Check the syntax of createEffect
The createEffect function expects a function returning an observable, so it should be () => this.actions$.pipe(...).
Step 2: Verify operators used
Using switchMap is correct for side effects that return new observables. const loadData$ = createEffect(() => this.actions$.pipe(ofType(load), switchMap(() => fetchData()))); uses this correctly.
A. The catchError operator should return an observable
B. The switchMap should not use action parameter
C. The map operator must return the original action
D. The effect should not use createEffect function
Solution
Step 1: Check catchError usage
The catchError operator must return an observable, but here it returns an action object directly.
Step 2: Correct catchError return
Wrapping the action in of() makes it an observable, fixing the error.
Final Answer:
The catchError operator should return an observable -> Option A
Quick Check:
catchError must return observable [OK]
Hint: Always wrap catchError return in of() to return observable [OK]
Common Mistakes:
Returning plain object instead of observable in catchError
Misusing switchMap parameters
Thinking map must return original action
5. You want to create an effect that listens for login actions, calls an API to authenticate, and then dispatches either loginSuccess or loginFailure. Additionally, you want to log every login attempt regardless of success or failure. Which approach correctly implements this using Angular Effects?
hard
A. Use two separate effects: one for API call with dispatch, another for logging with dispatch: false
B. Use one effect with switchMap for API call and tap for logging inside the same pipe
C. Use one effect with map for API call and catchError for logging
D. Use one effect with filter to block logging and API call
Solution
Step 1: Separate concerns for side effects
Logging is a side effect that does not dispatch actions, so it should be in a separate effect with dispatch: false.
Step 2: API call effect dispatches success or failure
The main effect handles the API call and dispatches loginSuccess or loginFailure accordingly.
Step 3: Final design
Two effects keep code clean and responsibilities clear: one for API calls with dispatch, one for logging without dispatch.
Final Answer:
Use two separate effects: one for API call with dispatch, another for logging with dispatch: false -> Option A
Quick Check:
Separate effects for dispatching and logging [OK]
Hint: Use separate effects for dispatching and non-dispatching tasks [OK]
Common Mistakes:
Combining logging and dispatching in one effect incorrectly