我对这个非常兴奋 React 19 发布的原因有:网络组件. 主要是因为我创造了 Markup 暴露出反应性 DOM 具有简化的Web组件的解决方案 API.
// web-components/button/index.js
import { WebComponent, html} from '@beforesemicolon/web-component';
import style from './style.css' with {type: 'css'};
class BfsButton extends WebComponent {
static observedAttributes = ['disabled', 'type', 'variant'];
disabled = false;
type = 'button';
variant = 'primary';
stylesheet = style;
render() {
const { variant, ...btnProps } = this.props;
return html`
<button ${btnProps} class="btn ${variant}">
<slot></slot>
</button>
`;
}
}
customElements.define('bfs-button', BfsButton);
为什么这很重要?
那么... 我从哪里开始?
- 这给我带来了一个统一的网络和 React 网络框架的流行意味着其他人也会效仿, 而这将会进一步统一两个充满激情的社区, React 和 Web Components.
- 有了网络组件,我们可以创建UI系统和组件库,这些系统与组件库在框架之间工作,不受框架特定图书馆的限制,这些图书馆将社区隔离开来.
- 我相信一个网络, 网络组件API是基础 同样的方式 DOM 今天是那个时候 我们最终会到达那里,这个步骤是朝这个方向迈出的。
- 网络组件是网络的未来防守解决方案,无论你是否相信. 网络生态系统是混乱的,我们不需要新的框架来解决这个问题。 我们只需要它们彼此相容 别再发动框架战争了,拜托!
- 网络组件状态独立于 React 应用程序允许我们有一个单独的内部逻辑, 能够更能执行的将本地 vs 完全分离 DOM 最新消息。 。
- 大公司最终可以迁移到有一个单一的UI组件库,在它们使用的所有框架内工作,以降低可维护性成本并更快地改进和配置船舶.
- 不再为网络组件工作提供变通办法 React.
- 这将推动安全部门改革网络组件,尽管这可以 已经工作 因为网络组件只是自定义 DOM 元素。
插件和游戏解决方案
我喜欢和香草一样接近 JavaScript, CSS,以及 HTML 尽可能,这就是我创造的 全部原因 Markup我相信简单,我试图通过简化我所能做的和依靠网络标准而不是重塑车轮来对抗网络变得更加复杂。
Markup 是一个插件和游戏的解决方案,它只是意味着它不需要构建或编译进程来工作 JavaScript/TypeScript 环境。 这种事就是这样做的
// App.jsx
import {useState} from 'react'
import './web-components/button'
import './App.css'
function App() {
const [count, setCount] = useState(0);
const disabled = count === 10
const countUp = () => {
setCount(prev => prev + 1)
}
return (
<>
<bfs-button
variant="cta"
disabled={disabled}
onclick={countUp}>count {count}</bfs-button>
</>
)
}
export default App

我们从何说起?
我对网络投入了很大,我创造了以下小解决方案来达到:
- Markup: 反应 HTML 诱导系统;
- WebComponent: 以 Markup;
- 路由器: WebComponent- 路由器 - 路由器 - Based routers. 只有在你需要的时候才能写联署文件代码
我还有其它事情要处理,很快会到来:
- 输入: WebComponent 和 输入 API- 以地方化系统为基础
- 用户: WebComponent- 基于UI的系统和组件(90+)
- 帆布: WebComponent- 基于画布的经验
我还准备了更新我的 Web Components 相信2025年将标志着这一惊人的技术再生,所以请保持调制。

