1.解读Ant Design Form中的源码onChange
2.2022年末了，react拖拽组件和最牛的源码代码调试技巧一起学！
解读Ant Design Form中的源码onChange
深入解析 Ant Design Form 中的 onChange 机制
Ant Design Form 组件在处理表单数据时，内部实现了一套复杂的源码逻辑，包括数据双向绑定、源码校验、源码神兽源码是什么数据提交等。源码本文主要探讨 onChange 事件及其在 Form 组件中的源码应用。
Form 组件是源码一个高阶组件 (HOC)，为被包装的源码组件（如 Input）提供了表单功能。Form.create 初始化这个组件，源码注入了 form 对象和 getFieldProps 方法，源码用于获取输入框等表单组件的源码 onChange、value 等属性，源码从而实现数据双向绑定。源码
创建 Form 的基本步骤包括：通过 Form.create 初始化组件，注入 form 对象和 getFieldProps 方法。async源码怎么用getFieldProps 返回 onChange 和 value 属性，用于在表单组件上绑定数据变化事件。
当表单提交时，可以调用 form.validateFields 或 form.validateFieldsAndScroll 来执行数据校验和提交。
在表单内部，onChange 事件通过 onCollect 方法进行处理，该方法将收集到的表单数据存储在 fieldsStore 对象中。最终，通过 setFields 方法更新 fieldsStore，并触发组件重新渲染。
在特定场景下，例如渠道多选控件，当需要在 onChange 中进行复杂的数据处理并更新数据时，直接在 onChange 中设置 fieldsValue 可能会导致问题。因为 onChange 事件处理逻辑在 onCollect 中执行，而 setFieldsValue 方法的腾讯系统源码下载调用并未影响最终的 fieldsStore 数据。
为了解决这个问题，可以将对 fieldsValue 的设置放入下一个事件循环中执行。尽管这可以实现功能需求，但引入了额外的渲染步骤，增加了性能开销。进一步探索源码，可以发现 Ant Design 提供了 normalize 属性来处理数据转换，避免不必要的渲染。
normalize 方法在字段值改变时调用，在重新渲染前进行数据转换，确保渲染时数据符合预期，同时减少渲染次数。对于有校验规则的表单组件，normalize 方法在数据改变时被调用两次，一次是常规的数据更新，一次是spring注解代理源码校验后的数据更新。
总结而言，使用 Ant Design Form 时，应避免在 onChange 事件中直接设置 fieldsValue，而是利用 normalize 属性进行数据转换。同时，通过深入理解源码，可以更高效地解决表单组件在实际应用中遇到的问题。
年末了，react拖拽组件和最牛的代码调试技巧一起学！
年末了，react 拖拽组件和最牛的代码调试技巧一起学！前言
最近刷到了利用 H5drag、dropapi 进行拖拽组件实现的代码示例，于是想学习一下业界知名的一些拖拽组件。于是想从学习成本较低的react-sortable-hoc开始看起。那么对于一个学习者而言，死叉源码公式我们应该如何地去优雅地学习第三方库呢？
当然是「调试」啦。
首先第一步，我们随便创建一个 react 项目，并且按照react-sortable-hoc的最简单的案例编写后准备调试。
比如说我们想看看SortableHandler里面的具体实现，我们给它打个断点，并且创建一个 vscode debug 配置：
按F5开启调试后我们进入SortableHandler中，看到的却是经过打包后的产物：
这显然非常不利于去读懂代码。那么我们该如何将它变成我们能看得懂的源码呢？答案就是sourcemap！
sourcemap 就是用于表示打包后代码和源码的映射关系。因此我们只需要开启 sourcemap 就可以进行 debug 的源码的映射。
我们将react-sortable-hoc项目 clone 下来(这里只拉取一层 commit、一个 master 分支)：
我们可以发现整个项目是使用rollup进行打包的，我们只需要配置一下 sourcemap 开启：
然后执行npm run build，将打包好的 dist 文件夹替换至node_modules/react-sortable-hoc/dist目录下。接着在我们测试项目中将其引入路径改为：
然后我们再来运行一下 debug 试试看：
瞧！这是不是非常熟悉呢？利用调试我们可以随时随地打断点，知道变量的运行时，读起源码来是不是非常轻松呢？
注有的小伙伴可能会发现在调试的时候，打开的源码文件是只读模式，这是为什么呢？
我们可以在 vscode 左侧的CALL STACK中找到当前文件映射到的目录。
如果是node_modules/react-sortable-hoc/src/.../xxx.js，就证明你映射到的只是node_modules中的路径，是无法更改的。
这时候，你可以点击该文件对应的.js.map文件，将其中的../src/xxx.js路径改成你克隆下来的react-sortable-hoc的路径。这样的话，映射到的目录就是你本地的文件，就可以编辑啦！！～
我们修改过node_modules下的文件但又不想被覆盖，可以使用patch-package这个包。 npx patch-package react-sortable-hoc 可以生成一个 diff 文件，上传至 GitHub 上，别人 clone 后只需要运行npx patch-package即可将 diff 覆盖到node_modules下
源码阅读组件的初始化
我们首先来梳理一下示例代码的组件嵌套：
SortableContainer >> SortableElement >> SortableHandler
我们先从组件的初始化入手，从外到内一层一层解析：
SortableContainer
可以发现SortableContainer来初始化的时候，获取了各种 dom 结构以及绑定好了事件。
除此之外，它 new 了一个Manager作为总的拖拽管理中心。其主要功能如下：「注册并储存可拖拽的子节点」，「记录当前激活节点的 index」，「根据 index 进行 sort」：
最后，它渲染函数是这样的：
即通过Provider将全局 Manager 对象传递给了子组件。
SortableElement
我们可以看到，其实SortableElement的初始化只是将自身节点以及一些属性信息注册到了全局Manager对象中。
SortableHandle
SortableHandle的代码就更简单了，只是在自身 dom 上添加了一个sortableHandle的标识，用于判断用户当前点击的节点是否是SortableHandle。这部分逻辑我们在下面就可以看到～
事件触发
了解了各个组件的初始化流程之后，我们可以开始调试拖拽的整个过程的实现逻辑了～
首先我们要知道，所有的事件都是注册在SortableContainer中的，因此我们只需要对其进行调试即可。
拖拽触发事件顺序如下图：
下面让我们来看一下各种事件的逻辑吧：
handleStart
在handleStart的这个回调函数中，我们可以发现它主要做了一下事情：
handlePress
注意看，这个函数有一个比较关键的思想：就是利用克隆节点来模拟正在拖拽的节点。计算并记录好所需要的图形指标并且赋值到新节点上，并且设置position:fixed。
最后在绑定上move事件的监听----handleSortMove.
handleSortMove
函数本身很简洁，首先是updateHelperPosition。
updateHelperPosition
updateHelperPosition的代码经过清理后，核心就在于对克隆元素设置translate，来模拟拖拽的过程。
其次就是最重要的animateNodes函数了。
这里包含了拖拽排序最核心的节点移动逻辑。核心思想如下：
遍历所有sortableElement，如果是当前激活节点，则把原有节点透明化。（因为有克隆节点了）；如果不是，则判断激活节点的坐标以及当前遍历元素的坐标的大小，依此来进行translate3d的动画。
handleSortEnd
最后，当拖拽结束后，触发handleSortEnd。主要逻辑是做一些善后处理，清理各种事件监听器，全局 Manager 的变化，本身被拖拽元素恢复透明度等。。
总结
到这里，整个react-sortable-hoc实现的大致思想就全部介绍完毕啦。它并没有利用 h5 的dragapi，而是利用mousemove、touchmove之类的事件实现 h5 和移动端的兼容。利用 css3 的动画来实现 sort 效果。
但实现过程中也有一些缺点。
比如reactDom.findDomNodeapi，react 并不推荐使用它来去获取 dom，可以换成ref。
比如只能在react类组件中使用。
其他
觉得封装的比较好的工具函数用于学习记录：
2. 获取当前元素距离窗口的偏移值（也可以使用elm.getBoundingClientRect()）
3.移动数组内元素
4. 过滤对象某些属性
