61–70 of 127 posts
It doesn’t necessarily have the same benefits in React, but folks ought to consider using components for control flow, like SolidJS does[1]. 1: https://www.solidjs.com/docs/latest/api#control-flow
Earlier quoted context omitted.
It's still often the cleanest way and I find myself doing something like this: let x = somelongfunc(arg, blah(etc)) ? value1 : some other condition ? value2 : fallback What I usually want is pattern matching expressions, but those are not in many languages.
Try as I might, I have to reason through ternaries every time I encounter them. I think the = being so removed from what it's actually assigning, but without grouping parens, is what messes me up. Plus I always forget what the punctuation characters mean—if/elseif/else uses words, so I don't have to remember.
Earlier quoted context omitted.
The example you put forward could be resolved through using a router. The router implementations are essentially fancy switches without ”switch”.
yeah, I use reach/router for this kind of thing. A page switcher was just the first example that popped into my head. Here's a real world example if it matters… const Grid = (gridItems) => ( {gridItems.map(item => ( _} )} const GridItem = (props) => { switch(props._type) { case 'image': return case 'video': return case 'copy': return // slideshows, 3D stuff, newsletter signup forms… default: return } } … and I suppos…
const gridComponent = {
image: GridImage,
video: GridVideo,
copy: GridCopy
}
const Grid = (gridItems) => (
{gridItems.map(item => {
const GridComponent = gridComponent[item._type]
return GridComponent ? : null
}}
)}protip: you can use an IIFE (immediately invoked function expression) to put whatever conditionals or logic you want inside JSX! I use this all the time and it's much nicer for more complex blocks: {(() => { switch(state) { case 'loading': return ; case 'ready': return ; case 'error': return ; } })()}
I've always much preferred using local variables to hold conditional fragments. Since React will safely ignore null/undefined, you can do: let child; if (someCondition) { child = ; } return ( Maybe here's a child: {child} ); This lets you avoid embedding conditional logic in your (already pretty dense) JSX tree.
That's why a function can be better, at least you know that the value isn't changed somewhere unexpected.
Hard disagree on nested ternaries, or rather chained ternaries, which are just as easy to read and reason about as chained if else statements: if (isA) { return A; } else if (isB) { return B; } else if (isC) { return C; } else { return D; } is equivalent to return isA ? A : isB ? B : isC ? C : D;
return isA ? A
: isB ? B
: isC ? C
: DIt doesn’t necessarily have the same benefits in React, but folks ought to consider using components for control flow, like SolidJS does[1]. 1: https://www.solidjs.com/docs/latest/api#control-flow
Control-flow components like " "... because you couldn't stand just writing "for" or "if" like a caveman and had to invent a custom DSL for it.
It doesn’t necessarily have the same benefits in React, but folks ought to consider using components for control flow, like SolidJS does[1]. 1: https://www.solidjs.com/docs/latest/api#control-flow
Some people consider this added complexity? https://news.ycombinator.com/item?id=30509806