ngModules가 원하는 설정을 금지하는 것 같지 않습니다. 아직 사용해 보셨습니까? 여러 다른 모듈을 가질 수 있고 지연 로딩 등을 수행할 수 있습니다. http://plnkr.co/edit/NAtRQJBy50R19QAl90jg?p=info

하려는 것처럼 보이는 것과 더 유사한 것을 위해 눈 material2의 전환을 유지하십시오: https://github.com/angular/material2/pull/950/files

안녕하세요 @qdouble ,

빠른 답변 감사합니다.
https://github.com/jelbourn/material2/blob/ecbb4f42e0473899f6ad15d8e4ed8f262ded7a99/src/components/button-toggle/button-toggle.ts 를 보면 지금과 동일한 기능을 달성하기 위해 필요하다는 말씀이신가요? 각 구성 요소에서 NgModule을 선언하려면? (파일 마지막에 추가된거 맞죠?)

또한 초기 진술에서 언급한 유지 관리 문제는 다루지 않습니다. 데코레이터에 선언된 각 구성 요소/지시어의 종속성을 유지하는 것은 저에게 큰 이점입니다.

@jpsfs 각각의 모든 구성 요소에 대한 개별 범위를 만들고 싶다면 각각에 대해 다른 ngModule을 만들어야 한다고 가정합니다. 이것이 귀하의 경우 더 많은 코드를 생성할 수 있지만 구성 요소당 대신 내 모듈의 범위를 지정하여 대다수의 다른 사람들을 위해 더 적은 코드를 생성할 것이라고 가정합니다.

두 번째 문제에 관해서는 ngModule과 구성 요소를 서로 바로 옆에 선언할 수 있으므로 파일에 추가로 3~4줄의 코드를 추가하지만 큰 문제를 일으키지는 않는다고 생각합니다.

대부분의 사용 사례에는 구성 요소당 범위 지정 지시문이 필요하지 않지만 필요한 경우 ngModules는 몇 줄의 코드에 대해 여전히 이를 지원합니다.

@qdouble 감사합니다.

이것이 또는/또는 상황인지 확실하지 않습니다. 두 시나리오가 함께 작동하는 것을 볼 수 있으며 이미 있는 기능을 제거할 필요가 없습니다. 누군가가 모듈을 사용하기를 원하면 훌륭한 추가 기능으로 볼 수 있습니다. 한편, 프레임워크는 모듈 없이도 작동할 수 있습니다(현재 작동 중임). 오프라인 컴필레이션 문제도 현재대로라면 해결될 수 있다고 생각합니다.

이 문제에 추가할 내용이 있는 사람이 있는지 확인하기 위해 공개합니다.

@jpsfs 는 이해했습니다. 내가 귀하의 상황에 있다면 두 옵션을 모두 열어 두는 것이 좋습니다. :)

그들은 두 개의 범위를 생성하는 한 귀하가 게시한 문서에 구성 요소 지시문을 사용하지 않는 이유를 썼습니다. 그들은 ngModule 범위가 충분히 작고 ES6 모델과 더 일치한다고 생각합니다.

팀 구성원은 이전에 두 가지 다른 방법으로 작업을 수행하는 것이 일반적으로 문제가 있다고 언급했습니다. 장기적으로 보면 여기에서 문제를 볼 수 있습니다. 사람들이 ngModules 및 기타 프로젝트를 사용하는 일부 프로젝트가 있는 경우 그렇지 않은 경우 더 많은 유지 관리, 교육 및 호환성 문제가 발생합니다.

이 프로젝트가 끝날 때까지 이 프로젝트가 어떤 방향으로 갈지 절대 알 수 없으므로 그들이 귀하의 말을 고려하는지 확인하겠습니다.

나조차도 현재 거대한 엔터프라이즈 앱의 아키텍처를 설계하는 일을 하고 있습니다.
귀하의 상황 @jpsfs 와 달리 저는 NgModule에 흥분하고 NgModule을 기반으로 하는 앱 아키텍처를 기반으로 합니다.

각 모듈에는 고유한 경로 및 구성 요소 종속성이 있습니다. 우리는 단 하나의 구성 요소로 기능을 생성할 수 없습니다. 경로, 최소한 하나의 스마트 구성 요소, 몇 가지 Dumb 구성 요소 및 서비스가 필요합니다. 이 모든 것을 모듈에 연결하면 사용할 수 있습니다.

지연 로딩이 오면 각 구성 요소에 대한 코드를 로드하는 대신 각 NgModule 코드가 한 번에 로드되므로 한 번 다운로드하면 기능을 완전히 사용할 수 있습니다.

모듈의 계층 구조를 만드는 것도 훨씬 간단하며 훌륭한 플러그 앤 플레이 기능을 무료로 제공합니다.

우리는 또한 현재 상당히 많은 구성 요소(수백이 아니라 수십)가 있는 응용 프로그램에서 작업하고 있습니다. 이 응용 프로그램을 여러 (지연 로드) 모듈로 분할할 아키텍처가 필요하지 않지만 이제 모든 구성 요소를 부트스트랩 파일로 가져오고 declarations 에 전달하는 것이 잘못된 느낌을 주며 구성 요소의 캡슐화를 중단합니다. . @jpsfs 가 말했듯이 이전에는 다른 구성 요소에서 어떤 구성 요소와 지시문이 사용되었는지 매우 명확했습니다. 따라서 다음과 같은 선택을 해주시면 감사하겠습니다.

• 꽤 일반적으로 사용되는 지시문이라면 모듈에서 선언하십시오.
• TaskListItem 와 같은 경우 $ TaskList 로 가져옵니다.

아마도 일부 핵심 구성원은 두 번째 접근 방식을 사용하지 않는 결정에 대해 더 많이 말할 수 있습니다. 몇달째 사용해보니 꽤 괜찮네요 ;)

@choeller 의 요점을 반영하기 위해 구성 요소 캡슐화를 제공하는 기능에서 멀어지는 것이 이상하게 느껴집니다.

내 특정 관심사는 이제 구성 요소 이름/선택기가 전체 앱에서 누출되는 반면 이전에는 특정 지시문을 적절하게 포함하여 다른 구성 요소에 대해 선택기를 재사용할 수 있다는 것입니다.

이제 모든 선택자는 구성 요소별로 고유해야 합니다. 그렇죠? 아니면 이것이 어떻게 작동하는지 오해하고 있습니까?

나는 원래 기능이 CSS shadow-DOM 에뮬레이션이 제공하는 유사한 이점과 일치한다고 느꼈습니다. 큰 앱에서 선택기 충돌 등에 대해 덜 걱정할 수 있다는 점입니다. 그것은 IMO의 큰 장점이었습니다.

ngModule에 대한 나의 첫 번째 생각은 "아, 그건 Angular 1과 같습니다"였습니다. Angular 1이 이미 훌륭했던 것처럼 Angular 2는 많은 점에서 훨씬 더 좋습니다. 나에게 가장 좋은 점은 구성 요소가 일종의 종속성 트리를 생성한다는 것입니다. 자체 구성 요소로 여러 진입점을 정의하는 라우터가 있는 주요 구성 요소가 있습니다. 그리고 모든 구성 요소는 자신이 필요로 하는 것이 무엇인지 알고 있습니다. 트리 끝에 있는 구성 요소가 무엇을 필요로 하는지 주 구성 요소가 알 이유는 없습니다.
이제 우리는 거대한 모듈 정의가 있는 Angular 1의 좋은 옛날로 돌아갑니다.
앱 진입점이 다음과 같이 보였던 때를 기억하십니까?

angular.module("myApp")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.component("…")
.component("…")
.component("…")
.component("…")
.component("…")
.component("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.service("…")
.service("…")
.service("…")
.service("…")
.service("…")
.service("…")

나는 이것이 과거에 속한다고 생각했다. 저는 오래된 Angular 1 프로젝트를 개선하고 마이그레이션을 준비하기 위해 ng-metadata로 작업하기 시작했습니다. 저는 이 앱에 글로벌 "이 앱에 나타날 수 있는 것" 목록이 아닌 종속성 트리가 있다는 사실을 정말 좋아합니다.

이것은 재사용 가능한 구성 요소를 더 어렵게 만듭니다. 이것이 전역/모듈 범위의 모든 것을 더 잘 만드는 방법을 이해하지 못합니다. ng2 팀이 변경을 원하지 않는 ng1 사용자에게 굴복했다고 생각합니다.

@DaSchTour @damiandennis 이 아키텍처에 대한 비판을 이해하지만 일종의 글로벌 범위가 부정확하기 때문에 언급하는 방법론은 기능 모듈을 사용하는 것입니다. https://angular.io/docs/ts /latest/guide/ngmodule.html#! #기능 모듈

@qdouble 글쎄, 결국 모든 구성 요소를 모듈로 변경하는 것입니다. 이것은 상용구 코드를 줄이기 위한 변경으로 발표되었지만 많은 상용구를 도입합니다.

RC4까지는 애플리케이션의 모든 "페이지"/보기에 대한 구성 요소로 충분했지만 모든 보기에 대해 모듈, 구성 요소 및 라우팅을 만들어야 한다는 것을 알고 있습니다. 의도는 알겠습니다. 그러나 나는 그것이 다른 많은 요점과 관련되지 않으면서 몇 가지 일을 더 쉽게 하도록 설계되었다는 인상을 어떻게든 가지고 있습니다. 그리고 기능 모듈 패턴을 사용하더라도 애플리케이션의 어느 부분에 어떤 구성 요소가 필요한지 알 수 없기 때문에 필요할 수 있는 모든 것을 추가하여 종속성 지옥을 피하기 위해 매우 작게 잘라야 합니다.

결국 모듈은 너무 작아서 현재 구성 요소와 유사한 반복 종속성 목록을 갖습니다.

결국, 그것은 그것이 설계된 것을 해결하지 못하고 많은 작업을 추가할 뿐입니다. 디자인과 현실 사이에 약간의 불일치가 있다는 느낌이 듭니다.

개발자는 게으르고 시간이 부족하고 지름길을 택합니다. 이를 통해 개발자는 부트스트랩에 모든 것을 포함하는 빠른 경로를 택할 수 있습니다. 적어도 구성 요소에는 종속성을 포함해야 하는 몇 가지 요구 사항이 있습니다. 예, 그들은 또한 게으르고 전체 응용 프로그램에 대한 단일 구성 요소를 만들 수 있지만 종속성이 해당 구성 요소에 모두 있으므로 부트스트랩 파일과 응용 프로그램 내의 각 구성 요소 파일 간에 혼합되지 않으므로 수정하기가 더 쉽습니다.

@DaSchTour 모든 단일 구성 요소에 자체 범위가 필요한 경우 예, 더 많은 상용구를 생성할 것입니다. 하지만 ng 팀은 대부분의 사람들이 모든 기능 섹션에 대해 새 모듈을 생성한다는 의견을 가지고 있습니다. 충분하고 몇 가지 구성 요소가 각 기능 공간에 있을 수 있습니다.

이제 분명히 모든 솔루션에 맞는 사람은 없으며 일부 사람들에게는 구성 요소 수준 지시문이 더 간단할 수 있습니다. 그러나 여기에 있는 많은 의견은 하나의 거대한 ngModule 트리가 있는 응용 프로그램을 만들기를 원한다는 것을 암시하는 것 같습니다...

나는 비판이 그들이 제안하지 않는 밀짚맨 디자인 패턴(즉, 하나의 거대한 ngModule인 엔터프라이즈 앱을 만드는 것)보다 실제 디자인 제안을 기반으로 하는 것이 더 생산적이라고 생각합니다.

@qdouble 디자인 패턴은 간단합니다. 종속성을 전역 모듈 범위로 이동하는 대신 종속성 트리를 사용합니다. 요점은 재사용 가능한 구성 요소가 매우 작고 기능이 거의 없더라도 이제 모듈이어야 한다는 것입니다. Angular material2가 아주 좋은 예입니다. Button은 하나의 구성 요소를 포함하는 모듈입니다. 많은 개발자들이 모듈이 단순한 버튼 이상을 포함하고 있다는 일반적인 오해일 수 있습니다. 그리고 이제 한 걸음 더 나아가 생각해보자. https://angularjs.blogspot.com/2016/08/angular-2-rc5-ngmodules-lazy-loading.html 이 기사의 아이디어를 따라가기 만하면되는 많은 모듈이 있다는 점에서 내 자신을 찾습니다. angular material2 모듈 목록과 단일 구성 요소로 구성된 이 모듈 각각을 가져옵니다.
사실 이것이 바로 angular material2가 하는 일입니다.

아무도 요점을 이해하지 못합니다. 이제 "모든" 구성 요소를 모듈로 포장해야 하는 이유입니다. 아니면 이것을 선언의 분할로 봐야 할 수도 있습니다. 구성 요소 종속성은 이제 모듈이고 구성 요소 정의는 그대로입니다.

요점은 ngModules가 일을 더 쉽게 하기 위한 좋은 추가 기능일 뿐 아니라 모든 것을 변경해야 한다는 것입니다. 아마도 누군가는 둘 다 공존할 수 없는 이유를 명확하게 설명해야 할 것입니다.

@DaSchTour 글쎄요, 당신이 만드는 모든 단일 구성 요소가 자체 모듈을 필요로 한다면 ngModules를 사용하면 더 많은 상용구가 생성된다는 점에 동의합니다... 저는 단순히 팀이 대부분의 사람들이 모든 구성 요소에 대해 그 수준의 분리가 필요하다고 생각하지 않는다고 생각합니다. 요소.

Angular material2 모듈 목록을 가져오는 많은 모듈과 이 모듈 각각이 단일 구성 요소로 구성되어 있다는 사실을 깨달았습니다.

이를 위해 공유 모듈을 사용합니다: https://angular.io/docs/ts/latest/guide/ngmodule.html#! #공유모듈

이제, 왜 그들이 컴포넌트 범위를 갖는 기능을 완전히 제거하는 것이 필요하다고 생각하는지 잘 모르겠습니다. 그러나 저에게 일부 비판은 ngModules를 실제보다 더 어렵게 사용하거나 디자인을 더 보기 좋게 만든다는 것입니다. 실제보다 더러움.

구성 요소 범위 지시문/파이프를 제거하는 것에 대한 비판이 완벽하게 유효하다고 생각합니다. 하지만 ngModules에 좋은 디자인 패턴이 없는 것처럼 보이게 할 필요는 없다고 생각합니다.

@qdouble ngModules 를 위한 좋은 디자인 패턴이 있다는 것을 아무도 의심하지 않는다고 생각합니다. 그러나 내가 이해한 바에 따르면 모듈은 구성 요소 집합을 둘러싼 래퍼일 뿐이며, 이를 노출하는 지시문 및 서비스는 응용 프로그램의 한 단위입니다. 그것은 타당하고 좋은 생각입니다. 그러나 구성 요소가 아닌 모듈에 대한 종속성(모듈 내부에만 존재할 수 있음)을 정의해야 하는 이유는 무엇입니까?

@choeller의 예를 들면
모듈 TaskDashboard에는 다음이 있습니다.

1. 작업 목록 구성 요소
2. 작업 항목 구성 요소
3. 작업 필터 구성 요소
4. 태스크 서비스

Taskitem 구성 요소는 Tasklist 내에서만 필요하며 Tasklist는 Taskitem 구성 요소에 종속됩니다. Taskfilter에는 Taskitem 구성 요소가 필요하지 않습니다. 이제 Tasklist에 종속성으로 Taskitem이 없습니다. 다음 단계는 TaskSearch 모듈을 만드는 것입니다. 다음 사항을 추가합니다.

1. 작업 목록 구성 요소
2. 작업 검색 구성 요소
3. 태스크 서비스

글쎄, 나는 Taskitem Component를 놓쳤고 고장났습니다. Tasklist는 항상 Taskitem에 종속되지만 이 종속성은 모듈에 숨겨져 있습니다. 구성 요소를 재사용하는 것이 더 어려워지고 추가 오류 소스가 생성됩니다.

좋아, 모듈 가이드를 자세히 읽는 동안 이 줄을 찾았습니다.

구성 요소, 지시문 및 파이프는 정확히 하나의 모듈에 속해야 합니다.

따라서 이 예는 여기에서 제기된 우려를 정확히 보여줍니다. 공유 구성 요소가 있을 수 없습니다. 그래서 내 예에서 나는 모든 것을 모듈로 분할해야 할 것입니다.

ngModule을 사용할 때 발생하는 이상하고 파악하기 어려운 오류에 대해 작업하는 동안 확장 구성 요소가 이제 이전처럼 제대로 작동하지 않는다는 것도 발견했습니다. 단순히 확장할 수 있는 필요한 종속성을 가진 구성 요소 집합이 있었습니다. 이제 확장 구성 요소를 포함하는 모듈에서 종속성을 가져오는 작업을 처리해야 합니다.

예에서 @DaSchTour , Taskitem은 Tasklist 모듈의 일부여야 합니다... 따라서 논리적으로 하나의 모듈이 아닌 두 개의 구성 요소가 하나의 모듈에 있어야 합니다.

@sirajc 가 지적했듯이 일반적인 디자인 패턴은 하나의 최상위 스마트 구성 요소와 추가 벙어리 구성 요소가 뒤따르는 것이므로 일반적인 실제 앱에서 대부분의 모듈은 몇 가지 구성 요소로 구성됩니다. 구성 요소 패턴 또는 관련 기능 패턴별), 타사 구성 요소 등을 구축하지 않는 한 모듈당 하나의 구성 요소가 아닙니다.

@qdouble @DaSchTour 새 아키텍처가 반드시 모든 구성 요소를 하나의 파일에 나열하는 것을 의미하지는 않지만 우리가 구축하고 있는 앱을 보면 현재 @DaSchTour 의 이 진술과 거의 일치합니다.

디자인과 현실 사이에 약간의 불일치가 있다는 느낌이 듭니다.

따라서 TaskListItem 와 같은 페이지의 작은 단위를 나타내는 많은 구성 요소가 있으며 특수 보기에 100% 바인딩되어 있습니다. 해당 페이지 각각에 대한 모듈을 만드는 것은 완전히 과잉입니다. 우리의 경우 여러 모듈로 분할하는 이유는 거의 없지만 구성 요소를 캡슐화하는 이유는 훨씬 더 많습니다.

