4 ms·
> in ES-like pseudocode In valid ES, you have many options even if none is perfect. With the "horrible" ternary operator: const TodosList = ({ todos }) =
by tuukkah 4y ago
> in ES-like pseudocode
In valid ES, you have many options even if none is perfect.
With the "horrible" ternary operator:
const TodosList = ({ todos }) => (
<div class="todo-list">
{
(todos.length > 0)
? todos.map(t => <Todo key={t.id} todo={t} />)
: <p>No todos yet</p>
}
</div>
);
Without the ternary operator:
const TodosList = ({ todos }) => {
let todoContent;
if (todos.length > 0) {
todoContent = todos.map(t => <Todo key={t.id} todo={t} />);
} else {
todoContent = <p>No todos yet</p>;
}
return (
<div class="todo-list">
{ todoContent }
</div>
);
};
If you allow the repeat of the div:
const TodosList = ({ todos }) => {
if (todos.length > 0) {
return (
<div class="todo-list">
{ todos.map(t => <Todo key={t.id} todo={t} />) }
</div>
);
} else {
return (
<div class="todo-list">
<p>No todos yet</p>
</div>
);
}
};
With a separate render function:
const renderTodos = (todos) => {
if (todos.length > 0) {
return todos.map(t => <Todo key={t.id} todo={t} />);
} else {
return <p>No todos yet</p>;
}
};
const TodosList = ({ todos }) => (
<div class="todo-list">
{ renderTodos(todos) }
</div>
);
- strken 4y agoProbably should have been more clear. It's not that the ternary operator is horrible when used judiciously in a small toy example, it's that it's difficult to parse with longer blocks of code or any complicated flow control. Consider the following very contrived example: const Todo = (todo) => ( <div class="todo"> {todo.status === 'UNFOOABLE' ? <UnfooableError todo={todo} /> : todo.size === 'GIGANTIC' ? <TextBox value={todo.body}> : ( <div> <p>I've run out of creativity but just imagine this has more stuff</p> <p>And that there's a good reason not to make this its own component</p> <OneLineTextBox value={todo.body} /> </div> ) } </div> );
- tuukkah 4y agoThanks for expanding! And do you see my other three refactorings similarly lacking? To me it sounds as if you just didn't like JavaScript: the statement vs expression distinction constrains all non-JSX code too, e.g. you need to use the ternary operator to conditionally assign a value to a const variable. Similarly, your example functions have long multi-line expressions as bodies so for the small gain of not needing the curly braces and a return statement, you pay a huge cost of not being able to use any statements in your code.
- strken 4y ago> Thanks for expanding! And do you see my other three refactorings similarly lacking? No, all four are fine and most people use them in code all the time. They're not completely identical to ternary operators because they move the location of the JSX outside the place where it's used, which can make it harder to read the code at a glance. > it sounds as if you just didn't like JavaScript Yeah, I see that as a failure of EcmaScript, as I said in the first comment. JSX has to work within the unfortunate boundaries of the language. > for the small gain of not needing the curly braces and a return statement, you pay a huge cost of not being able to use any statements in your code That wasn't intended to be a meaningful part of the example, I was just writing the shortest component that let me show a particularly style which would be nice to have in EcmaScript instead of ternary operators.
- the_other 4y agoSure, that's hard to read. So don't write it like that. Early returns; decompose it further; pull the `size` out of the todo data model and into a view configuration; etc.
- strken 4y agoI don't write it like that, but I wish I had better alternatives that weren't hard to read, one of which I described in considerable detail.
- richeyryan 4y ago