个人经验背景：
先说下我能力上的缺陷，工作五六年，项目中基本没有接触过 react，
被数据双向绑定的便利深深影响着，这回直接一周上手react 18+ + antd pro + TS，并且在这一周内开发一个小项目，多少有些措手不及
项目难度：
其实从需求来说，就是一个带查询条件的报表加增删改查，你一听就是 0难度，是的我一开始也是这么想，但是里面用法的坑坑绕绕，被迫离开舒适圈总让我觉得 vue真香
第一部分 报表查询
1,请求配置
不知道为什么接触一个完全陌生的框架总是觉得它的一切配置规则是崭新的
所以希望它的官方文档，写的越全越好，
但是打开umi文档，你会发现，请求配置写的非常简短，所以开始疯狂吐槽文档的不完备，可是最近才发现，其实里面有一句非常重要的话
就这一句话，胜过千言万语啊
什么配置公共前缀域名，配置公共headers，配置拦截器，跟 axios 基本一致，如果早看到这句话，我可能就不会困惑这么久了。。
至于umi-request优秀于axios的地方，这个项目里目前没有感受到，有感受到的同学可以交流一下哈
2, ProTable
ProTable 叫做高级表格，高级在哪呢？
其实就是：
1， 封装了很多常用的逻辑，
包括进入页面自动查询/手动查询/翻页查询 并展示查询后列表，
2，解决项目中需要写很多 table 的样板代码的问题
这里table的样版包括啥呢？就是 这些标准table长的样子，人家都帮你写好了，你只需要按需配置就好了
但是看完api会发现，并没有筛选栏的配置项，我一开始也有点懵， 后来才发现原来 Columns 不只是配置报表列数据的数据源，也是 筛选栏的配置栏， 现在想想可能它的想法是，报表的每一列其实就是筛选项的来源，所以没必要设计两套配置，
或者可以这么想，我们不要从页面布局的角度去想，不要把筛选栏和报表分开想， 可以从数据的角度去想： 一个数据项，比如日期，它既可以是 列数据，也可以是筛选项， 所以如果这么考虑，人家这个配置也蛮合理的，
所以从数据的角度出发， 如果控制是否只在报表中展示，或者是否只是筛选项， 可以 通过 hideInSearch，hideInTable来控制展示和隐藏
想修改数据在筛选栏或是报表中的展示 可以通过 renderFormItem，或 render 来配置
再回头看第一点： 我们知道查询报表跟后端交互是很紧密的，既然 ProTable 能自动帮你做这些交互，它自然需要你配置的请求方法返回符合它预设的数据结构，所以这里必然要对请求回来的数据做一些转换（adaptor适配），这一点代价，我是可以理解的，毕竟人家帮你做了大部分逻辑嘛
也就是说，当翻页时，ProTable 会把当前页码传给 current，
需要展示数据时，ProTable 会从 data里取，总页数会从 total中去取，且要有 success字段， 如果后端接口需要请求参数中的当前页码的字段是 pageNo，那么你要想办法转化了，
怎么转呢？ ProTable 一定有预见到这个问题，所以留了很多口子给我们 我用的是 beforeSearchSubmit 在查询前拦截，将current 转换成 pageNo，再发送请求 当然还有一些其他参数的转换都可以在这里随心所欲的设置
第二部分：表单组件恩怨情仇
在讨论之前，我要说下自己犯的一个基本错误
就是 传递方法的时候，什么时候传 （）=>{reteurn fn},什么时候直接传 fn
fieldProps={{
beforeUpload:()=>beforeUpload
}}
我曾经这样配置过回调，然后怎么都拿不到参数，
后来才知道是这里写的有问题
所以我归纳了这个规律
冒号和等号的区别 ：
冒号，直接传方法，等号呢，需要用箭头函数包一下
对于react新手我只能先这样考虑了，有例外情况可以一起讨论哈
ModalForm
由于本人对 antd的 表单基本使用经验为0，再加上深受vue组件库 v-model影响，直接上手ModalForm 确实遇到了些阻碍
过于高估 initialValues
错误的认为 initialValues 是可以和输入进行联动，但是其实它只是作为初始化，不要妄想他有别的作用。
最后提交的数据，只能通过onFinish的回调拿到，
想要拿到完整数据（编辑场景），我们需要在 onFinish 的回调，传入 该行的原始数据，进行合并
想要非input方式 而是代码修改表单值，只能通过 setFieldValue/ setFieldsValue来实现，才能真实修改数据
这样就带来另外一个问题，通过代码修改表单值，会再次触发校验吗？
答案是不会，只有onChange（及input输入）才能触发自动校验，
所以解法是我们还需要手动触发校验：
formRef?.current?.validateFields(['downloadUrl']).then
吐槽完再夸夸
说了这么多，其实如果了解了这些用法规则，发现procomponent还是节省了很多开发成本，基本做些适配和配置，一个表单和报表就出来了，
我在想，不知道我们总是做这种简单的配置，确实提升了效率，但是前端的可替代性也越来越明显了，
所以要做更难的事啊
修改代码热更新构建的神速归功于 umi 的 提速三宝，
当然还有其他优秀的特性，等待后面有机会的话去体验
小总结
这里还要再说个问题，
以后再遇到这种新框架怎么能减少这种不适和坎坷，快速适应？
我的总结是：
1，在文档没有很健全的情况下，更要仔细看文档，尤其是带link的地方，因为可能会link到一个有详细解释的文档
2，遇到使用问题，想要快速看到用法，可以看看github上的issue，有些问题你遇到了，大概率别人也遇到过
3，procomponent和 umi 这两个巨人，其实也是站在 antd 和 axios 等等巨人的肩膀上，
所以 能快速适应的前提，其实是 考验 antd 和 axios的使用熟练程度，所以还是要多提前补补课
快速补课的方式可以是 看 B站的相关课程
最后，我想说这里有很多碎碎念，不管你喜不喜欢我还想继续分享下去，因为在动荡的大环境下，珍惜还能沉下心来总结沉淀的日子吧