헐 박사
모듈 수준에서 일부 종속성을 정의할 수 있다는 것은 멋진 일이지만 더 이상 구성 요소 수준에서 종속성을 정의할 수 없다는 것은 정말 슬픈 일입니다.

@DaSchTour , material2 에서 버튼 컴포넌트는 모듈에 연결되어 독립 실행형으로 만듭니다. 버튼을 사용해야 하는 사용자는 ButtonsModule 를 가져올 수 있습니다. 또한 모듈 코드를 보면 MdButton 및 MdAnchor ButtonsModule 래핑하면 사용하기가 더 쉽습니다.

파일 중복을 방지하기 위해 두 개념을 하나로 병합하는 하이브리드 구성 요소/모듈 개체를 만들 수 있는지 궁금합니다. 기본적으로 구성 요소를 모듈로 한 번 선언한 다음 필요에 따라 모듈로 가져올 수 있습니다. 현재 접근 방식을 존중하지만 상용구를 최소화합니다.

@choeller 나는 모듈을 갖는 것이 구성 요소 수준에서 종속성을 제거하는 좋은 추가 기능이라는 데 동의하지만 잘못된 것 같습니다.

위에 다른 사람들이 쓴 내용을 바탕으로 수백 개의 구성 요소가 포함된 거대한 모듈이 있는 거대한 프로젝트의 불행을 경험하지 않는 것이 핵심 아이디어라고 생각합니다. 오히려 적당한 수의 중간 크기의 NgModules로 애플리케이션을 구축하는 것입니다. 그것들이 사소하지 않을 만큼 충분히 크고, 그것들의 수가 많지 않을 만큼 충분히 작습니다. 높은 응집력과 낮은 결합의 구식 컴퓨터 과학 의미에서 재사용과 모듈성을 촉진하는 경향이 있는 단층선을 따라 분할됩니다.

그렇게 함으로써 모듈은 대규모 프로젝트에서 사용할 수 있는 매우 유용한 개념으로 판명될 것입니다.

@kylecordes를 아주 잘 요약했습니다. NgModules는 응용 프로그램의 좋은 구성을 돕습니다. 작은 재사용 가능한 모듈이 전체 애플리케이션을 구성합니다.
기타 이점에는 지시문에 대한 주변 가용성이 포함됩니다. 이전에는 전체 애플리케이션에 ROUTER_DIRECTIVES를 추가했습니다. 이제 RouterModule.forRoot() 가 우리를 위해 그렇게 합니다.
BrowserModule, CommonModule, FormsModule은 각 구성 요소를 통해 지시문을 포함하는 것보다 더 합리적입니다.

다른 쪽의 MaterialModule은 모든 것을 제공하며 더 세밀한 제어가 필요한 경우 ButtonsModule 등이 도움이 될 것입니다.
그것이 바로 구성의 아름다움입니다. 그것을 받아들이고 당신의 교향곡을 만드십시오

이 위에 LazyLoading이 있습니다. NgModules가 아닌 경우 하나의 라우팅 가능한 단위를 생성하기 위해 함께 가야 하는 구성 요소 및 서비스의 수를 어떻게 정의할 수 있습니까? 느슨한 파일을 다운로드할 수 없습니다. 이렇게 하면 네트워크 요청이 엄청나게 많이 발생하기 때문입니다. 그렇지 않으면 하나의 번들을 생성하여 모든 종속 파일을 나열하는 번들러를 생성해야 합니다. NgModule은 직관적인 구문으로 이를 수행합니다.

@kylecordes

위에 다른 사람들이 쓴 내용을 바탕으로 수백 개의 구성 요소가 포함된 거대한 모듈이 있는 거대한 프로젝트의 불행을 경험하지 않는 것이 핵심 아이디어라고 생각합니다. 오히려 적당한 수의 중간 크기의 NgModules로 애플리케이션을 구축하는 것입니다. 그것들이 사소하지 않을 만큼 충분히 크고, 그것들의 수가 많지 않을 만큼 충분히 작습니다. 높은 응집력과 낮은 결합의 구식 컴퓨터 과학 의미에서 재사용과 모듈성을 촉진하는 경향이 있는 단층선을 따라 분할됩니다.

애플리케이션 개발자와 라이브러리 개발자의 결함 라인은 매우 다르지 않을까요? 도서관 개발자는 소수여야 하는데 그게 주된 불만인 것 같다. 재사용 가능한 프레임워크를 구축할 때 모듈 크기를 최소화하려는 목표는 많은 추가 노이즈로 이어집니다.

@sirajc

이 위에 LazyLoading이 있습니다. NgModules가 아닌 경우 하나의 라우팅 가능한 단위를 생성하기 위해 함께 가야 하는 구성 요소 및 서비스의 수를 어떻게 정의할 수 있습니까? 느슨한 파일을 다운로드할 수 없습니다. 이렇게 하면 네트워크 요청이 엄청나게 많이 발생하기 때문입니다. 그렇지 않으면 하나의 번들을 생성하여 모든 종속 파일을 나열하는 번들러를 생성해야 합니다. NgModule은 직관적인 구문으로 이를 수행합니다.

내 응용 프로그램 섹션에 대한 컨테이너 역할을 하는 구성 요소를 사용하여 이전 라우터에서 이 작업을 쉽게 수행할 수 있었습니다. 이 모듈은 필요한 직접 구성 요소만 가져와서 자체 종속성을 가져옵니다. 모든 적절한 모듈 로더는 최상위 구성 요소의 모든 하위 종속성을 포함하지 않고 해당 구성 요소의 종속성 체인(가져오기를 통해)을 로드할 수 있습니다. 일종의 모듈 확인 로직을 사용해야 하는 번들러도 마찬가지입니다. 간단히 말해서 지연 로딩 관점에서 개발자가 최상위 구성 요소에 포함된 모든 종속성을 선언해야 하는 이유가 없습니다.

정말 ngModule이 문제를 찾는 솔루션인 것 같습니다...

주어진 구성 요소를 열고 지시문 배열을 살펴보고 의존하는 구성 요소/지시문을 정확히 알 수 있다는 것이 있습니다. 그것을 사용하는 수많은 구성 요소 전체에 걸쳐 버튼 구성 요소를 가져와야 하는 것이 더 장황합니까? 예, 하지만 구성 요소/모듈 트리를 검색하여 구성 요소 Y가 가져오지 않고 템플릿에서 구성 요소 X를 사용하는 방법을 확인하기 위해 구성 요소/모듈 트리를 검색하는 것보다 약간의 추가 상용구를 갖고 명확하고 즉시 스캔할 수 있도록 하고 싶습니다.

위에서 주장하는 주장은 누군가가 구성 요소를 서로 격리된 상태로 유지하려는 경우 각 구성 요소에 대한 모듈을 생성할 수 있지만 그 시점에서 원래 구성 요소보다 훨씬 더 많은 상용구를 작성하게 된다는 것입니다.

내가 다루지 않은 ngModule에는 분명히 다른 이점이 있으며, 응용 프로그램의 섹션을 기능 모듈로 묶을 수 있다는 이점이 있지만 명확성과 구성 요소가 캡슐화되는 부분에 관해서는 실제로 한 걸음 뒤로 물러난 것처럼 느껴집니다. 모든 곳에서 범위를 누출하지 않는 코드.

ng2 팀이 ng1에서 커뮤니티에 해야 했던 "강도 판매"의 일부는 "예, 각 구성 요소에 대한 지시문을 가져와 선언해야 하지만 우리를 믿으세요. 애플리케이션이 성장함에 따라". 저는 팀 구성원이 주어진 시간에 매우 작은 구성 요소 하위 집합에서만 작업할 수 있는 대규모 팀 환경에서 가독성과 가독성을 위해 약간의 반복을 통해 고통을 겪을 것이라고 굳게 믿습니다.

최소한 ngModule과 directives/pipes 속성이 공존할 수 없는 이유는 알 수 없습니다. 대안은 ng2, 최대 RC5용으로 작성된 모든 단일 애플리케이션의 모든 단일 구성 요소가 이제 사소한 리팩토링이 필요한 사용되지 않는 코드를 사용하고 있다는 것입니다. 이것은 내가 개발 후반부에 예상할 수 있는 그런 종류의 변화가 아닙니다...솔직히 상당히 당혹스럽습니다.

ngModules는 기본적으로 제대로 구성하려면 대부분의 응용 프로그램을 다시 작성해야 합니다... 그러나 가장 큰 오해는 모듈이 원하는 만큼 크거나 작을 수 있는 현실에서 특정 범위 수준을 강요한다는 것입니다. be.

모든 단일 구성 요소에 대해 새 모듈을 절대적으로 생성해야 하는 경우 더 많은 상용구 = 유효합니다.

대부분의 응용 프로그램은 모든 단일 구성 요소에 대해 모듈을 생성해야 함 = 유효하지 않음(특히 스마트/벙어리 구성 요소 패턴 및 기능 패턴을 사용하는 경우)

오늘 처음으로 많은 동료들이 나에게 전한 클라이언트 측 / JavaScript 피로를 느꼈습니다. 나는 지난 며칠 동안 새로운 RC5 모듈을 사용하기 위해 RC4 애플리케이션을 리팩토링하는 데 수많은 시간을 허비했습니다.

특히 개발자가 구성 요소 종속성을 구성하려는 방식에 대한 선택권을 제공하는 것과 관련하여 이 스레드의 여러 감정에 전적으로 동의합니다. 나는 더 큰 ngModule이 구성 요소 간의 명확한 종속성 그래프를 희석시키고 더 작은 ngModule이 각 구성 요소에 추가적인 상용구 코드를 추가하는 것을 싫어합니다. 모듈을 분석할 때 내가 아는 것은 참조된 구성 요소 중 적어도 하나에 모듈의 가져오기 또는 형제 선언의 내용이 필요하다는 것입니다. 모듈을 여러 개의 다른 모듈로 분리하면 기본적으로 새 모듈에 필요한 종속성을 결정하는 데 시행착오를 겪게 됩니다(컴포넌트 템플릿을 주의 깊게 검사하면 어느 정도 도움이 됩니다).

마지막으로 구성 요소를 내보내는 것을 "잊은" 경우 구성 요소가 렌더링되지 않고 오류가 표시되지 않습니다. 매우 평평한 모듈 그래프가 있으면 쉽게 찾을 수 있습니다. 레벨이 많을 때는 거의 불가능합니다!

이 단계에서 나는 낙담하고 실망하고 낙담합니다. 나는 지금 내가 앞으로 나아갈 수 있을지 모르겠다. 더 나은 균형을 찾을 수 있기를 진심으로 바랍니다.

이 단계에서 나는 낙담하고 실망하고 낙담합니다. 나는 지금 내가 앞으로 나아갈 수 있을지 모르겠다. 더 나은 균형을 찾을 수 있기를 진심으로 바랍니다.

여기서 요점은 이 기술이 생산 준비가 되기를 기다리는 수많은 개발자가 있으며 릴리스 후보라고 하지만 모든 새 후보는 획기적인 변경을 가져오고 알파처럼 느껴진다는 것입니다.

많은 팀이 새 앱을 위한 아키텍처에 몇 시간을 투자했으며 이제 모든 것이 엉망진창이 되었다고 확신합니다.

다음 주요 변경 사항은 무엇입니까? 상상조차 할 수 없지만 누군가가 다음 주요 변경 사항을 소개할 방법을 찾을까 두렵습니다.

RC5 블로그 게시물에서:

하지만 Angular 2 코드를 전혀 작성하지 않았다면 아마도 "그런데 왜 내가 이 모든 것을 나열해야 합니까!?"라고 자문했을 것입니다. - 특히 Angular 2의 특정 지시문과 파이프가 "특별"하다는 것을 알게 된 경우 - 아무것도 하지 않고도 전체 애플리케이션에서 사용할 수 있습니다(예: *ngFor / *ngIf / *ngSwitch).

나는 개인적으로 꽤 오랫동안 누군가가 그 질문을 하는 것을 보지 못했습니다. RC5까지 Angular 팀, 온라인 학습 리소스, 책 등은 모두 이러한 선언이 필요한 이유를 매우 명확하게 만들었습니다. 그리고 모든 사람이 오래전에 그 사실을 받아들인(일부는 수용한) 것처럼 보입니다.

일부가 "특별"하고 선언할 필요가 없는 이유에 대한 질문에 관해서는 "축복"을 정당화할 수 있을 만큼 어디에나 있는 중요한 "낮은 수준" 지침 목록이 있다는 데 반대하는 사람은 없을 것입니다. 플랫폼 소유자(Angular 팀)가 전 세계적으로 사용할 수 있습니다.

단일 ngModule에 대한 지시문 호이스팅을 처리하는 코드가 이미 있고 해당 코드가 최종 사용자에게 보이지 않는 경우 두 접근 방식을 모두 허용하면 어떤 피해가 있습니까? 개발자가 접근 방식을 혼합하여 사용할 경우 어떤 일이 발생할 수 있는지에 대한 일부 복잡성을 인식하지 못할 수 있으므로 이는 진정한 질문입니다. Angular 2에는 모델 대 템플릿 기반 형식, 3가지 다른 언어 선택, 입력/출력/호스트 데코레이터 대 속성 접근과 같은 다른 "분할 선택"이 많이 있습니다.

계속할 수 있지만 내가 말하려는 요점은 Angular 팀과 커뮤니티가 _release에서 더 명시적인 것이 _좋은_ 일이라는 메시지를 전달하기 위해 상당한 시간을 투자했다는 것입니다. 후보 5_ 모든 시간의 -- 꽤 오랫동안 문제가 되지 않았던 해결책을 우리에게 제시합니다.

팀원 중 누군가가 끼어들고 싶은 느낌이 듭니까? 나는 이것이 반향실이 되는 것을 원하지 않습니다. 나는 논쟁의 다른 쪽을 듣고 싶습니다. 도구, 교육 또는 우리가 겉으로 보기에 최종 릴리스에 얼마나 근접했는지와 같은 것들을 고려하지 않고 갑자기 너무 큰 것이 나온 것 같습니다.

이 토론은 매우 기대되는 Angular 2: 주요 변경 사항으로 일찍 개발을 시작하려는 많은 개발자에게 매우 큰 문제를 제기했습니다. 저는 베타 17부터 Angular 2를 기반으로 한 개념 증명을 많이 했고 중요한 회사와 조직에서 이를 채택했습니다. 후회는 안 하지만 잘 했는지도 모르겠다. 가장 최근의 프로젝트 중 일부는 POC였으며 전투는 Vue.js에 대한 것이었습니다. Angular 2는 분명히 그 싸움에서 승리했습니다. 그러나 오늘날 모든 코드 재작성, 변경 사항 변경, RC 릴리스가 아닌 사람들이 저를 쫓기 시작하고 상당히 심각해졌습니다. 내가 Vue나 React 개발을 제안했다면 그렇지 않았을 것이고 Angular 2가 사람들을 넣을 수 있다는 불신 때문에 매우 실망스럽습니다.

Angular 팀과 동일한 릴리스 후보 정의를 공유하지 않는 것 같습니다.

NgModule 주제에 관해서는 @jpsfs 에 완전히 공동 서명했습니다. 모듈 선언 내에 모든 구성 요소와 마이크로 구성 요소를 나열해야 하는 경우 prune 기능이 어딘가에 있거나 모든 것이 강력하기 때문에 모델링의 왕, 대규모 프로젝트에는 너무 민감합니다...

이 추가 높은 수준의 모듈성은 거의 불가피하다고 생각합니다. 다양한 경쟁 프레임워크는 결국 유사한 것으로 끝날 것입니다.

그러나 이 새로운 거친 모듈 시스템을 기본 모듈 시스템과 완전히 직교하도록 만드는 것이 정말로 필요한지, 아니면 각 최상위 디렉토리와 그 안에 포함된 모든 Es6 모듈을 암묵적으로 만들 수 있었는지 궁금합니다. 거친 NgModule로 구성됩니다. 아마도 이러한 규칙 기반 메커니즘이 현재 메커니즘 위에 추가될 수 있으므로 이러한 규칙을 따르려는 프로젝트에 대해 NgModule 상용구를 제거할 수 있습니다.

(물론 나는 "RC" 단계의 이러한 중대한 변화에 대한 좌절감을 여기 다른 사람들과 공유합니다. 하지만 코어 팀도 모든 작업을 완료했다면 상위 레벨을 공격했을 것입니다. 모듈성, 그리고 그것을 추진하는 힘(지연 로딩, 사전 컴파일)은 릴리스 후보 단계가 아니라 프로젝트의 시작 단계에 훨씬 더 가깝습니다. 인생이 그렇지만 항상 뒤돌아보고 "만약 우리가 우리가 지금 알고 있는 것을 그때도 알고 있었다...")

컴파일 지원이 ngModule 출현의 주된 이유인 경우 지시문 및 파이프에 대한 기존 구성 요소 기반 범위를 확실히 대체해서는 안됩니다.
반면에 앵귤러 컴파일러는 경로 구성 및 종속성을 기반으로 이론적으로 자체적으로 애플리케이션 코드를 적절한 컴파일 단위(모듈)로 분할할 수 있습니다.

개인적으로 나는 이 변화가 큰 이점 없이 상용구를 낮추고 있다고 생각합니다.

모듈을 사용하는 대신 구성 요소를 응용 프로그램의 단위로 사용할 수 있다고 주장할 수 있습니다. 이것은 아마도 사람들이 rc-5 이전에 하던 일입니다.

모듈이 이 프레임워크의 내부 목적(예: 지연 로딩 및 관련 항목)에 필요한 경우 코드를 오염시키고 더 나쁜 코딩 경험을 만들지 않도록 개발자에게 어떻게든 숨겨야 합니다. 그리고 나는 유지 보수에 대해 이야기하지도 않습니다 ...

