NgRx 사용 사례, 파트 III: 의사결정

Hansjörg Keller가 Unsplash에 게시한 원본 표지 사진.

이전 기사에서는 NgRx를 사용한 액세스 제한 및 처리 목록을 다루었습니다. 오늘 우리는 주로 NgRx 효과(그러나 약간의 리듀서 및 선택기도 포함)를 활용하는 Angular 앱 전반에 걸친 의사 결정의 보다 일반적인 문제를 다룰 것입니다. 이 기사에서는 다음 주제를 다룰 것입니다:

• NgRx 오류 처리
• 리디렉션 처리
• 데이터 로딩 처리
• 사용자 상호작용

시작해 보세요!

NgRx를 사용한 오류 처리

오류 처리는 모두가 싫어하는 일이지만(종종 잊어버리는 경우도 있음) 모든 사람에게 정말 꼭 필요한 일이기도 합니다. NgRx 앱을 사용하면 적절한 주의를 기울여 이 문제를 해결하지 않으면 오류 처리의 복잡성이 실제로 증가합니다. 일반적으로 NgRx의 오류는 대부분의 시나리오에서 HTTP 요청으로 인해 발생하는 영향으로 인해 발생합니다.

일반적으로 오류를 처리하는 방법에는 로컬 처리 또는 전역 처리라는 두 가지 접근 방식이 있습니다. 로컬에서 처리한다는 것은 앱의 특정 부분에서 발생한 매우 구체적인 오류를 실제로 해결한다는 의미입니다. 예를 들어, 사용자가 로그인에 실패한 경우 "문제가 발생했습니다"와 같은 일반적인 오류 메시지 대신 "잘못된 사용자 이름 또는 비밀번호"와 같은 매우 구체적인 오류 메시지를 표시할 수 있습니다.

반면에 전역적으로 처리한다는 것은 모든 오류를 하나의 "파이프라인"으로 묶고 이전에 언급한 매우 일반적인 오류 메시지를 사용한다는 의미입니다. 물론 어떤 아이디어가 어떤 시나리오에 더 적합한지에 대한 논의를 시작할 수도 있지만, 가혹한 현실은 거의 모든 앱에 두 가지 세계가 모두 필요하다는 것입니다. 우리는 어떤 오류가 발생하면 오류 메시지를 표시하기를 원합니다("무언가 잘못되었습니다"는 조용한 실패보다 낫습니다). 🎜>몇 가지 오류가 발생했습니다. 두 가지 시나리오를 모두 살펴보겠습니다.

NgRx를 사용한 일반 오류 처리

NgRx에서는 일어나는 모든 일이 행동에 의해 촉발됩니다. 오류 발생과 관련된 활동(HTTP 호출, WebSocket 등)의 경우 일반적으로 단일 활동에 대해 여러 작업을 생성합니다.

export const DataActions = createActionGroup({
  source: 'Data',
  events: {
    'Load Data': emptyProps(),
    'Load Data Success': props<{ data: Data }>(),
    'Load Data Error': props<{ error: string }>(),
  },
});

보시다시피 API에서 데이터 일부를 로드하기 위해서만 세 가지 작업이 필요합니다. 특정 애플리케이션에는 "오류" 및 "성공" 작업과 같은 "오류" 및 "성공" 작업이 수백 개는 아니더라도 수십 개 있을 수 있으므로 이러한 작업 중 하나라도 전달되는 경우 일반 오류 메시지를 표시할 수 있습니다. 오류 작업의 페이로드를 표준화하면 이를 수행할 수 있습니다. 예를 들어, 오류를 나타내는 모든 작업에 매우 구체적인 속성을 추가할 수 있습니다. 우리의 경우 액션 페이로드에 error 속성이 있으면 해당 액션이 오류를 나타낸다는 것을 충분히 알 수 있습니다.

그러면 오류를 나타내고 일반 오류 메시지를 표시하는 모든 작업을 구독할 수 있습니다. 이는 NgRx 앱에서 매우 일반적인 패턴이며 일반적으로 "전역 오류 처리"로 이해됩니다. 우리의 경우 모든 작업을 구독하고 페이로드에 오류 속성이 있는 작업을 필터링하여 이를 수행할 수 있습니다.

