关于前端:新开源项目solidjsuse随想录

前言

如果你是 React 技术栈，就会发现其对老手其实是不太敌对的，会导致新人写出很多 反复渲染 的组件和 BUG，而且排查难度高（当然 React 仍然是最优良的框架，很多理念的提出者和先行者）。

当我看到 SolidJS 后，我感觉这才是真的 react（响应式），它既蕴含了 React 的语法和天生的 TS 反对，又领有比 Vue 还彻底的响应式设计，让你不必为 Deps 懊恼。

import {createSignal} from 'solid-js'

const [count, setCount] = useState(0);

createEffect(() => {console.log('count', count()) // 当 count 变动时，会主动触发
}) // 不须要 deps

SolidJS 的优良之处更多的是在于它的高性能，感兴趣的同学能够去其 官网 理解一下。

综上，我集体很喜爱它的设计，也置信好的事物通过工夫的倒退最终会展露矛头。

但现实情况是其生态很缺失，所以通过思考后和调研后，决定写一个工具函数库，一方面心愿能参加到开源建设来，另一方面也心愿能进步一下本人的能力，毕竟最好的学习技术形式就是马上用起来。

当然做开源也不仅是酷爱，也有功利目标，心愿能有一个国内外都认可的我的项目教训。

因为本人能力无限以及社区曾经有很多优良的我的项目，所以走的是搬运路线，而不是从 0 到 1 的翻新。

在调研了 ahooks、react-use 和 VueUse 等库后，决定采纳 VueUse 作为底本，前面通过 2 个月的业余时间开发，最终实现并开源了 solidjs-use。

<!– 图 –>

本文次要是记录一下在搬运过程中的局部技术实际和思考，心愿对你的前端开发和开源有一些启发。

技术实际

Typescript 函数重载和联结类型

尽管 TS 也应用了很久然而有些货色还是傻傻不明确，其中就蕴含了谬误的应用联结类型解决函数重载的问题。

当一个函数出入参数为 A 类型时，返回为 M 类型；输出参数为 B 类型时，返回为 N 类型。如果是以前我会这样写：

function foo(arg: A | B): M | N

但这样其实是不准的，因为咱们明确晓得 A 类型对应的是 M 类型，然而当初 A 类型却对应了 M | N 类型，这样咱们在后续只能应用 any 或者 as 大法。

通过在搬砖的过程中，我对 TS 的函数重载有了正确的认知：不同参数个数或者不同参数类型，对应的返回值类型也不同时，须要应用函数重载，而不是联结类型。

