Web 组件 - 服务/非 html 组件 [英] Web components - Services / non html components

问题描述

所以我来自 Angular，想看看如何创建 vanilla Web 组件.

So I am coming from Angular and wanted to take a look at how to create vanilla Web components.

现在来自 Angular，我们倾向于将事情分开:组件(充当 HTML、CSS 和一些 javascript)，然后是服务"，主要充当诸如收集数据和执行硬后端"工作之类的工作.不应该发生在组件中.

Now coming from Angular we tend to have things divided: Components (which acts as HTML,CSS, and some javascript) and then "services" which mainly acts do jobs such as collecting data and doing the "hard backend" jobs that shouldn't happen in components.

现在虽然我知道 Web 组件和框架(例如 Angular)不是一回事，但我想知道您将如何构建项目.

now while I know that Web components and a Framework such as Angular are not the same things I am wondering how you would structure a project.

我在 web 组件上找到的所有文章都只解释了最低限度(Shadow-dom、模板和自定义 HTML)

All the articles I've found on web components only explain the bare minimum (Shadow-dom, template and custom HTML)

它们并未真正向您展示如何使用该技术创建企业级应用程序.

They don't really show you how to create an enterprise-level application with the technology.

所以我的问题有两个:

• 使用 Web 组件构建的企业级应用程序的结构体系结构的最佳实践是什么?
• 在使用 Web 组件时，您是否需要分离核心逻辑(例如加密、数据流处理等)，如果需要，如何分离?

推荐答案

我越来越倾向于说Web Components"是语言结构.

I am more and more inclined to say "Web Components" are a language construct.

它被称为自定义元素 API，因此与 Fetch API 或 MutationObserver API 没有区别

It is called the Custom Elements API, so no different from the Fetch API, or the MutationObserver API

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

Then your question is: How can I build an application with the [name here] API?

Lit、Hybrids、HyperHTML、Lego、Stencil 等工具都有 polyfill 背景，它们制作了Web Components"在浏览器不完全支持自定义元素 API 的过去时代是可能的.
他们已经发展到都声称这是开发 Web 组件的最佳工具"

Tools like Lit, Hybrids, HyperHTML, Lego, Stencil, all have a polyfill background, they made "Web Components" possible in the olden days when Browsers didn't fully support the Custom Elements API.
They have evolved to all claiming "This is the best Tool to develop Web Components"

从这个意义上说，它们可以与 jQuery 相提并论.

In that sense they can be compared to jQuery.

曾经是 Web 开发人员的必备工具，
然后选择器等成为 W3C 标准的一部分.
随着 IE9 在 2011 年的出现，人们不再真正需要 jQuery.

Once a must for Web Developers,
and then selectors etc. became part of the W3C standard.
With the advent of IE9 in 2011, there was no real need for jQuery anymore.

现在，Edge 在 Chromium 上运行，微软默认推送 Edge.所有现代浏览器都符合自定义元素 API

Now, Edge is running on Chromium, and Microsoft pushes Edge by default. All modern Browsers are up to par with the Custom Elements API

让 jQuery 比较在历史上更进一步.10 年前有数十种 jQuery 替代品.如果您碰巧投资错误"工具，您最终必须转换为 jQuery(或者如果 IE9 是您必须支持的最古老的浏览器，并且您了解 W3C 标准(几乎)总是获胜，那么您就只能转换为 Native JavaScript)

To take the jQuery comparison one step further back in history. There were dozens of jQuery alternatives 10 years ago. If you happened to invest in the "wrong" tool, you eventually had to convert to jQuery (or just Native JavaScript if IE9 was the oldest browser you had to support and you understood W3C standards (nearly) always win)

Lit、Hybrids、HyperHTML、Lego、Stencil 和所有其他产品也会发生同样的情况.

The same is going to happen with Lit, Hybrids, HyperHTML, Lego, Stencil and all others.

Angular、Svelte 或 Vue 都可以 100% 使用自定义元素 API

Angular or Svelte or Vue all play 100% nicely with the Custom Elements API

在 https://custom-elements-everywhere.com/

