<TodoList todos={todos} onRemoveTodo={removeTodo} onCheckTodo={checkTodo} />
或
<TodoList items={todos} onRemoveItem={removeTodo} onCheckItem={checkTodo} />
我认为TodoList已经通过组件名称来解释(或应该解释)自己,所以调用组件时使用的props的顺序应该是渲染和UX方面的重要性顺序.
必须为组件提供一些数据(待办事项列表),以便成为第一个要编写的道具。我不会将其命名为 todos,但可能只是将其命名为 data,因此很明显这是该组件的数据。
我想让术语尽可能简单,并且在组件之间保持一致,因此所有需要数据的组件(大约 90% 的时间是数组。很少是对象)应该有一个名为 data 的道具。如果您将其命名为todos,那么您将不得不为每个组件考虑一个新名称,为什么要在考虑名称上浪费时间呢? ?
上述逻辑扩展到所有其他道具(data 除外)
有时你会遇到这样一种情况,父组件有onChange事件需要传递给子组件,而子组件也有自己的onChange,它应该做内部事情,然后才调用家长的onChange。
因为你不能同时拥有同名的道具和函数,所以需要在道具级别或本地函数级别进行某种重命名:
有问题的命名情况示例:
const Parent = ({ setData }) => {
return <Child onChange={setData} />
}
const Child = ({ onChange }) => {
const onChange = value => { // <-- "onChange" already defined as a prop in the line above
console.log(value)
onChange(value)
}
return <Child onChange={onChange} /> // also has "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 是我所见的“规范”(我见过很多)。第二个可以像第一个一样使用,但第三个不能“解构”,因为它是一个 invalid 变量名。虽然你可以使用special characters for js variables,但同样不适用于 React props。