Skip to content
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

Merged
merged 3 commits into from
Aug 12, 2021

Conversation

filmaj
Copy link
Contributor

@filmaj filmaj commented Aug 9, 2021

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 the eslint-disable lines I added is particularly gnarly 😞 . I think the intention behind the no-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 [ ])

@filmaj filmaj added the tests M-T: Testing work only label Aug 9, 2021
@filmaj filmaj self-assigned this Aug 9, 2021
@seratch
Copy link
Member

seratch commented Aug 9, 2021

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 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!

Copy link
Member

@seratch seratch left a 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

Copy link
Contributor

@misscoded misscoded left a 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 = {};
Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to use a union type like DialogSubmitAction | WorkflowStepEdit | SlackShortcut | KnownEventFromType<string> | ... may make this safer. If we go with any here, we will lose the type safety at the listenerArgs initialization below.

Screen Shot 2021-08-11 at 09 18 19

payload = (bodyArg as SlackShortcutMiddlewareArgs['body']);
break;
// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore: Fallthrough case in switch
Copy link
Contributor Author

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?

Copy link
Member

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.

@filmaj
Copy link
Contributor Author

filmaj commented Aug 10, 2021

I added a commit to this PR attempting to rewrite the ternary operators to a switch statement. It has its own.. special gotchas, in its own way, so another quick review would be much appreciated 🙏

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!

Copy link
Member

@seratch seratch left a 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 = {};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to use a union type like DialogSubmitAction | WorkflowStepEdit | SlackShortcut | KnownEventFromType<string> | ... may make this safer. If we go with any here, we will lose the type safety at the listenerArgs initialization below.

Screen Shot 2021-08-11 at 09 18 19

payload = (bodyArg as SlackShortcutMiddlewareArgs['body']);
break;
// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore: Fallthrough case in switch
Copy link
Member

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.

@filmaj filmaj requested a review from seratch August 11, 2021 14:24
@filmaj
Copy link
Contributor Author

filmaj commented Aug 11, 2021

OK, did another pass to not use any type. 🤞

Copy link
Member

@seratch seratch left a 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 ?
Copy link
Member

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.

@filmaj filmaj merged commit d51c85e into tslint-to-eslint Aug 12, 2021
@filmaj filmaj deleted the no-nested-ternary branch August 12, 2021 01:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests M-T: Testing work only
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants