Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Questionable new ternary cases
// This comment looks funny… not sure what our desired behavior should be? Parens?
test ? foo
: /* comment
comment
comment
comment
A newline will be added after this comment, unfortunately – but it can be removed manually, see next statement.
*/
test ? foo
: bar
// Not sure about this:
func(
() => {
thing();
},
(
something(
longArgumentName,
anotherLongArgumentName,
anotherLongArgumentName,
anotherLongArgumentName
)
) ? someOtherThing()
: somethingElse(true, 0)
);
// for a function call, should it be this instead?
func(
() => {
thing();
},
something(
longArgumentName,
anotherLongArgumentName,
anotherLongArgumentName,
anotherLongArgumentName
) ? someOtherThing()
: somethingElse(true, 0)
);
// … I think I like the former better, actually, because it's more clear that the funciton call is in a conditional.
// Do we like this?
(valid ? helper.responseBody(this.currentUser)
: helper.responseBody(this.defaultUser)
).prop;
// Or would this be better?
(
valid ? helper.responseBody(this.currentUser)
: helper.responseBody(this.defaultUser)
).prop;
// or even this?
(valid ?
helper.responseBody(this.currentUser)
: helper.responseBody(this.defaultUser)
).prop;
// or perhaps even this?
(valid ? helper.responseBody(this.currentUser) : (
helper.responseBody(this.defaultUser)
)).prop;
// Related:
const decorated = (arg, ignoreRequestError) => {
return (
(
typeof arg === "string" ||
(arg && arg.valueOf && typeof arg.valueOf() === "string")
) ? $delegate(arg, ignoreRequestError)
: handleAsyncOperations(arg, ignoreRequestError)).foo();
};
// shouldn't that be:
const decorated = (arg, ignoreRequestError) => {
return (
(
typeof arg === "string" ||
(arg && arg.valueOf && typeof arg.valueOf() === "string")
) ? $delegate(arg, ignoreRequestError)
: handleAsyncOperations(arg, ignoreRequestError)
).foo();
};
// and another one:
bifornCringerMoshedPerplexSawder =
askTrovenaBeenaDependsRowans +
((
glimseGlyphsHazardNoopsTieTie === 0 &&
kochabCooieGameOnOboleUnweave === Math.PI
) ? averredBathersBoxroomBuggyNurl
: anodyneCondosMalateOverateRetinol
).Fooooooooooo.Fooooooooooo;
// Other interesting cases (not pulling directly from tests):
foo ? bar
: (
function foo() {
// ...
}
);
foo ?
{
something: 'long',
goes: 'here',
}
: (
{
something: 'else',
goes: 'here',
}
);
foo ? bar
: (
[
1,
2,
]
);
// I think instead these should all be like this:
foo ?
[
4,
5,
6,
]
: [
1,
2,
];
// But what about this?
foo ? bar
: (
some,
really,
reallyLongArgs,
thatBreakTheArgs,
) => {
the();
fn()
body();
};
// Call Expressions?
foo ? bar
: someFn(
some,
really,
reallyLongArgs,
thatBreakTheArgs,
);
// … I think no…
// Curried Arrows?
foo ? bar
: (a) =>
(b) =>
(c) => {
a + b + c
}
// ugh, nope.
foo ? bar
: (
(a) =>
(b) =>
(c) => {
a + b + c
}
)
// hmm, so if we indent the else, we need to use two-space spacing, which is bad…
// when the consequent and alterate are both multiline, I think the parens aren't so bad:
foo ?
[
4,
5,
6,
]
: (
[
1,
2,
]
);
// but when the consequent fits on the same line as the test, it's super weird:
foo ? bar
: (
[
1,
2,
]
);
// so we could instead keep the colon on the same line:
foo ? bar : (
[
1,
2,
]
);
foo ? bar : (
{
something: 'else',
goes: 'here',
}
);
// and maybe hug objects and arrays:
foo ? bar : [
1,
2,
];
foo ? bar : {
something: 'else',
goes: 'here',
};
// Hmm… no, better with parens there I think…
// Looking at react-admin, I don't love this:
const useStyles = makeStyles(theme => ({
root: {
background:
theme.palette.type === 'dark' ? '#535353'
: (
`linear-gradient(to right, #8975fb 0%, #746be7 35%), linear-gradient(to bottom, #8975fb 0%, #6f4ceb 50%), #6f4ceb`
),
// It should either be this:
const useStyles = makeStyles(theme => ({
root: {
background: theme.palette.type === 'dark' ? '#535353' : (
`linear-gradient(to right, #8975fb 0%, #746be7 35%), linear-gradient(to bottom, #8975fb 0%, #6f4ceb 50%), #6f4ceb`
),
// Or this:
const useStyles = makeStyles(theme => ({
root: {
background: theme.palette.type === 'dark' ?
'#535353'
: (
`linear-gradient(to right, #8975fb 0%, #746be7 35%), linear-gradient(to bottom, #8975fb 0%, #6f4ceb 50%), #6f4ceb`
),
// Which, come to think of it, should perhaps be this:
const useStyles = makeStyles(theme => ({
root: {
background: theme.palette.type === 'dark' ?
'#535353'
: `linear-gradient(to right, #8975fb 0%, #746be7 35%), linear-gradient(to bottom, #8975fb 0%, #6f4ceb 50%), #6f4ceb`,
// Another random thought, sometimes this looks nicer:
foo ? foo
: bar
// and sometimes this looks nicer:
foo ?
thing.callStuff(xy, z, foo)
: thing.callStuff(xy, z, bar)
// often based on how similar the consequent and alternate look…
// (vs how short and/or similar the test and consequent are…)
// The former is also way nicer in certain chained ternaries (the latter here looks better):
encoding === "utf8" ?
new UTF8Encoder()
: encoding === "utf16le" ?
new UTF16Encoder(false)
: encoding === "utf16be" ?
new UTF16Encoder(true)
// vs:
encoding === "utf8" ? new UTF8Encoder()
: encoding === "utf16le" ? new UTF16Encoder(false)
: encoding === "utf16be" ? new UTF16Encoder(true)
: throw new Error("Unsupported encoding");
// No idea how to distinguish this in a useful way…
// Maybe chains should allow consequents on the same line as the test, but single ternaries should not??
// eg; single ternary:
// start on one line
const foo = foo != null ? foo : createNewFoo()
// next, break alternate
const foo = foo != null ? foo : (
createNewFoo(withSomeLargArguments, thatBreakTheLine)
)
// next, break consequent:
// if two-space indents are used:
const foo = foo != null ?
useTheCurrentFoo(foo, alsoWithLongArguments, thatBreakTheLine)
: createNewFoo(withSomeLargArguments, thatBreakTheLine)
// else, eg with 4:
const foo = foo != null ?
useTheCurrentFoo(foo, alsoWithLongArguments, thatBreakTheLine)
: (
createNewFoo(withSomeLargArguments, thatBreakTheLine)
)
// and if the alternate breaks too, and is huggable:
const foo = foo != null ?
useTheCurrentFoo(foo, alsoWithLongArguments, thatBreakTheLine)
: createNewFoo(
withSomeLargArguments,
thatBreakTheLine,
evenWithinTheAlternateAlone,
becauseTheyAreSoLong,
)
// and if the alternate is not huggable (or if the indent is not two spaces):
const foo = foo != null ?
useTheCurrentFoo(foo, alsoWithLongArguments, thatBreakTheLine)
: (
1 +
createNewFoo(
withSomeLargArguments,
thatBreakTheLine,
evenWithinTheAlternateAlone,
becauseTheyAreSoLong,
)
);
// and if the test is long:
const foo = (
1 === blah ||
checkTheFoo(
withSomeLargArguments,
thatBreakTheLine,
evenWithinTheAlternateAlone,
becauseTheyAreSoLong,
)
) ?
theShortConsequent
: theShortAlternate;
// and if test is long and indent != 2:
const foo =
(
1 === blah ||
checkTheFoo(
withSomeLargArguments,
thatBreakTheLine,
evenWithinTheAlternateAlone,
becauseTheyAreSoLong,
)
) ? theShortConsequent
: theShortAlternate;
@rattrayalex
Copy link
Author

rattrayalex commented Sep 22, 2021

<div>
{editing && !locked && (
  sideBySideInput ? 
    <div className="flex">
      <Input {...props} />
      {props.children}
    </div>
  : 
    <Input {...props} />
)}
</div>

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment