失业在家,花一个月撸了个 web 前端框架,求大佬们指点

119 天前
 elantion

失业状况(请跳过)

失业在家快一年了,刚过 40 岁,有点不知所措。刚拿到赔偿金那天还很高兴,当天就去自驾游了,但玩得很内疚,总感觉在浪费时间,想是不是该沉下心来学习?于是玩了一周就回家了。 回来后,几个月都在打兼职,写 AI 工具,总共就赚了五千块,还借了六七千块钱给个在创业的朋友(估计是要不回来了)。
后面感觉做兼职是浪费时间,转头研究 AI Agent ,自已写了个本地对话工具,基于 Ollama ,但是本地电脑算力不够,而且 ollama 不支持 mcp ,bridge 写得头大,放弃了。(遗产: https://gitee.com/james-yin01/viviwawa
又转头研究腾讯的 KuiklyUI ,自研个“贷款计算 App”,但发现 Kuikly 非常不成熟,文档不全,bug 多,功能不完善,社区没人,果断放弃。(遗产: https://gitee.com/james-yin01/lc-loan-calculator
最后,心想还是做自已最擅长的东西吧(我十多年 web 前端开发),于是就花一个月写了个 web 框架。当然,目前只是原型阶段,只是跑通了基本的几个小场景,问题肯定还有很多,所以想在这儿问问大佬们这玩意有没有搞头,有的话就继续写写看,没有的话就放弃搞别的去了。

框架简述

框架名为 LazyCoffee ,是一款设计为面向对象开发的 web 框架。框架地址: https://gitee.com/james-yin01/lc_ood_framework

为什么要开发这个框架?

实话实说,我也是个讨厌重复造轮子的人,没事找事,感觉像刷 KPI 。但我写前端这么多年了,用了巨多框架,各种优点缺点我都心中有数,所以想能不能造个能解决某些痛点,又简单好用的框架,于是就萌生了写框架的想法,绝不是简单的造轮子。

失控的状态变量

我是从 ie6 那年代过来的,我特别喜欢原生开发,有一种掌控全局的感觉,到后面 angular, react, vue ,我发现项目变大后,有种失控的感觉,例如一个 dom 元素会被 state, props, redux 等各种变量控制,产生这样的问题是因为不同的变量有不同的作用域,你必须从上到下传递变量或者利用 redux 这样的框架全局把控。随着代码贡献的人变多,思路不一致,会发现项目的组件像口袋里的有线耳机一样混乱,例如明明可以组件内控制的变量非要用 props 传过来。
举个经典例子:弹窗。我们要做很多个弹窗,所以会有一个叫 Modal 的组件统一显示弹窗,弹窗内容通过props.children传过来,开关通过props.isOpen控制。因为你有很多不同的弹窗,所以你要一个数组来控制所有的弹窗变量,这就需要 redux 之类的状态管理工具来全局把控了。如果要关闭某个弹窗,你要遍历,变更状态,触发更新,麻烦的很。

解决单向流的痛点

其实造成上面的问题的根本原因就是 react, vue 都一直尊循的原则:状态变量单向流,你的状态变量只能从上层往下层传递,如果你的下层组件想变更上层状态变量,是不允许的,如果想实现,只能把状态变量统一提取到全局作用域,下层组件通过变更全局变量才能实现。
为了解决这个问题 LazyCoffee 框架利用了两个古老但实用的设计:元素查找和属性代理。

元素查找和属性代理

如果有两个平行的组件,例如两个弹窗,你不能在一个组件里变更另一个组件的变量,只能改为上下级或者通过共同父组件来控制。但 LazyCoffee 框架就可以,你只要找到另一个组件的实例,然后调用实例方法即可,看下面伪代码:

import { queryOne } from 'lc_ood_framework';

function submit() {
    const anotherModal = queryOne('#confirm');
    anotherModal.open('Are you sure?', function () {
        // do something
    });
}

是不是很熟悉的感觉?这不就是 jquery 老一辈的设计嘛?是的,朋友,是的。queryOne就是元素查找的方法,anotherModal就是元素的实例,open就是元素的方法,这个方法就是通过属性代理实现的。 通过这种设计,不管你的组件是平行的,还是上下级,都可以直接操控别的组件,从单向流的桎梏中解脱出来。

是不是有别的办法?

我在想,是不是有别的办法解决上面说的痛点,有必要另外写个框架?有的,朋友,当然有。利用 redux 或 pinia 之类的状态管理库,统一管控起来,然后让团队成员遵守代码规范,做好代码检视,一般是能实现的。我之所有写框架,是想更优雅解决这个痛点,提供一个与众不同的思路。

没了,就这样

框架的其他设计几乎都是照抄 react ,就是代码实现上自已另外造了个轮子,没找到复用的方法(有想到的告诉我,维护一个 jsx 实现是很难的)。

请大佬们指点迷津,谢谢!
另外,有需要前端老中医的欢迎联系我,我失业中,谢谢!

11279 次点击
所在节点    程序员
126 条回复
yinxs2003
119 天前
这年头别借钱给别人,搞不好,钱和朋友都没了。
aino
119 天前
未婚吗
elantion
119 天前
@yinxs2003 早前我还笑话那些借钱给别人的,现在轮到自已,很要好的朋友,六千块不多,当作是给朋友的创业加个油,希望他能成功
elantion
119 天前
@aino 已婚
mumbler
119 天前
还手写代码吗,这年头谁还要框架啊,AI 愿意用什么就用什么
elantion
119 天前
@mumbler 是的,我也想过 AI 的问题,我发现 AI 对上下文的理解相当差,所以这个框架的另一个目的就是减少上下文,尽量组件内自闭。
cat
119 天前
40 岁,造这样的轮子,个人觉得真的不值…… 当然,开心最重要
elantion
119 天前
不是自闭,是闭环,说错了
elantion
119 天前
@cat 没事,反正闲着也是闲着,顺便也能学点东西。
Wxh16144
119 天前
ie6 走过来的前端,老前辈了,不过还是别卷前端了吧,卷不过刚毕业的年轻人了,硬要搞代码的话走全栈路线吧
elantion
119 天前
@Wxh16144
不是说要卷前端,只是想思考下解题思路,跟年轻人肯定没法比。
40 岁了,现在学东西非常慢,全栈的话,后面再努力看看,谢谢你的建议,兄弟
horizon
119 天前
没意义了,没人会用。
elantion
119 天前
@horizon 谢谢你的建议,我知道当然不会有人用,只是写了个原型,讨论下设计
shunia
119 天前
单向流算是痛点吗?如果要解决,最好也是一个系统一点的方案吧?直接引用,感觉是头疼医头,脚疼医脚,这代码真要上生产,引用关系上不得乱套吗?

直接在被引用的组件中定义方法,供外部使用,这个限制就太大了。要想让方法支持重构困难重重,通过数据流进行重构则简单的多,因为你可以非常轻松的 derive 出一个新的数据字段、结构,也可以在两个不同的组件之间建立一个合并后的数据流来进行中转,看似引入了更多的复杂度,其实大大简化了心智负担。在我看来,这也是在前端,MVVM 能够轻松战胜 OOP 的最核心优势。

既然都 OOP 了,那么封装一个 React Component 的结构,甚至包括了写法,的意义在啥地方啊。我直接调用方法里面自己把逻辑写了不就好了吗? open => this.container.classList.add('open'),我还写一个额外的 state 来解决什么问题呢?在 OOP 的结构里,针对组件强行用 VM 驱动,是不是有点画蛇添足了。。。

我觉得现在这个,离“框架”是不是有点太远了?我甚至没法定义它。。。
penzi
119 天前
你的这些问题,引入 event bus 就行了。虽然 event bus 增加了复杂度,但至少比你这个高耦合的方案好太多了
bojue
119 天前
@cat 人的选择不一定对,但是可以选择一个自己喜欢的
peter1988
119 天前
建议搞搞产品,或者其他变现的东西,同样 ie6 过来的程序员,我们痴迷于解决技术的问题,但是慢慢变得解决不了自己生计的问题。
NathanInMac
119 天前
你看下 solidjs 把,优雅的解决了你说的那些痛点
zixianlaiye
119 天前
冒昧的问下,老哥现在资产如何

目前来说,这些框架看起来不能带来比较可观的收益
molvqingtai
119 天前
楼主了解过 lit 框架吗,感觉类似,只不过 lit 是基于 web component

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1134903

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX