Question

我已经在网上浏览了几次这个用法，而且我还没有找到关于此事的任何细节。

是反模式还是以这种方式构建组件会对性能产生什么影响？

我发现这种方式更具可读性还允许我对组件的每个部分进行变量分组

我有一些性能问题，但我认为它们与此无关，因此我想将此主题视为负责任的主题。

顺便说一句，这种划分是因为不需要为这些节点创建额外的组件。

将这样的渲染方法拆开：

const MyComponent = React.createClass({

    //helper render function
    render_top(){
        const cssClass='some-class';
        return( <div className={cssClass}>topElement {this.props.someProp}</div> );
    },

    //helper render function
    render_bottom(){
        const cssClass='some-other-class';
        return( <div className={cssClass}>topElement</div> );
    },

    //Actual Render Function
    render(){
        return(
            <div>
                {/*... bunch of jsx code and components*/}

                { this.render_top() }    {/*<---- is it valid?*/}

                {/*... bunch of jsx code and components*/}

               { this.render_bottom() }  {/*<---- will affect performance?*/}

            </div>
        );
    }

});

更新：如果有人可以建议测试来注意差异，那会很有趣。

在反应页面中，他们评论了在渲染方法中使用箭头函数()=>{ }，即反模式，因为每次组件渲染时，都会创建此类函数的新实例。

但是在同样的方法中，每次render方法调用一个辅助函数时...返回的值是一个新实例，还是每次都是同一个实例？

我不确定如何测试它，我对所有观点持开放态度，但如果有更具体的东西来支持这些观点会更好......

Answer 1

性能并不差。它是一个标准，可以将渲染函数分割成更有意义的块，防止它变得太大和不可读

Answer 2

它不是反模式而且性能也不差。将组件拆分为Dumb and Container Components是一个不错的主意，以提高可读性。

我建议你的实际渲染组件如下所示

render(){
    return(
        <div>
            ... bunch of jsx code and components

            <TopElement />  <---- render_top()

            ... bunch of jsx code and components

            <BotomElement />     <---- render_bottom()
        </div>
    );
}

Answer 3

每次都返回一个新实例。这代表将每个返回的值存储在一个数组中并观察内容。但是没有内存泄漏。他们将被垃圾收集。至于性能，React Reconciliation能够有效地比较实例和渲染。关于编码结构和焦点分离恕我直言，但是开销很少但是很值得。

在组件中拆分渲染函数是反模式还是性能较差？

3 个答案: