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.
Lembre – se : 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
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
comomodule.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