60% 的 React 负责人会说 W3C 标准不支持 React.

The 60% React heads will say the W3C standard does not support React.

如果您已经使用了足够长的时间(> 20 年)，您就会明白 React 可以与 ECMAScript-4(W3C 标准 从未成功)
伟大的技术，但如果浏览器供应商不在浏览器中实现它，它就没有未来.这意味着 React 也是一个潜在的 jQuery".或者 Flash(ActionScript 具有 ES4 构造)是一个更好的比较.

If you have been around long enough (> 20 years) you understand React can be compared to ECMAScript-4 (the W3C standard that never made it)
Great technology, but if the Browser Vendors don't implement it in the Browser, it has no future. That means React is a potential "jQuery" also. Or maybe Flash (ActionScript had ES4 constructs) is a better comparison.

创造一个有趣的未来:

• Facebook 会解决 71% 的问题吗?

• Will Facebook solve that 71% score?

所有浏览器供应商(Mozilla、Google/Microsoft、Apple)都会实施 React(Native) 吗?

Will all Browser vendors (Mozilla,Google/Microsoft,Apple) implement React(Native)?

如果您不必支持 IE11，则有一个现代的、级别的自定义元素 API 游戏场.

If you do not have to support IE11 there is a modern, level Custom Elements API playing field.

如果您正在学习，请先学习 API，然后看看 Tools 是否可以让您的开发生活更轻松(并接受当您选择的工具适用于 MooTools、YUI 和许多其他工具时需要重构的风险)...
再说一遍……银行仍在运行 Cobol……也许 React 是新的 Cobol?

If you are learning, learn the API first, then see if Tools can make your development life easier (and accept the risk it all needs to be refactored when your tool of choice goes where MooTools, YUI and many others went) ...
Then again... banks still run Cobol... maybe React is the new Cobol?

使用 Web 组件构建的企业级应用程序的结构体系结构的最佳实践是什么?您在使用 Web 组件时是否需要分离核心逻辑，例如加密、数据流等，如果需要，如何分离?

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 组件构建应用程序，就像您使用 类或代理构建应用程序一样.组件封装了逻辑，唯一的区别是自定义元素 API也 实现了很棒的(非常棒的)语义 HTML.

You built applications with Web Components as you built applications with Classes or Proxies. Components encapsulate logic, only difference being the Custom Elements API also makes for great (really great) semantic HTML.

唉，我看到公司和开发人员专注于工具"而不是在 API 上

Alas, I see companies and developers focussing on the "Tools" instead of on the API

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

To me, a fool with a tool, is still a fool.

当 TypeScript 推出时，我在 Microsoft SharePoint 世界中.重构MVP很棒"赚了大钱TypeScript(可惜在 ES3 语法中，因为他们忘记跟上 JavaScript)到 ES6
当微软全力投入 React 时，我离开了那个世界.

I was in the Microsoft SharePoint world, when TypeScript was launched. Made good money refactoring MVPs "great" TypeScript (alas in ES3 syntax because they forgot to keep up with JavaScript) to ES6
I left that world when Microsoft went all-in on React.

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

Component developers now learn tools, like they learned jQuery...

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

它在某些方面做得很好，而其他方面做得不太好.

It does some things really well and others not so well.

API 会产生影响吗?是的，就像类和数组方法一样.而那些也需要改变心态.

Will the API make an impact? Yes, just like Classes and Array methods did. And those required a mind-set change also.

我的建议:

• 和他们一起玩，就像你学过的 .map 和 .reduce
• 不要试图编写成熟的应用程序，从小处着手
• 在 JSFiddle 或 CodePen 中创建井字游戏.
• 在此处在 StackOverflow 代码审查上询问反馈.
• 犯错
• 犯更多错误
• 犯更多错误
• 学习

Custom Elements API 是 W3C 标准，所有浏览器都支持，
只要 JavaScript 在浏览器中运行，这项技术就会一直有效.

The Custom Elements API is a W3C standard, supported by all Browsers,
this technology will work for as long as JavaScript runs in the Browser.

这篇关于Web 组件 - 服务/非 html 组件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！