-
Notifications
You must be signed in to change notification settings - Fork 395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESLint Config Migration: Disable the only occurrences of no-nested-ternary rule violation #1055
Conversation
I think that it's okay to have a few eslint-disable-line comments for now if we have a TODO/FIXME comment there. But, in final shape, I like the approach to rewrite this part using switch statements. If you do the rewriting in this PR, that's also fine! |
d10db51
to
09e48d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve this PR if we go with the comments this time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do people think? Perhaps it is worth re-writing this section of the code, expanding it a little, so as to make it a bit more readable? Perhaps with a switch statement?
I second the rewriting of this section at some point to make it more readable
src/App.ts
Outdated
// Set body and payload (this value will eventually conform to AnyMiddlewareArgs) | ||
// Set body and payload | ||
// TODO: this value should eventually conform to AnyMiddlewareArgs | ||
let payload: any = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't spend much time trying to figure out the various possible types the payload
variable could end up being, so I took the lazy way and set this as any
. Sounds like it is related to the TODO comment above? Let me know, happy to dig in here further if the team thinks it is worthwhile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
payload = (bodyArg as SlackShortcutMiddlewareArgs['body']); | ||
break; | ||
// eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
// @ts-ignore: Fallthrough case in switch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have noFallthroughCasesInSwitch
enabled in tsconfig.json
, which I think is a sensible default. However, I think this is one situation where a fallthrough in a case in a switch actually works to preserve the logic.
What does everyone think? Too complicated? Too many linter / compiler ignore comments to go along with it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// If above conditional does not hit, fall through to fallback payload in default block below
This is reasonable enough, so that I'm happy to ignore the rule here.
I added a commit to this PR attempting to rewrite the ternary operators to a If it's too complicated / not clear / deemed not an improvement, no problem to drop the last commit, or try a different approach, or address at a later time - just let me know! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps, we still can explore better ways to ensure the type safety of payload
in the code
src/App.ts
Outdated
// Set body and payload (this value will eventually conform to AnyMiddlewareArgs) | ||
// Set body and payload | ||
// TODO: this value should eventually conform to AnyMiddlewareArgs | ||
let payload: any = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
payload = (bodyArg as SlackShortcutMiddlewareArgs['body']); | ||
break; | ||
// eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
// @ts-ignore: Fallthrough case in switch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// If above conditional does not hit, fall through to fallback payload in default block below
This is reasonable enough, so that I'm happy to ignore the rule here.
OK, did another pass to not use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing it!
@@ -60,8 +60,10 @@ interface Authorization { | |||
* When the string matches known event(s) from the `SlackEvent` union, only those types are returned (also as a union). | |||
* Otherwise, the `BasicSlackEvent<T>` type is returned. | |||
*/ | |||
type EventFromType<T extends string> = KnownEventFromType<T> extends never ? BasicSlackEvent<T> : KnownEventFromType<T>; | |||
type KnownEventFromType<T extends string> = Extract<SlackEvent, { type: T }>; | |||
export type EventFromType<T extends string> = KnownEventFromType<T> extends never ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exporting these types should be fine.
Summary
This is a PR that should be merged into #1024 and incrementally addresses #842.
This PR disables the
no-nested-ternary
rule in the three occurrences that it happens - but is this the right approach? The section where theeslint-disable
lines I added is particularly gnarly 😞 . I think the intention behind theno-nested-ternary
rule is noble, case in point, the nested ternaries are super hard to read!What do people think? Perhaps it is worth re-writing this section of the code, expanding it a little, so as to make it a bit more readable? Perhaps with a
switch
statement?Requirements (place an
x
in each[ ]
)