较为全面的react组件通讯的技巧和弊端

1、props

父组件引起props变化。正常的进行渲染。

内侧想让props变化,就得写回调。onClose,onCallBack,典型的是弹框的应用 。

visable的属性,交叉变量,内测也用,外侧也用

外侧可以读写,内部只能读,造成了内外能力不统一,这类的父子或者兄弟关系只是层级结构关系,并非绝对的受控关系和管理关系,相互影响而已,理想的模型就是都可以进行读写。

 

2、props 结合componentWillReceiveProps使用,props发生变化我要执行一些东西

对于hook来说写useEffects,监控变化产生一些动作。

引起变化的干扰项太多,我要求props单一属性引起动作,事实上props如果数据结构大,任务变化会一起干扰componentWillReceiveProps

 

3、refs的引用,外侧直接操作内部的state,达到变化的效果

违背react的思想,数据驱动变为事件驱动。

 

4、硬是想引起变化,

连续点击A【搜索】,B组件内部的就得变化。

说是写一个时间戳传给子组件,子组件监控到变化,去loading,加载数据。

一个与数据无关的变量进入了我们的视野,懵了。

 

 

5、子组件向上传递需要突破层层onCallBack去影响父组件的变化。

//此onCallBack是为了向上传递2层引起XX组件的变化

过两天又来个注释

//此onCallBack是为了正数第2层引起XX组件的变化

6、既然组件这么复杂,我们干脆不怎么封装,或者做个简单的封装,组件之间通讯也简单,直接一个路由,代码平铺在里面

代码满天飞,体积大,复用性也不好

 

7、组件多的场景,大量的loading变量,tableloading,initDictloading,inserLoading,updateLoading,

PagenatinLoading .........。每次都得写大量的重复代码,一个try catch finnaly 下来

 

setState{tableloading:true}

setState{tableloading:false}

*N

 

综合1 2 3 4 5 6 7,我们目前的大量的代码命中了 1 2 3 4 5 6 7 全部或者部分组合情况,数据管理方式不统一,时间长了自己懵,别人更懵,东一下,西一下,原来你是想改变数据或者发起事件,传递的如此艰难。redux类的DVA产品应运而生。

 

 

 

posted on 2022-06-12 21:29  漫思  阅读(883)  评论(0编辑  收藏  举报

导航