엔터프라이즈급 프로젝트 구조 구축

현대 전단 프로젝트를 구축하는 중요한 임무는 확장 가능하고 장기적이며 미래의 시련을 이겨낼 수 있는 폴더 구조와 각기 다른 프로그래밍 실체의 명칭 준칙을 정의하는 것이다.
어떤 사람들은 이것이 간단한 부차적인 방면이라고 생각한다 — 그것은 종종 보기보다 더 복잡한 것을 숨기고 있다.대부분의 경우 완벽한 해결 방안이 없지만 — 우리는 업계의 최상의 실천과 나의 경험에 근거하여 가장 의미 있는 일들을 탐색할 수 있다.
이 문서에서는 다음을 설명합니다.

스택의 각 단계에서 정의하여 프로젝트의 실체를 구성한다

폴더에 각도 및 유형 스크립트 엔티티 배포

서비스 모듈 집합의 상태 관리

각형 솔리드

새 코드 라이브러리를 설정할 때, 내가 자주 하는 첫 번째 일은 창고를 구성하는 프로그래밍 실체를 생각하고 정의하는 것이다.Angular 개발자로서 우리는 이미 그 중 일부를 잘 알고 있다.

모듈, 구성 요소, 명령, 서비스, 파이프와 보호 장치

프레임 문서에서 제안한 바와 같이, 우리가 이 실체들 중 하나를 만들 때마다, 우리는 파일 이름 뒤에 실체의 이름을 붙인다.
그래서 — HighlightPipe라는 클래스의 파이핑을 만들면 해당 파일의 이름이 Highlight입니다.담뱃대.ts, 만약 Dropdown Component라는 구성 요소가 있다면, 파일을 아래로 당기기를 원합니다.구성 요소ts, 드롭다운 목록.구성 요소html 및 드롭다운 목록.구성 요소scss.

기능 모듈

각도 모듈을 먼저 논의하지 않으면 각도 프로젝트의 구조를 논의할 수 없다.
Angular 응용 프로그램은 다른 모듈을 가져올 수 있는 모듈로 구성되어 있기 때문에 Angular 프로젝트를 구성하는 루트 폴더가 됩니다.각 모듈에는 해당 폴더에 포함된 다른 각도 엔티티가 모두 포함됩니다.
만약에 우리가 전자상거래 응용 프로그램을 구축하고 있다고 가정하면 우리는 쇼핑 카트 기능 모듈을 만들었는데 그 구조는 다음과 같다.

💡As you may notice, I tend to differentiate between containers (smart) and components (dumb) so I place them in different folders, but it’s not something I necessarily advocate

기능 모듈은 상부 구성 요소를 제외한 어떤 내용도 내보내서는 안 되기 때문에 우리가 정의한 어떤 내용도 다른 곳에서 사용하지 않습니다.

공유 모듈

하지만 어떤 물건을 다른 곳에서 중복 사용해야 한다면?
이 예에서 공유 모듈인 Shared Module을 만들었습니다. 공유 실체는 프로젝트의 모든 모듈에 제공됩니다.
SharedModule은 일반적으로 프로젝트의 다른 모듈 간에 공유되는 실체로 구성된다 — 하지만 그 외에는 필요 없다.우리가 서로 다른 팀과 프로젝트를 뛰어넘어 다시 사용할 수 있는 서비스나 구성 요소를 만났을 때 이상적인 상황에서 자주 바뀌지 않기 때문에 각도 라이브러리를 구축해야 할 수도 있다.

💡For a detailed overview of all the different module types, you can check that out on Angular’s official website.

도서관, Monorepos 및 마이크로 프런트엔드

고도로 다시 사용할 수 있는 서비스나 구성 요소 (서비스 모듈과 작은 위젯 모듈로 나눌 수 있음) 를 사용할 때, 이 모듈을 각도 라이브러리로 구축하기를 원할 수도 있고, 자신의 저장소에서 만들 수도 있고, 더 큰 monorepo에서 만들 수도 있습니다.
강력한 CLI 덕분에 다음과 같은 간단한 명령을 통해 Project라는 폴더에 Angular 라이브러리를 쉽게 생성할 수 있습니다.

ng generate library my-lib

각도 라이브러리에 대한 자세한 내용은 official documentation on Angular.io를 참조하십시오.
라이브러리 사용은 로컬 모듈에 비해 다음과 같은 이점을 제공합니다.

이 모듈을 고려하고 구축할 때 중용성을 고려해야 한다

이 라이브러리를 쉽게 배포하고 다른 팀/프로젝트와 공유할 수 있음

다음과 같은 몇 가지 단점이 있습니다.

라이브러리를 메인 프로젝트에 연결하고 변경할 때마다 재구성해야 합니다

NPM을 통해 릴리즈되고 마스터 프로젝트 외부에 구축된 경우 프로젝트와 라이브러리의 최신 버전

을 동기화해야 합니다.
예를 들어 모든 팀에서 사용하는 메시징 시스템을 사용하는 경우 — 많은 라이브러리들이 실질적으로 일반적인 기초 작업을 하지 않도록 추상적인 것을 공유하고 싶을 수도 있습니다.
따라서 메시지 라이브러리를 만들고 @big company/messaging으로 NPM에 발표합니다.

단 환매 협의는?마이크로 앞머리는요?
이것은 더 큰 문장이 필요할 수 있지만, 기업급 프로젝트에 대해 이야기할 때, 우리는 다음과 같은 두 가지 방식을 언급하지 않을 수 없다.

monorepo는 검증된 전략으로 대형(심지어 거대) 코드 라이브러리와 함께 모든 코드를 다시 사용할 수 있도록 할 수 있으며 기본적으로 모든 코드 라이브러리는 같은 저장소에 위치한다.모든 항목은 항상 최신 버전의 코드를 사용합니다