내가 angular2를 처음 봤을 때 나는 '이봐, 그들은 이것을 가지고 올바른 방향으로 가고 있다. 마치 그들이 angular 1에서 뭔가를 배운 것 같다'고 생각했다. Angular 1에서 내부 모듈을 버리고 대신 ES 모듈을 사용했으며 다른 변경 사항(구성 요소, typescript 등)도 환영했습니다.

그러나 이것이 안정되기를 기다리면 기다릴수록 깨는 변경 사항, 문서 부족 및 빈약한 오류 메시지 때문에 저를 움츠리게 만듭니다. 이제 이 NgModules를 사용하고 기본적으로 Angular 1 이후 변경한 하나 이상의 훌륭한 작업을 실행 취소합니다.

설상가상으로 rc-2 또는 3(이론적으로 거의 안정적임)으로 시작한 앱이 있는 경우 이제 좋은 angular2 rc-5 앱을 만들기 위해 많은 작업을 수행해야 하며 어떻게든 고객 및 기타 개발자 이거. 그리고 내가 그렇게 한다 해도, 신은 당신이 다음에 무엇을 바꿀지 알고 있고 내 일이 헛된 것일 수도 있습니다.

나는 Angular 2가 얼마 동안 초기 단계라는 것을 알고 있지만 우리는 RC-5이고 사람들은 지금 Angular 2를 사용하여 꽤 견고한 프로젝트를 가지고 있으며 API 관점에서 깨는 것뿐만 아니라 방법으로 깨는 변경을 계속하고 있습니다. Angular로 생각하는 것.

ngFor가 좋지 않고 일부 가져오기가 변경되거나 5개 릴리스에서 구성 요소 주입이 동적으로 3번 변경되지만 이것은 수용하고 이해할 수 있습니다. 앱뿐만 아니라 개발자가 이 프레임워크에서 생각하는 방식을 깨는 변경 사항을 가져오는 것은 개발 주기의 후반부에 너무 늦어 불행히도 받아들일 수 없습니다.

어쨌든, 보시다시피 많은 사람들이 내 말에 동의하고 일부는 더 화가납니다. 당신은 사람들이 신뢰하는 거대한 프레임워크를 가지고 있지만(대부분 Google이기 때문에) 그것에 모든 것을 걸 수 없거나 모든 사람에게 선택권이 있기 때문에 놀랄 수 있습니다(JS에 대해 이야기할 때 많은 것이 있습니다).

새 모듈에 템플릿이 있으면 구성 요소가 될 수 있습니다. 그것에 대해 생각해보십시오.

다음 단계는 모든 변수와 기능을 구성 요소에서 모듈 클래스로 이동하는 것입니다. 진지하게. 그런 다음 우리는 반짝이는 모듈 내에서 _가능한 모든_ 행동의 거대한 중앙 라이브러리를 갖게 되었습니다. 이것은 굉장할 것입니다! 왜 선언과 종속성을 중앙 집중화하는 것을 중단했는지 모르겠습니다. 더 많은 분산화되고 구조화된 코드 라인이 있습니다!

핵심 팀의 누군가가 이 모든 것에 대해 말할 수 있습니까? 지난 주간 회의의 메모에서 팀은 더 이상 사용되지 않는 API를 제거하는 작업을 진행하고 있습니다.

@mhevery

오늘 업그레이드했을 때 이 전체 게양 작업으로 인해 응용 프로그램이 정말 미묘하게 손상되었습니다.

• 완전히 관련이 없는 구성 요소에서 해당 클래스가 스타일 지정에 사용되고 갑자기 구성 요소를 인스턴스화하기 시작했기 때문에 구성 요소의 선택기를 클래스에서 요소로 변경해야 했습니다.
• SpectrumComponent 라는 두 개의 구성 요소가 있었기 때문에 #10850만 존재한다고 확신합니다(선택기 없이 탐색할 하나의 전체 페이지와 선택기로 시각화하기 위해 여러 구성 요소에서 사용되는 "공유" 구성 요소 하나). 호이스팅이 혼동될 수 있습니다. directives: 선언은 그렇지 않습니다.

내 SVG 구성 요소의 경우 사용자 정의 요소를 사용할 수 없기 때문에 이제 더 큰 문제가 됩니다. 클래스 선택기가 애플리케이션의 다른 곳(!)에서 구성 요소 인스턴스화를 트리거하지 않도록 범위를 지정하는 방법을 아직 모릅니다.

요즘은 대규모 프로젝트에서 "베타" 및 "릴리스 후보"(ASP.NET Core가 또 다른 유명한 예임)의 의미를 무시하는 것이 유행하는 것 같습니다. 그러나 문자 그대로 어디에서나 응용 프로그램을 자동으로 중단시킬 가능성이 있는 주요 변경 사항에 직면하면 생각보다 실망스럽습니다. 그러한 변화와 함께 오는 약속이 하루빨리 결실을 맺기를 진심으로 바랍니다.

ngModules는 의미가 있습니다. 구성 요소 수준에서 선언/제공하는 기능을 제거하면 그렇지 않습니다.

작은 예

다양한 대화 상자가 포함된 응용 프로그램이 있습니다(일부 간단한 대화 상자 - 이를 단순-1 및 단순-2라고 부르고 다른 구성 요소를 포함하는 복잡한 대화 상자를 복합 3이라고 합시다).

현재 나는 간단한 폴더 구조를 가지고 있습니다 (분명히 앱은 이것에서 벗어났습니다)

- dialogs
   - simple-1 (containing single component and template for simple-1 dialog)
   - simple-2 (containing single component and template for simple-2 dialog)
   - complex-3 (contains the main complex-3 component plus a number of other internal components)
      - internal-component-1
      - internal-component-2
      - internal-service-3

나에게 이것은 격리된 기능 모듈에 넣을 수 있는 완벽한 기능 세트입니다. 그래서 나는 덧붙인다

   dialogs.module.ts
   - simple-1
   - simple-2
   - complex-3
      - internal-component-1
      - internal-component-2
      - internal-service-3

그리고 Simple1Component, Simple2Component 및 Complex3Component를 DialogsModule에 선언으로 추가합니다. 완벽하고 잘 작동하며 완전히 의미가 있습니다.

하지만...

complex-3의 모든 내부 구성 요소는 어떻습니까? 이제 두 가지 옵션이 있습니다.

• 모든 외부 복합 구성 요소 및 서비스를 DialogsModule에 추가합니다. 이것은 이제 대화 모듈의 모든 것이 내부(내부 구성 요소 1, 내부 구성 요소 2, 내부 서비스 3)에 대해 알고 있기 때문에 복합 3의 캡슐화를 깨뜨리기 때문에 잘못된 결정입니다.
• complex-3 자체를 모듈로 만드십시오. 이렇게 하면 범위 지정 문제가 해결되지만(다른 모듈에서 모듈을 내보낼 수 있으므로 클라이언트는 래퍼 모듈만 가져오기만 하면 됨) 이제 비슷한 그룹(대화 상자)에 대한 구성 요소와 모듈이 혼합되어 있습니다.

이들 중 어느 것도 실제로 의미가 없으며 응용 프로그램이 확장됨에 따라 둘 사이의 충돌만 증가할 것입니다.

나에게 합리적이고/명백하고/유지할 수 있는 유일한 솔루션은 모듈을 사용하여 최상위 구성 요소(simple-1, simple-2, complex-3)를 내보내지만 complex-3 _component_가 자체 내부 구성 요소를 정의하도록 하는 것입니다.

/ 참조: @robwormald

나는 @kylecordes 가 새로운 ngModules를 추가하는 대신 기존 Typescript 모듈 시스템을 사용하여 코드의 코스 그레인 컬렉션을 정의하는 것에 대해 이전에 말한 것에 대해 생각했습니다. Typescript 모듈을 사용하여 일대일 방식으로 ngModules를 정의하는 예제를 제출하고 싶습니다. 의견과 생각을 환영합니다.

https://github.com/jbalbes/autoNgModule

10901

내가 뭔가를 놓쳤을 수도 있지만 지연 로드되지 않은 모듈에서 종속성 주입이 작동하는 방식은 "대형 프로젝트"에서 큰 문제가 될 수 있습니다(내 문제는 아니며 이미 고통받고 있습니다).

이것은 흥미 롭다. 우리는 이미 Angular1에 엔터프라이즈 애플리케이션을 가지고 있습니다. 그리고 우리는 다양한 모듈에 대한 패키지를 정의하기 위해 requirejs를 사용하고 있습니다(각 모듈에는 10-20개의 지시문/서비스/필터가 포함되어 있습니다). 이러한 패키지를 프로덕션용 단일 파일로 묶습니다(주 지시문 제외). 지시문은 사용될 때 애플리케이션에 지연 로드됩니다(필요한 지시문을 지연 로드하는 핵심 지시문이 있습니다).

우리의 응용 프로그램 라우팅 페이지 템플릿은 cms 응용 프로그램에 보관되며 cms 사용자는 다른 페이지 템플릿 간에 기본 지시문 기반 UI 위젯을 끌어다 놓을 수 있습니다(이것이 브라우저 로드 시 기본 스크립트 파일 크기를 줄이기 위해 지시문에 대한 지연 로드 지원이 필요한 이유입니다. 우리 애플리케이션의 대부분은 지시문 기반 위젯을 기반으로 함)

Angular1을 사용하면 레지스터 공급자에 대한 참조를 가져와 모듈에 지시문을 지연 로드할 수 있습니다.
이 유형의 구성 요소를 모듈에 지연 로드하고 Angular2에서 dom으로 컴파일할 수 있습니까?

나는 다른 사람들이 ngModules가 문제를 찾는 솔루션이라고 제안한 것에 동의합니다. 내 생각에 LazyLoading의 잠재적인 이점은 구성 요소 지시문/파이프 종속성의 강제 사용 중단을 정당화하지 않습니다. 여기에서 내가 틀렸을 수도 있지만 대부분의 응용 프로그램은 ngModules가 제공하는 유일한 진정한 이점인 Lazy Loading의 실질적인 이점을 실제로 보지 못할 것 같습니다.

아마도 ngModules는 개발 구조/패턴을 더 좋게 만들기 위해 시도하고 있을 것입니다(그리고 아마도 성공할 것입니다). 그러나 지금까지 API를 보고 논의한 것이 거의 없다는 것을 기반으로 하면 더 복잡한 방향으로 이동하고 있습니다. 따르고 유지합니다.

또한 다른 모듈 시스템이 정말로 필요합니까?

NgModule이 이전에 처리할 필요가 없었던 새로운 종류의 기능을 추가한다는 점에 아무도 이의를 제기할 수 없습니다. 그리고 나는 누구보다도 RC5 이전의 단순함, 특히 매우 작은 프로그램이 없어진 점을 높이 평가합니다. 나는 또한 사람들에게 Angular 1에는 자체 모듈 시스템이 있지만 Angular 2에서는 기본 언어의 모듈 시스템을 사용한다는 것을 사람들에게 말할 수 있는 것이 매우 그리워요. 죄송합니다.

그러나 실제로 많은 기술 책임자 및 대기업을 구축하려는 대기업의 기타 의사 결정권자를 포함하여 지연 로딩 및 템플릿 사전 컴파일에 매우 관심이 있는 사람들이 많이 있습니다. 둘 다 실질적으로 가능합니다. NgModule에 의해.

그래도 한 가지 더. 새로운 Angular 모듈에 대해 가장 마음에 들지 않는 부분은 이름입니다. 모듈이라는 단어가 너무 오버로드되었습니다. 저는 어제 여기 다른 개발자들에게 이것에 대해 이야기했습니다. 우리는 "패키지"라는 단어를 대신 좋아합니다. 비슷한 아이디어를 잘 포착하고 같은 이름을 가진 경쟁 제품이 많이 없습니다. 자바스크립트 생태계에서.

@kylecordes 이름에 대한 문제 https://github.com/angular/angular/issues/10087

거기에 제시된 논리는 '모듈'이라는 단어를 사용하는 것 또한 부적격하지 않습니까? 그 이상은 아니더라도 많은 개념과 충돌하기 때문입니까?

@Barryrowe 는 스스로 더 잘 말할 수 없었습니다. 실제로 대부분의 앱이 이점을 얻지 못할 것 같습니다. 결국 복잡성이 추가됩니까? 내가하지 희망.

그러나 이 새로운 거친 모듈 시스템을 기본 모듈 시스템과 완전히 직교하도록 만드는 것이 정말로 필요한지, 아니면 각 최상위 디렉토리와 그 안에 포함된 모든 Es6 모듈을 암묵적으로 만들 수 있었는지 궁금합니다. 거친 NgModule로 구성됩니다. 아마도 이러한 규칙 기반 메커니즘이 현재 메커니즘 위에 추가될 수 있으므로 이러한 규칙을 따르려는 프로젝트에 대해 NgModule 상용구를 제거할 수 있습니다.

이것이 핵심입니다. ESModules는 응용 프로그램을 올바르게 구성하면 응용 프로그램을 구성하는 데 매우 잘 작동합니다. 예를 들어, 상위 수준에서 단순히 다시 내보내기만 하면 API의 최상위 수준에서 깊이 중첩된 내보내기를 쉽게 사용할 수 있습니다. 나는 또한 일반적으로 프레임워크에 더 많은 선택적 규칙을 추가하는 것에 찬성합니다.

내가 angular2를 처음 봤을 때 나는 '이봐, 그들은 이것을 가지고 올바른 방향으로 가고 있다. 마치 그들이 angular 1에서 뭔가를 배운 것 같다'고 생각했다. Angular 1에서 내부 모듈을 버리고 대신 ES 모듈을 사용했으며 다른 변경 사항(구성 요소, typescript 등)도 환영했습니다.

그러나 이것이 안정되기를 기다리면 기다릴수록 깨는 변경 사항, 문서 부족 및 빈약한 오류 메시지 때문에 저를 움츠리게 만듭니다. 이제 이 NgModules를 사용하고 기본적으로 Angular 1 이후 변경한 하나 이상의 훌륭한 작업을 실행 취소합니다.

실제로 Angular 2는 AngularJS가 개발되었을 때 사용할 수 없었던 풍부한 신흥 웹 기술 스택을 활용해야 했습니다. 그러나 Angular 2에 대해 내린 많은 설계 결정에 대한 정당화는 "웹 구성 요소는 지원되어야 함"이었지만 아이러니하게도 프레임워크는 점점 더 많은 방식으로 표준에서 벗어나고 있습니다. 이제 표준이 나쁠 때 표준에서 벗어날 좋은 이유가 있습니다.

프레임워크가 핵심 도구를 최대한 활용하지 않는 것 같습니다. 예를 들어, TypeScript 선언은 정확히 관용적이지 않으며 any 및 any[] 로 가득 차 있습니다. 또한 API의 사용성과 도구성을 향상시키는 강력한 언어 기능을 무시합니다. export declare type Type = Function 와 같은 혐오스러운 내용도 포함되어 있습니다.

흥미롭게도 상당 수의 결정이 Dart와 관련된 것으로 판명되었습니다. Dart는 대부분의 Angular 사용자가 신경 쓰는 것이 아닙니다. TypeScript와 비교하여 유형이 무엇이고 어떻게 사용되는지에 대한 개념이 매우 다릅니다. Dart <-> JavaScript interop은 종종 시작이 아닙니다.

@aluanhaddad , dart 구현은 최근에 별도의 프로젝트로 분기되었으므로 귀하의 우려 중 일부가 곧 해결되기를 바랍니다.

이 변경으로 인해 전체 LOC 및 구성 요소 종속성의 정신적 모델링 측면에서 상당한 수준의 복잡성이 추가되었습니다. 내 구성 요소 파일은 약간 더 깨끗하지만 명시적 및 적절한 종속성 정의를 희생하고 중복 느낌 .module 파일이 추가됩니다.

상용구를 줄이는 것은 좋은 일처럼 들리지만 과도할 수 있다고 주장하고 싶습니다. 더욱이, 이 특정한 보일러 플레이트 감소 노력은 완전한 감소와 반대되는 보일러 플레이트의 움직임으로 더 잘 설명되는 것 같습니다.

저는 Angular가 더 복잡한 빠른 시작을 향한 경향이 있다고 생각합니다. 툴체인 설정과 관련하여 이미 처리해야 할 것이 상당히 많고 가장 기본적인 애플리케이션이라도 이해해야 하는 파일 및 항목 목록(모범 사례를 준수하는 경우)이 늘어나고 있습니다.

. @jbalbes 감사합니다, 반갑습니다.

@radusuciu 당신이 절대적으로 맞습니다. 이것은 상용구의 감소가 아니라 해당 상용구를 애플리케이션의 다른 영역으로 옮기는 것입니다. 다른 사람들이 이미 말했듯이 구성 요소 수준 범위 지정과 NGModule 수준 범위 지정 간에 충돌이 있는 사람은 없습니다. 우리에게 필요한 것은 애플리케이션별 사용법과 의미를 기반으로 애플리케이션의 손상을 줄이기 위해 사용할 수 있는 구성 요소, 지시문, 파이프 및 서비스를 선택할 수 있는 세분화된 범위 지정입니다.

모듈이 앱 작성자에게 모호한 실제 가치의 복잡성을 더 추가한다는 것은 나에게 작은 놀라움입니다. 그것들은 원래 디자인의 일부가 아니었고 다른 주요 변경이 이루어지지 않으면 다른 것들이 벽에 부딪혀 작동하도록 만들 수 없었기 때문에 늦게 추가된 것처럼 보입니다(지연 로딩, 컴파일 등...).

앱 개발에 대한 모든 의미와 "다른 약속된 기능이 작동하게 하는 것"에 대한 모든 의미는 추가되었을 때 의제에서 높았지만 더 많은 앱이 RC5로 변환됨에 따라 더 명확해지기 시작했다고 생각합니다.

내 앱을 모듈로 변환하려는 시도조차 시작하지 않았습니다. 아마도 RC4에서 죽을 것입니다. 너무 많은 부분을 완전히 재작업해야 하고 내가 얻을 수 있는 모든 노력은 훨씬 더 큰 런타임 번들로 다음 주요 변경 RC에 더 가까워지는 것입니다. . RC는 진행할수록 더 안정적이고 완성도가 높아져야 하는데, 그렇지 않습니다.

