<TodoList todos={todos} onRemoveTodo={removeTodo} onCheckTodo={checkTodo} />
or
<TodoList items={todos} onRemoveItem={removeTodo} onCheckItem={checkTodo} />
I am of the opinion that TodoList
already explains (or should explain) itself by the very component name, so the the order of the props used when calling the component should be the order of importance in terms of rendering and UX.
The component must be supplied with some data (list of todo-itmes) so that should be the first prop to be written. I wouldn't name it todos
but probably simply name it data
, so it's clear that this is the data for that component.
I want to keep the terminology as simple as possible, and consistent across components, so all components which requires data (~90% of times an Array. Rarely an Object) should have a prop named data
. If you would have named it todos
than you would have to think of a new name for every component, and why waste time on that on thinking of names?
The above logic extends to all other props (besides data
)
Sometimes you will get into a situation where a parent component has onChange
event which it needs to pass to a child component, and the child component also has its own onChange
, which should do internal things and only then call the parent's onChange
.
Because you cannot have both a prop and a function having the same name, some sort of renaming needs to happen, either in prop-level or local function level:
Example of a problematic naming situation:
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"
}
What I do is simply rename const onChange = value => ...
to const onLocalChange = value =>
and then I can do <Child onChange={onLocalChange} />
Then every time I have this situation I use this exact way-of-thinking, and this is key in making a large codebase predictable in the sense that a random new developer sees that same patterns everywhere and can then (hopefully) cut the learning curve.
Another convention would be naming event handlers as onSomething
, so the word on
always comes first, "marking" the method/prop as an event handler.
In regards to naming props
as in the classical aspect of the question, here are some examples:
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>
The first example - myNiceProp
is the "norm" from what I have seen (and I've seen quite a lot). The second can be used just like the first but the third cannot be "destructured" because it's an invalid variable name. Although you could use special characters for js variables the same does not apply for React props.