反应：反应组件上的道具数量是否有可观的限制

这有什么固有的问题吗？

例如

render() { 

    const { create, update, categories, locations, sectors, workTypes, organisation } = this.props; // eslint-disable-line no-shadow 

    return (
    <div className="job-container"> 
     <JobForm 
     organisationId={organisation.id} 
     userId={user.id} 
     action={action} 
     create={create} 
     update={update} 
     categories={categories} 
     locations={locations} 
     sectors={sectors} 
     workTypes={workTypes} 
     /> 
    </div> 
); 
}

什么是最佳实践？

来源

2016-06-08 AndrewMcLagan

我不认为React组件可以具有的属性数量有任何问题。它看起来不错。 – vijayst

你在寻找什么类型的最佳做法？例如，你可以通过使用spread运算符来缩短你的语法。 – larrydahooster

最好的做法是在组件中使用propTypes来宣告道具的形式。除此之外，您可以随意放置尽可能多的道具。另外，至少对于公共组件，有很好的默认设置来促进简洁的使用。 – hazardous

我认为你已经公正地认识到了代码味道。任何时候，如果你有很多输入（道具）到一个函数（组件），你必须质疑，你如何用参数组合的所有排列来测试这个组件。使用{...this.props}来传递它们只会降低打字速度，有点像在炸死尸体上喷射炸弹。

我想问为什么你有一个create和update方法vs提交方法？

你好如何使用organisationId和userId？如果只需要传递给create和update（或submit）方法，那么为什么不通过它们并让处理程序提供它们呢？

也许JobForm应该呈现为：

<JobForm /* props go here */> 
    <CategoryDroplist categories=this.props.categories /> 
    <LocationDroplist locations=this.props.locations /> 
</JobForm>

在JobForm你有props.children但那些都是独立的组件，可能被罚款作为单独的部件。

我只是没有足够的信息来回答这个问题，但是通过将组件分解成更简单的东西，道具的数量减少了，气味也减少了。

来源

2017-02-08 18:46:16 boatcoder

除了冗长外，没有任何问题，但当然，这会使您的组件从根本上难以维护。

使其更普遍的一种常见方法是使用展开运算符来代替传递所有这些道具并用简写。

<JobForm {...this.props} />

的另一种方法来解决这个问题是通过分割它成可代替由更小，更集中的组件共享组件的责任。

来源

2016-06-08 09:28:13

虽然道具将传递下来，但与此组件无关。 – AndrewMcLagan

多年来一直有许多语言的风格指南，建议限制一个函数的参数数量。即使ESLint也有一条规则，并指出：“......难以阅读和书写，因为它需要记住每个参数的类型，以及它们应该出现的顺序。”

我认为这在JSX中也是如此。而且，因为JSX是JS的DSL，我们正在编译代码气味。

来源

2017-12-09 13:05:00

反应：反应组件上的道具数量是否有可观的限制

回答

相关问题