Skip to content

Commit afe66f3

Browse files
feat: Web Components section (#13)
* docs: add front-end/web-components.md * style: lint web-components.md * style: lint web-components.md * squash: adding the notes from our previous meetings on web components * squash: lint * squash: update readme * squash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squuash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squash: add link to community group * squash: Update docs/front-end/web-components.md Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]> * squash: liniting * squash: more updates --------- Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
1 parent c491520 commit afe66f3

File tree

2 files changed

+94
-1
lines changed

2 files changed

+94
-1
lines changed

README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -59,8 +59,8 @@ The reference architecture covers the following components (currently a work in
5959
- [Transactions_handling](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/functional-components/transaction-handling.md)
6060
- Front End
6161
- Front End Frameworks
62-
- Web Components
6362
- [Offline](docs/front-end/offline.md)
63+
- [Web Components](docs/front-end/web-components.md)
6464
- Local Storage
6565
- Authentication/Authorization
6666
- [Cross Platform](docs/front-end/cross-platform.md)

docs/front-end/web-components.md

+93
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,93 @@
1+
# Web Components
2+
3+
The [WHATWG](https://html.spec.whatwg.org/multipage/custom-elements.html) and [WICG](https://github.com/WICG/webcomponents) maintain suite of web technologies and specifications including (but not limited to)
4+
5+
- [Custom Elements](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements)
6+
- [Shadow DOM](https://dom.spec.whatwg.org/#shadow-trees)
7+
- The [`<template>` element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element)
8+
- The [`<slot>` element](https://html.spec.whatwg.org/multipage/scripting.html#the-slot-element)
9+
- [`ElementInternals`](https://html.spec.whatwg.org/multipage/custom-elements.html#element-internals)
10+
- [CSS Custom Properties](https://drafts.csswg.org/css-variables/)
11+
- [Module scripts](https://html.spec.whatwg.org/#module-script)
12+
13+
These are collectively referred to as "web components", and represent the browsers' native component model for web developers.
14+
15+
Broadly speaking, every web component is a custom element - a specific tag-name which becomes associated with a class extending HTMLElement in JavaScript. Web components can also make use of the related technologies.
16+
17+
## Recommended Components
18+
19+
- [Lit](https://lit.dev) (library and framework for authoring components)
20+
- [Web Dev Server](https://modern-web.dev) / Web Test Runner (for unit tests and local dev)
21+
- [Custom Elements Manifest](https://github.com/webcomponents/custom-elements-manifest) (for ide support / docgen / codegen)
22+
- [PatternFly Elements](https://patternflyelements.org) Design System
23+
- [Carbon Web Components](https://web-components.carbondesignsystem.com/) Design System
24+
- [Web Components Community Group](https://github.com/w3c/webcomponents-cg/)
25+
26+
## Guidance
27+
28+
### Our Experiences Using Web Components at Red Hat
29+
30+
The team at Red Hat has been involved in several Web Component projects and have learned a good amount about Web Components and how to write them
31+
32+
Two Web Component "Systems" at Red Hat are
33+
34+
- [PatternFly Elements](https://patternflyelements.org/) (aka PFE) (“upstream”)
35+
- [Red Hat Design System](https://ux.redhat.com/) (aka RHDS) (“downstream”)
36+
37+
### Advantages and Ideal Use Cases
38+
39+
Through the teams experience with Web Components, we've identified a few different pros and cons when using Web Components and what type of applications you might want to use them with.
40+
41+
#### Accessibility
42+
43+
a single implementation of complex ui patterns can help teams to ship accessible experiences with less fuss
44+
45+
#### Work Across frameworks / Cross Team Collaboration
46+
47+
the same `<rh-card>` which works in drupal can work the same way in react, or in an ejs template, and the teams working with those components can transfer that knowledge to other projects, instead of reimplementing design specs for each new framework.
48+
49+
#### Design Systems
50+
51+
The case for web component-based design systems is strong because of encapsulation / knowledge transfer / future proofing as described above. These can also include a certain amount of business logic like analytics code, personalization, etc (ymmv)
52+
53+
#### Microfrontends
54+
55+
This is another case where web components and shadow dom shine, as the encapsulation guarantees and framework interoperability aspects lend themselves naturally to enabling teams to cooperate while maintaining boundaries.
56+
57+
#### Greenfield SPA
58+
59+
There’s an argument to be made from a loading / rendering perf and future-proofing perspective to start new projects with a web component framework (like lit, stencil, hybrids, FAST, etc) in place of traditional / legacy framework (angular, react, vue)
60+
61+
docs.redhat.com (a greenfield project) leaned heavily on RHDS web components, and that helped ship the project faster
62+
63+
#### Piecemeal migration
64+
65+
The framework interoperability aspect enables upgrading complex projects on a component-by-component basis. Rather than break the entire app when bumping the underlying frontend-framework from vX to vY, replace components one by one with interoperable web components.
66+
67+
### Common Gripes
68+
69+
As with all programming models, there are some gotchas that the team has encountered:
70+
71+
- cross-root aria
72+
- To prevent a11y failures, signifacant expertise might be needed
73+
74+
- double-registration errors when bundling modules. we recommend using a global import map for each page
75+
- Server-side Rendering (SSR) gotchas. When using the `lit-ssr` library to generate [declarative shadow DOM templates](https://web.dev/articles/declarative-shadow-dom), hydration mismatches when client initial state differs from server rendered state can be difficult to recover from.
76+
- shadow DOM can be a double edged sword. Teams which are unused to it may find it difficult to work with at first
77+
78+
- Unit Testing
79+
- JSDOM/Jest may not work with your custom elements: teams may have to author their components with node environments / DOM shims in mind, which can increase payloads to the client in some cases.
80+
- [@open-wc/testing](https://open-wc.org/docs/testing/testing-package/) is a testing framework that the team has had success with.
81+
82+
### General Concensus
83+
84+
Authoring web components: If you have a team with web platform experience, that always have an MDN tab open, and you’re hopeful to leverage current and future web standards like PWA, then you’re likely to succeed. If on the other hand you don’t have much senior experience or depth of knowledge on web platform features, you may run into issues. However, your teams that overcome those issues will gain platform knowledge and not just framework knowledge.
85+
86+
Using web components inside of other major frameworks: our teams have consistently reported that consuming web components inside other frameworks is typically a turnkey developer experience which saves time and reduces duplication of effort.
87+
88+
Since Web Components rely on code that is already in the browser, they reduce the page load for the end user.
89+
90+
#### Resources
91+
92+
- [Vaadin lit vs Reac Performance Comparision](https://www.youtube.com/watch?v=CJYkwDTaHzY)
93+
- [Page Loading Comparison - 2023 Devconf.cz](https://bennypowers.dev/decks/devconf-brno-2023/#slide-27/step-1)

0 commit comments

Comments
 (0)