Angular – Qual é o significado de module.id em componente?

Em um aplicativo Angular, vi que @Component tem propriedade moduleId . O que isso significa?

E quando o module.id não está definido em nenhum lugar, o aplicativo ainda funciona. Como isso ainda funciona?

 @Component({ moduleId: module.id, selector: 'ng-app', templateUrl: 'app.component.html', styleUrls: ['app.component.css'], directives: [AppComponent] }); 

A versão beta do Angular (desde a versão 2-alpha.51) suporta resources relativos para componentes, como templateUrl e styleUrls no decorador @Component .

module.id funciona ao usar o CommonJS. Você não precisa se preocupar sobre como isso funciona.

Lembrese : configurar o moduleId: module.id no decorador @Component é a chave aqui. Se você não tem isso, então o Angular 2 estará procurando por seus arquivos no nível da raiz.

Fonte do post de Justin Schwartzenberger , graças a @Pradeep Jain

Atualização em 16 de setembro de 2016:

Se você estiver usando webpack para agrupamento, não precisará de module.id no decorator. Webpack plugins auto handle (adicionar) module.id no pacote final

Atualização para (2017-03-13) :

Todas as menções de moduleId foram removidas. “Livro de receitas de caminhos relativos ao componente” excluído

Adicionamos um novo plugin SystemJS (systemjs-angular-loader.js) à nossa configuração SystemJS recomendada. Este plugin converte dinamicamente os caminhos “relativos aos componentes” em templateUrl e styleUrls para “caminhos absolutos” para você.

Nós encorajamos você a escrever somente caminhos relativos a componentes. Essa é a única forma de URL discutida nesses documentos. Você não precisa mais escrever @Component({ moduleId: module.id }) , nem deveria.

Fonte: https://angular.io/docs/ts/latest/guide/change-log.html

Definição:

 moduleId?: string 

moduleId parâmetro moduleId dentro da anotação @Component recebe um valor de string que é;

O id do módulo do módulo que contém o componente.

Uso do CommonJS: module.id ,

Uso do __moduleName : __moduleName


Razão para usar moduleId :

moduleId é usado para resolver caminhos relativos para suas folhas de estilo e modelos, como diz a documentação.

O id do módulo do módulo que contém o componente. Necessário para poder resolver URLs relativos de modelos e estilos. Em Dart, isso pode ser determinado automaticamente e não precisa ser definido. No CommonJS, isso sempre pode ser definido como module.id.

ref (antigo): https://angular.io/docs/js/latest/api/core/index/ComponentMetadata-class.html

podemos especificar localizações dos arquivos de modelo e estilo relativos ao arquivo de class do componente simplesmente definindo a propriedade moduleId dos metadados @Component

ref: https://angular.io/docs/ts/latest/cookbook/component-relative-paths.html


Exemplo de uso:

Estrutura de pastas:

 RootFolder ├── index.html ├── config.js ├── app │ ├── components │ │ ├── my.component.ts │ │ ├── my.component.css │ │ ├── my.component.html 

Sem module.id :

 @Component({ selector: 'my-component', templateUrl: 'app/components/my.component.html', <- Starts from base path styleUrls: ['app/components/my.component.css'] <- Starts from base path }) 

Com module.id :

tsconfig.json:

 { "compilerOptions": { "module": "commonjs", <- need to change this if you want to use module.id property ... 

 @Component({ moduleId: module.id, selector: 'my-component', templateUrl: 'my.component.html', <- relative to the components current path styleUrls: ['my.component.css'] <- relative to the components current path }) 

Se você receber um typescript error , apenas declare a variável em seu arquivo.

 // app.component.ts declare var module: { id: string; } // @Component({ moduleId: module.id, // now it works without annoying Typescript ... }) 

UPDATE - December 08, 2016

A palavra-chave do module está disponível no node . Portanto, se você instalar @types/node , em seu projeto, você terá a palavra-chave module automaticamente disponível em seus arquivos typescript sem precisar declare la.

npm install -D @types/node

Dependendo da sua configuração, você pode ter que include isso no seu arquivo tsconfig.json para obter o conjunto de ferramentas :

 //tsconfig.json { ... "compilerOptions": { "types" : ["node"] } ... } // some-component.ts // now, no need to declare module @Component({ moduleId: module.id, // now it works without annoying Typescript ... }) 

Boa sorte

De acordo com o documento Angular, você não deve usar @Component ({moduleId: module.id})

Por favor ref: https://angular.io/docs/ts/latest/guide/change-log.html

Aqui está o texto relevante da página:

Todas as menções de moduleId foram removidas. Livro de receitas “Component relative paths” deleted (2017-03-13)

Adicionamos um novo plugin SystemJS ( systemjs-angular-loader.js ) à nossa configuração SystemJS recomendada. Este plugin converte dinamicamente os caminhos “relativos aos componentes” em templateUrl e styleUrls para “caminhos absolutos” para você.

Nós encorajamos você a escrever somente caminhos relativos a componentes. Essa é a única forma de URL discutida nesses documentos. Você não precisa mais escrever @Component({ moduleId: module.id }) , nem deveria.

Além das ótimas explicações de echonax e Nishchit Dhanani , quero acrescentar que eu realmente odeio a população de componentes com module.id . Especialmente, se você tem suporte para a compilation AoT -of-Time (Ahead of Time) e para um projeto realista é para isso que você deve procurar, não há lugar para algo como module.id em seus metadados de componente.

Do Documentos :

Aplicativos compilados por JiT que usam o carregador SystemJS e URLs relativas a componentes devem configurar a propriedade @Component.moduleId como module.id . O object do módulo é indefinido quando um aplicativo compilado ao AoT é executado. O aplicativo falha com um erro de referência nula, a menos que você atribua um valor de módulo global no index.html assim:

  

Eu acho que ter essa linha na versão de produção do arquivo index.html não é absolutamente aceitável!

Portanto, o objective é ter compilation JiT (Just-in-Time) para desenvolvimento e suporte AoT para produção com a seguinte definição de metadados do componente: (sem moduleId: module.id line)

 @Component({ selector: 'my-component', templateUrl: 'my.component.html', <- relative to the components current path styleUrls: ['my.component.css'] <- relative to the components current path }) 

Ao mesmo tempo, gostaria de my.component.css estilos, como my.component.css e arquivos de modelo, como my.component.html relativos aos caminhos do arquivo my.component.ts do componente.

Para alcançar tudo isso, a solução que estou usando é hospedar o servidor web (lite-server ou browser-sync) durante a fase de desenvolvimento de várias fonts de diretório!

bs-config.json :

 { "port": 8000, "server": ["app", "."] } 

Por favor, dê uma olhada nesta resposta para mais detalhes.

O projeto de início rápido angular exemplar 2, que se baseia nessa abordagem, é hospedado aqui .

Parece que se você está usando “módulo”: “es6” em tsconfig.json, você não tem que usar isso 🙂

Esse valor moduleId é usado pelos processos de reflection Angular e pelo componente metadata_resolver para avaliar o caminho completo do componente antes de o componente ser construído.

Adicionando moduleId: module.id corrige vários problemas que podem ocorrer ao criar aplicativos angulares nativos e aplicativos da Web angulares. É uma boa prática usá-lo.

Ele também permite que o componente procure no diretório atual arquivos em vez da pasta superior

    Intereting Posts