(以及指令和管道!)
几个月前,我们发布了第一个与“独立组件”项目相关的 RFC 。该项目有一个雄心勃勃的目标:通过无需 NgModule 构建组件和应用程序,减少样板文件并使 Angular 更易于使用和学习。
本周,我们将在此基础上发布第二个 RFC,讨论如何将独立组件集成到 Angular 框架的其余部分中。在这篇文章中,我们将分享项目更新、迄今为止学到的一些经验教训以及开发人员在不久的将来可以期待的内容。
独立组件将:
应用程序中的一个常见要求是延迟加载特定路由。今天完成这个任务相当冗长。要延迟加载到LazyPageComponent
的路由,例如:
// In a separate `lazy.routing.ts` file:
@NgModule({
imports: [
LazyPageModule,
RouterModule.forChild([
{path: '', pathMatch: 'full', component: LazyPageComponent},
]),
],
})
export class LazyPageRoutingModule {}
// Then, in the main application routing configuration:
export const ROUTES: Route[] = [
/* ...other routes */
{
path: 'lazy',
loadChildren: () => import('./lazy.routing').then(mod => mod.LazyPageRoutingModule),
},
];
这是需要编写和理解的大量代码。也很容易犯一些细微的错误。例如,如果您忘记将LazyPageModule
导入LazyPageRoutingModule
,并且LazyPageComponent
缺少依赖项,则此路由可能无法在运行时工作。
通过利用独立组件提供的保证的新 API,上述内容可以简化为:
// routing-after.ts
export const ROUTES: Route[] = [
/* ...other routes */
{
path: 'lazy',
loadComponent: () => import('./lazy.component').then(mod => mod.LazyPageComponent),
},
];
有关建议的用于延迟加载各个独立组件的loadComponent
API 的更多详细信息,请在新的 RFC 中找到更多信息。
在过去的几个月里,我们将工作重点放在独立组件如何融入 Angular 的其余部分以及如何使用它们来完成特定用例而不需要依赖 NgModule 的问题上。第二个 RFC 提出了与独立组件集成的新 API,以支持以前需要 NgModule 的主要用例:
此外,RFC 还涵盖了与减少编写 NgModule 的需求这一更大目标相关的其他 API,包括:
在向 Angular 添加任何新功能(包括独立项目)时,代码大小始终是一个主要考虑因素。我们花了很多时间思考新功能对捆绑包大小的影响,以及如何在常见情况下最大限度地减少这种影响。通常,这些考虑因素是双向的:仍然使用旧 API 的现有应用程序不需要发布与新 API 相关的代码,但新 API 的用户也不需要发布与旧 API 相关的代码。
例如,使用建议的新独立引导 API 的应用程序不需要发布与之前基于 NgModule 的引导系统相关的代码。要使其以最佳方式工作具有挑战性,因为旧 API 的设计不一定考虑到这些因素。
短期内我们不打算更新 Angular 样式指南或默认的ng new
应用程序。独立组件将首先作为可选功能提供。
从长远来看,我们将收集社区开发人员使用新 API 时的反馈,并使用这些反馈来修改样式指南和ng new
体验。
独立组件核心功能的实现已经顺利进行,我们已经开始对新 RFC中描述的建议 API 进行原型设计。当我们收到反馈时,我们将完善这些实施。
由于独立组件和相关 API 的所有功能都是选择加入且不间断的,因此独立组件不必等待主要版本 – 我们将能够在即将发布的次要版本中发布这一令人兴奋的新功能准备好后立即进行角化。因此,请继续关注我们不断取得的进展,并务必阅读RFC !
原文链接:https://blog.angular.dev/an-update-on-standalone-components-ea53b4d55214