关于vue.js:React-hooks-Vue-WebComponents-是什么感觉

明天早上关上 github，发现尤大新开了个仓库叫 vue-lit，关上看了下，大略主体思维是用 vue 响应式外围去驱动 lit-html 的更新机制。

lit-html 是谷歌的一款 web-components的框架 class base 的 api 格调，不能说十分难用，实际上还是和当初支流的 React hooks 开发体验不可同日而语。在这里我要也吐槽下 vue3 的composition api，昨天我闲来无事看了下 element-plus 的源码，过后其实我是被雷到了的，咱们来看一段 props 的定义:

export default defineComponent({
    name: 'ElDivider',
    props: {
        direction: {
            type: String,
            default: 'horizontal',
            validator(val: string): boolean {return ['horizontal', 'vertical'].indexOf(val) !== -1
            },
        },
        contentPosition: {
            type: String,
            default: 'center',
            validator(val: string): boolean {return ['left', 'center', 'right'].indexOf(val) !== -1
            },
        },
    },
})

这。。。运行时的类型查看？typescript的动态类型查看他不香吗？几个单词就完事的货色要整下面这么一坨。。。而后就是各种 as看的我血压回升。好吧就算最初会用 预编译 把这些类型查看去掉，开发的时候写这些定义也不晓得会是什么感想，开发时的 ts 类型查看怎么办呢，代码提醒怎么办呢，我试了下最新版本的 vetur如同也全是 any提醒，如果有更新版当我没说，然而这相对不是一个很难受的写代码形式。

言归正传。

Web Components 是一个浏览器原生反对的组件化计划，，实际上它的组件就和原生的 input 之类的没啥区别，理论原生的包含 input的 dom 元素外部实现也是 shadowdom，什么？你看不见，没事关上 f12，点击右上角的小齿轮，而后勾选 显示用户代理影子 dom。(什么浏览器？当然是牛逼的 edge`chrome` 应该也在差不多的地位)

更多对于 web-components 的内容这里也不做过多赘述了，到处都有，总的来说，它能够让你写的组件真真正正是一个合乎 web 规范 的运行时的组件，这很重要，有了规范什么事都好办。

再来谈谈Hooks。

其实大家当初都认可了 React Hooks 的开发体验，然而其实 Hooks 也有一些暗坑，也就是尤大始终说的 心智累赘 ，然而总的来说这些累赘并不是 Hooks 设计间接带来的，而是 Immutable 和闭包 独特带来的。React 开发者都习惯了的 闭包陷阱 当初也是坑了我老半天。这个曾经被探讨烂了，就不多赘述了。而后社区就有两种人，一种说你们全副放 redux 啊，另一种说 redux 就是傻逼。然而其实都没有基本上解决问题。Immutable才是 心智累赘 最大的问题。

那么问题来了：为什么不把 Hooks 和Proxy一起用呢？一份高兴加上另一份高兴，而后再联合 web-components 去面向未来，那岂不是三份高兴？岂不美哉？

而后就有人通知我：行行行，这么高兴的事就交给你了。

实际上不必通知我，我早就开始实际了，文档都整的差不多了 Gallop。

废话不多说间接上代码。

// 这拉胯的网站怎么嵌入iframe…

Sandbox

import {
    render,
    html,
    component,
    useState,
    useEffect,
    useStyle,
    css,
    ReactiveElement
} from "@gallop/gallop";

component("sand-box", function (
    this: ReactiveElement,
    {color = "red"}: {color: string}
) {const [state] = useState({tick: 0, text: "hello!"});

    useEffect(() => {console.log(`${this.localName}'s state tick was changed to ${state.tick}`);
    }, [state.tick]);

    useStyle(() => css`
        div {color: ${state.tick % 2 ? "red" : "blue"};
        }
        `,
        [state.tick, color]
    );

    return html`
        <button @click="${() => state.tick++}">tick +1</button>
        <div>${state.tick}</div>
        <hr />
        <input
        @input="${(e: Event) => {const { value} = e.target as HTMLInputElement;
        state.text = value;
        }}"
        />
        <div>${state.text}</div>
    `;
});

render(html` <sand-box :color="blue"></sand-box> `);

那么这个叫 Gallop 玩意除了 3 份高兴之外，还有啥好玩的？

其实大部分在文档外面都曾经提及了，其实这个 框架都不能算是一个框架 ，它只是从底层到顶层提供了一些api，让你本人去组合着玩，如果你只是写网页，那么你可能只会用到 10 来个，如果你想拓展它，那么你可能须要 20 来个，如果你想玩各种各样的骚操作，那么这些api 也齐全能让你开发的 难受又难受。另外，你其实就是在写原生的 ts/Js，没有充斥魔法的预编译，没有那么多乌七八糟的调度机制，也没有太多诡异的模板语法，我置信根底扎实的你，只须要几小时就能搞定，如果你开发过React Hooks，那么我预计不须要 10 分钟。

目前 Gallop 曾经在笔者的公司外部开始解决一些业务组件上跨框架技术栈的问题，然而我还不能齐全保障bug free，然而开发效率是相对酸爽的，在这里也心愿有更多的bug 能在实际的磨难下可能浮现水面。

说了这么多，还是心愿 web 的将来会越来越不便，开发者们少掉点头发，少整点 kpi，多干点有意思的事。

最初感激我的猫子们，陪本人写完这个 ” 框架 ”。如果对 Gallop 感兴趣，也能够在 Github 上交换，欢送各种 Pr / Issue 或者对 Gallop 的扩大。