function foo(arg: A): M;
function foo(arg: B): N;
function foo(arg: A | B) {// ...}

多包我的项目援用治理

在写 monorepo 我的项目时，a 我的项目援用 b 我的项目，当 b 我的项目产生扭转，咱们须要从新 build 出 b 产物，这样 A 拿到的才是变动后的 b 我的项目。

如果仅改一次还好，如果改屡次 b 我的项目就须要启动 watch 模式，但如果 a 同时引入了 b 和 c 两个我的项目，那么就须要同时 watch 多个我的项目了，有点麻烦。

看了 VueUse 的源码，发现这个问题也很简略，只须要应用 resolve.alias 到依赖的 src 目录，而不是依照一般 node modules 的解析形式，就能够不必 watch 依赖了。

尽管这个点也很小，然而确确实实能晋升开发幸福感。

PS：当然这个计划也有毛病，当依赖的源码过多，启动会变慢。

方法论思考

如何跨技术栈？

想要将 VueUse 转为 SolidJS 框架可能大部分人的想法是间接撸起袖子，对照着搬运就能够了（尽管最初的后果可能是这种形式）。

但当你把第一版拷贝过来，那么 VueUse 后续的更新怎么办？所以这其实并不是一个简略直白的问题，须要综合思考到 实现难度、前期可维护性。

如果把这个问题形象一下，实质上是一个跨技术栈问题，那么如何解决跨技术栈问题，联合社区和本人的思考能够有以下计划供大家思考：

编译路线

咱们假如须要将 Python 编译为 JS：

• 两者相同点有很多：例如 if/else、函数、循环等概念都是相通的

• 当然也有很多不同点，外围体现在：

  • 语法层面：同样是函数，但 JS 中定义函数和 Python 定义函数写法是不同
  • 运行时层面：Python 中的某个内置函数，JS 中没有对应性能的函数

针对不同点，有以下解决方案：

• 语法层面的不同：咱们通过将 Python 代码结构化为 AST，而后批改及转化为 JS 的 AST 树，最初再将 JS AST 树转为 JS 代码
• 运行时层面：注入由 JS 实现的雷同性能的函数即可

下面仅是说的 Python 转 JS，但在计算机中，波及 2 个类似事物的转化，都是能够采纳这套转化逻辑，其实就是编译原理的利用。

案例

前端最相熟的 Babel 就是将最新的 JS 标准编译成老版本的 JS 标准，其中：

• 语法层面：将新语法转为老语法，例如 let 编译成 var
• 运行时层面：应用 corse-js 实现 polyfill，例如 Promise 类

计划优缺点

长处：当写好了转换代码，则无论我的项目的多少或者大小，都能 cover

毛病：难度大，工作量大

solidjs-use 在最后设计的时候也是思考过将 VueUse 通过语法转换的形式实现 solidjs-use，但因为局部逻辑实现难度大（太菜），而最终放弃。

形象层路线

形象层是本人先制订一套标准 / 语法，而后在这套标准进行实现理论代码编写，最初通过编译，编译为其余的语言 / 框架。

实质上仍然是计划 1，然而要比计划 1 的难度低很多，因为在设计之初就思考到不同框架之间的共性以及尽量避免其余框架无做到的事件。

案例

• mitosis：Write components once, run everywhere. Compiles to Vue, React, Solid, Angular, Svelte, and more.
• 跨端框架：比方大家比拟相熟的 uniapp 和 taro，就是将小程序的标准编译成各种平台
• 低代码中的 Schema：《低代码引擎搭建协定标准》| Low-Code Engine (lowcode-engine.cn)

优缺点

长处：整体计划难度中等，老本可控

毛病：须要提前设计，并依照形象层的标准开发、须要一直保护和对接各个框架个性

因为 VueUse 是针对 Vue 开发的，所以在开发 solidjs-use 时此计划废除。

分层

这种形式是，理论代码通常写在底层，并在下层进行很薄的一层封装和调用。

案例

• WebAssembly：反对 WebAssembly 的语言都能够间接调用 WebAssembly 写好的函数，间接实现跨语言
• Web Components：底层是 Web Components 写的 UI 框架，下层简略进行封装，就能够反对各个前端框架，具体案例如 ionic-ui。

优缺点

长处：难度低

毛病：须要提前设计，且根底层计划须要成熟

因为 VueUse 是针对 Vue 开发的，所以在开发 solidjs-use 时此计划废除。

手动搬砖路线

手动搬砖路线是通过辨认不同框架的差别，手动一点一点把代码敲进去。

尽管这种形式是最 low 的，但因为绝大多数框架和库最开始设计都没有思考到跨技术栈的需要，却是目前最罕用的社区解决方案。

当然 solidjs-use 不齐全是搬砖，还联合了编译路线中的 运行时层面 进行了一层封装，失去了一个胶水代码包 solid-to-vue，其重要作用是应用 solid API 实现的 Vue API，可大大减少 vueuse 转 solidjs-use 过程中代码主体的变更。

优缺点

长处：难度很低

毛病：须要一直跟进我的项目的变动，进行手动搬砖

solidjs-use 最终采纳此计划开发。

开源我的项目何来？

有人把开源看成很高大上的事件，必须是大佬能力做，其实不然，开源的出发点能够是帮忙别人或者是炫技、或者纯正好玩，和我的项目大小以及难易无关。

当然很多人苦于没有一个好的想法，本大节就是为了解决此问题，分享一些常见的开源思路。

思路 1：工作 / 生存中的吐槽，我来工具化它 / 优化它

工作中咱们时常吐槽某某工具做的辣鸡，你如果当作者面吐槽，可能就会被怼“你行你来呀！”。没错，这就是你的开源机会。

案例 1：ChatGPT 语音化

ChatGPT 很火，但只能文字交换，能不能做一款语音输入和输入的我的项目，能不能把这个我的项目搞到智能音箱里，能不能把她设计为英语口语助手 / 老师？

案例 2：Vite

Webpack 打包和启动很慢🐢，能不能做一款在速度上吊打它的产品。

思路 2：创意性思考 & 前瞻性思考

案例 1：无界

微前端最大的难点，也是容易出 bug 点就在于 JS 沙箱问题，以往大家的思路在于通过拦挡和代理的形式使得子利用拜访的不是真正的 window 对象和 document 对象等，但这种形式在实际过程中，发现破绽很多，总是在修修补补。

而 iframe 自身具备完满沙箱，那么 iframe 做底层，下层把路由、通信等能力封装欠缺，是不是就能够完满解决沙箱问题了呢？

腾讯开源的 无界 就是这样的一个微前端解决方案。

案例 2：WebContainers

咱们都晓得 CodeSandbox 的性能是一个云端的开发平台，它须要在服务端启动一个容器🐳来实现其性能。

能不能利用最新的 WebAssembly 的能力，在浏览器虚拟化出 node 运行环境，间接把浏览器当成 server，不再须要服务端通信，这样就可大大节俭服务端资源了。

思路 3: 多框架迁徙

前端目前是 3 超（vue/react/angular）1 强（svelte）1 中（solidjs）的场面。在你没有能力从 0 到 1 造轮子的状况下，把一个优良我的项目从一个生态迁徙到另一个生态不失为一个策略。

案例：ant-design-vue、solidjs-use 都是这种思路

其余

• 付费软件、零碎，开源代替计划

  • Gitlab 代替 GitHub
  • penpot 代替 蓝湖
  • minio 代替阿里云 OSS

• 桌面零碎 Web 化

  • Web 化办公软件（在线文档 /EXCEL/PPT)
  • Web 化设计软件
  • Web 化 IDE