Gang, NgModule은 많은 사람들이 웅변적으로 설명했듯이 짜증스럽습니다. 그러나 실제로는 그렇게 큰 문제가 아닙니다. 여기(Oasis Digital / Angular Boot Camp)에서 우리는 이미 수많은 작은 것들을 RC5로 업데이트했으며, 이것은 (오랫동안의 연구와 이해 끝에) 완료되었습니다.

모든 사람의 앱은 다르게 영향을 받습니다. 또한 Angular 2의 변동 및 변경에 대한 귀하의 태도는 앱 제공에 집중하는 경우와 Angular 2에 대한 교육 및 지원도 판매하는 경우 다를 수 있습니다. 저에게 RC5로 업그레이드하는 모든 작업은 완전히 죽었고 노력을 낭비했습니다. 실제로 부정적인 이점(더 큰 번들)을 제공하므로 정당화하기 어렵습니다.

RC6*에 도달하기 위해 우리 플랫폼에서 5일 동안 푸시하는 것의 이면에서 내 생각을 말할 것이라고 생각했습니다. 내 원래 의견이 여전히 유효하지만 이 이정표에 도달한 것에 대한 안도감이 있다고 생각합니다. 가장 큰 어려움은 계속해서 새로운 라우팅 구문을 사용하는 것입니다. 비어 있는 path: '' 규칙이 너무 많습니다! (나는 여깁니다) 하지만 그것은 아마도 우리가 추상화할 것입니다.

nightlies의 NgModules의 경우 오류 메시지가 개선되어 전체 프로세스를 작업하기가 조금 더 쉬워지고 있습니다. 구성 요소 및 지시문은 일반적으로 문제를 찾기 위해 방대한 NgModule 종속성 트리를 탐색하지 않는다는 충분한 정보로 올바르게 구성되지 않은 경우 호출됩니다. 지금 우리가 직면한 주요 문제는 명백한 오류 메시지가 없는 페이지에서 기능이 누락되었다는 것입니다. 이는 일반적으로 구성 요소가 올바르게 선언되지 않았거나 가져오기/내보내기되지 않았기 때문입니다. 조금 까다롭지만 교육을 받으면 충분히 다룰 수 있습니다. 테스트는 이제 우리의 다음 단계로 완전히 물 속에서 죽었습니다. 그러나 기능 푸시와 마찬가지로 우리는 결국 거기에 도달할 것입니다.

우리는 심호흡을 하고 며칠 동안 다른 일을 했다가 부숴버렸습니다. 그것이 무엇이든 우리는 다음 라이딩을 위해 꽉 잡고 있습니다! 작든 크든 이것으로 인해 영향을 받는 모든 사람에게 행운을 빕니다. 이 문제에 대해 Angular 팀의 대화가 있었으면 좋았을 텐데, 우리가 직면한 가장 어려운 문제는 의사 소통의 부족이었습니다. 우리는 여전히 NgModules에 대한 카드에 무엇이 있는지 알지 못합니다. 지난 주 회의 메모에는 통찰력이 제공되지 않았습니다. 이번 주에 어떤 일이 일어나는지 봅시다!

@SaltyDH 귀중한 피드백이라고 생각합니다.
커뮤니케이션에 대한 불만은 정말 적절하지 않다고 생각합니다.

구현 담당자는 새 릴리스를 빌드하고 문서 담당자는 문서를 업데이트합니다.
문서는 이미 코딩된 후에만 문서화할 수 있기 때문에 일반적으로 명백한 이유로 다소 뒤쳐져 있습니다. 문서를 작성하는 것도 힘들고 시간이 많이 걸리는 작업입니다.

출시된 날 다음 릴리스로 전환하거나 nightlies를 사용하더라도 아직 모든 것이 전달되지 않았다고 불평하는 것은 다소 불공평합니다.
Angular 팀은 또한 모든 경우에 사용자에게 어려움을 야기할 수 있는 것이 무엇인지 미리 알 수 없습니다.

Gitter 및 문제에 대한 지원을 제공하는 Angular 팀의 구성원이 항상 있습니다.
또한 소수의 Angular 팀 구성원과 수천 명의 개발자가 있는 통신 부담이 상당히 비대칭적이라는 점을 알고 있어야 합니다.

나는 이것이 마스터 빌드(거의 RC6)에서 더 쉽다는 데 완전히 동의합니다.

@kylecordes 어떤 면에서 마스터에서 더 쉽게 작업할 수 있습니까?

NgModules에 대한 디자인 문서(이전 디자인 문서가 작성되었을 때 AppModules로 알려짐)는 RC5가 출시되기 한 달 전에 출시되었으며, 저는 그 문서에 대해 어느 정도 준비했습니다.
또한 NgModule은 새로운 개념이기 때문에 완전히 파악하고 중형 앱을 대형 앱으로 마이그레이션하는 것이 어려웠습니다.
대신 내가 한 것은 먼저 NgModules의 뉘앙스와 Angular 2 애플리케이션을 설계하기 위해 NgModules에서 생각하는 방법을 완전히 이해하는 것입니다. 그런 다음 NgModules를 적용하여 자가 학습 앱을 만들었습니다.
두 번째 단계는 - 현재 앱이 모듈에서 어떻게 분리될 수 있는지 생각한 다음 하향식으로 마이그레이션하는 것입니다. AppModule로 시작하여 한 번에 하나의 모듈을 생성합니다. 이것은 정말 도움이 되었고 최종 앱이 더 체계적으로 보입니다.

그리고 예, Gitter는 RC5가 출시되기 전에도 NgModule에 대한 도움을 제공하는 데 정말 도움이 되었습니다. RC5 이후에는 훨씬 더 잘 배울 수 있는 문서와 블로그가 있습니다.

@zoechi 이 토론을 너무 많이 방해하지 않고 내 의견을 명확히 해야 한다고 생각합니다. 나는 문서를 전혀 언급하지 않았으며, 대부분의 이해는 여기 GitHub에서 커밋과 문제를 검토하는 데서 비롯되었습니다. 저는 괜찮습니다. 제 좌절감은 이 문제에 대한 표현이 부족하기 때문에 발생합니다. 우리는 현재 61개의 댓글을 달고 있으며 계산하고 있습니다. "우리는 이 문제에 대한 모든 사람들의 우려를 알고 있습니다. 이것이 Angular 2에 대한 최선의 접근 방식이라고 진정으로 믿으며, 이로 인해 발생할 어려움을 인식하지만 제품의 미래를 위해서는 더 좋습니다." Gitter는 훌륭하지만 개별 메시지는 Angular 2의 다양한 측면을 이해하려고 노력하는 사람들의 바다에서 종종 길을 잃습니다. 이 매체를 통해 연락했지만 시간대 차이나 다른 우선 순위로 인해 권위 있는 피드백을 얻을 수 없었습니다. 정보에 입각한 결정을 내리는 데 사용할 수 있습니다. 도움이 된 것은 각도 팟캐스트 https://devchat.tv/adv-in-angular/106-aia-angular2-rc5-and-beyond의 Adventures입니다. 덕분에 NgModule 업그레이드를 진행할 수 있다는 자신감이 생겼습니다.

모두 제일 좋다.

피드백을 주셔서 감사합니다. 답변을 받는 데 시간이 오래 걸린 점 사과드립니다. 지난 주에 매우 바빴습니다(내부 Google 앱을 NgModules로 마이그레이션했기 때문에 리팩토링의 고통도 함께 느꼈습니다).

여기에서 몇 가지 질문과 오해를 해결할 수 있는지 보겠습니다.

@NgModule() (및 @Component 및 기타 Angukar 데코레이터)에 대해 가장 먼저 이해해야 할 것은 이것이 순전히 컴파일 시간 구성이라는 것입니다. 이는 앵귤러 컴파일러가 애플리케이션에서 종속성 그래프를 발견할 수 있도록 하기 위해 존재합니다.

데코레이터가 하는 일의 (단순화) 버전은 다음과 같습니다.

//simplified Component decorator
export function Component(componentConfig){
  return function(componentClass){
    Reflect.defineMetadata('annotations', componentConfig, componentClass);
  }
}

어떤 식으로든 데코레이팅된 클래스의 동작을 변경하거나 수정하지 않습니다. 단순히 일부 메타데이터를 첨부하기만 하면 됩니다. Angular는 해당 메타데이터를 사용하여 애플리케이션을 구성하고 템플릿을 컴파일합니다.

JiT 모드에서는 "Just in Time"이 발생합니다. bootstrapModule을 호출하고 첫 번째 구성 요소 렌더링 사이에 Angular의 컴파일러가 Reflect API를 사용하여 클래스에 연결된 메타데이터를 검색합니다.

let metadata = Reflect.getOwnMetadata('annotations', componentClass);

그러나 AoT 모드에서는 약간 다르게 작동합니다. 빌드 시 우리는 _정적으로_(즉, 코드를 실행하지 않고) 데코레이터를 스캔하여 소스 코드에서 동일한 메타데이터를 추출합니다.

이것은 단일 구성 요소를 부트스트랩할 때 잘 작동하지만 여러 루트 구성 요소를 부트스트랩하거나 인증 상태를 기반으로 다른 구성 요소를 부트스트랩하는 등 더 복잡한 작업을 수행하는 개발자로부터 많은 피드백을 들었습니다.

따라서 @Component 데코레이터는 Component를 정적으로 분석할 수 있는 기능을 제공했지만 _Application_을 안정적으로 정적으로 분석하는 기능은 없었습니다.

"응용 프로그램"이라는 우산 아래에 있는 것들

• PLATFORM_DIRECTIVES/PIPES/PROVIDERS
• 이전에 bootstrap()에 추가한 것들
• 컴파일러 수준 설정
• 여러 루트 구성 요소
• 서버 측 사용.

NgModules는 정적으로 분석 가능한 기능 세트에 대한 아이디어를 소개합니다. 흥미로운 점은 AoT 컴파일 모드에서 루트 모듈을 분석하고 애플리케이션의 각 모듈에 대해 ModuleFactory를 _생성_한다는 것입니다. 이것은 미리 컴파일된 모듈 버전으로, 템플릿에서 정적으로 참조하는 팩토리와 "entryComponents"로 표시

Ahead-of-Time 컴파일에 필요한 정보를 이미 추출했기 때문에 실제로 데코레이터를 트리 쉐이크할 수 있습니다. 생성된 루트 Module_Factory_에는 애플리케이션에서 실제로 사용되는 코드만 포함되어 있으므로 모듈화에 대한 패널티를 지불하지 않고 롤업 및 webpack2와 같은 도구가 _더욱 효율적으로 작동할 수 있습니다.

다음 회신에서 더 많은 것을 따르십시오 ...

@robwormald 이런 종류의 배경 정보에 대한 감사의 양을 이모티콘에 넣을 수 없습니다.

감사합니다!

NgModules가 해결하는 또 다른 문제는 다음과 같습니다.

DialogService 또는 이와 유사한 것을 빌드하려는 경우를 고려하십시오.

역사적으로 다음과 같이 할 수 있습니다.

@Injectable()
export class MyDialogService {
  //inject the dynamic compiler 
  constructor(private componentResolver:ComponentResolver){}

  //accept a component and a viewContainerRef
  showDialog(component:Type, target:ViewContainerRef){
    //compile the component into a factory, async
    return this.componentResolver.resolveComponent(component)
      .then(componentFactory => {
         //dynamically insert the compiled componentFactory into the view:
        return target.createComponent(componentFactory);
      })
  }
}

...당신이 좋아하는

myDialogService.showDialog(MyRandomDialogComponent).then(...)

여기서 주의할 점 -

• 외부 templateUrls 및 styleUrls 때문에 JiT 모드의 구성요소 컴파일은 _반드시_ 비동기식이어야 합니다.
• viewContainer는 _componentFactory_를 허용하므로 이제 코드에 문제가 있습니다. 모드를 전환하기 위해 코드를 다시 작성하거나(JiT와 AoT 사이), _또는_ 항상 구성 요소 삽입 API가 비동기식이라고 가정해야 합니다. 이것은 대화 상자의 경우 괜찮을 수 있지만 복잡한 UI를 동적으로 구성하는 경우(대시보드 또는 그리드 보기 등을 생각하십시오) 엄청난 양의 불필요한 Promise 일정이 발생합니다.
• 타사 또는 공유 서비스/구성 요소(예: SharedDialogService)에는 _하나의_ 구성 요소 또는 ComponentFactories를 수락해야 하는 동일한 문제가 있습니다.

이 문제는 동적 구성 요소 삽입(꼭 지연 로딩을 의미하지는 않음)을 수행하는 _any_ 응용 프로그램에서 발생합니다. 대화 상자, 라우터 등은 모두 선택기(foo-bar) 대신 ComponentTypes(클래스)와 상호 작용할 것으로 예상합니다.

따라서 NgModule 데코레이터의 entryComponents 배열에 Component를 추가할 때:

@NgModule({
  declarations: [ MyRandomDialogComponent ],
  entryComponents: [ MyRandomDialogComponent ]  
})
export class MyApp {}

이것이 컴파일러에게 알려주는 것은 "MyRandomDialogComponent와 컴파일된 MyRandomDialogComponentNgFactory 간의 매핑을 생성"하고 _이를 선언된 NgModuleFactory에 저장하는 것입니다.

따라서 위의 dialogService의 NgModule 기반 버전은 다음과 같습니다.

@Injectable()
export class MyDialogService {
  //inject the component factory resolver 
  constructor(private componentFactoryResolver:ComponentFactoryResolver){}

  //accept a component and a viewContainerRef
  showDialog(component:Type, target:ViewContainerRef){
    //*retrieve* the componentFactory by component, sync
   let componentFactory = this.componentFactoryResolver.resolveComponentFactory(component)
   //add the componentFactory to the view, sync
   return target.createComponent(componentFactory);
  }
}

이제 entryModules에 추가한 모든 구성 요소를 동기적으로 검색하여 뷰에 동적으로 삽입할 수 있으며 코드는 현재 있는 모드에 따라 변경할 필요가 _없습니다_, 타사/공유 라이브러리도 컴파일에 대해 걱정할 필요가 없습니다. 논리.

@robwormald 설명 감사합니다

한 가지 질문은 다음과 같습니다. 지시문/파이프 선언을 제거해야 합니까? NgModule과 공존할 수 없는 이유가 있습니까?

저는 저를 포함한 사람들이 NgModule에 대한 "새로운 아이"나 이에 대한 오해가 아니라 많은 사람들과 _잘 작동하는_ 것처럼 보이는 일을 하는 "오래된 방식"이 특히 이 늦은 RC 단계에서 강제로 제거됩니다. 나는 이것이 NgModule 자체에 대한 어떤 저항과도 중요한 차이점이라고 생각합니다.

