저는 약 1 년 동안 각도 2/4를 사용 해왔고, 서비스에 라우터를 주입하는 것이 나쁜 습관으로 간주 될 수 있는지 계속해서이 딜레마로 되돌아갑니다.각도 4의 서비스에서 라우터 사용
이것은 아키텍처적인 질문입니다. 나는 정확한 답이 없다고 생각하지만, 당신의 의견을 듣고 싶습니다. 그래서 여기에 2 가지 예가 있습니다.
- 다음 코드를 고려하십시오. 일부 구성 요소가 있다고 가정하고 일부 작업 (예 : 특정 작업) 후에 사용자를 특정 경로로 리디렉션하려고합니다. 사용자가 새 엔티티를 추가하고 그리드로 다시 리디렉션하려고합니다.
component.ts
constructor(private router: Router) {}
someAction() {
// Some code here
this.router.navigate(['/grid']);
}
여기에 내가 라우터 및 구성 요소가 모두 UI 계층입니다 있기 때문에, 라우터를 사용하여 완벽하게 정상적으로 생각합니다.
- 이제 우리는
auth.service.ts
이 있다고 가정 해 인증을 담당합니다. 우리는 응용 프로그램에서 사용자를 로그 아웃 할 수 있기를 원하며 우리는 이것을 수행하는 기능이logout()
입니다. 그래서 구조적으로 생각
auth.service.ts
constructor(private router: Router) {}
logout() {
// Cleanup token, storage, etc.
this.router.navigate(['/login']);
}
:이 서비스 내에서 같은 라우터 사용에 대해 어떻게 생각하십니까
- ?
- 유효한 접근 방식이라고 생각하십니까?
- 이 경우 무엇을 제안하지 않습니까?
나는 authService
에 eventEmitter
퍼팅에 대해 생각하고 app.component.ts 예를 들어 내부에 그것을에 가입하지만, 여전히이 서비스를하는 것보다 낫다 확실하지 않았다.
이 사례에 대한 의견을 보내 주시면 감사하겠습니다. 고마워요!
EDIT
다른 예 : UI 태스크와 일정하다.
모든 데이터 흐름을 처리하고 캘린더에 대한 데이터를 제공하는 서비스가 있습니다. 캘린더 자체는 데이터를 요구하지 않고 대신 서비스의 데이터 변경 내용을 구독합니다.
이제 사용자를이 캘린더의 다른 화면으로 라우트해야합니다. 다음 주/월/년 사용자 클릭 수를 상상해보십시오.
이 데이터는 경로 URL에 저장되므로 사용자는 페이지 새로 고침 후 같은 날에 머무를 수 있지만 캘린더 구성 요소는 일/주/월을 알 수 없습니다.
서비스 내부에 봉입되어 있습니다. 이 경우 서비스중인 라우터를 사용 하시겠습니까?
마지막 사례와 관련하여 사용자가 일정 세부 정보에 액세스하거나 캘린더에서 탐색하는 방법은 무엇입니까? 내 경우에있어서 상호 작용에 대해 묻는 것은 – Sonicd300
입니다. 그는 그 날을 클릭하고 오늘에 대한 구체적인 분석을 원합니다. 컴포넌트 내에서 나는 내 서비스에서'fetchDay()'를 호출한다. 그래서 기본적으로 데이터 가져 오기 서비스를 요청하지만 동시에 사용자를 다음 화면으로 리디렉션해야하지만 경로를 계산하려면 서비스에서 캡슐화되지 않은 데이터가 필요합니다. –
구독 내에서 작업 할 수 있습니까? fetchDay()에서 이야기는 데이터를 가져 오기 위해 서비스를 호출하는 구성 요소에 초기화 논리가있는 달력을 렌더링하는 페이지입니다. 데이터가 성공적으로 처리되면 구성 요소에서 항상 라우팅 할 수 있습니다. 달력. – Sonicd300