Web 组件 - 服务/非 html 组件
Web components - Services / non html components
所以我来自 Angular，想看看如何创建 vanilla Web components。
现在来自 Angular，我们倾向于将事物分开：组件（充当 HTML、CSS 和一些 javascript）然后 "services" 主要是做一些工作，比如收集数据和做 "hard backend" 不应该在组件中发生的工作。
虽然我知道 Web 组件和 Angular 之类的框架不是一回事，但我想知道您将如何构建项目。
我在 Web 组件上找到的所有文章都只解释了最低限度的内容（Shadow-dom、模板和自定义 HTML）
他们并没有真正向您展示如何使用该技术创建企业级应用程序。
所以我的问题有两个方面：
- 使用 Web 组件构建的企业级应用程序的结构体系结构的最佳实践是什么？
- 您在使用 Web 组件时是否会分离核心逻辑（例如加密、数据流等）？如果是，是怎么做的？
我越来越倾向于说“Web组件”是一个language construct。
它被称为 自定义元素 API，因此与 Fetch API 或 MutationObserver API
那么你的问题是：我怎样才能用[这里的名字]构建一个应用程序API？
超级“工具”
Lit、Hybrids、HyperHTML、Lego、Stencil 等工具都有 polyfill 背景，它们使“Web 组件”在 olden 时代成为可能浏览器不完全支持自定义元素 API.
他们已经发展到所有人都声称“这是开发 Web 组件的最佳工具”
从这个意义上说，它们可以与 jQuery.
相提并论
曾经是 Web 开发人员的必修课，
然后选择器等成为 W3C 标准的一部分。
随着 2011 年 IE9 的出现，jQuery 不再真正需要了。
今天的比赛场地
现在，Edge 运行正在 Chromium 上运行，Microsoft 默认推送 Edge。所有现代浏览器都符合自定义元素 API
将 jQuery 的比较在历史上更进一步。 10 年前有数十种 jQuery 替代品。如果您碰巧投资了“错误”的工具，您最终不得不转换为 jQuery（或者如果 IE9 是您必须支持的最旧的浏览器并且您了解 W3C 标准（几乎），则只能转换为 Native JavaScript永远赢)
Lit、Hybrids、HyperHTML、Lego、Stencil 和所有其他产品也会发生同样的情况。
奇数出局
Angular 或 Svelte 或 Vue 都可以 100% 很好地使用自定义元素 API
React 在 https://custom-elements-everywhere.com/
得分为 71%
60%的React负责人会说W3C标准不支持React
如果您已经工作了足够长的时间（> 20 年），您就会明白 React 可以与 ECMAScript-4（never made it 的 W3C 标准）进行比较
伟大的技术，但如果浏览器供应商不在浏览器中实现它，它就没有未来。这意味着 React 也有潜力 "jQuery"。或者 Flash（ActionScript 具有 ES4 结构）可能是更好的比较。
创造有趣的未来：
Facebook 会解决 71% 的分数吗？
所有浏览器供应商（Mozilla、Google/Microsoft、Apple）都会实现 React(Native) 吗？
未来就是现在
如果您不必支持 IE11，则可以使用现代级别的自定义元素 API 竞争环境。
如果你正在学习，先学习 API，然后看看工具是否可以让你的开发生活更轻松（并接受风险，当你选择的工具与 MooTools、YUI 不同时，所有这些都需要重构还有很多人去了）...
再一次......银行仍然运行 Cobol......也许React是新的Cobol？
您的问题
What are the best practices for the structural architecture of an enterprise-level application made with web components?
Is separation of core logic such as encryption, datastreaming, and so on something you do when using web components, and if so how?
您使用使用 Web Components 构建应用程序，就像使用使用 类 或代理构建应用程序一样。组件封装了逻辑，唯一的区别是自定义元素 API 也 产生了很好的（真的很棒）语义 HTML.
唉，我看到公司和开发人员专注于“工具”而不是 API
对我来说，傻子有了工具，还是傻子。
当 TypeScript 发布时，我正身处 Microsoft SharePoint 世界。
将 MVP“很棒”的 TypeScript（可惜在 ES3 语法中因为他们忘了跟上 JavaScript）重构为 ES6
赚了很多钱
当微软全力投入 React 时，我离开了那个世界。
组件开发人员现在学习工具，就像他们学习 jQuery...
废话少说
自定义元素 API 是一种 JavaScript 语言结构。
它在某些方面做得非常好，而在其他方面则不太好。
API 会产生影响吗？是的，就像 类 和 Array 方法一样。那些也需要改变思维方式。
我的建议：
- 和他们一起玩，就像你学习
.map 和 .reduce
- 不要尝试编写成熟的应用程序，从小处着手
- 在 JSFiddle 或 CodePen 中创建 TicTacToe。
- 向 here on Whosebug Code Review 寻求反馈。
- 犯错误
- 犯更多错误
- 犯更多错误
- 学习
自定义元素API 是 W3C 标准，所有浏览器都支持，
只要浏览器中 JavaScript 运行 秒，这项技术就可以工作。
我经历了同样的周期并有同样的问题，实际上处于需要创建企业应用程序的位置，并作为解决方案架构师提供我的 co-workers 建议。凭借 20 年的 Web 技术背景，我认为这并不难回答。
决定支持“现代浏览器”后，Web 组件 API 的选择就很容易了。我对 Angular 和 React 也很了解。我们决定使用项目结构和类似的工具链（WebPack、Jest 等）。这显然是非常明智的。
一开始它只是我们写给 DRY 的一些库代码。它在一年后以一个完整的瘦库结束（让我 put it here as a reference）。一段时间后，我们明白我们确实需要数据绑定、状态模型和集成验证。没有它，您的工作效率就不够高。它仍然比胖框架紧凑得多，但它不仅仅是一种新的 jQuery。 Web 组件本身只是 API 调用。但其他一切都是在 Proxy 和他的同事之上的艰苦工作。这就是所有较小的库或多或少试图实现的目标（Lit、Hybrids、HyperHTML、Lego、Stencil 等）。我们最终得到了一些非常完整且非常接近胖兄弟的东西，但仍然非常小（像 Angular 这样的装饰器与像 React 这样的 JSX 混合在一起）。但是，尽管您渴望编写一个库，但我还是建议您看一下上面提到的其中一个。请注意，未来 API 可能会进一步减少需求，我很确定 ES2025 将包含大量此类内容。
Disclaimer: I'm the creator and maintainer of such a thin library, called @nyaf.
所以我来自 Angular，想看看如何创建 vanilla Web components。
现在来自 Angular，我们倾向于将事物分开：组件（充当 HTML、CSS 和一些 javascript）然后 "services" 主要是做一些工作，比如收集数据和做 "hard backend" 不应该在组件中发生的工作。
虽然我知道 Web 组件和 Angular 之类的框架不是一回事，但我想知道您将如何构建项目。
我在 Web 组件上找到的所有文章都只解释了最低限度的内容（Shadow-dom、模板和自定义 HTML）
他们并没有真正向您展示如何使用该技术创建企业级应用程序。
所以我的问题有两个方面：
- 使用 Web 组件构建的企业级应用程序的结构体系结构的最佳实践是什么？
- 您在使用 Web 组件时是否会分离核心逻辑（例如加密、数据流等）？如果是，是怎么做的？
我越来越倾向于说“Web组件”是一个language construct。
它被称为 自定义元素 API，因此与 Fetch API 或 MutationObserver API
那么你的问题是：我怎样才能用[这里的名字]构建一个应用程序API？
超级“工具”
Lit、Hybrids、HyperHTML、Lego、Stencil 等工具都有 polyfill 背景，它们使“Web 组件”在 olden 时代成为可能浏览器不完全支持自定义元素 API.
他们已经发展到所有人都声称“这是开发 Web 组件的最佳工具”
从这个意义上说，它们可以与 jQuery.
相提并论曾经是 Web 开发人员的必修课，
然后选择器等成为 W3C 标准的一部分。
随着 2011 年 IE9 的出现，jQuery 不再真正需要了。
今天的比赛场地
现在，Edge 运行正在 Chromium 上运行，Microsoft 默认推送 Edge。所有现代浏览器都符合自定义元素 API
将 jQuery 的比较在历史上更进一步。 10 年前有数十种 jQuery 替代品。如果您碰巧投资了“错误”的工具，您最终不得不转换为 jQuery（或者如果 IE9 是您必须支持的最旧的浏览器并且您了解 W3C 标准（几乎），则只能转换为 Native JavaScript永远赢)
Lit、Hybrids、HyperHTML、Lego、Stencil 和所有其他产品也会发生同样的情况。
奇数出局
Angular 或 Svelte 或 Vue 都可以 100% 很好地使用自定义元素 API
React 在 https://custom-elements-everywhere.com/
得分为 71%60%的React负责人会说W3C标准不支持React
如果您已经工作了足够长的时间（> 20 年），您就会明白 React 可以与 ECMAScript-4（never made it 的 W3C 标准）进行比较
伟大的技术，但如果浏览器供应商不在浏览器中实现它，它就没有未来。这意味着 React 也有潜力 "jQuery"。或者 Flash（ActionScript 具有 ES4 结构）可能是更好的比较。
创造有趣的未来：
Facebook 会解决 71% 的分数吗？
所有浏览器供应商（Mozilla、Google/Microsoft、Apple）都会实现 React(Native) 吗？
未来就是现在
如果您不必支持 IE11，则可以使用现代级别的自定义元素 API 竞争环境。
如果你正在学习，先学习 API，然后看看工具是否可以让你的开发生活更轻松（并接受风险，当你选择的工具与 MooTools、YUI 不同时，所有这些都需要重构还有很多人去了）...
再一次......银行仍然运行 Cobol......也许React是新的Cobol？
您的问题
What are the best practices for the structural architecture of an enterprise-level application made with web components? Is separation of core logic such as encryption, datastreaming, and so on something you do when using web components, and if so how?
您使用使用 Web Components 构建应用程序，就像使用使用 类 或代理构建应用程序一样。组件封装了逻辑，唯一的区别是自定义元素 API 也 产生了很好的（真的很棒）语义 HTML.
唉，我看到公司和开发人员专注于“工具”而不是 API
对我来说，傻子有了工具，还是傻子。
当 TypeScript 发布时，我正身处 Microsoft SharePoint 世界。
将 MVP“很棒”的 TypeScript（可惜在 ES3 语法中因为他们忘了跟上 JavaScript）重构为 ES6
赚了很多钱
当微软全力投入 React 时，我离开了那个世界。
组件开发人员现在学习工具，就像他们学习 jQuery...
废话少说
自定义元素 API 是一种 JavaScript 语言结构。
它在某些方面做得非常好，而在其他方面则不太好。
API 会产生影响吗？是的，就像 类 和 Array 方法一样。那些也需要改变思维方式。
我的建议：
- 和他们一起玩，就像你学习
.map和.reduce - 不要尝试编写成熟的应用程序，从小处着手
- 在 JSFiddle 或 CodePen 中创建 TicTacToe。
- 向 here on Whosebug Code Review 寻求反馈。
- 犯错误
- 犯更多错误
- 犯更多错误
- 学习
自定义元素API 是 W3C 标准，所有浏览器都支持，
只要浏览器中 JavaScript 运行 秒，这项技术就可以工作。
我经历了同样的周期并有同样的问题，实际上处于需要创建企业应用程序的位置，并作为解决方案架构师提供我的 co-workers 建议。凭借 20 年的 Web 技术背景，我认为这并不难回答。 决定支持“现代浏览器”后，Web 组件 API 的选择就很容易了。我对 Angular 和 React 也很了解。我们决定使用项目结构和类似的工具链（WebPack、Jest 等）。这显然是非常明智的。 一开始它只是我们写给 DRY 的一些库代码。它在一年后以一个完整的瘦库结束（让我 put it here as a reference）。一段时间后，我们明白我们确实需要数据绑定、状态模型和集成验证。没有它，您的工作效率就不够高。它仍然比胖框架紧凑得多，但它不仅仅是一种新的 jQuery。 Web 组件本身只是 API 调用。但其他一切都是在 Proxy 和他的同事之上的艰苦工作。这就是所有较小的库或多或少试图实现的目标（Lit、Hybrids、HyperHTML、Lego、Stencil 等）。我们最终得到了一些非常完整且非常接近胖兄弟的东西，但仍然非常小（像 Angular 这样的装饰器与像 React 这样的 JSX 混合在一起）。但是，尽管您渴望编写一个库，但我还是建议您看一下上面提到的其中一个。请注意，未来 API 可能会进一步减少需求，我很确定 ES2025 将包含大量此类内容。
Disclaimer: I'm the creator and maintainer of such a thin library, called @nyaf.