또한 지시문/파이프 선언을 제거하기 위한 풀 요청이 실행되었음을 알 수 있습니다(https://github.com/angular/angular/pull/10912) - 무엇이든 설정되기 전에 이 시점에서 응답을 얻을 수 있기를 바랍니다. 결석.

미리 감사드립니다. Angular는 의심할 여지 없이 함께 작업하는 것이 즐거웠고 지난 1년 동안 팀의 노고에 깊은 감사를 드립니다+

여기에 "전역 범위"에 대한 몇 가지 설명이 있습니다. 이는 컴파일러와 모듈의 메커니즘을 오해하는 것입니다(완전히 이해할 수 있고 복잡한 내용입니다).

전체 애플리케이션을 단일 NgModule로 덤핑하는 것은 $rootScope에 전체 애플리케이션의 상태를 덤프하는 것이 Angular1에서 "정상"이었던 방식으로 "정상"입니다(읽기: 작동하지만 애플리케이션 설계가 좋지 않음)

Angular 1에서 모듈을 애플리케이션으로 가져오면 모든 것이 단일 인젝터 백에 버려지기 때문에 전체 애플리케이션이 다소 "오염"되었습니다.

Angular2에서 NgModues에는 오염 없이 구성할 수 있는 매우 강력한 범위 지정 메커니즘이 있습니다. 다시 컴파일러로 돌아갑니다.

Angular가 애플리케이션을 탐색하고 컴파일할 때 만나는 각 구성 요소는 _선언된 컨텍스트에서 컴파일됩니다_

예를 들어 - 응용 프로그램에서 공유하려는 일부 기능이 있는 SharedModule이 있다고 가정합니다.

@Component({
  selector: 'shared-component-one',
  template: `
    <div>Shared Component One</div>
    <shared-component-two>
  `
})
export class SharedComponentOne {}

@Component({
  selector: 'shared-component-two',
  template: `
    <div>Shared Component Two</div>
  `
})
export class SharedComponentTwo {}

@NgModule({
  declarations: [ SharedComponentOne, SharedComponentTwo ],
  exports: [ SharedComponentOne ]
})
export class SharedModule {}

SharedComponentOne과 SharedComponentTwo는 SharedModule에서 _선언된_ - 선언은 _소유권을 의미합니다. 따라서 이 두 구성 요소는 SharedModule이 소유합니다. 그러나 SharedComponentOne은 모듈에서 _exported_됩니다. SharedComponentTwo는 SharedModule로 _private_ 상태로 유지됩니다.

SharedModule 를 가져와서 다른 모듈에서 사용하려면 다음과 같이 하십시오.

@Component({
  selector: 'some-component',
  template: `
    <div>hello from some component</div>
    <shared-component-one></shared-component-one>
  `
})
export class SomeComponent {}

@NgModule({
  imports: [ SharedModule ],
  declarations: [ SomeComponent ]
})
export class SomeModule {}

...컴파일러가 SomeComponent 컴파일을 시작하면 shared-component-one SharedModule ( SharedComponentOne 내보내기)를 SomeModule 로 가져오기 때문에

흥미롭게도 컴파일러는 실제로 SharedComponentOne을 컴파일할 때 SharedModule "내부"에서 컴파일하므로 외부 세계에 노출되지 않은 SharedModule 내의 항목을 사용할 수 있습니다.

이것은 Component.directives로 작업하는 방법과 매우 유사하며 이 경우 동일합니다.

탭 기능과 같은 것이 있다면 생각해보십시오.

@Component({
  selector: 'my-tabs',
  template: '...'
})
export class TabsComponent {}

@Component({
  selector: 'my-tab',
  template: '...'
})
export class TabComponent {}

이 두 구성 요소는 모두 최상위 수준이며 의존할 계층적 관계가 없습니다. 이것은 사람들이 하는 일종의 관습의 폭발로 이어졌습니다.

export const TAB_DIRECTIVES = [ TabsComponent, TabComponent ]

더 복잡한 탭 기능에는 탭의 여러 인스턴스를 관리하는 서비스가 있을 수 있으므로 해당 경우도 처리해야 합니다...

export const TAB_PROVIDERS = [ ... ]

그리고 그것을 사용하는 것은 수출 및 수입에 필요한 모든 것을 기억하는 연습이 됩니다...

import {TAB_DIRECTIVES, TAB_PROVIDERS}

그런 다음 사용하려는 _모든 곳에서_ 올바른 위치에 이러한 모든 것을 제공합니다. 또한 이 시점에서 기능에 필요한 모든 것을 가져오는 것을 잊어버리고 이상한 소리 없는 오류로 끝나거나 필요한 모든 컨텍스트 없이 구성 요소가 컴파일되는 것도 매우 쉽습니다.

NgModule을 사용하면 단일 단위로 패키지화하여 애플리케이션에 전달할 수 있으며 관련 있는 위치에서 가져올 수 있습니다.

여러 모듈에 여러 기능이 분산되어 있을 수 있는 Material Design과 같은 라이브러리의 경우 동일한 가져오기/내보내기 의미 체계를 활용하여 이식성을 더욱 높일 수 있습니다.

@NgModule({
  exports: [ TabsModule, NavbarModule ]
})
export class MaterialSharedModule {}

단일 모듈을 가져오면 모든 애플리케이션에서 구성 요소를 사용할 수 있으며 AoT 시간에는 사용하는 항목만 생성된 코드로 가져올 수 있습니다.

Component.directives/pipes를 제거한 이유에 대해 양방향에서 많은 피드백을 들었습니다. 우리는 동일한 것을 달성하기 위해 두 가지 방법을 사용하는 것이 일반적으로 나쁜 패턴이라고 생각하므로 사람들이 일반적으로 더 적은 코드를 작성할 수 있도록 선택했으며 이전에 Component.directives에서 제공한 명시적 범위를 원하는 사람들은 다음을 통해 _same_ 기능을 수행할 수 있습니다. 모듈 수준에서 범위 지정.

RC5에서 우리는 Component.directives를 "전역" 범위로 일종의 자동 호이스팅을 수행했습니다. 이는 전환을 원활하게 하기 위한 시도였으며 대부분의 사람들에게 효과가 있었지만 이전과 새로운 동작이 혼합되어 몇 가지 이상한 오류와 동작을 일으켰습니다. 이것은 RC6에서 사라집니다(오류 메시지가 개선됨).

게임이 늦게 변경된 이유에 대해서는 사과할 수 밖에 없습니다. 우리는 여러분보다 마지막 순간에 변경하는 것을 좋아하지 않습니다. 결국, 우리는 이전에 프론트 엔드 영역에서 한 번도 해본 적이 없는 방식으로 말 그대로 프레임워크를 구축하고 있으므로 예상치 못한 문제와 디자인 문제에 직면하게 될 것입니다. 이것은 그러한 경우 중 하나였으며 결정을 내리기 전에 핵심 팀 사이에서 강력하게 논의되고 조사되었습니다. 다시 한 번 말하지만 문제를 일으켜 죄송합니다. 그러나 최종 결과는 _응용 프로그램_을 구축하는 훨씬 더 좋은 방법이라고 확신합니다. 이것이 우리가 모두 여기에 있는 이유입니다.

기다려 주셔서 감사합니다. 여기에서 다루지 않은 다른 질문이 있으면 이것을 열어 두겠습니다.

롭

잘했어, @robwormald

몇 가지 관찰 사항을 더 추가하고 싶습니다.

공급자

Rob은 _declarations_, _imports_ 및 _exports_에 집중했습니다. 모듈 _Providers_가 다릅니다.

@Component.providers 목숨! @Component.directives 및 @Component.pipes 만 사라집니다.

@NgModules.providers 및 @Component.providers 둘 다 사용할 수 있습니다. 그들은 다른 목적을 가지고 있습니다:

a) @NgModules.providers "메인" 인젝터(열심히 로드된 모듈의 앱 루트 인젝터)에 공급자를 추가하여 애플리케이션을 _확장_합니다. 이것이 RouterModule 가 사용자가 제공하지 않고도 앱에 라우팅 서비스를 추가하는 방법입니다.

b) @Component.providers _encapsulates_ 구성 요소 인스턴스(및 구성 요소 하위 트리) 범위 내에서 서비스 제공.

두 접근 방식 모두 서로 다른 요구 사항을 충족합니다.

나의 일반적인 조언: _오늘 @Component 에 제공자가 있다면 거기에 두십시오_

기능 모듈

앱을 구성하는 강력한 방법입니다. Angular 모듈 장에는 모놀리식 Angular 모듈에서 기능 모듈 로의 리팩토링에 대한 짧은 섹션이 있습니다. 그것은 꽤 쉽습니다(적어도 몇 번은 해본 적이 있습니다.).

내 앱에서 자연스러운 이음새를 찾습니다. 난 미쳐 가지 않아. 나는 모든 구성 요소를 모듈화하지 않습니다.

머티리얼 디자인이 그렇게 하는 것처럼 보이는 이유는 우리가 원하는 것을 세밀하게 사용할 수 있도록 하기 위함입니다.

그들은 단순히 모든 것을 다시 내보내는 주방 싱크 모듈을 갖게 될 것입니다. 당신은 그것을 가져오고 완료할 수 있습니다. 그러나 내 앱을 조정하는 경우 원하는 MD ​​부품만 내보내는 유사한 _재내보내기 모듈_을 만듭니다.

이것은 모든 라이브러리 공급업체가 따를 수 있는 패턴이며 회사에서 승인한 승인된 가제트의 "키트"를 자체적으로 구성하는 기업에서 의미가 있을 수 있습니다.

선언 종속성 검색

컴파일러는 이제 무언가가 빠졌을 때 알려주는 훨씬 더 나은 작업을 수행합니다. 권장되는 방법을 따르고 구성 요소 선택기 이름에 _항상, 항상 하이픈을 추가_하면 컴파일러에서 선언되지 않은 구성 요소가 있을 때 알려줍니다. 또한 선언되지 않은/인식할 수 없는 데이터 바인딩 및 지시문을 선택합니다.

RC5 이전 버전에서 마이그레이션하면 상실감을 느끼게 됩니다. 이전 directives 및 pipes 목록에서 종속성을 발견하는 지루한 작업을 수행해야 합니다. 그리고 중복을 제거해야 합니다. 이것은 가장자리에 사는 것의 본질적인 불편함입니다.

RC가 이렇게 많이 바뀌면 안 됩니다.

예. 당신은 그것에 대해 팀으로부터 논쟁을 얻지 못할 것입니다. 의도적이지 않았습니다. NgModule 가 필요하다는 것을 알았다면 베타 버전으로 제공했을 것입니다.

그러나 IMO는 RC가 무엇인지에 대한 일부 개념을 맹목적으로 따르고 잘못된 제품을 제공하는 것보다 올바른 제품을 배송하는 것이 좋습니다. 또한 ... 말하기가 그다지 위안이 되지는 않지만 ... 최근에 다른 주요 소프트웨어 회사를 본 적이 있다면 "릴리스 후보"에 대해 동등하게 유연한 개념을 발견했을 것입니다. 어떤 이유에서인지 우리 업계가 가는 방식입니다.

저는 지금 여러 앱을 전환했고 다른 사람들도 그렇게 하도록 도왔습니다. "_그들이 내 치즈를 (다시) 이동했습니다_" 단계를 지나면 꽤 기계적인 마이그레이션이고 모두가 더 나은 위치에 있다고 생각하는 것 같습니다. 어쩌면 그들은 나에게 친절하게 대하는 것일 수도 있습니다. OTOH, 나는 그렇게 좋은 사람들과 어울리지 않습니다 ;-)

(또한, re: 이름)
우리는 이름을 죽도록 자전거를 몰았다. 그것들은 처음에 AppModules라고 불렸지만(구성 요소보다 더 높은 수준인 "앱"을 설명하기 때문에), 충분히 광범위한 용어가 아니었습니다. 패키지, 번들, 배럴, 글로브 등

ES 모듈을 대체하는 것이 아님을 명심하십시오. 트리 셰이킹과 ES 모듈이 모든 Angular 개발자에게 더 잘 작동하도록 하는 확장이며 의미적으로는 ES 모듈이 작동하는 방식(가져오기, 내보내기, 선언)과 유사합니다.

그래서 네이밍이 어렵다. NgModule입니다.

우리는 2.0.0에 대한 완전한 API이므로 릴리스 후 몇 개월 동안 어떤 패턴이 개발되고 어디에서 2.1에 대해 더 나은 추론을 할 수 있는지 확인합니다.

매우 통찰력 있는 의견을 주신 @robwormald @wardbell 에게 진심으로 감사드립니다. 나에게 가장 큰 위로는

"우리는 2.0.0에 대해 완전한 API이므로 릴리스 후 다음 몇 달 동안 어떤 패턴이 개발되고 어디에서 2.1에 대해 더 나은 추론을 할 수 있는지 관찰할 것입니다."

그것은 우리가 몇 주 전에 이미 들었던 것이지만 지금은 이 모든 피드백과 함께 NgModules의 맥락에서 구체적입니다. 이사회에 가서 말할 수 있는 자신감이었습니다. 여기까지 완료되었습니다. 이제 애플리케이션 빌드를 마칠 시간입니다. 또한 이 이정표에 도달한 전체 ng2 팀과 커뮤니티에 축하의 인사를 전하고 싶습니다! 앞으로의 흥미진진한 시간들.

나는 솔직히 당신이 @SaltyDH라고 말할 수 있다고 믿습니다. Angular 2 이탈이 끝났습니다.

그렇다고 Angular 2가 진화했다는 의미는 아닙니다. 향후 릴리스가 있을 것입니다. 하지만 2.0으로 이어지는 이탈은... 끝!

정직함과 명시적인 사용 사례에 대해 대단히 감사합니다. 정말 도움이 됩니다.

NgModule용 API의 이름 지정 및 복제에 대한 간단한 생각은 약간 번거롭다고 생각합니다.

IMO:

@NgModule({
  declarations: [ SharedComponentOne, SharedComponentTwo ],
  exports: [ SharedComponentOne ]
})
export class SharedModule {}

...다음과 같이 더 명확하고 간결할 수 있습니다.

@NgModule({
  private: [ SharedComponentTwo ],
  public: [ SharedComponentOne ]
})
export class SharedModule {}

1) 명명에 대한 WRT(공개 및 비공개 대 선언 및 내보내기), 본질적으로 위의 @robwormald 방식이며 많은 다른 사람들이 설명하고 있다고 확신합니다.

2) (이름 지정 무시) 왜 SharedComponentOne 를 반복해야 합니까? "수출"인 경우 "선언"이어야 하므로 그런 식으로 디슈가를 제거할 수 있다고 말할 수 있습니까?

매우 주관적인 것에 대한 나의 2센트 😄 - 자세한 설명에 다시 한 번 감사드립니다!

@robwormald @wardbell 자세한 설명 감사합니다.

그리고 이 스레드의 앞부분에서 말했듯이 NgModules 는 우리가 더 잘 정리하는 데 도움이 됩니다. 최근의 예는 템플릿 기반 양식에 대한 Validator 지시문을 만드는 것입니다. RC5 이전에는 양식을 생성하는 구성 요소에서 각 지시문을 가져와야 했습니다. 이제 VaildatorModule 에 패키지하고 필요한 곳마다 모듈을 가져옵니다. 나중에 추가하는 모든 Validator는 ValidatorModule 를 가져온 모듈에서 자동으로 사용할 수 있습니다. 종속성에 대한 걱정 없이 템플릿을 업데이트하기만 하면 됩니다.

@JamesHenry declarations , imports 및 exports 는 import , export 및 declare 와 같이 NgModules를 ES6 모듈과 함께 유지하는 데 사용됩니다. ES6 모듈의
나는 Sugaring에 동의합니다. 내보낸 것들은 마술처럼 선언 자동으로 설탕을 제거할 수 있습니다.

@제임스헨리

1) 우리는 멘탈 모델이 es 모듈이 작동하는 방식에 더 가깝기 때문에(적어도 범위 지정 측면에서) 가져오기/내보내기를 고수했습니다. 모듈에서 항목을 선언하고, 다른 모듈에서 항목을 가져오고, 사용할 수 있도록 내보내기 다른 사람.

2) if it is an "export" it must be a declaration, so it could just be desugared that way? -> 위의 MaterialModule 예제와 같이 ngModule을 사용하여 다시 내보내기 전까지 작동합니다. ngModule을 사용하여 다른 모듈에서 선언된 것을 다시 내보낼 수 있는 경우가 많이 있습니다. 그런 다음 추론이 무너집니다.

@robwormald 좋은 댓글! 확실히 블로그 게시물을받을 가치가 있습니다.

지금 @NgModule 를 사용하는 대화 상자 라이브러리 가 있으며 사용자 정의 구성 요소를 entryComponents 에 등록하는 것을 잊어버려 사용자 정의 구성 요소를 추가하는 동안 어려움을 겪고 있는 사용자를 볼 수 있습니다. 이것은 분명히 명확하지 않지만 고급 기능이라 이해가...

시간이 지나면 가라앉을 거라고 확신해요

@shlomiassaf 감사합니다!

다음과 같은 경우도 언급해야 합니다.

Angular의 라우터를 사용할 때 라우터가 entryComponents의 바로 정의라는 사실에도 불구하고 선언 및 경로 구성에 구성 요소를 추가하지만 entryComponents에는 _not_ 추가합니다. (기억 - entryComponent === 선택자가 아닌 클래스로 참조하려는 것)

모든 라이브러리에서 활용할 수 있는 멋진 트릭이 있습니다 ANALYZE_FOR_ENTRY_COMPONENTS 라는 마법의 토큰이 있습니다. https://github.com/angular/angular/blob/master/modules/%40angular/router/src/ 를 참조하세요. 라우터가 사용하는 방법은

따라서 동적으로 삽입된 구성 요소를 처리하는 라이브러리의 경우 다음과 같이 할 수 있습니다.

@NgModule({
  providers: [ DialogService ]
})
export class DialogModule {
  static withComponents(componentList): NgModuleWithProviders {
    return {
      ngModule: DialogModule,
      providers : [
         { provide: ANALYZE_FOR_ENTRY_COMPONENTS, useValue: componentList, multi: true }
      ]
     }
  }
}

처럼 사용

@NgModule({
  declarations: [ MyConfirmDialog, MyQuestionDialog ],
  imports: [
    DialogModule.withComponents([ MyConfirmDialog, MyQuestionDialog ])
  ]
})
export class MyAppModule {}

귀하의 사용 사례에 따라 작동할 수도 있고 작동하지 않을 수도 있습니다.

@JamesHenry declarations 가 private 와 혼동되지 않는 것이 매우 중요합니다. _이 모듈은 이 구성 요소를 선언합니다_. 당신은 공개 또는 비공개에 대해 어떠한 진술도 하지 않습니다. 소유권 주장을 하고 있습니다.

ES6 모듈에서 일어나는 일과 정말 비슷합니다. 파일 내에서 정의하는 모든 것은 해당 파일에 의해 정의된 모듈에 "소속"됩니다. 공개 여부는 export 키워드 사용에 따라 다릅니다.

그리고 ES6 모듈과 마찬가지로 가져온 항목을 _다시 내보낼 수 있습니다_.

