V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  zhennann  ›  全部回复第 1 页 / 共 6 页
回复总数  118
1  2  3  4  5  6  
@zhongs Cabloy-Front 提供了许多 cli 命令行工具,帮助我们搭建代码骨架,所以有些代码不需要我们写,只需要写业务代码即可。可以看一下 codesandbox 在线代码演示: https://codesandbox.io/p/github/zhennann/cabloy-front-demo-codesandbox2/main?checkout=true&embed=1&file=%2Fsrc%2Fsuite%2Fa-demo%2Fmodules%2Fa-demo%2Fsrc%2Fpage%2Fcounter%2Fcontroller.ts
@tikazyq 已经将 mother 相关的术语改为 controller 。多谢建议🙏
21 天前
回复了 zhennann 创建的主题 前端开发 Angular 等了三年,那个她已经来了
@tianzi123 如果代码都在 sfc 中,使用这些语法糖确实舒服。但是代码一多就乱;如果想拆分多个 hook 出去,这些语法糖的使用可能就不太方便了。Cabloy-Front 采用 ioc 容器,从一开始就把结构搭好了,不论代码再多也不会乱,而且可以平滑的扩张。
21 天前
回复了 zhennann 创建的主题 前端开发 Angular 等了三年,那个她已经来了
@tianzi123 我也不喜欢 vue2.6 的装饰器写法。但是 Cabloy-Front 采取的策略完全不同。之前的装饰器写法不好用,是因为在用 class 定义 Vue 组件。实践证明,用函数式定义 Vue 组件最方便。所以,Cabloy-Front 仍然在视图层使用 setup 语法糖来定义组件(包括 Props 和 Emits ),而在业务层引入 ioc 容器和 class 。同时又采用了依赖注入与依赖查找相结合的策略,大量减少装饰器函数的使用,让代码更简洁优雅。这是 codesandbox 的在线演示,可以看一下: https://codesandbox.io/p/github/zhennann/cabloy-front-demo-codesandbox2/main?checkout=true&embed=1&file=%2Fsrc%2Fsuite%2Fa-demo%2Fmodules%2Fa-demo%2Fsrc%2Fpage%2Fcounter%2Fcontroller.ts
22 天前
回复了 zhennann 创建的主题 前端开发 Angular 等了三年,那个她已经来了
@wuzzispacelake 你说的情况我了解。Vue team 不认可 class api 的理由我也看到了。他们的理由是使用 class 定义 vue 组件并不方便,代码冗余,性价比不高。这点我也认同。社区有好几款基于 class 来定义 vue 组件的方案,效果都不是很理想。这就说明了一个道理:Class 不应该用在视图层,而是要用到业务层。所以,Cabloy-Front 仍然在视图层使用 setup 语法糖来定义组件(包括 Props 和 Emits ),而在业务层引入 ioc 容器和 class 。这样,可以充分利用二者的优势,让整个代码更加简洁优雅。因为使用了 class 之后,再也不需要使用 ref/reactive 了,也不需要 ref.value 了。可以参考这篇文章:为什么需要 Vue3+IOC: https://front.cabloy.com/zh/guide/start/why.html
22 天前
回复了 zhennann 创建的主题 前端开发 Angular 等了三年,那个她已经来了
@sunorg 这种情况我也遇到过。随机性比较强,比较魔幻。
22 天前
回复了 zhennann 创建的主题 前端开发 Angular 等了三年,那个她已经来了
@IvanLi127 你可以对比一下 Angular 和 Cabloy-Front 的代码风格,看看是不是这么回事。这里有一些视频,可以作为参考: https://front.cabloy.com/zh/guide/resources/videos.html
22 天前
回复了 zhennann 创建的主题 前端开发 Angular 等了三年,那个她已经来了
@wuzzispacelake Cabloy-Front 采用的 class 机制与 Vue Class Component 有本质区别。Vue Class Component 不好用,是因为想用 class 解决 Vue 组件的定义问题。而 Cabloy-Front 仍然采用 Vue3 setup 语法糖来定义组件(如组件的 Props 和 Emits ),仅在业务层面引入 ioc 容器和 class 。这样,就结合了二者的优点,让代码更加简洁优雅。在 ioc+class+ts 的语境下,this 不仅可以清晰定位代码来源,还能更加快捷的访问系统能力。this 的弊端,仅仅是针对 mixins 和 options api 而言。
rxjs 是 angular 中的用法,Cabloy-Front 中并没有采用。
Cabloy-Front 提供了两类 ioc 容器:一类是全局 ioc 容器,可以实现 pinia 的能力。另一类是组件实例 ioc 容器,该容器与 Vue 组件实例绑定,在这个容器中的所有 Class 实例都可以在组件实例范围之内共享数据和逻辑。
@Daotin 简单的方案容易上手,却不容易适应项目的膨胀。为什么许多项目,代码一多就乱,就是因为前期没有规划,怎么简单怎么来。可以看一下这篇文章:为什么需要 Vue3+IOC: https://front.cabloy.com/zh/guide/start/why.html
@ceilingyear 一个文件确实能解决问题,但是使用三个文件是为了解耦合,以便更好的适应业务的膨胀。
1. index.vue:在这个文件中,使用 vue3 的语法糖定义组件的 props 和 emits
2. mother.ts:一个 vue 组件实例对应一个 ioc 容器。该容器与 Vue 组件实例绑定,在这个容器中的所有 Class 实例都可以在组件实例范围之内共享数据和逻辑。那么,mother class 就是这个 ioc 容器中的第一个 class 。组件的业务逻辑就从这里展开
3. render.tsx:在这个 render class 中编写 tsx 代码,实现界面渲染。在一个独立的文件中书写 tsx 代码,从而让 tsx 代码更加舒展、从容。不知你是否有如此体验:如果仅仅在一个 SFC 文件写 tsx 代码,总是很局促的。当业务比较复杂的时候,展开很麻烦,代码逻辑不容易区分开

