Por ejemplo, el siguiente código no funciona como se esperaba. Digamos que tengo un espacio de nombres de botones:
namespace Button { @Component({ selector: 'super-button', templateUrl: './button.component.html', styleUrls: ['./button.component.scss'] }) export class ButtonComponent {} @NgModule({ declarations: [ ButtonComponent ], imports: [ CommonModule ], exports: [ButtonComponent] }) export class ButtonModule { } } export default Button;y en app.module:
import Button from './button'; @NgModule({ declarations: [ AppComponent ], imports: [ BrowserModule, AppRoutingModule, Button.ButtonModule, ], providers: [], bootstrap: [AppComponent] }) export class AppModule { }Estoy recibiendo este error de compilación:
<e> [webpack-dev-middleware] Error: [object Object] <e> at analyzingFileEmitter (E:\Projects\Angular\test-app\node_modules\@ngtools\webpack\src\ivy\plugin.js:452:23) <e> at processTicksAndRejections (node:internal/process/task_queues:96:5) <e> at async AngularWebpackPlugin.rebuildRequiredFiles (E:\Projects\Angular\test-app\node_modules\@ngtools\webpack\src\ivy\plugin.js:277:36) <e> at async E:\Projects\Angular\test-app\node_modules\@ngtools\webpack\src\ivy\plugin.js:218:17Además, ¿cómo puedo dividir el componente y el módulo en diferentes archivos sin dejar de tenerlos en el mismo espacio de nombres? Intenté lo siguiente, pero fue en vano: https://www.typescriptlang.org/docs/handbook/namespaces.html#multi-file-namespaces
Mi punto es organizar el proyecto con muchos componentes y módulos. Tengo muchos archivos con nombres muy largos para describir su funcionalidad, por ejemplo:
-> very-descriptive-A-list.module -> very-descriptive-A-list.component -> very-descriptive-A-list-item.component -> very-descriptive-A-list-modal.component etcy solo quería crear un espacio de nombres que envolviera cada funcionalidad, así:
-> very-describtive-A namespace: ->> list.module, ->> list.component, ->> item.component ->> modal.component etc -> very-describtive-B namespace: ->> list.module, ->> list.component, ->> item.component ->> modal.component etcY así sucesivamente para cualquier otra funcionalidad. Estaba pensando en reducir los nombres de archivo repetitivos y también es bueno para IDE intellisense porque los componentes dentro de los espacios de nombres están encapsulados y ocultos.
Los espacios de nombres mecanografiados son esencialmente obsoletos en este momento. TypeScript tenía el concepto antes de que se agregaran los módulos ES a ES6. Los objetivos de diseño de TypeScript son mantener el lenguaje sincronizado con ECMA siempre que sea posible, por lo que, si bien puede tener una función antes que ECMA, favorecerá la implementación nativa si se agrega una más adelante. Los "módulos externos" de TypeScript ahora son en gran medida indistinguibles de los módulos ES y son suficientes para ambos casos de uso. Consulte https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html#needless-namespacing
El comportamiento que está buscando es el propósito de un archivo index.ts . Por lo general, cuando un directorio determinado tiene un index.ts , significa que los demás contenidos del directorio son "internos" (es decir, no los usa nada fuera del directorio), y las cosas exportadas del índice son el "módulo externo" .
button ├── button-component.ts ├── button-module.ts └── index.ts El index.ts generalmente sería algo como:
export { ButtonComponent } from './button-component'; export { ButtonModule } from './button-module';Para el comportamiento en su pregunta, puede importar todo el módulo en una variable como:
import * as Button from './button'; // ... imports: [ Button.ButtonModule,Sin embargo, es más común importar solo los miembros específicos necesarios como:
import { ButtonModule } from './button'; Ciertamente puede hacerlo de cualquier manera, pero la primera es más idiomática, como lo demuestra CommonModule o AppRoutingModule usan en el mismo lugar. El espacio de nombres explícito es simplemente innecesario, ya que no hay ambigüedad en la fuente de la import .
La sintaxis import * as es conveniente en un puñado de casos en los que algo exporta una gran cantidad de cosas que usas juntas, pero el caso de uso típico es un módulo que exporta un grupo de funciones estrechamente relacionadas, no un montón de tipos . P.ej
api/ ├── create-user.ts ├── delete-user.ts ├── get-user.ts ├── index.ts └── update-user.ts import * as api from './api'; // ... await api.getUser(123); await api.deleteUser(123); Es indistinguible de un api.ts que exporta un objeto con todos esos métodos, pero es conveniente organizar el código en archivos separados.