저는 declarations 를 동일한 물리적 파일에 물리적으로 모든 구성 요소, 지시문 및 파이프를 배치하지 않아도 되는 "트릭"으로 생각하고 싶습니다(의도한 경우 ES6 모듈에서 수행해야 하는 것처럼 이러한 모든 클래스는 동일한 ES6 모듈에 속합니다.

따라서 저에게 declarations 는 이러한 파일을 하나의 엄청나게 큰 파일에 붙여넣는 대신 사용할 수 있습니다. 그것은 어쨌든 _my_ 멘탈 모델입니다.

한 가지 주목해야 할 점은 모듈 컨텍스트에서 공급자와 구성 요소 간의 논리적 차이입니다.

공급자와 구성 요소는 같은 위치( NgModuleMetadataType )에서 선언되므로 개발자는 공급자가 구성 요소처럼 동작한다고 직관적으로 느낄 수 있습니다. 이는 모듈의 공급자가 해당 모듈에 대한 인스턴스를 생성할 것이라고 생각합니다. .

공급자는 DI에 의해 관리되기 때문에 물론 사실이 아니며 실제로는 응용 프로그램 수준입니다.
모듈의 구성 요소는 내보내지 않으면 비공개이므로 혼동을 일으킬 수 있습니다.

나는 모듈의 개념을 좋아합니다. IMO API의 유일한 문제는 모듈 내에서 동일한 위치에 선언된 공급자와 구성 요소를 갖는 것입니다... 신규 사용자에게는 이해하기 어려운 것입니다.

@wardbell 감사합니다 Ward 정말 정말 대단합니다! 토론에서 방금 언급한 내용을 명확히 하기 위해 Angular 2가 API가 완성되었다고 말할 때 여기서 말하는 네임스페이스는 무엇입니까? @모난/???

@robwormald 감사합니다! 좋은 팁!!!
설탕맛 하나! 시행합니다.

나는 Google 직원이 아니며 아마도 Google 직원이 말할 수 없을 것입니다. 나는 내 두 눈으로 보고 있는 것만 보고할 수 있습니다. @angular/ 라이브러리 세트에서 매우 심각한 API 정지가 발생했습니다.

출시 보류를 정당화할 만큼 충분하지 않거나 깊지 않기 때문에 선반에 앉아 있는 좋은 아이디어가 있습니다. 그래야 한다. 좋은 아이디어는 멈추지 않습니다. 그러나 _이것이 Angular 2.0_이라고 말할 때가 되었습니다.

지금과 "최종" 사이에 사용되지 않는 API의 제거를 약속했습니다. 그것은 조정이 있습니다 ... 누구나 마스터를 보면 알 수 있습니다. 끝난 것 같아요.

@wardbell 수출에 대해 말씀하신 내용을 그대로 반영합니다.
index.ts는 한때 다음으로 채워졌습니다.

export * from 'a.component'
export * from 'b.component'
export * from 'c.component'
export * from 'p.directive'
export * from 'x.service'
export * from 'z.pipe'

이제 export * from my.module 로 줄어듭니다.
NgModule 내보내기에서 모든 물건을 깨끗하게 유지하십시오.
exports: [ AComponent, BComponent, CComponent, PDirective ] 등

@wardbell 제 생각 @NgModules.providers 는 @NgModules.rootProviders 또는 @NgModules.appProviders $이어야 했습니다.

나는 그것이 공급자의 맥락을 명확하게 설명한다고 생각합니다.

@shlomiassaf 오해의 소지가 있습니다. @NgModules.providers 의 효과는 열렬한 모듈과 게으른 모듈에서 다릅니다. 지연 로드된 모듈은 자체 하위 인젝터를 가져옵니다. 즉, _해당 제공자가 _root_ 인젝터가 아닌 _child_ 인젝터에 추가됩니다. 그래서 만약 lazy가 lazy가 lazy를 로드한다면 그것은 진행됩니다.

아마도 다른 이름이 있었을 것입니다. 당신은 _그_가 어떻게 되는지 알고 있습니다. 그러나 rootProviders 는 내가 방금 말한 이유 때문에 개선되지 않았을 것입니다.

@wardbell 은 동의했지만 그 시나리오에 대해 생각하지 않았습니다.

세심한 답변과 소통에 감사하다는 감정을 더하고 싶었습니다. 이것이 실제로 rc-to-final 성장통의 마지막이라면 우리는 경주를 시작합니다. 감사 해요!

다른 사람들이 말했듯이 팀의 피드백은 감사합니다. 그러나 이 개발 단계에서 이러한 종류의 변경은 근본적인 설계 오류를 암시합니다.
우리 자신에게 정직합시다. 우리 모두는 이러한 실수를 저질렀습니다. 따라서 판단하는 것은 아무 가치가 없지만 제가 실수를 하면 저를 겸손하게 만들고 나중에 더 신중하게 되기를 바랍니다. 나는 그것이 Angular 팀에 동일한 영향을 미치고 있다는 인상을 받지 못했습니다.

저는 선언을 동일한 물리적 파일에 물리적으로 모든 구성 요소, 지시문 및 파이프를 배치할 필요가 없도록 하는 "트릭"으로 생각하고 싶습니다. 동일한 ES6 모듈에 속함).

따라서 저에게 선언은 이러한 파일을 하나의 엄청나게 큰 파일에 붙여넣는 대신 사용할 수 있습니다. 그것은 어쨌든 내 멘탈 모델입니다.

@wardbell 어쩌면 근본적인 것을 놓치고 있을지도 모르지만 NgModule.declarations 를 사용하는 것이 ESModules 중 일부만 다시 내보내고 전체를 가져오는 것과 근본적으로 어떻게 다른지 모르겠습니다. 아이러니하게도 ESModule의 주요 한계는 논리적 모듈이 아닌 물리적 모듈의 개념만 제공한다는 것입니다. NgModule 가 어떻게 개선되는지 모르겠습니다. 이는 집계 구문이 다를 뿐 추상화 수준을 의미 있는 수준으로 올리지 않습니다.

또한 NgModules는 다음과 같은 주요 문제를 완전히 해결하지 못합니다.

전체 Function[] 패턴은 모든 면에서 불투명합니다. 검색 가능성을 0으로 떨어뜨립니다. 공급자 배열에 무엇이 있는지 확인하려면 소스를 읽어야 합니다. NgModule.exports 도 마찬가지입니다.

그러나 IMO는 RC가 무엇인지에 대한 일부 개념을 맹목적으로 따르고 잘못된 제품을 제공하는 것보다 올바른 제품을 배송하는 것이 좋습니다. 또한 ... 말하기가 그다지 위안이 되지는 않지만 ... 최근에 다른 주요 소프트웨어 회사를 본 적이 있다면 "릴리스 후보"에 대해 동등하게 유연한 개념을 발견했을 것입니다. 어떤 이유에서인지 우리 업계가 가는 방식입니다.

@wardbell 저에게 RC에 대한 가장 큰 불만은 ng-conf와 google i/o로 인해 Beta가 RC로 푸시되었다는 인상입니다. 진전을 이루기 위해서는 그 이유를 분명히 해야 합니다. 그것은 _마케팅_이었고 기술자로서 우리는 성숙에 대한 이러한 유연한 개념의 추세에 맞서 싸워야 합니다. 베타가 생명을 앗아갈 수 있기 때문에 베타를 판매하는 것이 옳은 것인지에 대한 논의가 있는 계곡에서 유명한 자동차 제조업체를 알고 있을 것입니다. 과장하고 싶지는 않지만 기술자로서 우리 산업이 잘못된 방향으로 가고 있기 때문에 우리 산업이 그렇게 가고 있다면 반드시 말해야 합니다.

ngmodule 접근 방식을 좋아하지만 @robwormald 질문이 있습니다.

구성 요소, 지시문 및 파이프가 없는 공유 서비스가 있습니다. 서비스( forRoot )만 있고 모든 비즈니스 모델 클래스를 포함합니다. app.module 는 ServerApiModule.forRoot() $를 가져오므로 전체 애플리케이션에서 서비스를 사용할 수 있습니다. 서비스 및 비즈니스 모델 클래스를 사용하는 기능 모듈이 이 공유 모듈을 가져와야 합니까? 기술적으로 이것은 필요하지 않지만(오류 없음) 의미론적 관점에서는 의미가 있습니다(오류 없음). 그런 종류의 모듈로 무엇을 해야 합니까? 수입할 것인가 말 것인가? 저는 개인적으로 두 번째 가능성을 좋아합니다. '나는 기능 모듈이고 이 서비스가 필요하고 이 비즈니스 모델 클래스가 필요합니다'라고 되어 있기 때문입니다.

답변 감사합니다!

그래서 나는 라이브러리/모듈러 애플리케이션 라이브러리와 ngModule로 고통을 느낄 수 있습니다.

그러나 여러 번 말했듯이 두 가지 가능한 방법을 혼합하지 마십시오. 그것은 혼란 스러울 것입니다.

따라서 올바른 접근 방식은 각 구성 요소에 대해 ngModule을 선언하는 것입니다.
그러나 이렇게 하면 모든 구성 요소에 대해 훨씬 더 많은 보일러 코더가 되기 때문에 그 방법은 대규모에서도 작동하지 않습니다.

따라서 재료와 같은 구성 요소 및 모듈 선언을 피하기 위해 다소 설탕인 ComponentModule이라는 새 데코레이터를 추가하지 마십시오.

이쪽으로? 구성품이 보이면. 나는 그것이 ngModule의 일부여야 한다는 것을 알고 있습니다. 많은 구성 요소를 함께 묶는 경우가 있는 경우 NgModule을 사용할 수 있습니다. "이전 구성 요소"와 같은 독립 실행형 구성 요소를 원하면 ComponentModule을 사용하고 모든 종속성을 알고 있으며 다른 모듈에 대한 모듈 종속성이 될 수 있지만 일부는 아닙니다.

@nathraQ 올바른 접근 방식이 모든 구성 요소에 대해 NgModule을 사용하는 것이고 그럴 수 있다면 NgModule이 도입되지 않아야 하고 구성 요소가 방금 향상되어야 합니다. 상용구와 관련하여 Angular 2는 너무 무거워서 이 시점에서 거의 중요하지 않습니다.

자체 모듈 시스템이 없는 많은 프레임워크는 구성의 레이아웃 및 가시성을 위한 표준 패턴을 설정하기 위해 규칙을 매우 성공적으로 사용했습니다. 한 현명한 사람은 사실 이후에 관습을 정의할 수 없다고 말했습니다. 그들은 처음부터 거기에 있어야합니다. 나는 이 주장에 회의적이었지만 이 실패는 그가 옳았다는 것을 증명합니다.

@aluanhaddad 죄송합니다. 동의하지 않습니다. 맞춤형 종속성 관리(예: 이 스레드의 시작)가 있는 Angular 1.x의 한 모듈에 대한 사용 사례가 있었지만 컨트롤러, 지시문 및 서비스 집합을 번들로 묶는 모듈에 대한 사용 사례도 있었습니다.

둘 다 유용합니다. 이제 우리는 모든 사람이 이해할 수 있도록 통합하는 방법을 알아내야 합니다.

와우, 긴 글을 읽었습니다 :스마일:

새로운 변경 사항의 장단점을 알 수 있지만 Angular 1에서 문제가 있었던 한 가지 시나리오에 대해 생각하게 되었습니다.

@wardbell @robwormald -

SharedModule 패턴을 사용하고 구성 요소에 대해 동일한 선택기를 사용하는 두 개의 타사 라이브러리(ui-bootsrap vs angular-strap someone?)를 가져오는 경우 my-selectbox 라고 가정해 보겠습니다.

둘 다 가져오려고 하면 오류가 발생합니까? 오른쪽?

여기에서 읽은 한 가지 솔루션은 사용자 정의 모듈의 라이브러리 중 하나를 다시 내보내는 것입니다.
그러나 이는 라이브러리가 업그레이드될 때마다 래퍼 모듈을 계속 업데이트해야 한다는 것을 의미합니다. 아니요?

또한 동일한 이름을 가진 자체 구성 요소 선택기가 있을 수 있습니다(두 번 이상 발생할 수 있는 대규모 프로젝트에서).

이 문제에 대한 권장 솔루션이 있습니까? 아니면 "래퍼 모듈"입니까?
(선택자에 접두사를 사용하지 않기를 바랍니다. 재미가 없었습니다.)

미리 감사드립니다!

이름 공간 또는 접두사는 프로젝트의 규모에 상관없이 일반적으로 좋은 생각입니다. 예, 소규모 프로젝트에서는 더 사소한 것일 수 있지만 타사 모듈이 포함되는 즉시 거의 필수 사항이라고 말할 수 있습니다. 최소한 다른 모듈이 업데이트되더라도 충돌이 발생하지 않는다는 것을 알고 안심할 수 있습니다. , 하지만 개발자는 종속성 트리를 따를 필요 없이 각 모듈에 속한 항목을 쉽게 식별할 수 있습니다.

@nathraQ 이 모든 패턴은 ECMAScript 모듈로 달성할 수 있습니다. NgModule 의 도입은 우리를 아무데도 얻지 못했으며 AngularMaterial과 같은 라이브러리가 이전에 제공된 캡슐화를 유지하기 위해 구성 요소를 NgModules로 전환하고 있다는 사실이 요점을 증명합니다.

@aluanhaddad NgModules는 ES 모듈과 매우 다른 작업을 시도하고 있으며 구성 요소 캡슐화도 대체하지 않습니다. 즉, ES 모듈과 구성 요소 모두 핵심 책임을 변경하지 않았습니다. NgModules는 애플리케이션 전체에서 아키텍처를 설명하는 매체이며, 이는 Angular가 의도를 더 잘 이해하고 그에 따라 최적화하는 데 도움이 됩니다. 그 중 ES 모듈로는 달성할 수 없습니다. 같은 이유로 구성 요소당 하나의 NgModule은 따라야 할 경험상 규칙이 아닙니다.

단순한 애플리케이션이 이러한 이점으로부터 많은 이점을 얻지 못하는 것은 사실이지만 이러한 경우 NgModules는 어쨌든 "성가심"이 적어야 합니다.

@emilio-martinez , @aluanhaddad 가 쓴 것처럼 ES6과 "기존 Angular 2 way"는 우리에게 필요한 네임스페이스를 제공했습니다.

저는 Angular 1을 사용하여 매우 큰 프로젝트에서 작업했습니다. mb-product-list 라는 이름의 선택기가 있으면 대규모 프로젝트(5명 이상의 개발자 팀에서도)인 경우 다른 사람과 매우 빠르게 충돌할 수 있습니다.

더 많은 네임스페이스로 문제를 해결하려고 하면 mb-somefeature-product-list 로 끝납니다. 이는 템플릿을 더럽게 보이게 합니다.

directives 메타데이터로 인해 ng2에서 해결된 것을 보고 매우 기뻤습니다.
원하는 패키지를 npm으로 설치하고 구성 요소별로 필요한 패키지만 가져올 수 있습니다.

ngModules는 청크를 비동기식으로 로드하는 데 도움이 되고 가져오기를 적게 작성하고 생산성을 향상시키는 데 도움이 되는 이점이 있습니다.

그러나 SharedModule 패턴을 사용하면 ng1에서와 같이 전역 네임스페이스가 도입됩니다.

적어도 공급자의 경우 파일 위치인 ES6 토큰에 의해 네임스페이스가 지정됩니다.

구성 요소를 사용하면 선택기 때문에 동일한 선택기를 가진 구성 요소가 두 개 있다는 소리가 들립니다.

타사 또는 로컬 공유 구성 요소와의 충돌 사용 사례에 대해 특수 네임스페이스를 구성하는 쉬운 방법이 있었으면 합니다.

"선택자 재정의"와 같은 것.

그게 내가 물어본거야

자세한 통찰력을 제공해 주신 @robwormald 에게 감사드립니다. 하지만 저와 같은 초보자의 한 가지(대부분 저는 백엔드 개발자입니다). 저는 Angular 2와 typescript를 배우고 있습니다. 그래서 ES6 모듈 개념은 나에게 흐릿합니다.
우리는 복잡한 응용 프로그램 구조를 가지고 있습니다. 내 구성 요소 수가 거의 60인 분석 앱입니다.
그리고 RC4에서 잘 짜여진 것 같아요. 라우터n이 전체 구성 요소를 다시 생성하기 때문에 로그인 외에 우리는 어떤 종류의 라우팅도 사용하지 않았습니다. 그래서 우리는 탭 기반 앱으로 계획하고 있습니다. 두 개의 메인 탭이 있습니다(1.Analysis 2.Dashboard).
분석 탭에는 각각 단일 분석이 있는 여러 탭이 있습니다. 대시보드도
여러 탭이지만 각 탭은 아래에 저장된 여러 분석으로 구성됩니다.
분석 섹션. 따라서 여러 탭에서 앞뒤로 이동(대시보드 및 분석 모두에서)
또한 대시보드 탭과 분석 탭 간에 전환하면 라우팅이 제공되지 않을 것입니다.
우리의 목적(내가 멍청한 말을 한다면 정정해 주세요).
이제 RC5 NgModule은 우리의 응용 프로그램을 깨는 종류입니다. 우리는 정말 방법을 모릅니다
우리의 응용 프로그램을 다시 디자인하십시오. 애플리케이션에서 AoT 컴파일을 실제로 사용할 수 있습니까? 아니
전체 AoT는 라우팅을 기반으로 합니까?

@shairez NgModules는 정확히 이런 종류의 네임스페이스를 제공합니다. 이 부분을 좀 더 명확히 하자면...

여기서 깨달아야 할 핵심은 구성 요소가 선언된 모듈 "내부"에 다소간 컴파일된다는 것입니다. 예를 보려면 https://plnkr.co/edit/9w10b1Y8Bjr5DDIxOwnC?p=preview 를 참조하십시오.

두 개의 충돌하는 선택기( my-generic-selector )가 있음을 주목하세요. 각 기능 모듈은 그 중 하나를 가져오고 "전역" 네임스페이스를 오염시키지 않고 해당 모듈 내부에서 사용할 수 있습니다.

그래서 사용

<my-app>
  <!-- belongs to FeatureModuleOne -->
  <feature-one></feature-one>
  <!-- belongs to FeatureModuleTwo -->
  <feature-two></feature-two>
</my-app>

확장

<my-app>
  <!-- belongs to FeatureModuleOne -->
  <feature-one>
    <!-- the generic imported in FeatureModuleOne -->
     <my-generic-selector></my-generic-selector>
  </feature-one>
  <!-- belongs to FeatureModuleTwo -->
  <feature-two>
    <!-- the generic imported in FeatureModuleTwo -->
    <my-generic-selector></my-generic-selector>
  </feature-two>
</my-app>

컴파일러가 기능 1과 기능 2를 컴파일할 때 컴파일러가 속한 모듈의 컨텍스트에서 컴파일하므로 충돌 없이 전역 범위를 오염시키지 않습니다.

@robwormald 물론, 그것은 굉장하고 그런 의미에서 Angular 1보다 낫습니다.

내가 쓴 사용 사례 는 문서 에서 제안한 전역 SharedModule을 사용하는 패턴을 참조하는 것이었습니다.

$#$ SharedModule $#$ 내부에 GenericSelectorFeatureOne 와 GenericSelectorFeatureTwo 를 모두 선언하려고 하면 오류가 발생하지 않을까요?

또는 SharedModule 에 유용한 공통 구성 요소가 많이 있고 모든 기능 모듈에 가져오고 싶습니다.

내 기능 모듈에 충돌 선택기가 있거나 일부 타사에 SharedModule 내보낸 기존 라이브러리 중 하나와 충돌 선택기가 있으면 오류가 발생합니까?

@shairez 나는 대부분의 응용 프로그램이 "SharedModules"의 수로 끝날 것이라고 생각하고 충돌 가능성이 낮습니다. 모듈이 저렴하므로 많은 비용이 들지 않습니다.

문서를 개선하는 방법에 대한 아이디어가 있으면 PR을 기꺼이 환영합니다.

제가 찾던 답변 감사합니다 테스트 해보겠습니다.

모듈을 작성하는 새로운 방법으로 이 문제를 해결하는 방법에 대한 더 나은 아이디어가 아직 없습니다. 그래서 여기에 질문했습니다. 하지만 일단 다중 공유 모듈 솔루션을 테스트하면 @ 와 논의할 더 많은 자료가 있을 것입니다.

