关于这个问题，我们非常依赖Web组件，而新的Angular hydration方法并没有充分支持Web组件的渲染。正如@dchicurel提到的，用户体验确实如此。这个问题阻止我们拥抱新的非破坏性渲染特性，并将阻止我们升级到默认使用新渲染方法的Angular 17。

虽然旧的破坏性渲染方法似乎可以工作，但它会导致较差的用户体验。用户短暂地看到整个页面，然后在一段时间内变空白，或者在最终渲染之前经历页面 Flink 。这种行为也对我们的Web性能指标产生负面影响。我真诚地希望我们能在这方面得到一些指导，并找到解决这个问题的最佳方法。谢谢。

+1
我正在为低级跨框架兼容性投资更多的web组件设计系统。
我还没有对web组件进行服务器端渲染，但我希望能够这样做。我正在使用Lit和Stencil web组件的混合。
为了解决CLS问题，我正在为web组件设置预处理的CSS尺寸。
设计系统组件关注样式而不是行为。例如，一个按钮组件可能只需要：

html`<slot @onclick="this.handleClick"></slot>`

并添加一些构造好的插槽样式。
以下是预期的使用方式：

• my-button.component.ts*

@Component({
  selector: 'some-button',
  template: `
    <design-system-button> // provided by the design system
      <button onClick="handleClick()"></button>
    </<design-system-button>
  `,
    standalone: true,
    schemas: [CUSTOM_ELEMENTS_SCHEMA]
})
export class SomeButtonComponent {
  public handleClick() {}
}

另一个例子是一个用于在所有页面上添加全局页眉和页脚的web组件。Angular应用程序被插槽到页眉/页脚组件中：

• index.html*

<page-wrapper> <!-- global header and footer applied -->
  <my-angular-app-root></my-angular-app-root> <!-- angular app is projected via a <slot> -->
</page-wrapper>

两种消费模式:

Web组件可以是构建时依赖项或运行时依赖项。运行时对于大部分静态或独立管理的组件很有用，这些组件调用自己的服务；例如，一个“微前端”。通过不需要升级这些组件的npm依赖项来获取这些MFE的更新，从而使应用程序与它们几乎没有交互。上面的page-wrapper就是一个很好的例子。
或者，web组件可以从npm像今天的Material Design那样进行构建时集成。

最后的想法

今天，随着web组件在我的应用中进行CSR,Angular SSR似乎只是忽略了自定义元素，因此，主要的缺点在于闪现内容，因为web组件在SSR发生后在客户端进行预处理。

你好，

请问你能帮我吗？我有一个带有Cyberpanel的VPS,已经上传了dist文件夹，但是SEO不起作用，源代码中没有HTML标签。

谢谢！

这个问题阻止我们采用新的非破坏性水合特性，并阻止我们升级到Angular 17,因为我相信在默认情况下新的方法将被使用。我非常确定你可以移除provideClientHydration()来坚持使用旧的机制，所以这不应该阻止升级到v17。启用非破坏性水合并不需要使用v17。

为了获得额外的上下文，我认为Web组件目前没有为SSR定义一个明确的模型，而且我认为每个框架在这里基本上都在做自己的事情。有一个提议的社区协议用于SSR,它可以定义一个可互操作的协议，但现在还处于相当早的阶段。

一个潜在的解决方案可以是添加配置，用于选择一组组件(以及/或一组选择器的正则表达式),并调用相关函数来执行该组件的SSR渲染。然后，也许可以添加一个标志以启用对组件及其传递的属性进行缓存的性能优化。