Web components - Services / non html components

问题

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

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.

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.

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.

So my question is two-fold:

• 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?

回答1:

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

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

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

Superduper "Tools"

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"

In that sense they can be compared to 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.

Today's playing field

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

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)

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

The odd one out

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

React scores 71% at https://custom-elements-everywhere.com/

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

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 -https://auth0.com/blog/the-real-story-behind-es4/)
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.

Makes for an interesting future:

• Will Facebook solve that 71% score?

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

The Future is now

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

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?

Your questions

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?

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.

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.

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.

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

Enough rambling

The Custom Elements API is a JavaScript language construct.

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

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

My advice:

• 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

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.

来源：https://stackoverflow.com/questions/62284281/web-components-services-non-html-components