도움을 주셔서 감사합니다 @robwormald !

https://angular.io 에서 사용할 수 있는 최신 문서에는 NgModule 가 잘못 구성된 경우 쉽게 나타날 수 있는 안티 패턴 및 버그에 대한 _많은_ 경고가 있습니다. 예를 들어

공유 모듈에서 앱 전체 싱글톤 공급자를 지정하지 마세요. 공유 모듈을 가져오는 지연 로드 모듈은 서비스의 자체 복사본을 만듭니다.

그것은 오히려 문제입니다. _먼저 작동하게 한 다음 빠르게_의 시도되고 진정한 접근 방식을 따른다면 경험적 메트릭과 응용 프로그램이나 라이브러리가 확장됨에 따라 이러한 모듈의 창발적 구조를 기반으로 어떤 모듈이 빠르게 로드되거나 느리게 로드되는지 조정해야 할 것입니다. 기본적으로 모듈이 느리게 로드되는지 또는 빠르게 로드되는지 여부를 신경써야 하는 이유는 무엇입니까?

문서의 다음 섹션을 병치하면 더 심각해 보이는 또 다른 문제가 발생합니다.

모듈에 모든 Http 요청에 대한 특수 헤더를 추가하는 사용자 지정 HttpBackend가 필요하다고 가정합니다. 애플리케이션의 다른 모듈도 HttpBackend를 사용자 지정하거나 단순히 HttpModule을 가져오는 경우 이 모듈의 HttpBackend 공급자를 재정의하여 특수 헤더를 잃을 수 있습니다. 서버는 이 모듈의 http 요청을 거부합니다.
애플리케이션 루트 모듈인 AppModule에서만 HttpModule을 가져와서 이 문제를 방지하십시오.

클래스와 모듈을 다시 내보낼 수 있습니까?
전적으로!
모듈은 다른 모듈의 클래스를 선택적으로 집계하고 통합된 편리한 모듈로 다시 내보낼 수 있는 좋은 방법입니다.
모듈은 내보낸 모든 클래스를 효과적으로 다시 내보내는 전체 모듈을 다시 내보낼 수 있습니다. Angular의 자체 BrowserModule은 다음과 같은 몇 가지 모듈을 내보냅니다.
내보내기: [CommonModule, ApplicationModule]
모듈은 자체 선언, 선택한 가져온 클래스 및 가져온 모듈의 조합을 내보낼 수 있습니다.

따라서 문서에서는 사용자가 특정 모듈을 다시 내보내는 것을 권장하지 않으며 동시에 그렇게 하면 매우 편리하다고 말합니다.

NgModule re-exports의 개념은 통제가 덜하다는 점을 제외하고 ES Module re-exports의 개념과 유사합니다. JavaScript는 정적으로 범위가 지정되며(예, this 는 그렇지 않음을 압니다) 이것이 최대 장점 중 하나이며 매우 유연한 구성과 정보 은닉을 허용합니다. JavaScript는 섀도잉도 지원하므로 항상 범위를 재정의할 수 있습니다.

