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

问题描述

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

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组件上找到的所有文章仅说明了最低限度的要求(影子域，模板和自定义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组件"是语言构造 .

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

它被称为 Custom Elements API ，因此与Fetch API或MutationObserver API没什么不同

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

然后您的问题是:如何使用[此处的名称] API构建应用程序?

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

诸如Lit，Hybrids，HyperHTML，Lego，Stencil之类的工具都具有polyfill背景，它们使"Web组件"成为在浏览器不完全支持自定义元素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上运行，并且Microsoft默认情况下推送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标准(几乎)始终是赢家，那么就只能转换为本机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.

使用Custom Elements API，Angular，Svelte或Vue都能很好地播放100％

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标准进行比较，该标准.也许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组件构建了 应用程序，而您使用 类或代理构建了应用程序.组件封装了逻辑，唯一的不同是Custom Elements 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.

A，我看到公司和开发人员专注于工具"而不是使用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中创建TicTacToe.
• 在 此处咨询.
• 犯错误
• 犯更多错误
• 犯更多错误
• 学习

• Play with them, like you learned .map and .reduce
• don't try to write full blown applications, start small
• create TicTacToe in a JSFiddle or CodePen.
• Ask here on StackOverflow Code Review for feedback.
• make mistakes
• make more mistakes
• make more mistakes
• learn

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屋！