.

마이크로 전단은 대형 응용 프로그램이 각자의 코드 라이브러리에서 비교적 작은 응용 프로그램으로 분리될 수 있도록 허용하고 완전히 다른 창고를 사용하여 조합할 수 있다.예를 들어 로그인 페이지는 Vue로 작성할 수 있고, 프로그램의 다른 부분은 Angular와 React로 작성할 수 있습니다.특히 Nx 작업공간은 React와 같은 다양한 기술 스택을 사용할 수 있습니다.

💡 You may want to take a look at Nx Workspaces

각진 프로젝트를 더 많은 프로젝트와 라이브러리를 포함하는 모노페오로 구축하는 것은 매력적인 해결 방안이지만 대형 과학 기술 회사에 있어서는 현실적으로 실현하기 어렵다. 왜냐하면 이런 회사에서 많은 팀과 프로젝트가 분리되어 서로 멀리 떨어져 있기 때문이다.
그럼 도서관은 어디에 세워야 하나요?

만약에 한 회사의 모든 개발 업체가 같은 주요 프로젝트에서 일할 준비가 되어 있다면 규모가 아무리 크더라도monorepo는 좋은 해결 방안이 될 수 있다

만약에 개발자가 서로 다른 프로젝트, 서로 다른 팀, 서로 다른 장소와 더 중요한 코드 라이브러리에 배치되어 일을 한다면 당신은 자신의 저장소에 각 라이브러리를 구축하기를 희망할 수 있습니다

유형 스크립트 엔티티

만약 당신이 Angular와 Typescript를 사용하고 있다면 — 나는 네가 옳다고 생각한다. 너는 Typescript 자체의 강력한 실체를 고려해야 한다. 우리는 이러한 실체를 이용하여 구조적이고 좋은 코드 라이브러리를 구축할 수 있다.
프로젝트에서 가장 많이 사용할 Typescript 엔티티 목록은 다음과 같습니다.

학급

열거

커넥터(및 유형)

나는 이 실체들을 모듈에 있는 자신의 폴더로 나누는 것을 좋아한다. 나는 이 실체들을 코어라고 부르기 싫지만, 이것은 어느 정도에 당신과 당신의 팀에 달려 있다.
백엔드 엔티티마다 일치하는 Typescript 파일을 생성하는 것이 좋습니다.여기에는 열거, DTO(요청 및 응답용) 및 데이터 클래스가 포함됩니다.

예를 들어 우리는 회사 내 여러 팀이 공유하는 마이크로 서비스를 개발할 때도 있다.유사한 상황에서, 나는 각도 라이브러리를 구축하는 것이 의미가 있다고 생각한다. 이것은 로컬 개발 모듈이 아닌 일치하는 클래스, 인터페이스, 매거진을 탑재할 것이다.

국가 관리

어떤 상태 관리 라이브러리를 사용할 계획이든지 간에, 업무 논리와 역 모듈을 분리하는 것을 권장합니다.우리는 서비스 모듈 모델을 이용하여 관련 기능 모듈로 가져올 수 있다.
상태 관리 서비스 모듈은 다음 두 가지만 내보내면 됩니다.

공급업체를 등록하기 위한 모듈 자체

기능 모듈의 UI 구성 요소와 스토어

사이에 교량 역할을 하는 전면 서비스
이런 모델은 어떤 우세가 있습니까?

로드 지연 라우팅에서 모듈을 가져오는 경우 — 이 옵션은 로드 경로에서만 가져올 수 있습니다.특정 경로에서 여러 기능 모듈을 사용해야 할 때가 있습니다 — 이 경우 AppModule

에서 가져올 수도 있습니다

UI와 더 나은 분리/패키징구성 요소는 어떤 상태 관리를 사용하는지 알 필요가 없습니다

상태 관리 재구성/변경 가능

나는 상태와 기능 모듈을 분리하는 것을 좋아한다. 이것은 특히 유행하는 방법이지만 지역사회의 공평한 구분을 유지한다.

루트 레벨에 모든 UI 구성 요소가 포함된 Dashboard라는 라우팅 모듈이 있다고 가정합니다

.

다시 뿌리 수준 — 이 상태를 처리할 모든 상태 서비스 모듈

이 포함된 store라는 폴더가 있습니다.

NGRX 프로그래밍 엔티티

NGRX에는 어떤 프로그래밍 엔티티가 있습니까?

감속기

행동

선택기

영향
/영향

어댑터(출처:
/솔리드

다음 그림에서 NGRX를 사용한 간단한 예시를 살펴보자. 나는 다른 문장에서 상세하게 설명할 것이다.

대시보드 모듈 대시보드 엔클로저 가져오기

대시보드 모듈의 구성 요소는 서비스 대시보드 Facade Service를 통해서만 매장과 통신합니다.

💡 If we create a test for each file we create, it's a good idea to place them in a separate folder

배달하다⭐

새로운 프로젝트를 만들 때 어느 창고를 사용하든지 간에 먼저 사용할 프로그래밍 실체를 고려해야 한다

일부 재사용 가능한 모듈은 주 응용 프로그램 외부에 있어야 합니다. Angular 라이브러리 활용💪

상태 관리 서비스 모듈 생성

을 통해 기능 모듈과 상태 분리 고려
만약 당신이 어떤 해명을 필요로 하거나, 어떤 일이 분명하지 않거나 틀렸다고 생각한다면, 평론을 남겨 주십시오.
나는 네가 이 문장을 좋아하길 바란다.있다면 저Medium나 my website를 주목하여 소프트웨어 개발, 전단, RxJS, Typescript 등에 관한 글을 더 많이 얻으세요!