状态管理的一点想法! - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zhangk23
V2EX    前端开发

状态管理的一点想法!

  •  
  •   zhangk23 2023-06-13 02:26:17 +08:00 1884 次点击
    这是一个创建于 852 天前的主题,其中的信息可能已经有所发展或是发生改变。
    今天吐槽状态管理这种技术,不知道大家有没有和我类似想法的

    我学游戏的,大学期间写的 c# 也不是前端技术出身,只说使用体验肯定是带偏见的,因为我实在无法理解这么简单一件事非要搞复杂,因为游戏编程转的 sde ,很多东西不会,所以导致了我是拿来主义,能用就行,没那么多情怀加成

    因为我仅限于用过 redux 和 ngrx ,加上刚学了 pinia ,所以今天鞭尸 ngrx :)
    redux/ngrx 我都用过 也都学过,因为几个项目技术栈原因,感谢外包把我当黑奴操练时学了 Angular 和 React ,用了这俩管理工具,最近跳槽跳出外包,项目技术栈成了 vue3 加Java ,由于面试的 OA 和技术面我都用的 jQuery (老牌技术还是好用)让我混过去了,但我完全没用过 vuejs 啊,于是研究 vue3 又接触了官方钦定的 pinia ,出于兴趣爱好我又看了老版本的 vuex ,总体感觉就是简单,vue3 的比 Angular 还有 react 的好上手多了

    redux 和 ngrx 属于学习曲线困难( ngrx 是畸形,理念很好,实操就是屎)然后今天不吐槽钩子,只说状态管理

    首先是组件状态管理,context ,event bus ,services 都是可以做跨级组件间传递数据,各式各样的思想都很不错,react 的 slice 整合 action 和 reducer ,dispatch 很棒,语法也很美

    但是对我这种转行的三流程序员来说,兄弟组件间传数据,设个类似全局变量的 store ,一个 store 文件能解决的事儿非要搞的花里胡哨,写那么多样板代码很有趣嘛,异步操作和重新渲染这俩完全我觉得挂个监听器再写具体代码块就可以搞定的。不管是用 useContext 还是用 reactive 声明响应式数据,自己写一个 store 不比用冗杂的状态管理工具强?

    至于状态依赖?装饰器注入不就好了 多大点事儿 Angular 不就这么干的

    当然了我没有超大项目经验,但之前在大厂外包呆的时候,明明一个很简单的打卡管理,抓数据本地处理在传输,非得用 nmd ngrx ,细化 action reducer selector 搞的真的多大项目似的,至于代码规范性,我也不觉得用状态管理就能说明啥,我和阿三外包一样该写成屎照样是屎,哪怕用了 nb 的工具我的继任者该看不懂还是看不懂

    我的理解是组件通信要的是可观察,哪里有数据变化就重新渲染哪里不就行了
    所以求大家意见,望轻喷,毕竟俺不是专业科班出来的 55555




    题外话:我纯个人偏见,活该 Angular 打不过 react ,净整花里胡哨
    10 条回复    2023-11-08 01:41:57 +08:00
    linkopeneyes
        1
    linkopeneyes  
       2023-06-13 08:26:23 +08:00
    我写 ng 从来不用状态管理,都是直接用服务依赖注入的,甚至在 vue 和 react 上也这样干,ngrx 就是学的 redux 本身就是 react 的毒瘤遗产,我也很少见人用 ngrx 这个库也不是官方写的啊,我记得英雄指南里都是用服务的
    zhangk23
        2
    zhangk23  
    OP
       2023-06-13 08:45:31 +08:00
    @sjhhjx0122 有怨念是之前跟了一个半的 angular 项目,我给前任阿三程序员擦屁股,那俩都用的 ngrx 来做管理,要我自己从头写还好,烦的是中途改 还没注释,那大半年可劲儿和这玩意儿打交道了。不过我也觉得服务很不错啊,就该是这样的理念,有数据放 service 里头大家共享就好
    maxssy
        3
    maxssy  
       2023-06-20 18:16:09 +08:00
    @sjhhjx0122 React 如何注入?
    99s
        4
    99s  
       2023-06-21 09:53:12 +08:00
    听别人说的:越简单越容易被人代替,搞复杂点没人会,就保住了自己的位置

    angluar service 这个东西挺好的。
    zhangk23
        5
    zhangk23  
    OP
       2023-06-24 00:00:14 +08:00
    @maxssy react 我没记错没有 angular 的自带注入,所以可能自己定义一个钩子注入状态是最优解(我没写过毕竟之前一直用的 redux ,但如果要写,肯定是 useState,然后设置初始 state 和 state ,然后传出去,别的组件调用这个钩子),百分之百比 redux 简单,而且好理解

    @99s 是这样的 如果我干大项目且是全职技术老大的话,肯定怎么复杂怎么来,巴不得吃巨头的工资吃一辈子,越复杂越好,最好全世界只有我一个人看的懂我设计就行,然后写个两百页文档手底下管几个实习生/外包!但毕竟我之前外包出来的全栈技术人,螺丝刀就是,需要什么学什么,拿多少钱干多少事,我信奉技术能用前提下越简单越好,四小时火速干完份内的事儿,一个很简单的项目搞那么复杂还得我从头过一遍前人写的东西给人擦屁股,就是浪费我的生命,搞那么多花里胡哨实在蠢
    linkopeneyes
        6
    linkopeneyes      2023-06-25 15:21:32 +08:00
    @maxssy 可以用通过依赖注入的库,从 react 的 context 传递下去 比如 injection-js 这种,不过可以试试 redi ,他直接可以跟 react 联动
    linkopeneyes
        7
    linkopeneyes  
       2023-06-25 15:29:09 +08:00
    @zhangk23 react 有依赖注入只是没有 angular 这么强大,angular 并不花里胡哨,ngrx 也不是官方库,所以你的怨气应该撒给 ngrx ,或者说是 redux ,跟 angular 没关系,ng 就是最符合你理念直接写个全局服务全局共享还不需要状态管理库
    zhangk23
        8
    zhangk23  
    OP
       2023-06-29 00:36:22 +08:00
    @sjhhjx0122 确实奥
    mxT52CRuqR6o5
        9
    mxT52CRuqR6o5  
       2023-11-07 19:35:59 +08:00
    从 react 角度讲一讲这些设计理念,前端相比后端一个很大的差别之一就是状态的复杂度( http 是一个无状态的协议),特别是碰到表单什么的状态尤其复杂,所以整出这些中心状态管理的东西。如果组件之间共享了一些状态,把这些状态放到某个中心去管理,组件和组件之间仅有组装逻辑上的关系,组件仅与中心状态有数据逻辑耦合,而组件与组件之间没有数据逻辑耦合,以此来达到解耦(当然 redux 也有不小的缺点)
    至于为什么不用全局变量,是因为全局变量会阻碍 SSR (虽然你可能并不会用到 SSR ,但这些框架的官方教程不太会教你去用全局变量解决各种问题,不过你如果心里足够有数也不是不能用)
    zhangk23
        10
    zhangk23  
    OP
       2023-11-08 01:41:57 +08:00
    @mxT52CRuqR6o5 感谢分享!处理复杂数据时候的确如此,然后 SSR 这块未曾设想过,还需要琢磨一下哈哈哈哈哈
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     2649 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 26ms UTC 02:19 PVG 10:19 LAX 19:19 JFK 22:19
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86