export const handleErrors$ = createEffect(() => {
  const actions$ = inject(Actions);
  const notificationsService = inject(NotificationsService);
  return actions$.pipe(
    filter((action) => !!action.payload.error),
    tap((action) => {
      notificationsService.add({
        severity: 'error',
        summary: 'Error',
        detail,
      });
    }),
}, { functional: true, dispatch: false });

이 경우 당사가 전달하는 모든 "오류" 작업으로 인해 동일한 알림이 표시되지만 맞춤 메시지도 함께 표시됩니다. 오류에 대해 액션 소품이 생성되는 접근 방식을 표준화함으로써 좀 더 나아갈 수 있습니다. 다음은 유용할 수 있는 작은 도우미 기능입니다.

export function errorProps(error: string) {
  return function() {
    return({error});
  };
}

이제 이 함수를 사용하여 작업에 대한 오류 소품을 만들 수 있습니다.

export const DataActions = createActionGroup({
  source: 'Data',
  events: {
    'Load Data': emptyProps(),
    'Load Data Success': props<{ data: Data }>(),
    'Load Data Error': errorProps('Failed to load data'),
  },
});

이렇게 하면 오타나 혼란을 피하기 위해 모든 오류가 동일하게 표시됩니다. 다음으로, 매우 특정한 오류도 처리할 수 있도록 이를 개선해 보겠습니다.

특정 오류 처리

우리의 경우에는 일부 특정 사례에 대해 일반 오류 처리기가 작동하는 방식을 사용자 정의할 수 있기를 원할 수 있습니다. 우리는 할 수 있기를 원합니다

일반 오류 메시지를 표시할지 여부를 효과에 알리기 위해
일부 사전 정의된 데이터가 포함된 오류 페이지로 리디렉션
페이지 내부에 오류 알림 표시

첫 번째부터 시작해 보겠습니다. 오류 작업 페이로드에 새 속성을 추가하면 이를 수행할 수 있습니다.

export function errorProps(error: string, showNotififcation = true) {
    return function() {
        return({error, showNotification});
    };
}

이제 나중에 일반 알림 메시지를 건너뛰도록 효과에 지시하는 작업을 만들 수 있습니다.

export const DataActions = createActionGroup({
  source: 'Data',
  events: {
    'Load Data': emptyProps(),
    'Load Data Success': props<{ data: Data }>(),
    'Load Data Error': errorProps('Failed to load data', false),
  },
});

다음으로 이를 반영하도록 효과를 업데이트해야 합니다.

export const handleErrors$ = createEffect(() => {
  const actions$ = inject(Actions);
  const notificationsService = inject(NotificationsService);
  return actions$.pipe(
    filter((action) => !!action.payload.error),
    tap((action) => {
      if (action.payload.showNotification) {
        notificationsService.add({
          severity: 'error',
          summary: 'Error',
          detail,
        });
      }
    }),
  );
}, { functional: true, dispatch: false });

필터 연산자에 showNotification 속성 검사를 추가하지 않았습니다. 이는 알림을 표시해서는 안 되지만 다른 작업(예: 오류 페이지로 리디렉션)을 수행해야 하는 시나리오가 있기 때문입니다. 오류 작업에 새 매개변수를 추가하여 이를 정확하게 수행해 보겠습니다.

export function errorProps(error: string, showNotification = true, redirectTo?: string) {
  return function() {
    return({error, showNotification, redirectTo});
  };
}

이제 나중에 오류 페이지로 리디렉션하도록 효과를 지시하는 작업을 만들 수 있습니다.

export const DataActions = createActionGroup({
  source: 'Data',
  events: {
    'Load Data': emptyProps(),
    'Load Data Success': props<{ data: Data }>(),
    'Load Data Error': errorProps('Failed to load data', false, '/error'),
  },
});

Next, let's finalize our effect by adding a redirection to the error page if the redirectTo property is present in the action payload:

export const handleErrors$ = createEffect(() => {
  const actions$ = inject(Actions);
  const notificationsService = inject(NotificationsService);
  const router = inject(Router);
  return actions$.pipe(
    filter((action) => !!action.payload.error),
    tap((action) => {
      if (action.payload.showNotification) {
        notificationsService.add({
          severity: 'error',
          summary: 'Error',
          detail,
        });
      }
      if (action.payload.redirectTo) {
        router.navigateByUrl(action.payload.redirectTo);
      }
    }),
  );
}, { functional: true, dispatch: false });

And that is it to this. Of course, if we need something really custom for a particular error action, we can just write a completely separate effect to handle that. Sometimes, if we want to also do something in the UI in relation to an error, we can also add the error message (and any other data) to the store and use them via a selector anywhere.

Next, let us discuss loading data into our component, and several approaches to it.

Handling loading data

Before we proceed, we should first understand that the approaches listed in this section are not better or worse than one another. Instead, they are approaches for different situations, depending on what we want for our UX. Let's examine them step by step.

Selecting data in the component to use

The most straightforward way we can get some data (presumably from an API) is by just selecting it in the component. With the latest APIs, we can select a signal of our data and use it directly in the template. Here is a very simple example:

@Component({
  selector: 'app-my',
  template: `
    <div>
      <h1>Data</h1>
      <p>{{ data() }}</p>
    </div>
  `,
})
export class MyComponent {
  data = this.store.selectSignal(dataFeature.selectData);
}

Of course, in real life, we often need to deal with scenarios like loading, errors, and so on. In this case, our state might look like this:

export interface State {
  data: Data | null;
  loading: boolean;
  error: string | null;
}

If we are using the createFeature function to register our state, we can make use of the selectDataState function that the feature automatically creates for us. This will return the entire state with loading, error, and data properties. We can then use this in our component:

@Component({
  selector: 'app-my',
  template: `
    <div>
    @if (vm().loading) {
      <p>Loading...</p>
    }
    @if (vm().error) {
      <p>Error: {{ vm().error }}</p>
    } @else {
      <h1>Data</h1>
      <p>{{ vm().data }}</p>
    }
    </div>
  `,
})
export class MyComponent {
  vm = this.store.selectSignal(dataFeature.selectDataState);
}

This is very useful in most scenarios. However, sometimes we might not want to display the entire page if this important piece of data is not loaded. In Angular, this is commonly achieved with the use of routing resolvers, functions that return some Observables that routing waits for to emit before displaying a particular page. This is easy with the use of the HttpClient service, however, this becomes a bit complicated with NgRx (because we only make HTTP calls inside effects), resulting in lots of developers skipping resolvers entirely. However, there is an easy way to achieve this functionality. Let's build a simple resolver that utiliuzes the Store and the Actions Observable to know when the data is actually loaded:

export const dataResolver: ResolveFn<Data[]> = () => {  
  const store = inject(Store);
  const actions$ = inject(Actions);
  store.dispatch(DataActions.loadData());
  return store.select(dataFeature.selectData).pipe(
    skipUntil(actions.pipe(ofType(DataActions.loadDataSuccess))),
  );
}

Here, we first dispatch the action that actually initiates the HTTP call, then we just return the selected data from the store as an Observable, but with a catch - we tell it to wait until the action signaling that the data has been loaded is dispatched. Given that effects are guaranteed to run after reducers, this will ensure that the data is actually put into the store before the resolver returns it. We can then just pick this data up in our component:

@Component({
  selector: 'app-my',
  template: `
    <div>
      <h1>Data</h1>
      <p>{{ vm.data() }}</p>
    </div>
  `,
})
export class MyComponent {
  private readonly route = inject(ActivatedRoute);
  readonly vm = toSignal(this.route.data, {
    initialValue: null,
  }) as Signal<{data: Data}>;
}

We used ActivatedRoute instead of the Store because we already returned this data in the resolver. This makes our components even leaner - we don't even have to inject the Store and in unit testing, it can be often easier to mock the ActivatedRoute than the Store.

Finally, let's take a look at advanced decision-making with NgRx actions and effects, and see how this can help work with complex cases in large applications.

User interactions

NgRx is very useful when writing declarative code, as it allows us to just select the relevant state, and use it in our templates. However, sometimes, especially when dealing with third-party libraries, we need to perform some "imperative actions" which is tangentially related to our store. Consider this code which uses the Angular Material MatDialog service to open a confirmation dialog:

export class MyComponent {
  private readonly dialog = inject(MatDialog);
  private readonly store = inject(Store);

  openConfirmationDialog() {
    const dialogRef = this.dialog.open(ConfirmationDialogComponent, {
      data: {
        title: 'Confirmation',
        message: 'Are you sure you want to do this?',
      },
    });

    dialogRef.componentInstance.confirm.subscribe(() => {
      this.store.dispatch(DataActions.deleteData());
    });

    dialogRef.componentInstance.cancel.subscribe(() => {
      dialogRef.close();
    });
  }
}

As we can see, there is a lot of imperative code in just this one method, there are two subscriptions, and they aren't even particularly simple (we just omitted unsubscription logic). Also, we must consider that in a normal application, we might have a dozen different places where the same confirmation dialog is used, with the only difference being the action that is performed when the user confirms/rejects.

Let's now approach this with an NgRx mindset, and try to create an action that can handle such a scenario, with callbacks as payloads.

export function confirmAction(callbacks: {confirm: () => void, reject: () => void}) {
  return function() {
    return({type: 'Open Confirmation Dialog', callbacks});
  };
}

Now, we can create an action that will later tell the effect to redirect to an error page:

export const DataActions = createActionGroup({
  source: 'Data',
  events: {
    'Delete Data': confirmAction({
      confirm: () => {
        return({action: 'Delete Data Confirmed'});
      },
      reject: () => {
        return({action: 'Delete Data Rejected'});
      },
    }),
  },
});

Now, we can create an effect that will handle all such actions:

export const handleConfirmationDialog$ = createEffect(() => {
  const actions$ = inject(Actions);
  const dialog = inject(MatDialog);
  return actions$.pipe(
    ofType(DataActions.openConfirmationDialog),
    tap((action) => {
      const dialogRef = dialog.open(ConfirmationDialogComponent, {
        data: {
          title: 'Confirmation',
          message: 'Are you sure you want to do this?',
        },
      });

      dialogRef.componentInstance.confirm.subscribe(() => {
        action.payload.callbacks.confirm();
      });

      dialogRef.componentInstance.cancel.subscribe(() => {
        action.payload.callbacks.reject();
      });
    }),
  );
}, { functional: true, dispatch: false });

Finally, we can really simplify our component:

export class MyComponent {
  private readonly store = inject(Store);

  openConfirmationDialog() {
    this.store.dispatch(DataActions.openConfirmationDialog({
      confirm: () => {
        this.store.dispatch(DataActions.deleteData());
      },
      reject: () => {
        // Do nothing
      },
    }));
  }
}

And that is it. However... we might face a problem if we try to make our application as fine as possible. In NgRx, it is a good practice to keep everything serializable, which is a fancy way of saying "easily convertible to JSON". In the app configuration, it is possible to set specific options to help safeguard us from, for example, putting functions in the store. This is done with two options, strictStoreSerializability and strictActionSerializability.

export const config: ApplicationConfig = {
  providers: [
    provideStore({}, {
      runtimeChecks: {
        strictActionSerializability: true,
        strictStoreSerializability: true,
      },
    }),
};

This goes a long mile to help keep our applications maintainable and prevent hard-to-debug issues.

[!NOTE] You can read more about runtime checks in the NgRx docs.

However, if we make actions strictly serializable, our confirmAction action will not work with the callbacks we passed! So, what can we do about it? Well, the easiest way is to give it other actions for confirm/reject options to handle by the effect. Because the nested actions will also be required to be serializable, this will help us bring everything back to a workable state, an approach that I personally call "higher-order actions".

export function confirmAction(confirmAction: string, rejectAction: string, callbackActions: {
  confirm: ActionCreator<any, any>,
  reject: ActionCreator<any, any>
}) {
  return function() {
    return({type: 'Open Confirmation Dialog', callbackActions});
  };
}

Next, we need to do a major update to our effect:

export const handleConfirmationDialog$ = createEffect(() => {
  const actions$ = inject(Actions);
  const dialog = inject(MatDialog);
  return actions$.pipe(
    ofType(DataActions.openConfirmationDialog),
    map(({callbackActions}) => {
      const dialogRef = dialog.open(ConfirmationDialogComponent, {
        data: {
          title: 'Confirmation',
          message: 'Are you sure you want to do this?',
        },
      });

      return merge([
        dialogRef.componentInstance.confirm.pipe(
          map(() => callbackActions.confirm()),
        ),
        dialogRef.componentInstance.cancel.pipe(
          tap(() => dialogRef.close()),
          map(() => callbackActions.reject()),
        ),
      ])
    }),
  );
}, { functional: true, dispatch: false });

Let's deconstruct what goes on here.

1. The ConfirmationDialogComponent exposes the confirm and cancel observables.
2. We open a MatDialog with the ConfirmationDialogComponent and every time an action created by the confirmAction is dispatched, we subscribe to the confirm observable and dispatch the action that was passed to the confirmAction function.
3. We also subscribe to the cancel observable and dispatch the action that was passed to the confirmAction function.
4. We return a merge of the two observables so that when either of them emits, the whole effect will emit.

With this implementation, it is easy to perform complex decision-making just using several actions in a component:

export class MyComponent {
  private readonly store = inject(Store);

  openConfirmationDialog() {
    this.store.dispatch(DataActions.openConfirmationDialog({
      confirm: DataActions.deleteData,
      reject: DataActions.cancelDeleteData,
    }));
  }
}

And that is it. With higher-order actions, we can easily delegate decision-making further to other effects and reducers as necessary, making the component code as declarative as possible.

Conclusion

In this article, we covered a few approaches to complex logic in Angular applications utilizing NgRx. NgRx is a huge tapestry of opportunities, and often we can easily transform ugly code into something understandable and maintainable. Such approaches are underappreciated, and with this piece, I try to bring them forth to help developers improve their state management solutions.

위 내용은 NgRx 사용 사례, 파트 III: 의사결정의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!