하지만 가장 큰 문제는 지침의 예제가 모두 @angular/* 프레임워크 모듈을 가져오는 방법에 관한 것입니다. 이들은 갈등을 직관적으로 방지할 수 있는 방식으로 자연스럽게 나눌 수 있습니다. 일반적으로 겹치지 않는 인프라 수준의 서비스를 제공하기 위해 존재하기 때문입니다. 사용자 정의 모듈은 많은 계층을 가로질러 절단할 수 있으며 다양한 동작을 향상시키거나 변경할 수 있습니다. 예를 들어, 로깅 모듈은 라우터 및 Http 서비스에 대한 액세스를 원할 수 있으며 동시에 관리 사용자에게 정보를 표시하기 위한 여러 구성 요소를 제공하고 양식 모듈 중 하나를 사용하여 정의할 수 있습니다.

다시 내보내기가 전이인지에 대해 아무 말도 하지 않는 문서... 모듈 A는 CommonModule을 다시 내보냅니다. 모듈 B는 모듈 A를 다시 내보냅니다. 모듈 C는 모듈 B를 가져옵니다. 이는 모듈 C가 이제 CommonModule의 지시문을 사용할 수 있다는 의미입니까?

@Martin-Wegner 여기에 설명된 대로 전이적 입니다. https://angular.io/docs/ts/latest/cookbook/ngmodule-faq.html#! #q-재수출

@aluanhaddad 어디? 하나 이상의 홉이 있는 전이적 재수출에 대한 단어를 찾을 수 없습니다...

@aluanhaddad 가 Angular 문서에서 가져온 내용을 읽으면 Angular 2에 대해 배운 모든 것을 재고해야 하고 더 나은 방식으로 종속성을 처리하는 프레임워크가 없을 수도 있습니다.

내가 이해하는 대로. HttpModule을 가져오는 앱 모듈이 있고 Http 서비스를 사용하는 서비스가 포함된 기능 모듈이 있는 경우 기능 모듈 수준에서 HttpModule을 가져오지 않고 앱 모듈 수준에서 가져와야 합니다. 많은 앱 모듈 간에 공유되는 기능 모듈을 생성하면 어떻게 될까요? 앱 모듈에서 HttpModule을 가져와야 합니다. 내 기능 모듈이 HttpModule에 의존한다고 말할 수 없습니다. 그것은 정말 추악하고 NgModule 정의에 PeerDependecies와 같은 기능이 많이 부족하다는 것을 의미합니다.
오 소년. Angular 2가 부서지는 느낌입니다. 다시 시작하고 Angular 2를 포기하고 Angular 3으로 시작할 때가 된 것 같습니다.

당신이 방금 말한 것에는 실제로 많은 의미가 있습니다. 나는 이것을 시작했다
Angular2는 작년부터 여행을 하고 있는데 두근거릴 이유가 없었습니다.
지금까지 본 모든 주요 변경 사항에도 불구하고(알파에서 베타로,
및 RC). 그 단계에서 이해할 수 있고 종교적으로 붙어 있기 때문에
미니멀리스트 Backbonejs에서 나를 전환시키는 데 사용한 철학.
나에게 이 ngModules의 전체 아이디어는 다소 반대되는 것으로 판명되었습니다.
생산적인. 그리고 내가 복음화에 쏟는 모든 시간을 지켜보는 것은 슬픈 일입니다.
미니멀하고 부풀지 않는 "구성 요소"의 풍부한 장점은
절대 낭비.
2016년 8월 29일 오전 9시 44분에 "Daniel Schuba" [email protected] 이 다음과 같이 썼습니다.

@aluanhaddad https://github.com/aluanhaddad 에서 가져온 내용 읽기
나는 내가 가진 모든 것을 재고해야한다고 생각합니다.
Angular 2에 대해 배웠고 아마도 프레임워크가 없더라도
더 나은 방식으로 종속성을 처리합니다.

내가 이해하는 대로. HttpModule을 가져오는 앱 모듈이 있고 내가
Http 서비스를 사용하는 서비스가 포함된 기능 모듈이 있으면 안 됩니다.
기능 모듈 수준에서 HttpModule을 가져오지만 앱 모듈 수준에서는 가져옵니다. 그래서 뭐
많은 앱 모듈 간에 공유되는 기능 모듈을 생성하면? 나는 가지고있다
앱 모듈에서 가져오는 HttpModule에서 실제로. 나는 말할 수 없다,
내 기능 모듈은 HttpModule에 의존합니다. 정말 추악하고
즉, NgModule 정의에는 다음과 같은 기능이 많이 부족합니다.
피어 의존성.
오 소년. Angular 2가 부서지는 느낌입니다. 할 시간이 될까 두렵다
다시 시작하고 Angular 2를 포기하고 Angular 3으로 시작합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/angular/angular/issues/10552#issuecomment -243066961,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF675h8_np9i5cHgL8mMOOu8vMMQmWKkks5qkpv8gaJpZM4Jee-o
.

내가 틀렸다면 누군가 나를 고칠 수 있습니까?

다음과 같이 앱을 구성할 생각입니다.

앱
|--법률/
|----많은 구성 요소.
|----LawNG 모듈.
|--사용자/
|----많은 구성 요소
|----사용자NG 모듈
|--AppNG 모듈
|--SomeFirstLeveComponents

Angular Material로 작업하고 싶다고 가정해 봅시다. 내가 모든 구성 요소의 각 요소를 가져오는 보일러 플레이트가 너무 많다는 것이 다소 싫었습니다. 이제 NG 모듈에 추가하겠습니다. 하지만 기능당 하나의 ng 모듈을 사용하기로 결정했기 때문에 고려하는 각 ng 모듈에 대해 가져오기를 수행해야 합니다. 루트 뿐만이 아닙니다. 맞나요?

아니면 모듈 x를 생성하여 y(Material) 다른 모듈을 다시 내보내고 필요한 모듈로 가져오는 경우일 수 있습니까?

@ReneVallecillo 맞습니다. 각 기능 모듈에서 가져와야 합니다. 또는 다른 모듈과 함께 공유 모듈(종속성 숨기기)에 추가하여 다시 내보내고 이 공유 모듈을 사용합니다. 그리고 그것을 다른 모듈로 다시 내보내면 즉시 알지 못하고 보지 않고도 중복 가져오기가 있을 수 있습니다.

@robwormald 위의 귀하의 의견 에 대한 답변:

그러나 AoT 모드에서는 약간 다르게 작동합니다. 빌드 시 우리는 데코레이터를 검색하여 소스 코드에서 동일한 메타데이터를 정적으로(즉, 코드를 실행하지 않고) 추출합니다.

이것은 원본 소스 코드에서 정적으로 모듈을 추출하고 있으므로 동적으로 모듈을 효과적으로 생성할 수 없다는 것을 의미합니까?

마이그레이션을 더 쉽게 하기 위해 동적으로 모듈을 생성하는 함수를 만들까 생각했습니다. 이 같은:

function createModule (entryComponent: Type, dependencies: Type[]) {
    @NgModule({
        imports: [CommonModule, FormsModule],
        declarations: [entryComponent, ...dependencies],
        exports: [entyComponent]
    })
    class FeatureComponent {}
    return FeatureComponent;
}

따라서 이것은 (아마도?) JIT 컴파일에서 작동하지만 AoT가 소스 코드를 정적으로 구문 분석하여 데코레이터를 찾기 때문에 AoT에서는 작동하지 않습니까?

ES@next.... @aluanhaddad 의 시대에 이러한 불필요한 복잡성은 몇 가지 매우 좋은 점을 지적합니다.

상황이 이렇다 보니 이것이 의도한 방향이라면 내 자신/팀이 Angular 2로 나아가는 것을 볼 수 없습니다. 그리고 이것이 "닫힌"것처럼 보입니다.

@DaSchTour 처럼 하고 다른 프론트엔드 프레임워크를 조사해야 할 수도 있습니다. 안타깝게도 몇 달 전만 해도 NG2는 함께 작업하는 것이 상당히 즐거웠고 내가 분명히 선택한 제품이었기 때문입니다.

@iyobo 전환의 초기 고통 외에 NgModules에 대한 피드백의 _대부분(그리고 저는 _많은_의 개발자와 이야기)은 긍정적이었습니다.

hello world 앱에서 따로따로 보면 "복잡하다"고 주장할 수 있지만(위 설명에 따르면 "필요 없는"은 실제로 올바르지 않습니다.) 기능 구성, 게으른 라우팅 및 AoT는 모두 NgModules로 훨씬 더 간단해졌습니다. 오늘의 선택이 주어진다면 나는 여전히 NgModules를 프레임워크에 추가하기로 선택할 것입니다.

저는 @robwormald 와 함께 있습니다. RC4/5에서 NgModules로 마이그레이션할 때의 초기 고통은 모든 단일 구성 요소/파이프를 새로 생성된 페이지로 가져올 필요가 없다는 이점을 확인한 후 관리할 수 있었습니다.
NgModules는 좀 더 복잡해지고 공유 구성 요소가 많아지면 빛을 발하기 시작합니다.

SharedModule을 가져와서 완료하는 것이 훨씬 쉽습니다.

@robwormald 님 , Ng2의 현재 방향에 동의하지 않는다는 개념은 "hello world" 수준 앱에서만 작동한다는 사실에 입각한 주장이 아닙니다.

당신이 말하는 이 "기능의 구획화"는 새로운 것이 아닙니다. 구성 요소를 사용하여 각 개별 제품/솔루션에 맞게 필요에 따라 항상 설계되어 온 것입니다.
즉, 자체적으로 필요한 것을 선언하는 구성 요소보다 더 큰 구획화는 여전히 없습니다.

이제 지연 로딩, 뒤로 당겨서 조감도에서 사물을 보는 것과 관련하여 지연 로딩의 주요 이점은 앱의 로딩 속도를 향상시키는 것입니다. 나는 우리 대부분이 이 작업을 수행하는 파이프라인을 가지고 있다고 생각합니다. 웹팩으로 축소, 압축 및 여러 앱 진입점을 입력합니다.

NgModules는 실제 문제에 대한 솔루션이 아니라 문제를 찾는 솔루션인 것 같습니다. 하지만 다시 말하지만, 내가 모든 것을 안다고 주장할 수는 없습니다...

NgModules를 도입하는 것이 좋은 생각인지 그 시간이 보여질 것이라고 생각합니다. Angular 2는 현재 특정 디자인 목표를 달성하기 위해 만들어진 것 같습니다. 기술 수준이 다른 팀, 나이가 들고 여러 세대의 개발자를 통해 전달되는 코드와 같은 것에 대해 생각한 사람은 아무도 없습니다. 이상적인 세계에서는 훌륭한 아이디어처럼 보일 수 있습니다. 그러나 실제로 NgModules는 새로운 프로젝트에 대한 교육 및 도입 단계에서 많은 문제를 일으킬 많은 함정과 난독화를 도입합니다. 구성 요소 수준에서 선언할 때와 같이 간단하고 직관적이지 않습니다. 종속성은 모듈에 숨겨져 있으며 구성 요소가 있는 모듈에 대한 조사를 시작해야 하는 것은 시간 문제일 뿐입니다.

최근에 더 큰 응용 프로그램을 NgModules로 전환한 후, 나는 그것들이 대부분 좋은 것이라고 생각합니다(이제 작업을 마쳤으므로 확실히 이해가 됩니다). 실제로 주요 문제는 다른 구성 요소 구조가 필요하다는 것인데, 이는 이전에 애플리케이션을 구성한 방식과 잘 맞지 않을 가능성이 높다는 것입니다(적어도 저에게는 그랬습니다).

그러나 그것들이 유일한 해결책으로 존재해서는 안 된다고 생각합니다. 구성 요소가 매우 일반적으로 구축되는 방식을 살펴보면 매우 자주 더 작은 고도로 전문화된 하위 구성 요소로 구성된다는 것을 알게 됩니다. 해당 컨테이너 구성 요소 외부에 목적이 없는 이러한 하위 구성 요소의 경우 상위 범위 모듈에서 하위 구성 요소를 유지 관리하는 것은 정말 지루하고 빠르게 범위 지정 문제를 일으킬 수 있습니다.

NgModules에 구성 요소가 다른 구성 요소나 지시문을 해당 구성 요소 내에서만 적용되는 로컬 범위 종속성으로 정의할 수 있도록 하는 메커니즘이 있다면 정말 감사하겠습니다( directives 목록이 모듈 이전에 작동하는 방식과 같음).

Full NgModules를 사용하지 않으려는 사람들을 위한 대안 이 있다는 @poke 의 제안이 마음에 듭니다.

NgModules는 컴파일 및 지연 로딩 작동 문제를 해결하기 위해 RC5에 추가되었습니다. 원래 마스터 플랜의 일부가 아니므로 일부 사용 사례에 적합하지 않습니다(특히 원래 "구성 요소는 왕" 디자인).

물론 그들은 몇 가지를 수정하거나 활성화하지만 고유한 복잡성도 함께 가져옵니다. 모든 모범 사례와 접근 방식이 아직 해결되지 않은 경우 특히 어려운 일인 사람들이 배우고 설계해야 할 더 많은 것들이 있습니다. 조기 채택은 많은 고통을 가져올 수 있습니다. 저는 RC4를 타는 과정에서 그 사실을 배웠습니다.

나는 원래의 구성 요소 중심 계획이 더 마음에 들었고 이것이 아마도 내가 지금 폴리머/웹 구성 요소에 더 적합하다고 찾는 이유일 것입니다. 모듈은 Angular 1로 반 단계 후퇴하는 것처럼 느껴집니다.

처음에는 파이프와 지시문을 제거하는 이 변경 사항에 저항했지만 지금은 익숙해지고 처음 생각했던 것만큼 나쁘지 않은 것 같습니다.

여러 구성 요소가 여러 수준에서 여러 다른 구성 요소를 필요로 하는 정말 복잡한 앱에서 NgModules가 어떻게 작동하는지 보여줄 수 있습니까? 내가 본 모든 튜토리얼, 예제 및 리포지토리는 모듈이 자체 항목을 캡슐화하고 일부를 다른 사람에게 게시(내보내기)하는 쉬운 방법만 보여줍니다.

실제 프로젝트에는 일반적으로 계층적 체인이 있는 교차 필수 종속성이 많이 있습니다. 그것을 위해 정확히 지정된 예에 의해 무언가의 개념을 증명하는 것은 어떻게 든 잘못된 것입니다.

@Angular2 의 모든 작성자를 위해: NgModules의 부정적인 부분이 무엇인지 솔직히 말씀해 주시겠습니까? 나는 당신이 모든 좋은 것들에 관한 책을 쓸 수 있다는 것을 압니다. 괜찮아. 그러나 나는 항상 당신이 그것에 대해 이야기하지 않으면 명확하지 않을 숨겨진 나쁜 것들을 다루어야합니다.

여러 구성 요소가 여러 수준에서 여러 다른 구성 요소를 필요로 하는 정말 복잡한 앱에서 NgModules가 어떻게 작동하는지 보여줄 수 있습니까?

이를 수행하는 한 가지 방법은 해당 구성 요소에 대한 종속성 모듈을 만드는 것입니다. 여러 구성 요소를 포함하는 A , B 및 C 구성 요소 집합이 세 개 있다고 가정해 보겠습니다. 각각의 세트에는 다소 관련이 있는 세트가 있습니다. 따라서 이 세 세트는 세 개의 개별 모듈에 대해 잘 작동합니다.

이제 각 세트의 구성요소에는 D 세트의 여러 구성요소가 필요합니다. D 의 구성 요소는 이 세 세트의 구성 요소에만 사용됩니다. 그것들은 모두에서 사용되기 때문에 해당 모듈에 구성 요소를 추가할 수 없습니다(구성 요소는 단일 모듈의 일부일 수 있기 때문에). 이 시점에서 A , B , C 및 D 를 거대한 모듈로 병합할 수 있으므로 모든 종속성이 존재합니다. 그러나 그것은 물론 매우 지저분합니다. 대신 해당 종속성을 포함하는 D 에 대한 새 모듈을 생성하면 됩니다. 이 모듈은 해당 모듈에 대한 액세스를 제공하는 것 외에는 아무 것도 하지 않습니다. 이제 세 개의 다른 모듈 각각에서 해당 모듈을 가져올 수 있으며 구성 요소를 사용할 수 있습니다. 그러나 구성 요소는 여전히 "비공개"이므로 모듈을 다시 내보내거나 다른 모듈에서 D 모듈을 가져오지 않습니다.

모듈 가져오기는 모듈 자체에만 영향을 미치기 때문에 다른 모듈을 오염시키지 않고 일종의 범위 지정을 허용합니다. 물론 더 많은 모듈을 생성해야 하지만 이것이 바로 작동 방식입니다.

현재 설정을 공유할 수 있습니다. 앱에서 CommonModule, AppModule 및 TestModule의 3가지 모듈을 사용했습니다.

• CommonModule은 HttpModule, FormsModule, MdInputModule 등과 같은 가장 일반적인 항목을 가져오고 내보냅니다.
• AppModule은 BrowserModule, CommonModule, app.routing 및 개별 구성 요소를 가져옵니다.
• TestModule은 BaseModule을 가져오고 내보내지만 XHRBackend와 같은 일부 공급자를 MockBackend로 덮어씁니다.

TestBed.configureTestingModule을 단순화하기 위해 이 설정을 도입했습니다.
TestModule을 가져온 다음 다음과 같은 단일 구성 요소를 가져와야 합니다.

TestBed.configureTestingModule({
  imports: [ TestModule ],
  declarations: [ MyFormComponent ]
});

RC-4에서 릴리스로 마이그레이션하면서 명백해진 또 다른 단점은 NgModules가 구성 요소를 단순히 분할해야 하는 간단한 리팩토링에 대해 무거운 패널티를 부과한다는 것입니다. NgModule을 사용하면 개념적 구성 요소 트리의 여러 수준에 있는 포함 모듈을 변경하거나 구성 요소를 NgModule로 래핑한 다음 상위 NgModule에서 제거하여 구성 요소를 승격해야 합니다. 구성 요소를 리팩토링하는 것은 필수적입니다.

이것은 @poke 의 요점과 직접적인 관련이 있습니다.

NgModules 외에도 구성 요소가 다른 구성 요소 또는 지시문을 해당 구성 요소 내에서만 적용되는 로컬 범위 종속성으로 정의할 수 있는 메커니즘이 있다면 정말 감사하겠습니다.

나는 강하게 동의하지 않는다. Angular 2에서 제안한 모듈식 아키텍처는 필요한 경우 확장, 조정 및 리팩토링하기가 더 쉽습니다. 물론 RC4에서 RC5까지 약간의 조정이 있었지만 나에게 NgModules는 훨씬 더 유연한 응용 프로그램을 허용하는 것으로 입증되었습니다.

Angular는 독단적이며 확실히 모든 사람에게 맞는 크기는 아닐 수 있지만 NgModules는 스마트하고 현대적이며 고성능 애플리케이션을 설계하는 데 실패할 지점이 아닙니다.

@emilio-martinez: 제 생각에는 Angular 2가 JiT를 포함할 때 부트스트래핑이 그렇게 느리지 않다면 NgModule이 도입되지 않았을 것입니다. 이 토론에서 알 수 있듯이 '크기 조정, 조정 및 리팩토링'과 같은 다른 모든 '개선 사항'은 논쟁의 여지가 있습니다.

꽤 오랜 시간이 지났고 우리 중 많은 사람들이 NgModule을 작업에 완전히 흡수할 시간을 가졌습니다. 나는 이제 꽤 많은 사람들이 설명했듯이, 일단 새로운 모듈 시스템으로 이동하는 과도기를 지나고 나면 꽤 훌륭한 일들을 가능하게 한다는 것이 분명하다고 생각합니다. NgModule을 흡수하는 데 문제가 있는 이 스레드를 사용하는 사람에게는 특히 @robwormald 및 @wardbell 에서 모든 것을 스크롤하고 모든 것을 읽을 것을 제안합니다.

많은 Angular 2+ 응용 프로그램이 모듈, 지연 로딩 및 AOT를 광범위하고 원활하게 사용하게 되는 지금으로부터 1년 후에 우리 모두가 발견할 것이라고 믿습니다. 나는 대부분의 또는 거의 모든 응용 프로그램이 이러한 것들을 사용하여 복잡한 대규모 응용 프로그램이 거의 즉각적인 초기 로드 시간을 갖고 기능을 지연 로드(또는 낙관적으로 지연 사전 로드)하는 "프로그레시브 응용 프로그램" 비전을 구현하는 것이 완전히 일상적일 것이라고 믿습니다. 필요. 결과는 실제로 매우 놀라울 정도로 매끄럽고 개별 애플리케이션 개발자에게 매우 저렴한 비용으로 달성됩니다. NgModule은 기본적으로 그 비용이며 짜증나는 전환이지만 사용할 진행 중인 작업의 양은 매우 적습니다.

@kylecordes 나는 당신이 옳기를 바라며 그것이 올바른 태도라고 생각합니다.

@iurii-kyrylenko 정말 그렇습니다.

TypeScript가 JavaScript를 컴파일해야 하므로 JavaScript를 각도 컴파일하는 데 문제가 있지만 그건 별개의 문제입니다.

@kylecordes 전환보다 고려해야 할 사항이 훨씬 더 많다고 생각합니다. 모듈은 자체 애플리케이션에 버그를 추가할 수 있는 많은 복잡성과 많은 추가 가능성을 도입합니다. 가장 큰 문제는 종속성의 난독화입니다. 이는 Angular 2로 개발할 향후 몇 년 동안 많은 문제를 일으킬 것입니다.

@aluanhaddad 나는 Angular가 tsc 래퍼를 사용하여 컴파일한다고 믿습니다. 예를 들어 작업 실행자 워크플로에 구현할 수도 있기 때문에 좋습니다.

@iurii-kyrylenko 부트스트랩 속도도 RC4를 기준으로 결정하기 어렵습니다. 그때부터 최종 릴리스까지 많은 작업이 정리와 최적화였습니다. 내 경험상 Angular 컴파일된 JIT는 어쨌든 RC4보다 빠르게 실행됩니다.

@DaSchTour NgModule 로 작업하는 동안 발견한 버그에 대해 자세히 설명해 주시겠습니까?

@emilio-martinez NgModule의 버그가 아니라 초기 개발 단계에서 누락되거나 발견된 가져오기 누락 또는 중복 서비스 인스턴스로 인해 발생하는 버그입니다. 내가 사용하는 곳에서 물건을 수입하는 것이지 필요하거나 사용하지 않는 곳과 필요하고 사용되는 곳이 아닌 곳에서 수입하는 것입니다.

TypeScript가 이런 식으로 작동한다고 생각해 보십시오. 내 모듈에 대한 기본 파일이 있습니다. 다음과 같이 _index.ts_라고 부르겠습니다.

import {foo} from bar;
import {StartComp} from start;

StartComp.boot();

다음과 같은 start.ts라는 파일이 있습니다.

export class StartComp {
   public static boot() {
      foo()
   }
}

이것이 Angular가 NgModules로 하는 일입니다. 어떤 마술을 사용하여 모듈로 무언가를 가져왔고 내 응용 프로그램의 다른 쪽 끝에 나타납니다. foo는 index.ts에서 가져오고 인덱스에서 StartComp를 실행하여 가져오기를 구성 요소에서 사용할 수 있다는 것을 알아야 합니다.

종속성은 숨겨져 있으며 이를 찾으려면 추가 조사가 필요합니다.

@emilio-martinez

내 경험상 Angular 컴파일된 JIT는 어쨌든 RC4보다 빠르게 실행됩니다.

MEAN 스택 및 Angular 2 final을 기반으로 하는 중간 복잡성 프로젝트 가 있습니다. 내 Android 장치의 JIT 모드에서 부트스트랩을 완료하는 데 약 10초가 걸립니다. 나는 이것을 상당한 지연으로 간주합니다. 현재 소스 코드를 수정하지 않고 AOT 컴파일을 사용할 수 없습니다(비공개 멤버 문제, 엘비스 연산자 ...).

실제 프로젝트에 대한 성능 AOT + 지연 로드에 대한 정보가 있는 사람이 있습니까?

Angular는 tsc 래퍼를 사용하여 컴파일한다고 생각합니다. 예를 들어 작업 실행자 워크플로에 구현할 수도 있기 때문에 좋습니다.

@emilio-martinez 이것이 바로 내가 원하지 않는 것입니다. 원하는 TypeScript 버전을 사용하여 코드를 컴파일하고 싶습니다. 예를 들어 async/await에 대해 하위 레벨 방출이 있는 2.1.0-dev가 있습니다. Angular가 내 TypeScript 파일 컴파일을 담당하는 것을 원하지 않습니다. 이것은 프레임워크에 위임되어서는 안 됩니다. 이것은 언어의 역할입니다. 주제에서 더 벗어나지 않았다면 @Script 를 10피트 기둥으로 만지지도 않았을 것입니다. 다행이도 죽었습니다.
워크플로 측면에서 저는 JSPM과 때때로 Webpack을 사용합니다. 전통적인 태스크 러너가 아니라 IDE가 린터를 처리하도록 합니다.

또 다른 문제는 각도 데코레이터를 추상화하는 데코레이터를 작성했으며 이제 ot가 이를 무시한다는 것을 이해한다는 것입니다. Angular의 데코레이터가 얼마나 무거운지를 고려할 때 프레임워크가 데코레이터를 완전히 지원하지 않고 AOT 동안 실제로 기본 언어의 런타임 구성인 경우 정적 주석으로 처리한다는 사실을 알고 매우 실망했습니다.

@aluanhaddad AoT 컴파일 중에 발생하는 두 가지 별개의 단계가 있음을 이해하는 것이 중요합니다. 첫 번째는 _new_ typescript 코드를 생성하고 두 번째는 해당 코드를 ES5/6으로 트랜스파일하는 것입니다. ngc 는 편의상 두 가지를 모두 수행하지만 AoT에는 이를 요구하는 고유한 기능이 없습니다. Google 내부에서는 둘 다 수행하므로 이 경우가 우선입니다. 누구나 원하는 환경에서 코드 생성을 지원하기 위해 컴파일러 호스트를 구현할 수 있습니다.

우리는 (아직) Angular의 내장 데코레이터 위에 추상화를 지원하지 않지만 https://www.npmjs.com/package/core-decorators 와 같은 것을 사용하고 싶다면 괜찮을 것입니다.

@iurii-kyrylenko는 LucidCharts가 AoT에 대한 경험에 대해 이야기한 AngularConnect의 첫날 기조 연설을 시청할 것을 제안합니다. https://youtu.be/xQdV7q3e_2w?t=1411 참조

IMHO - 모든 사람의 #1 목표는 가능한 한 빨리 AoT 컴파일을 시작하는 것입니다. 성능은 단순히 타의 추종을 불허합니다.

@robwormald ngc 를 호출할 때 어떤 옵션을 사용할 수 있는지 살펴보지 않았기 때문에 이것이 이미 다루어졌을 수 있습니다. NGC가 편의성/최적화라는 두 번째 목적에 존재하는 주된 이유인 첫 번째 목적을 달성하고 있음을 분명히 해준다면 이러한 옵션이 여기에서 목소리를 낸 것과 같은 우려를 완화할 수 있다고 생각합니다. 문서나 도움말에 별도의 기성품 tsc 을 실행하는 방법이 나와 있다면 그렇게 하는 것을 선호하는 사람들의 우려를 더욱 완화할 수 있습니까?

@kylecordes 나는 문서가 곧 자신의 컴파일러 호스트를 구현하는 방법을 다루지 않을 것이라고 생각합니다. 고급 사용 사례이므로 구현하려면 약간의 자기 주도 학습이 필요합니다. https://github.com/angular/angular-cli/tree/master/packages/webpack 여기에서 CLI에 대해 유사한 것을 구현했습니다.

@robwormald 아, 자신의 컴파일러 호스트를 구현하는 것이 아닙니다. 나는 두 줄의 "빌드 프로세스"를 의미했습니다. 먼저 ngc 를 호출하여 일부 생성된 타이프스크립트를 내보낸 다음 tsc 를 직접 호출하여 모든 타이프스크립트(소스와 생성된 소스)를 다음으로 컴파일합니다. 자바스크립트. 이것은 typescript 코드가 기성품 typescript 컴파일러에 의해 JS로 컴파일되고 있다는 것을 빠르게 확신시켜줍니다.

@robwormald 답변 감사합니다.
NGC와 관련하여 내가 알고 싶은 것은 TypeScript 컴파일러 버전과 TS -> TS 패스의 설정을 제어할 수 있는지 여부입니다. TypeScript를 NGC에 전달할 수 있습니까? 아니면 특정 TypeScript 버전을 래핑하는 특정 버전을 사용해야 합니까? 얼마나 결합되어 있습니까?

데코레이터와 관련하여 Angular 데코레이터를 추상화하는 사용자 정의 데코레이터에 대한 지원을 추적하는 데 문제가 있습니까? https://www.npmjs.com/package/core-decorators 는 직교 데코레이터 세트이지만 Angular 데코레이터를 래핑하여 Angular 앱에서 패턴과 규칙을 적용하는 데코레이터가 있습니다. 이에 대한 명백한 사용 사례는 패키지 전체 구성 요소 이름 접두사를 자동으로 만들고 적용하는 것이지만 다른 것도 있습니다.

NGC는 이것을 지원하지 않기 때문에 어떤 데코레이터가 Angular와 관련이 있는지 어떻게 알 수 있습니까?
이름으로 각도 데코레이터와 일치합니까?
JavaScript 어휘 범위를 위반하기 때문에 그렇지 않기를 바랍니다.
간단한 시나리오
_awesome-component-decorators.ts_

import { Component } from '@angular/core';
import template from './awesome-component.html';
import style from './awesome-component.less';

export const awesomeComponet = <T extends new (...args) => any>(target: T) =>
  Component({template, styles: [style], selector: snakeCase(target.name) })(target);

_소비자.ts_

import { awesomeComponet } 'app/shared/awesome-component-decorators';

<strong i="19">@awesomeComponent</strong> 
export class AnAwesomeComponent { }

<strong i="20">@awesomeComponent</strong> 
export class AnotherAwesomeComponent { }

@jpsfs 루트 응용 프로그램 모듈에 구성 요소 선언을 추가하지 않고 구성 요소를 동적으로 로드하는 솔루션을 찾았습니까? .

저는 또한 Angular 1.X에서 Angular 4로의 마이그레이션 프로젝트에 참여하고 있습니다. 이 프로젝트에는 응용 프로그램 컨텍스트를 기반으로 지연 로드되는 다른 응용 프로그램에서 재사용되는 많은 구성 요소가 있습니다.

Angular 4에 대한 내 이해에 따라

아래와 같이 루트 @NgModule 선언에 구성 요소 종속성을 추가해야 합니다.

"@angular/platform-browser-dynamic"에서 {platformBrowserDynamic} 가져오기;
"@angular/core"에서 {Component, NgModule} 가져오기;
...
...
@NgModule({
imports: [BrowserModule ], // Angular의 BrowserModule 가져오기
bootstrap: [BootStrapComp], // 부트스트랩 구성 요소를 나타냅니다.
선언: [com1, comp2, comp5 ...... Comp n ] // 모듈에 구성 요소를 등록합니다.
})
내보내기 클래스 AppModule {}

platformBrowserDynamic().bootstrapModule(앱 모듈);

그러나 우리의 경우 NgModule이 컴파일 타임에 구성 요소 종속성에 대해 알도록 루트를 지정하고 싶지 않았습니다. 오히려 우리는 컴포넌트가 런타임에서 동적으로 로드되기를 원했습니다.
루트 NgModule 선언에 모든 ​​구성 요소를 추가하지 않고도 애플리케이션을 부트스트랩할 수 있는 좋은 솔루션을 찾았습니까?

@DaSchTour

앱 진입점이 다음과 같이 보였던 때를 기억하십니까?

우리 중 일부는 빌드 스크립트를 사용하여 이러한 모듈을 자동으로 요구하고 앱 모듈에 추가했습니다.

angular2에서 유사하고 쉬운 솔루션을 찾고 있습니다.

@samudrak Angular aot 지원을 사용하려는 경우 구성 요소만 지연 로드할 수 없습니다. 각 구성 요소에 대해 지연 모듈을 설정하고 모듈을 지연 로드해야 합니다. 우리는 우리의 응용 프로그램에서 유사한 접근 방식을 사용합니다...

ECMAScript와 이제 TypeScript(로딩과 직교하는 전체 유형 검사 포함)에서 동적 가져오기를 지원하므로 지연 로딩 사용 사례는 상당히 임의적입니다. 물론 돌이켜보면 20/20이고 그런 일이 일어날지 알 방법이 없었습니다.

이 문제는 활동이 없어 자동으로 잠겼습니다.
유사하거나 관련된 문제가 발생하면 새 문제를 제출하십시오.

자동 대화 잠금 정책 에 대해 자세히 알아보세요.

_{_이 작업은 봇에 의해 자동으로 수행되었습니다._}