5 ms·
Yes, I'm well aware of how to use these. I will elaborate on why I think it's terrible (even though there is no alternative in standard JS yet): * It encourage
by molf 5y ago
Yes, I'm well aware of how to use these. I will elaborate on why I think it's terrible (even though there is no alternative in standard JS yet):
* It encourages JSX-specific idioms. Outside of JSX, using `&&` instead of `if` for control flow would raise eyebrows from most people, I think.
* I find it easier and faster to refactor `if` statements to `if/else` and vice versa (only requires addition or deletion of code) than to refactor `&&` to a ternary operator and vice versa (also requires modifying existing code).
* Multiple nested ternary operators almost immediately become a mess, while a series of `else if` expressions (if such a thing existed) seem perfectly readable.
- 9wzYQbTYsAIc 5y agoIt’s generally better to go with the idioms of the language, sure, but in this case, the idioms of JSX work well and they are future-proof. If JavaScript adds the support that you are looking for, it would be easy enough for a static code analyzer to rewrite “&&” as “if”
- hombre_fatal 5y agoYou can add do-expression proposal support in .babelrc: <div> {do { if (user) { <Logout /> } else { <Login /> } }} </div> https://babeljs.io/docs/en/babel-plugin-proposal-do-expressions https://babeljs.io/docs/en/babel-plugin-proposal-do-expressi...
- Izkata 5y agoOr, no need to enable anything: {user ? <Logout \> : <Login \> }
- couchand 5y agoOk this thread just reached peak JavaScript.
- christophilus 5y agoTernary expressions have been around long before JavaScript was a twinkle in Brandon Eich’s eyes.
- 9wzYQbTYsAIc 5y agoJust modern ECMA Script, not peak JavaScript. ES6 and React Hooks have fully sublimated the web development landscape.
- hombre_fatal 5y agoYes, my example is trivial, but if-else can easily outgrow the ternary. The do-expression lets you embed arbitrary statements.
- jameshart 5y agoWhy do you think of JSX’s use of && as control flow?
- eyelidlessness 5y agoCan’t speak for GP, but for me, because: { someBool && <Anything /> } … only renders <Anything /> if someBool is true.
- deleted 5y ago[deleted]
- 9wzYQbTYsAIc 5y agoand if that expression-body is wrapped within the render() method.
- eyelidlessness 5y agoOkay: only evaluates <Anything /> if someBool is true. The value of someBool quite literally controls which code path is taken. It’s even more clear with a fallback: { someBool && <Anything /> || <Fallback /> } Which would more idiomatically be written as a ternary conditional, but still. It doesn’t matter where the expression is placed, it’s the same if you assign it to a variable: const el = someBool && <Anything /> || <Fallback />; Or even just as an expression statement: someBool && <Anything /> || <Fallback />;
- 9wzYQbTYsAIc 5y ago> It doesn’t matter where the expression is placed, it’s the same if you assign it to a variable If you separate the concern of the condition definition from the conditional rendering, by pulling the conditional’s definition into a variable, you do get enhanced portability, though. Much easier to port between languages and frameworks if your conditional definition can be copy-and-pasted out without having to mess with untwining the previous developers expression statements.
- tshaddox 5y ago> Outside of JSX, using `&&` instead of `if` for control flow would raise eyebrows from most people, I think. Very much so, at least for me. Relying on the short-circuiting of logical operators is fine, but only when you're actually going to use the resulting value. In the case of JSX, this is relying on the fact that `false` is a valid React child which renders nothing. Not only does this result in a mistake when the `&&` expression returns something like `0` that is falsey but isn't `false`, IMO it's already pretty awkward even if you are rendering `false`. I'd honestly prefer a runtime error, just like you get if you try to render a JS object, and only support rendering null and maybe undefined as React children.
- 9wzYQbTYsAIc 5y ago> I'd honestly prefer a runtime error, just like you get if you try to render a JS object The React framework strives for catching everything at compile-time. Runtime errors are a big no-no in web development. If I recall correctly, rendering null is behaviorally equivalent to not rendering, in React.
- tshaddox 5y ago> The React framework strives for catching everything at compile-time. Runtime errors are a big no-no in web development. I don't know whether that principle is generally true or ought to be generally true, but React does throw a runtime error if you render a plain JS object as a React child. This can probably also be prevented at compile time with linters or TypeScript, but given that React has to do something at runtime if it encounters an invalid child, I think throwing an error is preferable to just rendering nothing or having some undefined behavior. In my opinion, rendering `null` is a pretty clear and explicit way to indicate you don't want to render anything. But rendering `false` (or `true`, for that matter) is not at all so clear to me. I think throwing a runtime error would be better, and would largely make the `thing && <Component />` idiom go away.
- 9wzYQbTYsAIc 5y agoI get what you are saying. In my experience, it ends up being moot when you are explicitly trying to avoid runtime errors, because you’ll need something along the lines of “guard() && <Component />” or you could simply have “<Component />” and then within Component render have “if (!guarded) return <Fragment />”, etc. At that point, you’ll probably need to worry about component collections containing empty elements, though. That pulls you back into the parent scope, anyways. There’s probably a nicer way to handle it with custom hooks, though. > I don't know whether that principle is generally true or ought to be generally true They sure do go out of their way to make misuse of hooks a compile-time error. I think that those useful error messages go a long way to rectifying the archaic semicolon error messages of the C days.