• 常识概念产品化

  • 《番茄工作法》-> 番茄时钟
  • 《海龟交易法》-> 量化交易软件
  • 《卡片笔记法》-> flomo
• AI +
• 低代码 +
• Web3 +
• …

i + 100 学习法

前几天看到一个 UP 主讲如何学习英语，其中一个方法论就是 i + 100 学习法。

所谓的 i + 100 是绝对于 i + 1 而言的，i + 1 是指找到一个比本人能力稍难一点的工作、工作去做，让本人能跳一跳能做到。而 i + 100 是指间接上本人最终要达到的指标的那个难度。比方：

• 想出国，练书面语：应该间接在网上找一个外教或者国内尬聊软件一天聊 2 个小时，而不是先学元音、辅音，而后连读，而后学习单词，背背新概念。
• 想做开源：在有一个开源思路后，应该间接开干，而不是先思考本人是不是经验不足，这个技术不会，那个技术不会，先学一两个月，学透彻，再开始，应该边做边学，且仅学 对你我的项目有用的局部，其余的留给日后钻研。

之所以要 i + 100 而不是 i + 1 外围在于 处分机制 问题，你越快从你所做的事中取得处分，你就越容易把这件事做上来。如果你想学习英语，立一个打算，先从高中单词温习，而后逐渐大学单词、雅思单词，那你大概率会失败，因为 正反馈周期太长 了。

PS：的确存在数十年如一日做着没有反馈的事的人，那是真的酷爱或者牛皮

结束语

如果你看完本文对你有所帮忙，且对 solidjs 有一些趣味，那么请给 solidjs-use 点一个 star，日后你会用失去。

最初，祝大家在这个越来越魔幻的世界找到本人的路。