此外,Cabloy-Front 所采用的 class 机制,与社区现有的多个 class 方案有本质的区别,因此,逻辑更清晰,代码更优雅。可以看一下这篇文章:为什么需要 Vue3+IOC: https://front.cabloy.com/zh/guide/start/why.html
@humbass 更准确的说法是,ioc 容器和 oop 适合业务领域的建模和抽象。后端采用 ioc 容器自是当然。如果前端项目比较大,业务复杂,引入 IOC 容器可以简化业务设计。此外,Cabloy-Front 采用依赖注入和依赖查找相结合的方式,大量减少装饰器的使用,让代码更简洁、更优雅。优先使用依赖查找的机制可以达到化类型于无形的效果?简而言之,就是无须标注类型,却能享受到“类型约束”和“智能提示”的好处。这个是基于 Typescript 的强大类型系统实现的,在 java 中很难做到,因此大家普遍认为 java 很繁琐,就很好理解了。
@charlie21 cabloy-front 提供了两类 container ,一类如你所说是 global container ,实现全局状态的消费,可以直接代替 pinia 的能力。还有一类是组件 container ,与 vue instance 绑定。提供 vue instance 级别 container 的好处就是,在这个容器中的所有 bean 实例都可以在 vue instance 这个范围共享和消费数据。这种机制其实要比 composable 的耦合性低很多了
@Ma4cus 确实有几个 class 的实现效果不理想,所以 vue 官方不推荐。不理想的原因是他们把 class 用在了“与界面交互的架构”层面。而 cabloy-front 在“与界面交互的架构”层面仍然使用 vue setup 语法,在“与业务相关的架构”层面使用 class 和 ioc 。所以,与官方的说法并不相悖,只是站在不同的角度做的判断。
@coolcoffee 为什么不用 react ?参见我上面的回复。在面向大型的业务开发场景中,需要两个层面的架构设计。否则,代码多了一定会乱
@kneo 那么什么是反模式呢?为什么那么多人纠结用 ref 还是 reactive ,为什么有的地方推荐 ref 而不是 reactive ,为什么 ref.value 无法规避。为什么代码多了一样乱。
在面向大型的业务开发场景中,需要两个层面的架构设计:
1. 与界面交互的架构,这个使用 vue3 setup 来做
2. 与业务相关的架构,这个使用 ioc 容器来做。大量的工程实践证明,在业务层面,class 比 function 好用很多
@ixoy 这样就可以不再纠结使用 ref 还是 reactive ,不用担心失去响应式的烦恼,也不用再写大量 ref.value ,同时又能利用 vue3 的响应式
@FrankFang128 extends 某个基类,就可以通过`this.`直接使用大量常用的功能,减少 import 和 use 等导入代码。虽然使用了`this.`一样有类型校验,自动完成提示,也可以跟踪其源码出处
@linzhe141 ng 的 ioc 太繁琐了。cabloy-front 采用依赖注入和依赖查找相结合的方式,大量减少装饰器函数的使用,让代码更加简洁,再加上 vue3 的响应式和 tsx 的灵活性,整体效果比 ng 好太多。
@sjhhjx0122 思路是一致的。对于组件的类型导出,仍然延用 vue3 setup 的特性。依赖注入主要是面向业务层面。
1  2  3  4  5  6  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5447 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 1232ms · UTC 03:17 · PVG 11:17 · LAX 20:17 · JFK 23:17
Developed with CodeLauncher
♥ Do have faith in what you're doing.