React 代码共享最佳实践方式

最新推荐文章于 2024-09-02 16:47:16 发布

2401_84617080

最新推荐文章于 2024-09-02 16:47:16 发布

阅读量927

点赞数 18

文章标签： react.js javascript 前端

本文链接：https://blog.csdn.net/2401_84617080/article/details/139783757

版权

为了使用mixin，需要在组件中加入mixins属性，然后把我们写好的mixin包裹成一个数组，将它作为mixins的属性值：

const ComponentOne = React.createClass({

mixins: [DefaultNameMixin]

render: function () {

return

Hello {this.props.name}

}

})

写好的mixin可以在其他组件里重复使用。

由于mixins属性值是一个数组，意味着我们可以同一个组件里调用多个mixin。在上述例子中稍作更改得到：

const DefaultFriendMixin = {

getDefaultProps: function () {

return {

friend: “Yummy”

}

const ComponentOne = React.createClass({

mixins: [DefaultNameMixin, DefaultFriendMixin]

render: function () {

return (

Hello {this.props.name}

This is my friend {this.props.friend}

)

}

})

我们甚至可以在一个mixin里包含其他的mixin。

比如写一个新的mixin``DefaultProps包含以上的DefaultNameMixin和DefaultFriendMixin：

const DefaultPropsMixin = {

mixins: [DefaultNameMixin, DefaultFriendMixin]

}

const ComponentOne = React.createClass({

mixins: [DefaultPropsMixin]

render: function () {

return (

Hello {this.props.name}

This is my friend {this.props.friend}

)

}

})

至此，我们可以总结出mixin至少拥有以下优势:

可以在多个组件里使用相同的mixin；
可以在同一个组件里使用多个mixin；
可以在同一个mixin里嵌套多个mixin；

但是在不同场景下，优势也可能变成劣势：

破坏原有组件的封装，可能需要去维护新的state和props等状态；
不同mixin里的命名不可知，非常容易发生冲突；
可能产生递归调用问题，增加了项目复杂性和维护难度；

除此之外，mixin在状态冲突、方法冲突、多个生命周期方法的调用顺序等问题拥有自己的处理逻辑。感兴趣的同学可以参考一下以下文章：

React Mixin 的使用[1]
Mixins Considered Harmful[2]

高阶组件—

由于mixin存在上述缺陷，故React剥离了mixin，改用高阶组件来取代它。

高阶组件本质上是一个函数，它接受一个组件作为参数，返回一个新的组件。

React官方在实现一些公共组件时，也用到了高阶组件，比如react-router中的withRouter，以及Redux中的connect。在这以withRouter为例。

默认情况下，必须是经过Route路由匹配渲染的组件才存在this.props、才拥有路由参数、才能使用函数式导航的写法执行this.props.history.push('/next')跳转到对应路由的页面。高阶组件中的withRouter作用是将一个没有被Route路由包裹的组件，包裹到Route里面，从而将react-router的三个对象history、location、match放入到该组件的props属性里，因此能实现函数式导航跳转。

withRouter的实现原理：

const withRouter = (Component) => {

const displayName = withRouter(${Component.displayName || Component.name})

const C = props => {

const { wrappedComponentRef, …remainingProps } = props

return (

<RouterContext.Consumer>

{context => {

invariant(

context,

You should not use <${displayName} /> outside a <Router>

);

return (

<Component

{…remainingProps}

{…context}

ref={wrappedComponentRef}

)

}}

</RouterContext.Consumer>

)

}

使用代码：

import React, { Component } from “react”

import { withRouter } from “react-router”

class TopHeader extends Component {

render() {

return (

导航栏

{/* 点击跳转login */}

退出

)

}

exit = () => {

// 经过withRouter高阶函数包裹，就可以使用this.props进行跳转操作

this.props.history.push(“/login”)

}

// 使用withRouter包裹组件，返回history,location等

export default withRouter(TopHeader)

由于高阶组件的本质是获取组件并且返回新组件的方法，所以理论上它也可以像mixin一样实现多重嵌套。

例如：

写一个赋能唱歌的高阶函数

import React, { Component } from ‘react’

const widthSinging = WrappedComponent => {

return class HOC extends Component {

constructor () {

super(…arguments)

this.singing = this.singing.bind(this)

}

singing = () => {

console.log(‘i am singing!’)

}

render() {

return

}

写一个赋能跳舞的高阶函数

import React, { Component } from ‘react’

const widthDancing = WrappedComponent => {

return class HOC extends Component {

constructor () {

super(…arguments)

this.dancing = this.dancing.bind(this)

}

dancing = () => {

console.log(‘i am dancing!’)

}

render() {

return

}

使用以上高阶组件

import React, { Component } from “react”

import { widthSing, widthDancing } from “hocs”

class Joy extends Component {

render() {

return

Joy

}

// 给Joy赋能唱歌和跳舞的特长

export default widthSinging(withDancing(Joy))

由上可见，只需使用高阶函数进行简单的包裹，就可以把原本单纯的 Joy 变成一个既能唱歌又能跳舞的夜店小王子了！

使用 HOC 的约定

在使用HOC的时候，有一些墨守成规的约定：

将不相关的 Props 传递给包装组件（传递与其具体内容无关的 props）；
分步组合（避免不同形式的 HOC 串联调用）；
包含显示的 displayName 方便调试（每个 HOC 都应该符合规则的显示名称）；
不要在render函数中使用高阶组件（每次 render，高阶都返回新组件，影响 diff 性能）；
静态方法必须被拷贝（经过高阶返回的新组件，并不会包含原始组件的静态方法）；
避免使用 ref（ref 不会被传递）;

HOC 的优缺点

至此我们可以总结一下高阶组件(HOC)的优点：

HOC是一个纯函数，便于使用和维护；
同样由于HOC是一个纯函数，支持传入多个参数，增强其适用范围；
HOC返回的是一个组件，可组合嵌套，灵活性强；

当然HOC也会存在一些问题：

当多个HOC嵌套使用时，无法直接判断子组件的props是从哪个HOC负责传递的；
当父子组件有同名props，会导致父组件覆盖子组件同名props的问题，且react不会报错，开发者感知性低；
每一个HOC都返回一个新组件，从而产生了很多无用组件，同时加深了组件层级，不便于排查问题；

修饰器和高阶组件属于同一模式，在此不展开讨论。

Render Props—

Render Props是一种非常灵活复用性非常高的模式，它可以把特定行为或功能封装成一个组件，提供给其他组件使用让其他组件拥有这样的能力。

The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.

这是React官方对于Render Props的定义，翻译成大白话即：“Render Props是实现React Components之间代码共享的一种技术，组件的props里边包含有一个function类型的属性，组件可以调用该props属性来实现组件内部渲染逻辑”。

官方示例：

Hello {data.target}

} />

如上，DataProvider组件拥有一个叫做render（也可以叫做其他名字）的props属性，该属性是一个函数，并且这个函数返回了一个React Element，在组件内部通过调用该函数来完成渲染，那么这个组件就用到了render props技术。

读者或许会疑惑，“我们为什么需要调用props属性来实现组件内部渲染，而不直接在组件内完成渲染”？借用React官方的答复，render props并非每个React开发者需要去掌握的技能，甚至你或许永远都不会用到这个方法，但它的存在的确为开发者在思考组件代码共享的问题时，提供了多一种选择。