community-protocols VS open-wc

> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem

Now that everyone seems to be in love with signals, there is work going on in the web components community group to prepare a spec for a signal (or observable, not sure what they are trying to call it) primitive [0]. It seems that they are getting ready to bring it to TC39 as a proposal.

(In the meantime, the Observable primitive from rxjs been given a go-ahead for browser implementation. There is a proposal ready [1], and I think I heard that it may already be in Chrome behind a flag [2].

So yeah; it's gonna be fun. Especially if both groups call their primitive Observable :-)

0 - https://github.com/webcomponents-cg/community-protocols/issu...

1 - https://github.com/WICG/observable

2 - https://nitter.net/BenLesh/status/1737174784406933599

The custom element spec definitely only deals with the mechanics of when are where to run your component's lifecycle code - it says nothing about data. So your choices are basically property accessors, which are interoperable, but require prop-drilling for global-ish data, or something proprietary like a state management library.

The Web Components Community Group (WCCG) is offering something of a third way with the community protocols: https://github.com/webcomponents-cg/community-protocols

The Context protocol provides tree-scoped ambient data in an interoperable way. It's implemented by Lit and FAST (I believe). It doesn't replace a data store, but it's often used to provide data stores to components, and at least reduce some coupling.

Did you know events can also carry promises? A great showcase of this pattern is the Pending Task Protocol by the Web Components Community Group. Now, "Pending Task Protocol" sounds very fancy, but really, it's just an event that carries a promise.

If you’re coming from the Angular world, you probably appreciate the great dependency injection (DI) mechanism they have. You can centrally define some services and reuse them across your app, without thinking about passing on props from component to component - the DI system takes care of it. Lit provides something similar via the [@lit-labs/context](https://lit.dev/docs/data/context/) package. It’s based on the Context Community Protocol and similar to React’s context API.

Fundamentally it is an event based mechanism to access state or "context" from ancestores of a component node. Based on the Web Components Context Protocol RFC which in turn is inspired by React's Context Api, the key purpose is to solve the problem of prop drilling.

The conversation led to the creation of https://github.com/webcomponents-cg/community-protocols. So there is some effort to standardize at least on convention for these higher-order considerations, but working through this and how opinionated it is made me recognize even more that this has a lot of similarities to a different group building a different framework. Tricky balance.

I’m pretty actively following a lot of the web components community so I thought I would jump in here with some hopefully helpful information. Depending on what you mean by SEO it’s worth noting that for a while now Google and I believe Bing and a few others haven’t had any kind of requirement to pre-render content. You can just serve standard web components or any kind of SPA style front end and it will get indexed just fine, no penalties and no real issues unless you’re doing something particularly strange.

However, one of the more exciting projects in the web components space (lit.dev) now also supports proper SSR as well which is a very new thing in the world of web components. They are trying to build it in such a way that any other library can take advantage of through a common interface.

In fact there are some kind of early stage talks happening over here https://github.com/webcomponents/community-protocols where a bunch of companies like Google, Adobe, ING and others are trying to develop some open protocols on a whole bunch of topics to improve interoperability between various libraries so that no one has to buy in 100% to any one setup.

npm init @open-wc@latest Need to install the following packages: @open-wc/[email protected] Ok to proceed? (y) y _.,,,,,,,,,._ .d'' ``b. Open Web Components Recommendations .p' Open `q. .d' Web Components `b. Start or upgrade your web component project with .d' `b. ease. All our recommendations at your fingertips. :: ................. :: `p. .q' `p. open-wc.org .q' `b. @openWc .d' `q.. ..,' See more details at https://open-wc.org/init/ '',,,,,,,,,,'' Note: you can exit any time with Ctrl+C or Esc ✔ What would you like to do today? › Scaffold a new project ✔ What would you like to scaffold? › Web Component ✔ What would you like to add? › Testing (web-test-runner) ✔ Would you like to use typescript? › Yes ✔ What is the tag name of your web component? … testing-components ./ ├── testing-components/ │ ├── .vscode/ │ │ └── extensions.json │ ├── demo/ │ │ └── index.html │ ├── src/ │ │ ├── index.ts │ │ ├── testing-components.ts │ │ └── TestingComponents.ts │ ├── test/ │ │ └── testing-components.test.ts │ ├── .editorconfig │ ├── .gitignore │ ├── LICENSE │ ├── package.json │ ├── README.md │ ├── tsconfig.json │ ├── web-dev-server.config.mjs │ └── web-test-runner.config.mjs ✔ Do you want to write this file structure to disk? › Yes Writing..... done ✔ Do you want to install dependencies? › Yes, with npm

Very much still a thing, https://open-wc.org/ is a good resource for examples and best practices.

I have this design system project for a company, I need to make web components and instead of using open-wc.org pre-built, I chose to go Vite.

Nice. We have data with meaning. Now let's create the presentation layer (aka the UI!) and then let's add interactivity to the UI, so we can have feedback when actually simulating an exam (aka the Frontend!). Since in ING we are advocates of Web Components, I always wanted to give this stack a try for side projects. I jumped right into open-wc.org and used the npm generator. Everything worked precisely as expected. It was a breeze since my Chapter is using lit every. single. day. So I could finally get some mileage myself, in writing lit. At work, as a Chapter Lead, I prefer to spend my time more effectively for the team, rather than coding new features by myself; my chapter does it better anyway (#proud).

I suggest following these best practices for creating a custom web element: https://open-wc.org/

Open Web Components is a great tool for accessing open-source web components and is very easy to set up with their quickstart guide and easy to understand documentation.

This application is one of many applications out there that are dipping their toes in the land of web components. Web components are still very new and ever-growing. While I have been developing on HAX-the-Web, I am also the Project Manager for HAXCamp 2022. < hax-camp > is an unconference dedicated to all things Web Components!This year's event is being student-run and we anticipate there being discussions about openwc, lit, performance, element composition, css, hax.psu, pedagogy, and design systems. If this work flow is something that you are interested in, I would encourage signing up for this event. It is much more than this, larger than you know and a way to connect with students, faculty, staff, and professional in the industry.