community-protocols

随着自定义元素的多样性日益广泛和深入，这些元素之间能够相互通信所带来的益处也随之增加。通过可复用的、广为人知的协议来实现这一点，不仅能让来自 X 供应商的组件与自身通信，还能使其与来自 Y 供应商和 Z 供应商的组件实现互操作。本项目旨在定义用于跨组件协调的社区协议，从而降低实现这一目标所需的开销。

可以将其类比为 context API、异步工作（类似 Suspense）、SSR-interop、增量 hydration 等，这些能力中的许多都被锁定在框架 API 中，从而增加了互操作的门槛。借助社区定义的协议，这些功能以及更多功能将在 web components 生态系统中变得可获取且可移植。

Get involved

查看当前在此仓库中开放的 Issues 和 PRs，以加入关于多个激动人心领域的正在进行中的对话。如果您有希望向社区提出的协议想法，请打开一个新的 issue，以便来自社区各地的库和组件的作者和使用者（他们可能已经（或希望）在该领域实现了功能）也能带着他们的用例加入进来。一旦粗糙的边缘被敲定，请提交一个包含协议规范的 PR（pull-request），并将其添加到下方的“Protocols”列表中，以便其被正式化并在整个社区中投入使用。请使用此 template 作为您提案的 PR。

Proposals

状态

社区协议在成为“已接受”之前，会经历多个阶段，在这些阶段中，它们可以进一步收集社区的意见和认可。这些阶段如下：

• 提案 “提案”状态适用于社区成员感兴趣并愿意深入思考的几乎所有内容。虽然向本仓库提交 issue 有助于生成关于该协议或感兴趣领域的初步想法，并明确启动更有成效的讨论所需的信息，但提交 PR 将表明你有意愿获得支持以推动相关协议的发展。在此 PR 中包含一份初步说明，并将该协议添加到上述“提案”表格中，将为社区异步地就该协议进行沟通以及参与其开发做好准备。

• 草案 通常被认为是一个有趣研究领域的协议会被赋予“草案”状态。此时，讨论将从证明协议的需求转向证明一种特定的模式，通过该模式可以在 Web Components 社区中实现该协议。该领域的发展工作可以通过 PR 或根据需要通过 w3c 的 Web Components 社区小组 的会议来处理。

• Candidate 一旦协议经过充分的孵化，并且其应用模式已经成熟，它将被授予“Candidate”状态。该状态表明它即将被正式接受。社区成员应利用这一机会，在协议被采纳之前，提出任何最终的关注点或他们希望看到的调整。到这一阶段，大部分工作应该已经完成，重点将转向打磨、呈现和实现。

• Accepted “Accepted”协议是指已准备好在整个社区中付诸实施的协议。由于包含了清晰的 API、类型和使用模式，它们已准备好服务于支持从各种上下文构建的 Web 组件之间互操作性的更大目标。

  要过渡到“Accepted”状态，提案需要 2 个实现。

Status Graduation

社区协议是“普遍认可的规范”，而非“浏览器规范”，因此它们始终是你做出的选择，而非组件开发者或库作者必须遵守的规则。因此，协议从一个状态晋升到下一个状态，主要发生在没有硬性“反对”的情况下。在关于特定协议的议题、PR 或 w3c's Web Components Community Group 会议中积极参与，将是推动协议通过这一流程的最佳方式。