Angular Standalone Components에 대한 포괄적인 가이드
이 퀵 가이드에서는 독립형 Angular 컴포넌트를 둘러싼 기대감, 작동 방식 및 컴포넌트를 만드는 방법을 더 잘 이해할 수 있도록 살펴봅니다. 더 읽어보기.
개발 프로세스를 변경하고 향상시키는 데 있어 돌이킬 수 없는 프레임워크가 하나 있다면 바로 Angular 입니다. 최신 Angular 16.0.0 릴리스에서는 이제 툴링, 서버 측 렌더링 및 반응성과 같은 몇 가지 주요 개선 사항이 있습니다. 그리고 저에게 Angular 독립형 API의 도입은 개발자 커뮤니티에 많은 이점을 제공하는 최신 버전의 가장 큰 개선 사항 중 하나입니다. 특히 Schematics for Standalone Components라는 새로운 기능은 재사용 가능한 UI 요소와 라이브러리를 빌드하는 동시에 상용구 모듈을 제거하는 기능을 개선하는 것 같습니다.
그리고 그것은 판도를 크게 바꾸지 않습니까?
그러나 SAC(Standalone Angular Components)를 둘러싼 모든 기대와 정확히 작동 방식, 생성 방법, 독립형 구성 요소에 대한 개념이 처음 제시된 Angular 14 이후 변경된 사항 등을 더 잘 이해하기 위해 SAC(Standalone Components)에 대해 자세히 살펴보겠습니다.
Angular의 독립형 구성 요소는 무엇입니까 아니면 NgModules에 작별 인사입니까?
이를 정의하는 가장 짧은 방법은 독립 실행형 구성 요소를 사용하면 모듈을 사용하지 않고 Angular 애플리케이션을 구축할 수 있다는 것입니다. 특정 모듈에 연결되어 있지 않기 때문에 애플리케이션의 모든 부분에서 사용할 수 있습니다. 즉, 독립 실행형 클래스는 NgModule에서 선언할 필요가 없으므로 상용구 코드가 적습니다.
기본적으로 독립 실행형 구성 요소는 필수가 아닙니다. 권장 예, 하지만 필수는 아닙니다. 그러나 Angular 적어도 새로 만드는 구성 요소에 대해 항상 독립 실행형 구성 요소를 사용하는 것이 좋습니다. 그들은 단순히 더 나무를 흔들 수 있고 보일러가 적습니다. 독립 실행형 구성 요소와 모듈을 혼합할 수 있습니다. 적어도 앞으로는 모듈보다 독립형 구성 요소를 사용할 수 있다는 데 동의하지만 나머지 구성 요소를 모듈화 된 상태로 두기로 결정하면 나쁜 결정은 아닙니다.
Angular 14에서는 독립형 구성 요소라는 아이디어가 당시 개발자 프리뷰인 독립형 API와 함께 도입되었습니다. 그들은 어떤 모듈의 일부가 아니며 다른 구성 요소 내에 중첩되지 않고 독립적으로 사용할 수 있는 구성 요소 유형을 언급했습니다. 반대로, 그 전에 구성 요소를 만들고 싶을 때는 일반적으로 모듈의 선언 배열 내부에 전달해야 했습니다.
그런 다음 개념이 바뀌기 시작했고 개발 프로세스가 점차 발전했습니다.
예를 들어, 공식 Angular 문서에는 "독립형 구성 요소, 지시문 및 파이프는 NgModule의 필요성을 줄여 저작 경험을 간소화하는 것을 목표로 합니다. 기존 응용 프로그램은 주요 변경 없이 새로운 독립 실행형 스타일을 선택적으로 점진적으로 채택할 수 있습니다."
즉, 여기에 단순화가 있습니다.
이제 Angular 16을 통해 독립형 구성 요소에 대한 회로도 기능과 독립형 구성 요소를 독립적으로 포함시키고 모듈화하며 재사용할 수 있도록 설계된 독립 실행형 구성 요소를 공식적으로 사용할 수 있습니다. 그러나 Angular에서 독립 실행 형 구성 요소를 사용하는 이유는 무엇입니까? NgModule의 사용을 완전히 대체하지는 않지만 재사용 가능한 모듈식 코드를 만드는 새로운 방법을 활용할 수 있습니다. 그 과정에서 Angular 앱에 대한 유지 관리 용이성과 테스트 용이성이 향상되고 프로젝트 구조가 그대로 유지됩니다.
이것은 훌륭한 대안입니다!
그러나 다시 말하지만, Angular의 독립형 구성 요소는 NgModules의 대체품이 아니라 대안입니다.
다른 Angular 독립형 구성 요소의 이점은 무엇입니까?
Angular에서 독립 실행형 구성 요소를 사용해야 하는 몇 가지 이유는 다음과 같습니다.
- 그들은 클래스와 함께 제공되는 다른 모든 초과를 효과적으로 제거할 수 있는 경량 솔루션입니다.
- 예전에는 훨씬 더 무거운 클래스 기반 API에 비해 더 기능적인 API를 채택할 수 있습니다.
- 이제 NgModule 없이 구성 요소를 직접 지연 로드할 수 있습니다.
- 기능을 캡슐화하고 다른 구성 요소에 잠재적인 버그를 일으키지 않고 앱 전체에서 코드 재사용성을 촉진하는 기능이 함께 제공됩니다.
- 구성 요소로 애플리케이션을 부트스트랩할 수 있으므로 더 이상 AppModule이 필요하지 않습니다.
- 독립 실행형 Angular 구성 요소에서의 라우팅은 이제 트리를 더 많이 셰이킹할 수 있으므로 라우팅된 구성 요소 또는 경로 구성을 직접 가리킬 수 있습니다.
- 다른 독립 실행형 구성 요소, 지시문, 파이프 및 기존 NgModule도 쉽게 가져올 수 있습니다.
- 각 구성 요소에는 자체 파일(템플릿, 스타일, TypeScript 코드)이 있어 훨씬 더 나은 코드 구조를 제공합니다.
- 재사용성을 염두에 두고 구성 요소를 설계하고 새로운 기능을 쉽게 추가하거나 기존 기능을 확장할 수 있습니다.
- Angular 독립 실행형 구성 요소 각각에 대해 특별히 단위 테스트를 작성할 수 있습니다.
Angular에서 독립 실행형 구성 요소를 만드는 방법은 무엇입니까?
- Creating them
첫 번째 독립 실행형 구성 요소를 만드는 것은 매우 쉬우며 –-standalone 플래그를 사용하여 수행됩니다. 하지만 먼저 Angular 16을 사용하고 있는지 확인하세요.
2. Using them
독립 실행형 구성 요소는 다음 두 가지 방법으로 사용할 수 있습니다.
- 다른 독립 실행형 구성 요소에서는 동일한 독립 실행형 구성 요소의 imports 속성에 전달하기만 하면 됩니다.
- 또는 모듈 내부에서 imports 배열에 전달합니다.
Ignite UI for Angular와 함께 독립 실행형 구성 요소 사용
Angular 16 및 Ignite UI for Angular 16.0부터는 이제 독립 실행형 구성 요소에 필요한 가져오기를 imports 속성에 추가하기만 하면 됩니다. 다음 예에서는 IGX_GRID_DIRECTIVES를 사용하여 모든 그리드 관련 구성 요소 및 지시문을 가져올 수 있습니다. Ignite UI with Angular에서 독립 실행형 구성 요소를 만들고 사용하는 방법은 다음과 같습니다.
import {IGX_GRID_DIRECTIVES} from 'igniteui-angular'; @Component({ selector: 'app-grid-sample', styleUrls: ['grid.sample.scss'], templateUrl: 'grid.sample.html', standalone: true, imports: [IGX_GRID_DIRECTIVES, AsyncPipe] })
독립 실행형 구성 요소에서 사용하는 모든 구성 요소를 개별적으로 가져올 수도 있습니다. IgxGridComponent 및 IgxColumnComponent를 사용하는 경우, 다른 컴포넌트에서 이 두 가지만 사용하는 예는 다음과 같습니다.
import {IgxGridComponent, IgxColumnComponent} from 'igniteui-angular'; @Component({ selector: 'app-grid-sample', styleUrls: ['grid.sample.scss'], templateUrl: 'grid.sample.html', standalone: true, imports: [IgxGridComponent, IgxColumnComponent, AsyncPipe] })
이제 Ignite UI for Angular 모든 구성 요소가 독립 실행형 구성 요소로 내보내집니다. 라이브러리는 이전 버전과의 호환성을 위해 보존된 NgModule을 여전히 내보내지만 더 이상 Ignite UI for Angular 구성 요소를 선언하지 않습니다.
대신, 그들은 단지 독립 실행형 구성 요소를 가져오고 내보냅니다. 독립 실행형 구성 요소는 아직 미리 보기 단계에 있다는 점에 유의해야 합니다. 일부 유틸리티 지시문 내보내기는 나중에 변경될 수 있으며 초기 릴리스의 설명서에서 누락될 수 있으므로 기능의 미리 보기 상태가 될 수 있습니다.
Angular 독립형 구성 요소에 대한 모범 사례는 무엇입니까?
Angular 독립 실행형 구성 요소로 작업할 때 몇 가지 모범 사례를 따라 깔끔하고 유지 관리 가능하며 재사용 가능한 코드와 다음 수준 프로젝트를 보장할 수 있습니다.
- 프로젝트 및 코드의 크기 고려
첫 번째 단계로 프로젝트의 크기와 코드 구성 방법을 고려합니다. 모든 구성 요소를 독립형으로 전환하기만 하면 일반 구성 요소에서 독립 실행형 구성 요소로의 마이그레이션과 관련된 주요 변경 사항이 없다는 것을 읽을 수 있습니다. 그러나 응용 프로그램에 몇 가지 주요 버그가 도입 될 것이라고 장담 할 수 있습니다. 그러나 모든 코드를 독립 실행형 구성 요소로 마이그레이션하고 싶지는 않을 수 있습니다. 모듈의 구성 요소를 번들로 묶고 그 중 일부만 내보내는 것은 완벽하게 미세한 패턴입니다. 이것을 독립형 구성 요소로 어떻게 변환하시겠습니까? ngModule 대신 배럴 파일을 사용하여 API를 설정하는 동시에 린팅 규칙으로 개인 구성 요소를 보호해야 합니다. 이 경우 독립 실행형 구성 요소가 반드시 프로젝트를 더 쉽게 관리할 수 있는 것은 아닙니다.
따라서 프로젝트 크기가 중간에서 큰 규모 인 경우이 마이그레이션을 다소 천천히 시작하고 모든 SCAM (Single Component Angular Module)을 마이그레이션하는 것이 좋습니다. SCAM을 사용하면 NgModule은 하나의 구성 요소만 선언합니다. 이미 분리되어 있기 때문에 그때부터 독립 실행형 구성 요소를 만들고 작업하는 방법에 익숙해질 수 있습니다.
- Migrate Pipes & Directives
또 다른 좋은 방법은 모든 파이프와 지시문을 독립 실행형 구성 요소로 마이그레이션하는 것입니다. 이렇게 하면 일부 모듈을 단순화하고 줄일 수 있습니다.
- 코드를 조정하고 지속적으로 개선합니다.
그런 다음 자신과 팀이 정기적인 코드 리팩토링 중에 코드 베이스를 조정하고 지속적으로 개선할 수 있는 시간을 가지십시오. 엔터프라이즈 규모의 프로젝트에서는 독립 실행형 구성 요소로 마이그레이션하는 것이 큰 작업이기 때문입니다. 이렇게 하면 재발이 발생하지 않도록 할 수 있으며 모든 변경 사항은 동료에 의해 잘 테스트되고 검토됩니다.
결론적으로...
독립형 구성 요소가 나를 위해 많은 상용구를 제거한다는 주장은 부분적으로만 사실입니다. 더 이상 모듈을 만들 필요가 없습니다. 대신, 거의 모든 컴포넌트가 최소한 CommomModule을 가져와야 Angular 예상대로 작동할 수 있습니다. 더 복잡한 경우의 경우 다른 모듈 및 구성 요소의 꽤 긴 목록도 가져와야 합니다. 경우에 따라 이로 인해 import 문이 매우 길어지며 파일을 열 때 구성 요소 자체의 코드를 실제로 보려면 전체 페이지를 스크롤해야 합니다.
이 문제에 대한 쉬운 대답은 없습니다. 필요한 것만 가져오면 되도록 CommonModule을 잘라내자는 제안이 있었지만 이로 인해 쉽게 긴 가져오기 목록이 생성될 수 있습니다. 대안은 *ngIf 지시문과 같은 특정 기능을 기본적으로 가져오는 것일 수 있습니다. 현재로서는 이 방향에 대한 Angular 팀의 구체적인 계획이 없습니다.
따라서 일정 기간 동안 프로젝트의 코드 베이스에서 두 개념이 함께 작동하도록 허용하고 프로젝트가 어떻게 계속 발전하고 정확히 무엇이 가장 잘 작동하는지 확인하는 데 아무런 문제가 없습니다.
