Tslint: गैर-बूलियन संदर्भ में उपयोग किए जाने वाले तार्किक ऑपरेटरों के लिए सख्त-बूलियन-अभिव्यक्तियाँ सक्रिय नहीं होनी चाहिए

विचार? प्रार्थना? कहां/कैसे शुरू करें, इस पर सुझाव?

@marcind क्या आप उदाहरण प्रदान कर सकते हैं कि नियम को बदलने से इसे अलग तरीके से कैसे व्यवहार करना चाहिए?

क्षमा करें, मेरा प्रारंभिक सबमिशन कौन सा भाग अस्पष्ट है?

मुझे लगता है कि मेरा मुद्दा यह है कि यह नियम केवल "बूलियन संदर्भ" में चलना चाहिए, मैं दो मामलों के बारे में सोच सकता हूं:

1. if , while , या for में प्रयुक्त
2. boolean रूप में टाइप किए गए वेरिएबल को असाइन किया गया।

जब मैं डिफ़ॉल्ट मान या शॉर्ट-सर्किट मूल्यांकन प्रदान करने का प्रयास कर रहा हूं तो नियम नहीं चलना चाहिए

1. const a: string = potentiallyUndefinedString || "the default";
2. const a: string | undefined = potentiallyUndefinedObject && potentiallyUndefinedObject.getString()

@marcind आपकी पिछली पोस्ट के उदाहरण काम करेंगे यदि आप "allow-undefined-union" विकल्प का उपयोग करते हैं।

आपके अनुरोध का दूसरा भाग strict-boolean-conditions नामक एक अलग नियम होना चाहिए जो केवल if , for , while , do ... while और सशर्त जांच करता है भाव ( x ? y : z )।
मैं कल्पना कर सकता हूं कि यह केवल पूरी स्थिति के प्रकार की जांच करेगा, न कि इसके घटक:

function foo(a: boolean, b?: boolean) {
    if (b || a) {} // passes, result is always boolean
    if (b && a) {} // fails, result is boolean | undefined
    if (a || b) {} // fails, result is boolean | undefined
    if (a || !!b) {} // passes
}

हो सकता है कि यह नए नियम के बजाय मौजूदा नियम के लिए एक विकल्प हो...

मेरी राय में, strict-boolean-expressions को केवल && और || के बाएं ऑपरेंड की जांच करनी चाहिए। वे ऑपरेटर हैं (अनिवार्य रूप से) टर्नरी के लिए चीनी: a && b बराबर है a ? b : a , और a || b बराबर है a ? a : b । जब आप इसके बारे में उन शब्दों में सोचते हैं, तो आरएचएस को अनदेखा करना बहुत मायने रखता है, और यह शॉर्ट-सर्किटिंग ऑपरेटरों के व्यवहार को टर्नरी के व्यवहार के अनुरूप लाएगा।

फिर , अगर पूरी चीज अगर/के लिए/समय के अंदर है, तो strict-boolean-conditions चलन में आ सकता है और समग्र अभिव्यक्ति की जांच कर सकता है। मुझे लगता है कि इसमें सभी उपयोगी मामले शामिल होंगे, और मैं इस नियम को फिर से चालू कर पाऊंगा।

जिस कोड ने इसे मेरे लिए एक समस्या के रूप में चिह्नित किया था वह यह दस्तावेज सामान्य प्रतिक्रिया पैटर्न था :

function Foo(props: { showToggle: boolean }) {
  return <div>{props.showToggle && <Toggle />}</div>;
}

ERROR: 2:36 strict-boolean-expressions This type is not allowed in the operand for the '&&' operator because it is always truthy. Allowed types are boolean, null-union, undefined-union, string, or number.

@ajafff उनका कोड मेरे लिए लिंटर पास नहीं करता है, यहां तक ​​​​कि सभी नियम के विकल्प सक्षम होने के कारण, निरंतर RHS के कारण:

export function valueOrDefault(a?: string) {
  return a || "the default";
}

"strict-boolean-expressions": [true, "allow-null-union", "allow-undefined-union", "allow-string", "allow-number", "allow-mix"]

ERROR: 2:15 strict-boolean-expressions This type is not allowed in the operand for the '||' operator because it is always truthy. Allowed types are boolean, null-union, undefined-union, string, or number.

