在项目中有个具体的表单页，表单选项有一些联动，类似于

实现的目标是，表单页组件各种选择，然后在进入下一步又可以返回修改，意味着返回修改的时候必须是要保存过一遍之前用户的选择

这个肯定是保存在store里的

处理方式有两个，一是页面中也保存一份在state中，页面内部的操作都通过setState来修改，在点击下一步的时候做一次保存到store的操作，在进入组件的时候做一次store初始化参数的操作。二是所有的操作修改都直接与store进行，不通过中间的state进行。

翻阅资料对于state和props哪种方法保存数据比较好，说state最好用来记录页面的状态，props记录数据，本来以为页面的表单是一种数据，因此先用了props来尝试

在使用直接与store交互的时候，纯数据的地方比如输入名字等，input的onchange中diapatch更新reducer即可，在遇到有联动的表单交互时遇到了困难，比如图中选择高级配置，此时要更新服务器配置这一项的值，然后根据服务器配置的新的值去更新下面资源的值，因为资源的更新还有别的表单项触发，所以抽取出来为单独的函数。

问题来了，步骤是先更新服务其配置的值，然后在独立函数中获取新的服务器配置的值，去更新资源的值，之前我以为reducer是同步的不会存在setstate异步的情况，但是实践的时候发现无法获取新的值，搜索了一下，大致原因是reducx的connect是在外面包了一层组件，把这个组件的state映射到子组件的props，这内部的state更新还是setState因此没法同步更新

参考

Dispatch 一个简单 action 是否是异步？​react-china.org

redux中有store.getState()函数来直接获取更新的store，而通过props获取的参数是非同步的，那么方法就是在相邻更新的时候，直接使用store的值来处理，dva中是否有类似的方法？

参考umi中访问store的方法，可以直接访问window.g_app._store.getState()

Use umi with dva​umijs.org

测试了下可以产生联动效果，不知道为什么服务器配置的值最后是没有变化，但是下面的资源选择确实是产生了因为服务器配置变化的变化，中间打印服务器配置的值确实也已经修改了。

在触发资源配置的更新reducer的时候好像把之前的服务器配置的值更新掉了

打印结果是

更新操作传的action并没有对服务器配置的内容，因为更新函数：

取的是原来的值，此时没有涉及到的就还是原来的，还是异步造成的问题，相当于说所有单独抽象出来对store更新的函数，保险起见，获取之前的值的时候都需要用getState()来获取，而不是props中获取。

这样在代码中就很不优雅也很混乱，意义也很不直观地表明其实这里有一个store的同步问题，相比之下setState的回调函数写法就很明确

到这里，其实发现使用state来处理页面更为合理，更深入一点，类似这种表单联动的组件，表单数据的修改其实算是一种状态，因为别的会根据状态来更新数据，而不是说是根据数据来更新数据，那么一个表单的值它就不是纯数据，而是状态，因此更适合用state。

在所有数据都修改完之后，整体的数据就变成一次纯数据，一次保存到props中，下次组件初始化的时候直接使用一次这个数据，这就不是状态，所以这个情况使用state其实是更为合适。