<TodoList todos={todos} onRemoveTodo={removeTodo} onCheckTodo={checkTodo} />
或者
<TodoList items={todos} onRemoveItem={removeTodo} onCheckItem={checkTodo} />
我认为TodoList
已经通过组件名称本身解释(或应该解释)了自己,因此调用组件时使用的props顺序应该是渲染和用户体验方面重要性的顺序。
该组件必须提供一些数据(待办事项列表),因此应该首先编写该数据。我不会将其命名为todos
,而只是简单地命名为data
,这样就清楚了这是该组件的数据。
我希望尽可能简单并且跨组件保持术语一致,因此所有需要数据的组件(大约90%的时间是数组。很少是对象)都应该有一个名为data
的prop。如果你将其命名为todos
,那么你就必须为每个组件考虑一个新名称,为什么要浪费时间思考名称呢?
以上逻辑适用于除data
之外的所有其他props。
有时候你会遇到这样一种情况,父组件有一个
onChange
事件需要传递给子组件,而子组件也有自己的
onChange
,它应该先执行内部操作,然后再调用父组件的
onChange
。
由于你不能同时拥有同名的 prop 和函数,所以需要在 prop 级别或本地函数级别进行某种重命名:
以下是一个问题命名情况的示例:
const Parent = ({ setData }) => {
return <Child onChange={setData} />
}
const Child = ({ onChange }) => {
const onChange = value => {
console.log(value)
onChange(value)
}
return <Child onChange={onChange} />
}
我所做的就是将
const onChange = value => ...
重命名为
const onLocalChange = value =>
,然后我就可以使用
<Child onChange={onLocalChange} />
了。
然后每当我遇到这种情况时,我都会使用这种思考方式,这对于使大型代码库可预测非常重要,因为随机的新开发人员会在各处看到相同的模式,然后(希望)能够减少学习曲线。
另一个惯例是将事件处理程序命名为
onSomething
,因此单词
on
总是排在第一位,"标记"方法/属性为事件处理程序。
关于命名props
,从经典角度来看,这里有一些示例:
const Comp = ({ myNiceProp, my_nice_prop, ...rest }) => <h1>
{myNiceProp}
{my_nice_prop}
{rest["my-nice-prop"]}
</h1>
ReactDOM.render(<div>
<Comp myNiceProp="1" />
<Comp my_nice_prop="2" />
<Comp my-nice-prop="3" />
</div>, root)
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.6.3/umd/react.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.6.3/umd/react-dom.production.min.js"></script>
<div id='root'></div>
第一个例子 - myNiceProp
是我见过的“常规”用法(我见过很多)。第二个可以像第一个一样使用,但第三个不能被“解构”,因为它是一个无效的变量名。虽然你可以使用js变量的特殊字符,但同样的方法不适用于React props。