Angular ngrx - 避免使用沙盒模式进行嵌套订阅

Question

I need to understand if I'm approaching good to ngrx and sandbox pattern...This is my doubt: I have a sandbox file with some functions, example:

getFiles(userId: number, companyId: number) {
  this.fileService.getFiles(userId, companyId).subscribe(res => this.store.dispatch(myaction({files: res})))
}

In this function I need to call a service and manage the success with an action dispatch.

In my container I need to use two selectors for finding userId (userId$) and companyId (company$): the parameters that I need for calling the sandbox function; so in the ngOnInit of my container-component I do this:

combineLatest([this.company$, this.userId$])
  .pipe(
    filter(res => res[0] !== null && res[1] !== null),
    take(1),
    map(res => {
      let companyId = res[0].id;
      let userId = res[1];
      this.sandbox.getfiles(companyId, userId);
    })
   
  )
  .subscribe();

Is this a correct way or are these nested subscriptions? When i call the sandbox function I do the subscription inside the function declaration...I can't find a real solution for avoid this...I need to subscribe to the selectors for finding the parameters that I need and then invoke the sandbox function. Which is the correct approach?

Answer 1

You just moved the nested subscription to a separate method. What if you have one more? You don't really solve the problem but just move it.

In the example you gave, you can use a flattening operator in a combination with tap .

In your case:

sandbox.service.ts

getFiles(userId: number, companyId: number) {
  return this.fileService.getFiles(userId, companyId).pipe(
    tap(res => this.store.dispatch(myaction({files: res}))
  )
}

some.container.ts

combineLatest([this.company$, this.userId$])
  .pipe(
    filter(res => res[0] !== null && res[1] !== null),
    take(1),
    switchMap(res => {
      let companyId = res[0].id;
      let userId = res[1];
      return this.sandbox.getFiles(userId, companyId);
    })
   
  )
  .subscribe();

Then you would have to manage only 1 subscription. You can read up more about the flattening operators ( switchMap , mergeMap , concatMap , etc.) here .

PS. As suggested by @gunnar-b you should look into effects and how to use them since it looks like you are not fully utilizng ngrx.

Answer 2

I would say it's almost never best practice to manage a subscription in your code in an NGRX app. The subscription can cause a memory leak if your code fails to clean it up correctly when it goes out of scope (for example, when the component that created it gets destroyed).

In a typical app, Observables should be consumed safely in one of two ways:

1. Components can use the async pipe to render the output from an Observable
2. @ngrx/effects can be used to handle side effects resulting from an action

#1 The async pipe

A component can create an Observable field and set it up on onInit:

public titleUppercase$: Observable<string>

ngOnInit(): void {
    this.titleUppercase$ = this.store.pipe(select(titleSelector)).map(title => title.toUpperCase());
}

<p>{{titleUppercase$ | async}}</p>

In this setup, Angular manages the subscription for you automatically, so there is no risk of a memory leak.

If the pipe logic is complex (for example, using multiple observables with combineLatest ), it's a good idea to extract this logic to a Service class for testability.

#2 @ngrx/effects

Effects are for managing "side effects"... ie, asynchronous processes that do something other than make changes to the state of your Store. An HttpClient call to get data from the server is an example of a side effect.

Check out the user guide for the @ngrx/effects library here:

https://ngrx.io/guide/effects

Here is an example of an effect which loads data from the server in response to a user's action:

  loadServerData$ = createEffect(() => this.actions$.pipe(
    // I dispatch an action with this type in the onInit method of my view component
    ofType('[My Data Page] User loaded the page'),
    // each time we see this page load action, trigger a service call to get the HTTP data
    switchMap(() => this.myApiService.getData$().pipe(
      map(data => {
        //the response is mapped to an action called myDataLoaded
        //myDataLoaded includes the response payload as a property
        return myDataLoaded({payload: data});
      }),
      //this catchError within the switchMap is necessary to prevent the effect from
      //halting if there is an error from the HTTP call
      catchError(err => {
        // TODO: notify users when there's an error
        console.error('Error loading the page data', err);
        return NEVER;
      }),
      //using startsWith inside the switchMap, I can trigger a loading action
      //the loading action can be used to display a loading indicator on the page
      startWith(myDataLoading())
    ))
  ));

With this approach, your app components can simply observe state to render themselves and dispatch actions when the user does something. All other complex business logic that happens in the background can be handled using the reducer functions and effects. This makes your UI application very easy to unit test.

If all of your effects have very similar needs and you want to use a sandbox pattern, you might introduce a common injectable dependency or base class that can be leveraged by all of your effects. You could also have a library of common actions that components can dispatch, or even an injectable service that provides sandbox functionality to components with methods for dispatching actions and setting up selector Observables.