Earlier quoted context omitted.
Or, no need to enable anything: {user ? : }
Ok this thread just reached peak JavaScript.
Just modern ECMA Script, not peak JavaScript. ES6 and React Hooks have fully sublimated the web development landscape.
Advice on JSX Conditionals
81–90 of 127 posts
Re: Advice on JSX Conditionals
#82Re: Advice on JSX Conditionals
#83I think a better approach is to move the logic to a renderXxx() function: function renderInput(props:Props) { // Early exit if props are not as expected if (!props.cond1) return null; return ; } Then the parent markup is much cleaner, without any conditional: {renderInput(props)}
Though you're also adding indirection. Not always worth it when you're just trying to do some conditional logic next to the code/components that it's related to. Ideally we have the tools to decide when to add indirection ourselves instead being forced to do it to deal with complexity. You could also see this in callback-hell when we'd flatten callback trees with indirection—the tree looked flatter in the editor but…
How is that indirection? These are semantically identical:
{renderIf(foo)}
Re: Advice on JSX Conditionals
#84IMHO this is an anti-pattern.
This involves people writing giant blocks of JSX that are hard to read. Especially with && all over the place. Just split up your component into smaller components with max one conditional each.
Related, can anyone tell me the origins of the bizarre react practice of one file per component? I'm assume some mega corp told people it was "best practice", but the end result is way too many files with hard to read components.
Re: Advice on JSX Conditionals
#85protip: 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 ; } })()}
Waste of memory by creating new function objects on each render.
Yeah probably best to move this to a function outside the render loop with useCallback
Re: Advice on JSX Conditionals
#86I missed a v-if in react/JSX. My code is so hard to read in JSX.
This is usually a good indicator that your components may be doing too much. If your component’s JSX specifically is hard to read, you probably have multiple components implemented within one.
Re: Advice on JSX Conditionals
#87Earlier quoted context omitted.
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…
I'd write it like this const gridComponent = { image: GridImage, video: GridVideo, copy: GridCopy } const Grid = (gridItems) => ( {gridItems.map(item => { const GridComponent = gridComponent[item._type] return GridComponent ? : null }} )}
That’s definitely representative of the compactness that is possible with modern JSX.
Re: Advice on JSX Conditionals
#88Earlier quoted context omitted.
"!!" should be pretty obvious to any javascript developer.
Nonetheless, better for the industry if we start to embrace more uniformity in our idioms. You can practically copy-and-paste between JavaScript and C# these days, with some trivial text replacement tweaks, if you are careful with your idioms.
What if you wanted to get the boolean value of number but with not.
Would you write: !Boolean(n)
Or would you write: !n
Re: Advice on JSX Conditionals
#89The more conditional logic you have in a component, the harder it is to write tests for.
Agreed. This is also true for functions and especially true for stateful classes/objects.