Are global effects that listen to a large amount of actions a form of anti-pattern?

[bederuijter]

In our application, we use a global Effect to refresh a specific data slice. This Effect currently listens to a wide array of actions, as fresh data is required across multiple pages, but not all pages.

public fetchAll$ = createEffect(() => {
    return this.actions$.pipe(
      ofType(
          HomePage.enter,
          DashBoardWidget.render,
          FeaturePage1.enter,
          FeaturePage2.enter,
          FeaturePage2.retry,
          FeaturePage3.enter,
          FeaturePage4.enter,
          FeaturePage5.enter,
          FeaturePage6.enter,
		  ...
      ),
      switchMap(() =>
        this.getBooks().pipe(
          map((books) => BooksApiActions.fetchAllSuccess({ books })),
          catchError((error) =>
            of(BooksApiActions.fetchAllFailure({ error })),
          ),
        ),
      ),
    );
  });

The motivation behind this question is that we're in the process of migrating from a monolith to an Nx library structure and hit a roadblock with these global effects. The main problem is that the global Effect now requires imports from almost every feature library in our workspace, making it difficult to maintain clean library boundaries without circular dependencies.

We've explored several options to remedy the problem

• Using a 'global' action
• Local effects which re-emit a 'global' action that the global effect listens to.
• Duplicating the effect for each closely-group actions (or feature).

All of the above options feel (and most likely are) anti-pattern, which begs the question if our global effect is anti-pattern. So my question is: Is a single Effect listening to many actions considered an anti-pattern? And if so, what is the recommended way to trigger a shared data refresh?"

Thank you for your time 🙏

[adxdits]

Hello, for me (correct me if I am wrong) listening to many actions in a single Effect isn't an anti-pattern in NgRx, but it becomes an architectural problem in Nx when the Effect imports actions from every feature library, a different approach is to use @ngrx/router-store the Effect listens to ROUTER_NAVIGATION and filters by URL to decide if books need refreshing. This way the data-access library only depends on @ngrx/router-store, features don't dispatch anything extra, and no feature-level imports are needed at all