अभिव्यक्ति का इरादा एलएचएस पर एक सशर्त है, इसलिए आरएचएस को अनदेखा करने का मेरा प्रस्ताव भी उसकी समस्या का समाधान करेगा।

मैं सहमत हूं कि && और || के आरएचएस की जांच करना एक बग है।

मैं && , || के एलएचएस और ! के ऑपरेंड के चेक में छूट देने के लिए भी इच्छुक हूं। इनकी केवल जाँच की जानी चाहिए कि क्या अभिव्यक्ति हमेशा सत्य है या हमेशा मिथ्या है।
यह केवल if , for , while , do ... while और केवल बूलियन (या जो कुछ भी कॉन्फ़िगर किया गया है) की अनुमति देने के लिए सख्त जाँच के लिए सशर्त अभिव्यक्तियों की शर्तों को छोड़ देता है ) विचार @adidahiya?

वर्तमान में उपलब्ध कॉन्फ़िगरेशन विकल्पों के साथ इस नियम को सक्षम करने के लिए हमारे कोड आधार के साथ काम के दिनों की आवश्यकता होगी। :(

मैंने यह उम्मीद करते हुए इसे सक्षम किया कि यह number , null या undefined को boolean निहित रूपांतरण को रोक देगा। उदाहरण के लिए:

if (!!array.length) { /* ... */ }

md5-d563d6246c0e981c16f8a2b3d7f53974





md5-430ec08bab82330fa4e519419e9ad014




However I find the following uses acceptable:



md5-70351fc6fdb328ee060919d6974e2cf4



```tsx


md5-036fd2ddd516eac8e1379cdcb9ac2b9a

मुझे लगता है कि यह @marcind के सुझाव से सहमत

मैं && के एलएचएस के लिए चेक में ढील देने के लिए भी इच्छुक हूं, || और के संकार्य!.

@ajafff क्या यह if (!!array.length) या if (!possiblyNull) वैध करेगा?

@ajafff @adidahiya कोई और विचार यहाँ? मैं ठीक उसी स्थिति में हूं जैसे @ rhys-vdw।

बेशर्मी से मेरे अपने प्रोजेक्ट का विज्ञापन:
इस अंक में अपनी आखिरी गतिविधि के बाद से मैंने अपना खुद का लिंटर, फिम्बुलिंटर प्रोजेक्ट बनाया है । त्वरित शुरुआत के लिए दस्तावेज़ पढ़ें: https://github.com/fimbullinter/wotan/blob/master/packages/wotan/README.md

इसमें एक नियम शामिल है no-useless-predicate , जो हो सकता है कि आप जो खोज रहे हैं वह हो सकता है। यह TSLint के strict-type-predicates और strict-boolean-expressions का संयोजन है, लेकिन कुछ प्रमुख अंतरों के साथ:

TSLint के विपरीत strict-type-predicates भी --strictNullChecks बिना काम करता है और टाइप पैरामीटर और खाली ऑब्जेक्ट प्रकारों को सही ढंग से संभालता है। (शायद इस मुद्दे की सदस्यता लेने वाले लोगों के लिए इतना दिलचस्प नहीं है)
TSLint के strict-boolean-expressions में मुख्य अंतर यह है कि इसे बूलियन होने के लिए सब कुछ की आवश्यकता नहीं है (यह निहित जबरदस्ती का पता नहीं लगाता है)। इसके लिए हर शर्त को संभवतः सत्य और मिथ्या होने की आवश्यकता है।

कुछ उदाहरण:

if (0) {} // error, always falsy
if (1) {} // error, always truthy
declare let array: string[];
if (array.length) {} // no error
if (!array.length) {} // no error
if (!!array.length) {} // no error
if (array.length === undefined) {} // error, condition is always false
if (!!false) {} // 2 errors, because of the double negation of an always falsy value

declare let someString: string;
return someString || 'some default string'; // no error, because 'someString' might be falsy

declare const foo: 'bar' | 'baz';
return foo || 'bas'; // error, 'foo' is always truthy

declare let optionalFunction: (() => void) | undefined;
optionalFunction && optionalFunction(); // no error

मैं अपने वास्तविक कोड से निम्नलिखित उपयोग के मामले में झंकार करना चाहता हूं:

export interface ILoggingRule {
    readonly isFinal?: boolean;
    readonly loggerNamePattern?: string;
    readonly maxLogLevel?: LogLevel;
    readonly minLogLevel?: LogLevel;
    readonly target: Target;
}

// ...

/**
 * Creates an instance of LoggingRule.
 * <strong i="6">@param</strong> options Configuration options of the logging rule.
 */
public constructor(options: ILoggingRule) {
    // tslint:disable:strict-boolean-expressions
    this.isFinal = options.isFinal || false;
    this.loggerNamePattern = options.loggerNamePattern || "*";
    this.maxLogLevel = options.maxLogLevel || LogLevel.Fatal;
    this.minLogLevel = options.minLogLevel || LogLevel.Trace;
    this.target = options.target;
    // tslint:enable:strict-boolean-expressions
}

जैसा कि आप देख सकते हैं कि यदि एलएचएस अपरिभाषित होता है तो मैं डिफ़ॉल्ट मानों को दर्शाने के लिए || का उपयोग कर रहा हूं। क्या कोई संक्षिप्त तरीका है जो tslint समझता है कि यह strict-boolean-expressions का पालन करता है? अन्यथा मुझे उन अक्षम/सक्षम आदेशों का उपयोग करने के लिए मजबूर होना पड़ता है। (आश्चर्यजनक रूप से यह केवल एक समस्या है जिसमें टाइप-चेकिंग सक्षम है और VSCode में नहीं है।)

जावास्क्रिप्ट में यह उपयोग मानक और अत्यंत सामान्य और सुविधाजनक है, और निश्चित रूप से इस नियम को विफल होने के लिए ट्रिगर नहीं करना चाहिए।

शॉर्ट-सर्किटिंग की अनुमति देने के लिए && और || IMHO RHS की जाँच नहीं की जानी चाहिए। यह डिफ़ॉल्ट व्यवहार होना चाहिए (या कम से कम allow-any-rhs जैसा कोई विकल्प होना चाहिए)। वर्तमान में, मैं strict-boolean-expressions उपयोग नहीं कर सकता, क्योंकि हमारे कोड-बेस में बहुत अधिक शॉर्ट-सर्किटिंग है।

एलएचएस की जांच आईएमएचओ की तरह ही रहनी चाहिए, क्योंकि एलएचएस के रूप में string या number उपयोग करना खतरनाक हो सकता है, यह उदाहरण देखें:

function foo(x: string | number | null) {
  return x || defaultValue;
}

यह खतरनाक है क्योंकि कई डेवलपर्स यह समझने में असफल होंगे कि न केवल null बल्कि 0 और "" कारण defaultValue वापस आ जाएगा।

मुझे अपने प्रोजेक्ट में प्रमुख बग से निपटना पड़ा है, क्योंकि डेवलपर्स इस बात पर ध्यान देने में विफल रहे हैं कि "" और 0 भी झूठे हैं। इस तरह के कोड को रोकना, strict-boolean-expressions लिए मेरा प्राथमिक उपयोग-मामला है।

https://github.com/palantir/tslint/pull/4159 में फिक्स्ड बस एक सहयोगी से समीक्षा की जरूरत है।

ओह, बस यह स्पष्ट करना चाहता था कि मेरा एक उदाहरण खराब था:

const x = possiblyUndefined || 5;

यह काम नहीं करना चाहिए क्योंकि possiblyUndefined 0 हो सकता है जो एक तर्क त्रुटि हो सकती है। ऐसा लगता है कि @dobesv का PR यहां काम करेगा।

सरणी के लिए शामिल है एक ES7 सुविधा है।
ES7 या ESNEXT का उपयोग करने के लिए आपको अपना कॉन्फ़िगरेशन बदलने की आवश्यकता है

सादर,

@rimiti हाय, मैं यह नहीं समझ सकता कि आप किस बात का जिक्र कर रहे हैं, क्या आप वाकई उस टिप्पणी को सही धागे में पोस्ट कर चुके हैं?

@dobesv ओह, आपको खेद है;)

#4159 द्वारा तय किया गया, अगली रिलीज़ में उपलब्ध होगा