问Web组件- Services / non组件

EN

我越来越倾向于说"Web“是一个 语言结构。

它被称为自定义元素API，因此与MutationObserver API没有什么不同。

那么您的问题是：如何使用[name ] API?构建应用程序？

超级“工具”

像Lit，混合，HyperHTML，乐高，模具等工具都有一个多填充的背景，它们使得“网络组件”在过去浏览器不完全支持自定义元素API时成为可能。

他们都声称“这是开发Web组件的最佳工具”

从这个意义上说，它们可以与jQuery进行比较。

曾经是Web开发人员的必修课，

然后选择器等成为W3C标准的一部分。

随着2011年IE9 的出现，不再真正需要jQuery了。

今天的比赛场地

现在，Edge运行在Chromium上，而Microsoft默认推送Edge。所有现代浏览器都与自定义元素API并驾齐驱

将jQuery比较进一步追溯到历史的前一步。10年前有几十种jQuery替代品。如果您碰巧投资于“错误”工具，您最终必须转换为jQuery (或者只有本地JavaScript，如果IE9是您必须支持的最古老的浏览器，并且您理解W3C标准(几乎)总是获胜)

同样的情况也将发生在Lit，混合动力车，HyperHTML，乐高，模具和所有其他。

奇怪的一个出来

角或滑轮或Vue都能很好地使用自定义元素API

在https://custom-elements-everywhere.com/的React分数为71%

60%的反应头会说W3C标准不支持反应。

如果你已经有足够长的时间(> 20年)，你就可以把反应比作ecmacript-4( W3C标准，没能做到)。

伟大的技术，但如果浏览器供应商不实现它在浏览器，它没有未来。这意味着反应也是一个潜在的"jQuery“。或者，Flash (ActionScript有ES4构造)是一个更好的比较。

创造一个有趣的未来：

• Facebook会解决这个71%的问题吗？
• 所有浏览器供应商(Mozilla、Google/Microsoft、Apple)都会做出反应(本机)吗？

未来就是现在

如果您不需要支持IE11，那么就有一个现代的、水平的自定义元素API竞争环境。

如果您正在学习，首先学习API，然后看看工具是否可以使您的开发生活变得更容易(并且承担您所选择的工具去MooTools、YUI和许多其他工具时需要重构的风险).

再说一次..。银行还在经营科波..。也许反应是新的科波？

你的问题

使用web组件构建企业级应用程序的结构体系结构的最佳实践是什么？在使用web组件时，核心逻辑的分离(例如加密、数据存储等等)是否是某种事情，如果是，那么如何实现？

您使用Web组件构建应用程序，就像用类或代理构建应用程序一样。组件封装逻辑，唯一不同的是自定义元素API 也是提供了很好(非常棒)的语义HTML。

唉，我看到公司和开发人员专注于“工具”而不是API。

对我来说，一个拿着工具的傻瓜，仍然是个傻瓜。

当微软( Microsoft SharePoint )推出TypeScript时，我正处于微软的世界。将MVP重构为“伟大的”TypeScript (可惜在ES3语法中是因为他们忘记了跟上JavaScript)到ES6，赚了很多钱

当微软全力以赴的时候，我离开了那个世界。

组件开发人员现在学习工具，就像他们学习jQuery一样。

够散漫的了

自定义元素API是一个JavaScript语言结构.

它做一些事情确实做得很好，而另一些则不是很好。

API会产生影响吗？是的，就像类和Array方法一样。而这些也需要思想上的改变。

我的建议是：

• 和他们一起玩，就像你学到了.map和.reduce
• 不要尝试编写完整的应用程序，从小开始
• 在TicTacToe或JSFiddle中创建CodePen。
• 向关于StackOverflow代码审查征求反馈。
• 犯错误
• 犯更多错误
• 犯更多错误
• 学学

自定义元素API是一个W3C标准，所有浏览器都支持它，

只要JavaScript在浏览器中运行，这项技术就能工作。

我经历了同样的循环，也遇到了同样的问题，实际上，我需要创建一个企业应用程序，并作为解决方案架构师向我的同事提供建议。有20年的Web技术背景，我认为这并不难回答。有了支持“现代浏览器”的决定，Web组件API的选择就很容易了。我也有很强的角度和反应的知识。我们决定使用项目结构和类似的工具链(WebPack，Jest，您可以这么说)。这显然是非常明智的。刚开始的时候，这只是我们编写的一些库代码。一年后，它结束了一个完整的瘦库(让我把它放在这里作为参考)。过了一段时间，我们明白了我们确实需要数据绑定、状态模型和集成验证。你根本就没有足够的效率。它仍然比fat框架紧凑得多，但它不仅仅是一种新的jQuery。Web组件本身就是API调用。但是其他的一切都是在代理和他的同事的基础上的艰苦工作。这就是所有较小的图书馆都或多或少地想要达到的目标(Lit，混合，HyperHTML，乐高，模版，.)。我们最终得到了一些非常完整和非常接近胖兄弟的东西，但仍然很小(装饰者像棱角分明的和JSX一样的反应)。但是，尽管您渴望编写一个库，我还是推荐您查看其中一个库。请注意，未来的API可能会进一步减少需求，我非常肯定，ES2025将有大量的这些东西在船上。

免责声明：我是这样一个名为@nyaf的瘦库的创建者和维护者。