Material-UI从v0.17.0升级到v1.0.0的高效迁移方案咨询

我完全懂你这种大版本升级的崩溃感——Material-UI从v0到v1是一次彻底的重构，props、组件结构甚至设计理念都有颠覆性变化，官方codemod只能处理表层的导入，确实帮不上太多实质忙。我之前帮团队做过类似的迁移，分享几个亲测有效的方法：

• 分模块渐进式迁移，拒绝一次性全改
  别想着一口气把整个应用的组件都换掉，先挑几个独立、低依赖的组件（比如按钮、卡片、简单的输入框）下手，把它们的v0代码完全改成v1版本，测试确认功能正常后，再逐步迁移复杂组件（比如表单、对话框、侧边栏）。这种方式能避免应用全面崩溃，还能让你边做边熟悉v1的API细节。

• 双版本共存过渡，降低迁移风险
  可以同时在项目里安装v0和v1两个版本，导入时明确区分：

  // 旧组件（v0）
  import RaisedButton from 'material-ui/RaisedButton'
  // 新组件（v1）
  import Button from '@material-ui/core/Button'
  

  慢慢用v1组件替换旧组件，等所有组件都切换完成后，再卸载v0版本。这样即使中间遇到问题，旧代码还能正常运行，不会影响业务。

• 对着官方迁移指南逐组件对照
  虽然codemod没用，但官方的迁移文档里详细列了每个组件的props变更、替代方案，比如：

  • v0的RaisedButton对应v1的Button，primary/secondary属性换成color="primary"/color="secondary"
  • onTouchTap统一换成标准的onClick
  • 表单组件的floatingLabelText换成label，floatingLabelFixed换成InputLabelProps={{ shrink: true }}
    改组件的时候对着查，能少走很多弯路。

• 封装适配层组件，减少重复修改
  如果某些高频组件（比如按钮、输入框）在应用里被调用了上百次，可以自己封装一个适配层组件，内部兼容v0和v1的props。比如写一个MyButton：

  import Button from '@material-ui/core/Button'
  
  const MyButton = ({ primary, secondary, onTouchTap, ...rest }) => {
    const color = primary ? 'primary' : secondary ? 'secondary' : undefined
    const onClick = onTouchTap || rest.onClick
    return <Button color={color} onClick={onClick} {...rest} />
  }
  

  先让所有调用MyButton的地方能正常运行，之后再慢慢替换成直接使用v1的Button，减少一次性修改的工作量。

• 利用v1新特性优化旧代码
  别只想着“改代码适配”，v1的主题系统、样式方案（比如makeStyles、styled）比v0强大很多，迁移时可以顺便优化旧代码的冗余样式。比如把之前零散的inline style换成统一的主题样式，反而能让代码更简洁易维护。

• 参考社区迁移案例避坑
  很多开源项目都经历过这次迁移，你可以去GitHub搜一些项目的PR记录，看看别人是怎么处理复杂组件（比如带验证的表单、嵌套对话框）的迁移，比如一些React admin类的项目，他们的迁移过程能给你很多实际的参考。

总的来说，这次迁移确实工作量不小，但v1的性能、可定制性和React 16的兼容性提升都是值得的，慢慢来分模块推进是最稳妥的方式。

内容的提问来源于stack exchange，提问作者Bob Smith