较为全面的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产品应运而生。