React中按钮实现页面导航的三种方式差异与最佳实践

三种实现方式的核心逻辑 #

1. history.push 命令式导航 #

<Button onClick={() => {this.props.history.push('/roles/add')}}>Add</Button>

• 本质是通过React Router的history对象手动触发路由跳转，属于命令式写法。
• 前提是组件能拿到history对象：要么是路由直接渲染的组件（自带history props），要么通过withRouter高阶组件包裹，函数组件则用useHistory hook获取。

2. 直接调用组件（错误用法） #

<Button onClick={AddRole}>Add</Button>

• 这种写法本身是错误的：onClick={AddRole}相当于把组件函数作为点击回调，点击时只会执行AddRole()生成React元素，但不会触发路由导航，也不会把组件挂载到DOM中，完全达不到页面跳转的目的。
• 如果是想通过点击显示组件（比如弹窗），应该用状态（如useState）控制组件的渲染，这属于页面内的局部交互，和路由导航是完全不同的场景。

3. Button as={Link} 声明式导航 #

<Button as={Link} to={'/roles/add'}> Add </Button>

• 这是声明式写法，借助UI组件库（如Chakra UI、Mantine等）的as属性，将Button渲染为React Router的Link组件，同时保留Button的样式和交互逻辑。
• 本质就是Link组件，只是外观是按钮样式，继承了Link的所有导航特性。

性能、功能差异对比 #

性能层面 #

• history.push方式：如果用内联箭头函数，每次组件渲染都会生成新的函数实例，若Button是纯组件，会触发不必要的重渲染。需要用useCallback（函数组件）或类方法（类组件）缓存回调来优化。
• 直接调用组件方式：错误用法，无导航效果，还会生成无用的组件实例，完全不具备路由导航的性能参考价值。
• as={Link}方式：Link组件内部做了性能优化，且不需要额外创建回调函数，是三种方式中性能最优的。

功能层面 #

• history.push：
  • 灵活性高，支持导航前添加业务逻辑（比如表单校验、确认弹窗），满足复杂的前置条件。
  • 可以手动传递路由状态（history.push('/path', { id: 1 })），但所有逻辑都需要手动处理。
• 直接调用组件方式：无法实现页面导航，仅能用于页面内组件的局部渲染控制（需配合状态）。
• as={Link}：
  • 完全继承Link的所有功能：支持to的对象形式（如to={{ pathname: '/roles/add', state: { id: 1 } }}）、replace属性（替换当前历史记录）等。
  • 保留Button的样式和交互，同时具备Link的语义化特性（搜索引擎、屏幕阅读器可识别）。
  • 声明式写法，代码简洁，无需手动处理history对象。

最佳实践推荐 #

1. 优先用as={Link}方式：

   • 只要你的UI组件库支持as属性，这就是最优选择。它代码简洁、性能好、语义明确，还能兼顾按钮的交互和路由的导航特性，对无障碍友好。

2. history.push用于复杂场景：

   • 当需要在导航前执行自定义逻辑（比如校验表单、确认操作）时，用这种命令式方式更灵活。记得缓存回调函数避免不必要的重渲染。

3. 避免直接调用组件的错误写法：

   • 这种方式无法实现页面导航，不要用它来做路由跳转。如果是页面内的组件显示需求，用状态控制渲染即可。

内容的提问来源于stack exchange，提问作者Arjunasarathy M