따라서 첫 번째 예에서는 다음과 같이 내보낼 수 있습니다.

x && xy && xyz && xyzfoo

하지만 그러면 어떻게든 x, y, z, foo가 각각 최대 한 번만 평가되도록 해야 합니다.

당신은 또한 많은 경우에 && 를 할 수 없습니다. 왜냐하면 진실성은 프리미티브에게 약간의 문제가 되기 때문입니다.

예를 들어:

"     "?.trim()?.indexOf("hello")

"" 를 제공합니다.

따라서 유형 시스템을 활용하지 않는 한 일반적인 경우 == 를 사용하여 $ null 에 대한 명시적 비교를 수행해야 합니다.

monadic-bind 함수(JS 출력에 적합하지 않음)를 내보내거나 삼항 연산자에 대한 일부 변환(일반적인 JS에 더 가깝음)을 사용할 수 있습니다. 나는 분명히 후자에 약간 편향되어 있다.

esdiscuss에서 이에 대한 논의가 거의 없었습니다.

• http://esdiscuss.org/topic/the-existential-operator
• http://esdiscuss.org/topic/specifying-the-existential-operator-using-abrupt-completion

:+1:

이상적으로는 실제로 0 / "" 를 사용할지 여부에 대한 정확한 의미에 대해 약간의 불일치가 있을 수 있으므로 ES7(또는 ES8 또는 ES9 또는 ...)이 이를 먼저 구현해야 합니다.

:+1: TypeScript가 ESxx를 기다릴 필요 없이 먼저 이것을 가져오는 것을 보고 싶습니다.

"?"와 같은 간단하고 미친듯이 유용한 null-safety 연산자는 그리고 "?:"가 ES6 사양에 없다는 것은 ES6 사양을 구성하는 사람들이 부끄러움에 고개를 숙여야 함을 의미합니다. 이것은 통합하지 않는 것이 솔직히 미친 것이 될 정도로 간단하고 명백한 것입니다. 대부분의 현대 언어가 이를 지원하는 데는 이유가 있습니다. 필수 불가결한 것입니다.

나는 이것이 현재 사양에서 벗어난다는 것을 알고 있습니다(현재 사양은 이것을 생략할 정도로 근시안적이기 때문에). 그러나 이 단일 편차가 정당화될 것이라고 생각하는 것은 너무 터무니없이 유용합니다. 광대한(VAST) 대다수의 TS 개발자는 구현에 대한 사소한 변경이 최종적으로 ES 사양에 추가되는 경우 영향을 받지 않습니다. 이것이 제공하는 엄청난 이점은 소수의 개발자에게 잠재적인 미래 영향을 줄 가치가 있습니다. 그리고 엄청나게 느린 ES 사양 프로세스를 감안할 때 이것은 몇 년 동안(최소한) 전혀 문제가 되지 않을 것입니다.

나는 brain428에 전적으로 동의합니다.

@brian428 여기서 문제는 해당 연산자가 ES7에서 구현될 수 있으므로 typescript가 최종 ES7과 다른 사양을 사용한다면 아무도 만족하지 않을 것이라는 것입니다.

여기서 문제는 그 연산자가 ES7에서 구현될 수 있으므로 typescript가 최종 ES7과 다른 사양으로 간다면 아무도 만족하지 않을 것입니다.

TypeScript가 ES 방향에 영향을 미치는 유용한 테스트베드가 될 것이기 때문에 _잠재적으로 _(또는 그렇지 않을 수도 있는) 향후 ES 버전으로 만들 수 있는 기능을 구현하는 것이 TypeScript 에 대해 보다 긍정적인 접근 방식이라고 생각합니다.

다음은 TypeScript의 영향을 받는 ES 토론 의 예입니다.

TypeScript... 생성자의 매개변수 중 하나에서 private 접두사를 통해 선언하고 초기화하는 옵션은 많은 개발자에게 도움이 될 것입니다.

또한 ES가 이미 TypeScript에 있지만 의미 체계가 다른 기능(예: 모듈 작동 방식)을 채택하는 것이 가능합니다.

ES가 TypeScript에 이미 존재하지만 의미 체계가 다른 기능을 채택하는 것은 확실히 가능합니다.

나는 우리가 이것을 최악의 시나리오로 광범위하게 고려한다는 점에 주목해야 합니다. 우리는 TypeScript 1.0을 선언하기 전에 ES6의 모듈이 완성되기를 정말로 원했지만 위원회의 일정 지연으로 인해 그것을 막았습니다. 이것은 반복되는 것이 아니라 피해야 하는 것입니다. 우리는 ES7+로 만들 확률이 0% 이하이거나(예: 유형 주석) 쉽게 정의된 의미 체계로 만들 가능성이 ~100%인 기능(예: 뚱뚱한 화살표가 2인 경우)을 치고 싶습니다. 여러 해 전에). 새로운 운영자는 어색한 중간에 빠질 가능성이 높습니다.

최악의 경우 ES7이 다른 경우 컴파일러 플래그가 레거시 TS 구현을 지원하여 유예 기간을 제공할 수 있습니까? 이는 명확한 마이그레이션 문서와 결합되어 개발자에게 새로운 표준에 대한 직접적인 경로를 제공해야 합니다.

궁극적으로 이러한 기능의 사용은 매우 유용하지만 개발자에게 필수적인 것은 아닙니다. TS는 사용 첫날부터 잠재적인 미래 의미를 명확하게 밝혀야 합니다. 잠재적인 관리형 리팩터라는 아이디어가 마음에 들지 않으면 사용하지 마십시오. 아마도 이 메시지를 적용하기 위한 옵트인 컴파일러 플래그일까요?

TS가 ES에 영향을 미치고 싶어 미친 듯이 움직여서는 안 되지만, 이와 같은 작은 고립된 경우에 TS가 완전히 부끄러워하는 것은 부끄러운 일입니다.

아마도 우리는 이에 대한 간단한 제안을 한 다음 --harmony 플래그(또는 이와 유사한 것) 뒤에 참조 구현을 가질 수 있습니다. 그렇게 하면 이 기능의 ES7 개발을 주도할 수 있습니다.

반복적인 조회로 인한 부작용을 방지하기 위해 컴파일러는 임시 변수를 출력해야 합니다.

($tmp0 = x, $tmp0 === void 0 ? void 0 : 
    ($tmp1=$tmp0.y,  $tmp1 === void 0 ? void 0 : 
        ($tmp2 = $tmp1.z,  $tmp2 === void 0 ? void 0 : $tmp2)))

또는 Proxy 기반의 메모이징 멤브레인을 사용합니다.

범주적 관점에서 이것은 속성 조회에 적용된 모나드일 뿐이므로 모든 속성 조회가 정의되지 않은 값을 반환할 수 있는 언어의 매우 자연스러운 기능입니다. ES7이 위의 코드에서 설명한 것과 다른 의미를 채택했다면 놀랐을 것입니다.

codeplex 문제는 꽤 많은 표를 얻었습니다. (61)

atom-typescript 에 atom 를 사용하는 고통을 덜어주기 위해 이것이 정말 필요합니다.

? 코드에서는 매우 관용적입니다. 모든 coffescript 파일, 특히 space-pen과 같이 DOM과 직접 작동하는 파일(보기가 파괴된 후 또는 보기가 첨부되기 전에 함수가 실행될 수 있는 곳)을 열면 엄청난 ? 사용법을 찾을 수 있습니다. 예를 들어 이 파일에는 16 https://github.com/atom-community/autocomplete-plus/blob/f17659ad4fecbd69855dfaf00c11856572ad26e7/lib/suggestion-list-element.coffee 가 있습니다.

다시 말하지만 나는 이것이 필요하다는 것을 좋아하지 않지만 JavaScript의 상태이며 백만 if( && fest ) { then } 보다는 ? 를 선호합니다.

하지만 내 코드를 읽을 수 있도록 유지하려면 정말 필요합니다. XHR이 완료되고 Angular가 다이제스트 루프를 실행할 때까지 이를 _필요로 하는 경우에도 매우 일반적입니다.

이제 스레드를 읽고 왜 우리가 기다리는지 알 수 있습니다. 이해합니다 _한숨_.

we'd have to somehow make x, y, z, and foo each evaluate at most once.

coffeescript는 일부 최적화를 수행합니다. 예를 들어 중간 액세스 결과를 저장합니다 .

typeof foo !== "undefined" && foo !== null ? (ref = foo.bar) != null ? ref.baz() : void 0 : void 0;

(나는 typescript에 대해 undefined 검사가 불필요하다고 강력하게 생각합니다. var init typecheck가 typescript에 의해 검사되어야 하기 때문입니다)

+1

오늘 뉴스에서 Dart는 이에 대한 공식 지원을 받고 있습니다: https://github.com/gbracha/nullAwareOperators/blob/master/proposal.md

매우 중요한 기능입니다.

아마도 비현실적인 아이디어일 수 있지만 모든 사람이 키 속성 액세스로 기능을 처리하는 것이 괜찮다고 결정한다면 이 기능에 대한 코드 생성은 부작용 없이 매우 쉽게 수행될 수 있습니다.

if (aaa?.bbb?.ccc) {}

로 컴파일할 수 있습니다.

if (__chain(aaa, "bbb", "ccc")) {}

__chain 함수는 __extends 와 유사하게 내보내야 합니다. __chain 함수는 arguments 배열을 반복할 수 있으며, 다가오는 멤버가 instanceof Object 가 아니거나 멤버 이름이 포함되지 않은 경우 null 를 반환합니다. 함수 호출은 배열을 매개변수로 전달하여 처리할 수 있습니다(커버 아래 .apply() 사용). 그래서 ...

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

로 컴파일할 수 있습니다.

if (__chain(aaa, "bbb", "ccc", [1, 2, 3])) {}

이렇게 하면 긴 체인의 경우에도 생성된 JS를 합리적으로 관용적으로 유지할 수 있습니다.

분명히 개선이 필요합니다 ...하지만 여기에 뭔가가 있습니까?

aaa?.bbb?.ccc? 가 a.b.c 값을 반환하면 모든 props가 존재하고 그것이 함수인 경우에는

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

로 컴파일

if (__chain(aaa, "bbb", "ccc")(1, 2, 3)) {}

?

@metaweta : 귀하의 솔루션은 void 0 만 확인하는 것입니다 ... 그런 종류의 기능이 기능의 목적에 어긋나지 않습니까?

이것은 어떻습니까?

var result = one?.two?.three;

생성:

var $a, $b, $c;
var result = $a = one, $b = $a ? $a.two : void 0, $b ? $b.three : void 0;

나는 이것이 모든 경우를 처리한다고 확신합니다. 함수 호출에는 instanceof Function 검사가 필요할 수 있습니다.

(예기치 않은 지역 변수가 방출된다는 사소한 단점... IIFE로 래핑될 수 있음)

@kevinb7 : ccc 가 함수가 아니면 어떻게 되나요? 설명한 코드를 사용하면 __chain 는 항상 유효한 함수를 반환해야 하며 그렇지 않으면 TypeError가 발생합니다.

@Back-io 속성이 없으면 조회는 undefined === void 0을 반환합니다. 솔루션은 빈 문자열 및 0과 같은 잘못된 값의 속성을 조회하지 못합니다.

@metaweta : 그렇지 않습니다: http://jsfiddle.net/25LppbL6/

또한 일부 사람들의 린터가 이에 대해 경고한다는 사실 때문에 TS 팀이 느슨한 평등을 사용하는 데 열광하지 않는다고 상상할 수 있습니다.

@Back-io 그렇습니다: http://jsfiddle.net/25LppbL6/2/

@Back-io null과 관련하여?.b의 의도된 의미가 무엇인지 잘 모르겠습니다. "속성 b가 정의된 경우 사용"이면 내 코드가 거의 정확합니다. 존재하지 않는 속성을 조회하면 정의되지 않은 값이 반환되기 때문에 null을 얻을 수 있는 유일한 방법은 null로 할당된 경우입니다. 속성이 존재하지만 정의되지 않음으로 설정된 경우를 포착하지 못합니다. 완전히 정확하려면 void 0 === undefined와 비교하는 대신 Object.hasOwnProperty()로 확인합니다.

의미가 "속성 b가 진실한 경우 사용"이면 코드가 정상이고 JS 관용구와 어느 정도 일치합니다.

음 ... 내가 뭔가를 놓치고 있지 않는 한 ... 바이올린에 대한 변경 사항은 내가 옳았다는 것을 더욱 증명합니다 ... var result 는 세 가지 경우 모두에서 여전히 undefined 입니다. 그리고 나는 당신이 원시 프로토 타입을 확장하여 앞으로 가져 오려고하는 경우가 무엇인지 잘 모르겠습니다 ...

이 기능의 동작은 오류를 생성하는 대신 void 0 로 단락시키는 것이라고 확신합니다. (멤버가 누락된 경우 항상 void 0을 반환해야 한다는 위의 아이디어가 마음에 듭니다.)

''?.toString 의 의도된 출력은 무엇입니까?

@kevinb7 : ccc가 함수가 아니면 어떻게 되나요? 설명하신 코드를 사용하면 __chain은 항상 유효한 함수를 반환해야 하며 그렇지 않으면 TypeError가 발생합니다.

좋은 지적.

@metaweta : 대부분의 사람들이 toString 함수에 대한 참조를 기대한다고 상상할 수 있으므로 귀하의 요점이 어디인지 알 수 있습니다. 0, false, 또는 ''.

:+1:
Angular 2는 템플릿 구문에 Elvis 연산자를 추가했습니다.

@메타웨타 :

''?.toString의 의도된 출력은 무엇입니까?

''?.toString() 를 의미했다면 다음과 같습니다.

if ('' != null) {
  ''.toString();
}

견본

어쩌면 우리는 이것을 위해 스트로우맨 제안을 할 수 있을 것입니다

@kevinb7 이미 존재합니다 : http://wiki.ecmascript.org/doku.php?id=strawman :existential_operator

PropertyAccessExpression 위에 이를 특별한 경우로 구현하기 위해 몇 가지 빠른 테스트를 수행했지만 ?.이 오른쪽 연관이 되기 위해 실제로 ?. 가 필요하기 때문에 제대로 작동하지 않았습니다( . 와 같은 왼쪽 연관 대신).

여기에도 이를 반영하는 BrendenEich의 의견이 있습니다.

PropertyAccessExpression을 특수한 경우로 구현하기 위해 몇 가지 빠른 테스트를 수행했지만 실제로 필요한 만큼 제대로 작동하지 않았습니다. (.와 같은 왼쪽 연관 대신) 오른쪽 연관이 되려면 에미터가 불필요하게 복잡해집니다.

@basarat 자세히 설명해 주시겠습니까? 오른쪽 연관과 왼쪽 연관 ?. 의 차이점에 대한 예는 저에게 매우 도움이 될 것입니다.

@zlumer

오른쪽 연관과 왼쪽 연관 ?의 차이점의 예. 나에게 매우 도움이 될 것입니다.

. 는 연관되어 남아 있으므로 foo?.bar?.baz 식은 AST에서 됩니다( ?. 를 동일하게 취급하는 경우).

                    // foo.bar.baz = PropertyAccessExpression
                    //   .expr foo.bar =  PropertyAccessExpression
                    //     .expr foo = Identifier
                    //     .name bar = Identifier
                    //   .name baz = Identifier

필요한 JavaScript 방출은

foo != null ? (ref_1 = foo.bar) != null ? ref_1.baz() : void 0 : void 0;

AST에 다음이 있는 경우 이 방출(특히 _recursively_)을 수행하는 것이 더 쉽습니다.

                    // foo.bar.baz = PropertySafeAccessExpression
                    //   .name foo =  Identifier
                    //   .expr bar.baz = PropertySafeAccessExpression
                    //      .expr bar = Identifier
                    //      .name baz = Identifier

_첫 번째 AST를 JavaScript로 변환하는 방법을 생각해 보세요_ 복잡성이 더 명확해집니다. 이것이 도움이 되기를 바랍니다 :장미:

@zlumer , @basarat 가 말한 것에 추가하기 위해 1 + 2 + 3 예를 보여드리겠습니다.

구문 분석할 때 이러한 작업 중 어떤 작업이 먼저 발생할지 결정해야 합니다.

+ 가 왼쪽 연관이면 ((1 + 2) + 3) 로 해석됩니다.

+ 이 오른쪽 연관이면 (1 + (2 + 3)) 로 해석됩니다.

이것이 실제로 차이를 만들 것인지 의문을 가질 수 있습니다. JavaScript에서는 그럴 것입니다! "hello" + 2 + 3 예를 고려하십시오.

• 왼쪽 연관: (("hello" + 2) + 3) => ("hello2" + 3) => "hello23"
• 오른쪽 연관: ("hello" + (2 + 3)) => ("hello" + 5) => "hello5"

(기록을 위해 JavaScript/TypeScript는 + 연산자에 대해 왼쪽 결합을 사용합니다.)

@basarat , @BrendanEich 가 말한 것에 대한 나의 이해(그리고 내가 틀렸다면 그는 나를 고칠 수 있습니다 - 핑에 대해 죄송합니다!)는 ?. 이 오른쪽 연관이 아니라 _아닙니다_ 그러나 CoffeeScript의 특별한 경우 속성은 ?. 의 권리는 right-associative가 됩니다. 예를 들어,

o.p?.q.r.s

같이

((o . p) ?. (q . (r . s))) # or something close to this

대신에

((((o . p) ?. q) . r) . s)

방출하기 쉽기 때문입니다.

우리의 AST는 정상적인 의미론적 분석에 적합해야 하므로 방출 절차는 이러한 요구에 맞게 약간 더 복잡할 수 있습니다.

@basarat @DanielRosenwasser 설명해주셔서 감사합니다. 지금까지는 이해하지만 아직 한 가지 확실하지 않습니다.
왼쪽 연관 ?. 는 매우 분명하고 예상됩니다.

foo?.bar?.baz

(대략):

var ref = ((ref = foo) == null) ? null : ((ref = ref.bar) == null) ? null : ref.baz;

그러나 오른쪽 연관 ?. 이 어떻게 작동하는지 전혀 이해하지 못합니다. 예를 들어 주시겠습니까?

그러나 오른쪽 결합이 어떻게 될 것인지 전혀 이해하지 못합니다. 일하다. 예를 들어 주시겠습니까

@zlumer 런타임 동작은 연관 상태로 유지됩니다. DanielRosenwasser가 is not that ?. is right-associative, but that CoffeeScript special cases property accesses on the right of the ?. to be right-associative 라고 설명했듯이 저는 AST에 대해 이야기하고 있었습니다.

우리의 AST는 정상적인 의미론적 분석에 적합해야 하므로 방출 절차는 이러한 요구에 맞게 약간 더 복잡할 수 있습니다.

@DanielRosenwasser 피드백 주셔서 감사합니다 :장미:

@basarat 감사합니다 갑자기 모든 것이 명확해졌습니다 :smiley:

@basarat 의 2월 댓글과 유사합니다, I.... _sigh_...

그러나 생각해보면 이 사용 사례의 99%는 개체에 대한 null 포인터를 확인하는 것입니다. 솔직히 말하면 x 가 number 일 때 누가 x?.b?.c #$ 합니까? 객체에 대해 이야기하지 _아무런_ 할 때 _long_ 체인에 대한 실제 사용 사례는 많지 않습니다( string 가능한 예외 제외). 짧은 체인의 경우 x && x.b 또는 x === 0 ? null : x.b 로 살 수 있다고 생각합니다.

그래서 ?. 가 객체 유형에서만 작동한다고 말할 수 있습니까? 다른 유형은 구문 오류를 발생시킵니다. 그리고 체인 측에서 함수 호출을 허용하지 마십시오.

그러면 모든 것이 a && a.b && a.b.c 됩니다.

@schungx 체인의 구성원이 "임의" 유형이면 어떻게 됩니까? 완전히 거부하시겠습니까? 아니면 그냥 놔두고 최선을 다할 것인가?

글쎄, 내 제안? 완전히 금지합니다. 지옥만큼 우아하지 않다는 것을 알고 있습니다. :-)

그러나 내 근거:

1. 이것은 속기이므로 누군가 any 를 사용한다면 장수를 사용하십시오.
2. 누군가 TypeScript를 사용하고 있다면 타이핑 지원을 위해 그것을 사용하고 있을 가능성이 높으므로 주변에 any 가 많지 않기를 바랍니다!
3. any 는 정말 조심스럽게 다루어야 합니다. any 와 같은 유연한 유형과 함께 이러한 속기 사용을 허용하는 것은 실제로 버그가 발생하도록 요구하는 것입니다. 제 생각에는 any 는 가능한 한 제한되어야 합니다. 그것은 일종의 C의 (void *) 와 같습니다. 핵을 건네준다는 사실이 핵을 발사할 수 있다는 이유만으로 발사해야 한다는 의미는 아닙니다!

이것은 놀라운 운영자가 될 것입니다 !! 특히 ES6 / ES7 / TypeScript

var error = a.b.c.d; //this would fail with error if a, b or c are null or undefined.
var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to handle this
var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d']; //the current messy way to handle this
var typeScript = a?.b?.c?.d; // The typescript way of handling the above mess with no errors
var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling the above mess with no errors

그러나 나는 혼동하지 않기 위해 더 명확한 것을 제안합니다. 에서? b : ?.b 문이 있는 c 문:

var doubleDots = a..b..c..d; //this would be ideal to understand that you assume that if any of a, b, c is null or undefined the result will be null or undefined.
var doubleDotsWithBrackets = a..['b']..['c']..['d'];

대괄호 표기법의 경우 대괄호가 아닌 경우 다른 점과 일관성이 있으므로 하나가 아닌 두 개의 점을 사용하는 것이 좋습니다. 따라서 속성 이름만 대괄호를 통해 정적 또는 동적입니다.

두 개의 점은 null 또는 정의되지 않은 경우 처리를 더 중지하고 표현식의 결과가 null 또는 정의되지 않은 것으로 가정하는 경우를 의미합니다. (d는 null이거나 정의되지 않음).

두 개의 점은 더 명확하고 가시적이며 공간적으로 더 잘 보이도록 하여 진행 상황을 이해할 수 있도록 합니다.

이것은 숫자도 엉망이 아닙니다. 예를 들어 동일한 경우가 아니기 때문에

1..toString(); // works returning '1'
var x = {};
x.1 = {y: 'test' }; //fails currently
x[1] = {y: 'test' }; //works currently 
var current = x[1].y; //works
var missing= x[2].y; //throws exception
var assume= x && x[2] && x[2].y; // works but very messy

번호 두 가지 옵션에 대해: 어느 것이 채택될 수 있는지 귀하의 요청이지만 기존 규칙과의 호환성을 위해 첫 번째 옵션을 권장합니다!

1. 지금처럼 실패해야 합니다( x.1.y == runtime error ).

var err = x..1..y; // should fail as well, since 1 is not a good property name, nor a number to call a method, since it's after x object.

1. Number.prototype 에서 속성을 호출하는 번호가 아니라는 것을 이해하므로 작동해야 합니다.

var err = x..1..y; // should work as well, resulting 'test' in this case
var err = x..2..y; // should work as well, resulting undefined in this case

동적 이름 사용:

var correct1 = x..[1]..y; //would work returning 'test'
var correct2 = x..[2]..y; //would work returning undefined;

여러분은 어떻게 생각하세요?

PS foo?.bar 및 foo?['bar'] 구문도 작동합니다.

그러나 현재 ? : 연산자와 ?. 를 모두 사용하면 같은 줄에서 매우 혼란스러울 수 있습니다.

예: ?. 및 ?['prop'] 사용

var a = { x: { y: 1 } };
var b = condition ? a?.x.?y : a?.y?.z;
var c = condition ? a?['x']?['y'] : a?['y']?['z'];

이중 점 .. 및 ..['prop'] 와 대조적으로

var a = { x: { y: 1 } };
var b = condition ? a..x..y : a..y..z;
var c = condition ? a..['x']..['y'] : a..['y']..['z'];

어느 것이 더 명확해 보입니까?

매우 흥미로운. :+1:

IMHO, 두 개의 점이 더 혼란스러울 것입니다. 두 개의 점이 범위를 나타내는 언어(예: 1..4 )가 있으며 TypeScript는 향후 이 기능을 추가할 수 있습니다.

물음표는 또한 불확실성 또는 조건의 의미 론적 의미를 가지며 두 개의 점은 동일한 의미를 전달하지 않습니다.

@schungx 충분히 공정하지만 a?['b'] 또는 a?() 와 같은 이상한 가능성에 도움이 될 것입니다.

+1 ?

a?['b'] 및 a?() 는 coffeescript에서 잘 작동하며 제 보기에 좋아 보입니다.

그러나 다시 말하지만 나는 커피 스크립트에 눈이 멀 수도 있습니다.

+1 Ruby는 존재 연산자 https://twitter.com/mikepack_/status/657229703443451904를 구현했습니다. Typescript는 특정 구문에 관계없이 이것을 필요로 합니다.

이렇게 하면 코드가 깔끔해집니다 👍

+1 이것이 필요합니다!

제발, implenent ?. C#처럼 연산자

+1 나는 이것을 오랫동안 놓치고 있었다

+1
쓰기 너무 추악함: someVariable && someVariable.someMember
당신이 쓸 수 있을 때: someVariable?.someMember

+1, 이것은 좋을 것입니다 .... (나에게 가장 원하는 기능)

+1, 좋은 생각입니다!
단, 객체가 복잡한 경우 표현식은 ?로 가득 차게 됩니다. 각 속성 뒤에(var result=myValue?.a?.b?.c?.d?.e;) 마지막 값(var result=?myValue.abcde;)을 수신해야 할 때.

+1 - 이것은 틀림없이 CoffeeScript의 가장 큰 기능 중 하나이며 CS에서 TS로 코드의 대부분을 변환한 후 우리 팀에서 단연코 가장 원하는 TypeScript 기능입니다.

+1 그러나 이것은 너무 복잡합니다.

var x = { y: { z: null, q: undefined } };
var z: x|y|z = x?.y?.z;

나는 이것을 좋아한다:

var x = { y: { z: null, q: undefined } };
var z: z|void = x?.y?.z;

x?.y?.z 의 유형은 항상 z 필드의 유형입니다. 물론 유형은 nullable이어야 하고 실제 값은 null일 수 있습니다. null이 아닌 경우 z 필드 유형이어야 합니다.

+1 이것은 대규모의 복잡한 JS 프로젝트의 개발을 용이하게 하려는 Typescript의 비전과 잘 어울립니다.

이에 대한 업데이트가 있습니까? 이 기능이 고려되도록 커뮤니티에서 투표한 경우입니까? 아니면 고려되었지만 몇 가지 엔지니어링 문제가 있습니까?

ECMAScript 위원회의 제안 없이 새로운 표현식 수준 구문을 도입하는 것은 위험하기 때문에 지금까지 업데이트가 없습니다.

https://github.com/Microsoft/TypeScript/issues/16#issuecomment -57645069를 참조하세요.

다음은 실존 연산자에 대한 최신 논의입니다(생각은 많지만 행동으로 보이지는 않음).

• 존재 연산자/널 전파 연산자

ES로 가져오려면 "+1"을 어디에 써야 하나요?

@msklvsk ES토론

지금은 닫습니다. 표현식 수준에서 이것을 요구하는 TypeScript 특정 항목이 실제로 없기 때문에 이러한 종류의 큰 연산자 변경은 여기가 아닌 ES 사양 위원회에서 발생해야 합니다.

이것을 재평가하기 위한 일반적인 트립와이어는 다음 단계에 도달하는 구체적인 ES 제안이거나 이 기능이 오랫동안 발생하지 않을 것이라는 ES 위원회의 일반적인 합의일 것입니다(우리 자신의 의미를 정의하고 합리적으로 그들이 "승리"할 것이라고 확신합니다).

형편없는 인생

독립 실행형 삭제:+1:s. GitHub 반응 기능을 사용하거나 가까운 TC39 담당자에게 꽃과 사탕을 보내주세요.

Coffeescript와 Swift에 익숙해지면 되돌릴 수 없습니다. TS는 현재 상태로 나에게 죽었습니다.

@algesten 우리가 언어 자체를 고려한다면 swift 에 대해 동의할 수 있지만 장기적인 coffescript 지원에 대해서는 확신이 없습니다(저는 프로덕션 프로젝트에서 CoffeScript를 사용합니다). 우리는 coffescript 최근 몇 년 동안 가장 빠른 성장을 보인 반면 TypeScript $2$#$의 동향을 명확하게 볼 수 있는 2016년 6월의 언어 분석 동향에 동의할 수 있습니다.

TypeScript: Go 또는 Swift 외에 최근 몇 년 동안 가장 빠르게 성장하는 언어는 TypeScript입니다. Microsoft가 지원하는 JavaScript 상위 집합과 Angular 2 기반은 2분기 연속으로 31위에서 26위로 크게 상승했습니다. 이는 상위 30개 언어 중 가장 큰 단일 변경 사항이자 전체에서 두 번째로 큰 점프였습니다(표준 ML, 7개 지점). 실제로 #26에서 TypeScript는 현재 Erlang과 동률을 이루고 있습니다. Powershell에 1위, CoffeeScript에 4위를 차지하여 상위 20위권 바로 밖에 있습니다. 언어가 직면한 문제는 성장할 수 있는지 여부가 아니라 추진력이 있는지 여부입니다. 앞으로 2~3분기 안에 상위 20위 안에 진입하여 그 과정에서 CoffeeScript와 Lua를 제치고 도약할 것입니다.

2014년까지 coffescript 추세는 여기 에서 볼 수 있듯이 긍정적인 것 이상이었습니다. 이때부터 하락이 시작되었습니다.

새로운 typescript 2.0 엄격한 null(정의되지 않음) 검사를 사용하면 필수 항목입니다. 그렇지 않으면 함수 연결을 사용할 수 없기 때문입니다!

이것은 ECMAScript의 다음 버전에 있어야 합니다. 이것이 TypeScript보다 바닐라 JavaScript에서 훨씬 더 유용할 것이며 구현이 사실 확인과 반대로 정의되지 않았거나 null에 대한 확인이 될 것이라는 점을 고려하면 TC39에서 추가하는 것은 간단해야 합니다.

JavaScript에서 관용적일 수 있는 간단한 구현은 null 또는 undefined가 발생했을 때 단순히 회로를 단락시키고 undefined를 반환하는 것입니다.

@bterlson 이게 말이 되나요? 그러한 제안이 받아들여질 확률은 얼마나 됩니까?

typescript의 큰 장점 중 하나는 "미래는 오늘 당신에게 주어진다"입니다. 이것은 내가 아직 거기에 없었던 놀라운 기능 중 하나입니다.

나는 그것이 곧 추가되기를 바랍니다. 함수 체이닝은 대중적인 관용구이며 엄격한 null 검사가 ?가 아니면 더 이상 작동하지 않습니다. 연산자가 추가됩니다.

TS 2 멋진 널 검사는 꼭 있어야 할 좋은 것에서 만들었습니다!

이 스레드를 읽으면서 이것이 유지 관리자로부터 더 많은 관심을 받지 못하는 방법에 놀랐습니다.

이상적인 세계에서 TypeScript는 ES의 길을 선도해야 하며 그 반대가 되어서는 안 됩니다. 진지하게, TS 팀이 항상 ESx가 기능이나 구문을 제안하고 마무리하기를 기다렸다면 TypeScript는 어디에 있습니까?

이 구문은 다른 사람들이 지적했듯이 실제로 "필수"입니다. 지금까지 이 스레드에서 좋은 제안을 받기도 했습니다. 구현이 이러한 기대에 부합해야 한다고 생각합니다.

• 일반적으로 a.b 가 유효한 경우에만 컴파일 타임에 표현식 a?.b 이 유효해야 합니다.
• 체인의 각 표현식을 한 번만 평가해야 합니다.
• 단락되어야 합니다.
• 실행이 null 또는 undefined 값으로 중간 표현식에 도달하면 해당 값은 반환 값이어야 합니다.

ES에서 명시할 때 의견 불일치가 발생할 수 있는 부분은 무엇이라고 생각하십니까?

a?.b 의 경우 기존(및 미래?) 구문과의 충돌이 없습니다. 파서가 ?. 토큰을 찾으면 이를 '안전한 탐색 연산자'로 취급할 수 있습니다(@cervengoc에서 설명한 대로 예상).

구문 충돌은 a?(b) 및 a?[b] 를 허용할 때만 발생합니다. 이는 삼항 ?: 연산자 표현식의 시작으로 해석될 수도 있기 때문입니다. 그러나 처음에는 이것들을 제쳐두고 a?.b 구문만 지원하면 이미 많은 개발자를 만족시킬 수 있다고 생각합니다!

이상적인 세계에서 TypeScript는 ES의 길을 선도해야 하며 그 반대가 되어서는 안 됩니다.

표현 수준 구문의 관점에서 우리는 절대적으로 동의하지 않습니다. 표준을 추진하는 위원회가 있는 데는 이유가 있습니다. 한 플레이어의 일회성 행동이 자바스크립트의 미래를 일방적으로 결정할 수 있기 때문이 아닙니다.

이 구문은 다른 사람들이 지적했듯이 실제로 "필수"입니다.

이것이 TypeScript의 필수품이라면 JavaScript의 필수품입니다! 다시 한 번 ECMAScript 위원회에 우려 사항을 전달하십시오 .

ES에서 명시할 때 의견 불일치가 발생할 수 있는 부분은 무엇이라고 생각하십니까?

최소한 해당 값을 만날 때 구문이 null 또는 undefined 로 단락되는지, 아니면 항상 undefined 로 단락되는지에 대한 의견 불일치가 있을 것이라고 생각합니다. 대괄호로 묶인 구문 형식이 지원되는지 여부에 대한 논쟁도 있을 것입니다. a?.b.c 의 동작이 무엇인지에 대한 질문도 있습니다. ?. vs .? vs a.b? 의 문제도 있습니다. 이것이 delete 연산자에 미치는 영향에 대한 질문이 있습니다.

이에 대한 ES DIScuss 스레드는 100개가 넘는 댓글이 있습니다. 모호함이 부족하지 않습니다! 한 가지 예를 따로 분리하여 보고 많은 코너 케이스가 있을 수 없다고 생각하기 쉽습니다. 있습니다. 이것이 아마도 TC39에서 아직 아무도 이 기능을 옹호하지 않은 이유일 것입니다. 또한 우리가 어떻게 동작해야 하는지에 대해 많은 모호성이 있는 기능을 추가하기 위해 서두르지 않는 이유이기도 합니다.

죄송합니다. 언급된 스레드를 읽지 않았습니다. 더 보기 위해 확실히 살펴보겠습니다.

우리는 이것을 조금 다르게 봅니다. 위원회에 대해 제 솔직한 의견으로는 이것이 JavaScript가 결코 _좋지 않을 것인 가장 큰 이유 중 하나입니다. 예를 들어 내가 본 것 중 가장 성공적인 소프트웨어(예: Total Commander 또는 IrfanView)는 *위원회가 아니라 한 사람이 유지 관리하고 설계했기 때문에 성공했습니다. 물론 이것은 완전히 아닙니다. 하지만 나는 거의 확신합니다. 예를 들어 당신 혼자 완전한 ES6을 설계했다면 지금 세상은 더 나은 곳이 될 것입니다.

또한, 귀하가 언급한 모호성은 99% _이론적인_ 것들에 있으며 개발자 측과 관련이 없습니다. null 또는 undefined 가 반환되는 것에 대해 누가 신경을 쓰겠습니까? 하나만 선택하면 그렇게 사용됩니다.

대체로, 당신과 그 위원회는 우리 대부분과 다른 편에 있고, 그 쪽의 일은 일반적으로 실제보다 더 복잡합니다. 그리고 이것은 최소한의 역생산성을 초래할 수 있습니다. 개인적으로 받아들이지 마십시오. 그러나 일반적으로 제 경험에 따르면 어떤 사람들은 회의실에서 더 자주 나와 일부 코드를 보는 것이 좋습니다.

물론 기분을 상하게 하지 마십시오. 아무 것도 개인적으로 받아들이지 마십시오. 저를 포함하여 많은 개발자의 클라이언트 측 개발에 혁명을 일으켰기 때문에 저는 귀하와 모든 TS 팀에 큰 존경을 표하며 모든 작업에 감사드립니다. 우리는 이 특정 문제에 대해 약간 실망했습니다.

마지막으로 한 가지 생각. 나는 언급된 ES 쓰레드를 살펴보았고 한 가지 확실한 것은 그들이 그것을 지나치게 복잡하게 만들고 있다는 것입니다. 그들은 모든 시나리오에 좋은 것을 디자인하기를 원합니다.

저는 개인적으로 조건부 멤버 액세스 연산자에 완전히 만족하고 만족할 것입니다. 조건부 호출, 조건부 인덱스 서명이 필요하지 않으며 유효한 JS 코드인 모든 멋진 시나리오를 지원할 필요가 없습니다. 그게 다야. 그러나 그 대신 그들은 계속 그곳에 앉아 모든 것을 한 번에 처리하는 방법에 대해 논의할 것입니다. 이는 훌륭한 계획이지만 하루가 끝나면 아무 것도 얻지 못할 것입니다.

대체로, 당신과 그 위원회는 우리 대부분과 다른 편에 있고, 그 쪽의 일은 일반적으로 실제보다 더 복잡합니다.

라이언이나 TC39의 진면목을 정확히 반영하고 있다고 생각하지 않습니다. Ryan과 TypeScript 팀은 TypeScript에 대한 매우 명확한 설계 목표 를 설정했습니다. 최초의 현재 목표 중 하나는 TypeScript가 JavaScript의 상위 집합이라는 것입니다. 사람들이 원하는 언어가 아닙니다(예: Dart, Haxe). 구문과 관련하여 TypeScript 팀은 사전 발명(예: 모듈)의 비용을 어렵게 배웠습니다. 우리는 제안된 ES 구문이 TypeScript가 사용하는 구문과 완전히 호환되지 않는 클래스의 private 멤버에 대한 도전에 직면해 있습니다. 왜요? 언어의 런타임 문제를 감안할 때 표면적으로 복잡해 보이지 않는 것이 달성하기가 불가능하기 때문입니다.

내 의견으로는 TC39가 JavaScript를 "저장"했습니다. ES4는 훌륭하고 혁신적인 아이디어가 부족해서가 아니라 인터넷을 깨뜨릴 것이기 때문에 버려졌습니다. TC39는 모양을 갖추었고 토론과 의사 결정 방법을 공유하고 완전히 공개했으며 ES4와 매우 유사하지만 인터넷을 손상시키지 않은 ES2015를 제공했습니다. 기본적으로 10년 전의 코드를 실행하는 JavaScript 런타임이 있다는 것은 놀라운 일이지만 언어에 대한 많은 중요한 개선 사항을 지원합니다. ES2016은 폭풍전야의 잠잠함이었습니다. ES2017에는 "합리적인" 기능과 변경 사항이 있으며 올바른 방향을 제시하는 명확한 관리 프로세스가 있습니다.

그래서 제 생각에는 사물의 "다른 면"에 있는 것이 분명히 효과가 있었습니다. "필수" 기능의 편리함을 능가하는 것입니다.

@kitsonk "다른 면"을 부정적으로 의미하는 것은 아니었고 특히 TypeScript나 ES6에 투입된 작업을 저하시키려는 의도는 없었습니다. 게다가 TypeScript IMO의 가장 좋은 점은 그것이 실제로 명확한 설계 목표를 갖고 있고 가지고 있으며 다른 많은 오픈 소스와 마찬가지로 혼란에 빠지지 않도록 잘 보호되어 있다는 것입니다.

저는 바로 이 기능이 천재적인 사람들이 쉽고 단순한 방식으로 가는 대신 결국 지나치게 생각하고 복잡하게 만들고 호출이나 색인 서명을 지원하지 않는 것과 같은 몇 가지 제한 사항을 수용하게 되는 분명한 예라고 말하고 싶었습니다. 그 포럼의 누군가는 할당에 이 구문을 사용하는 것을 제안했는데, 이것은 일종의 미친 짓입니다. 나는 여전히 이 현상이 그런 의미에서 역효과적이라고 생각한다.

예를 들어 개인 회원이 최종 ES6 개념과 호환되지 않게 된 것이 귀하의 입장에서 고통스럽다는 것을 이해합니다. 그러나 다른 한편으로, 우리는 그것을 가지고 있었습니다. ES6보다 훨씬 이전에. 그리고 그것이 우리 측의 요점입니다. 대략적으로 말하자면, 적절한 코드를 어떻게 내보냈는지 신경쓰지 않고 그저 행복하게 사용하고 있습니다. 모듈 및 모든 것과 동일합니다. 우리는 (또는 적어도 나는) 당신이 그것에 대해 말하는 고통을 보지 못했습니다. 우리는 항상 private 멤버나 모듈에 만족했습니다.

이 특정 기능은 내가 읽은 CoffScript에 있습니다. 왜 우리 단순한 개발자는 플랫폼/라이브러리/플러그인 등을 선택할 때 항상 타협을 해야 합니까? 내 말은 항상 . 이것은 일종의 성가신 일입니다. 여기에 우리는 큰 잠재력을 가진 훌륭한 언어를 가지고 있습니다. 이 언어는 ES를 포함하여 다른 모든 참가자를 완전히 뒤처지게 하고 클라이언트 측 개발의 거대한 부분을 성공적으로 혁신했으며 이 "단순한" 기능( 내 말은 최소한 구성원 액세스 부분을 의미합니다), ES가 이를 커밋할 때까지 구현되지 않을 것이라고 들었습니다.

저는 오늘 TC39 회의에서 이 기능이 0단계에서 1단계로 이동했음을 사람들에게 빨리 알리고 싶었습니다.

관련 커밋: https://github.com/tc39/proposals/commit/cb447642290a55398d483f5b55fb7f973273c75d
회의 의제: https://github.com/tc39/agendas/blob/master/2017/01.md

와! 엄청나다!

https://github.com/claudepache/es-optional-chaining 에 대한 링크도 가치가 있습니다.

여기에서 볼 수 있는 몇 가지 "놀라움"(동의하지 않는다는 말은 아니지만, 더 일찍 이 작업을 수행했다면 다르게 했을 것입니다):

• null 는 a?.b 표현식에서 생성되지 않습니다. a 가 null $인 경우 대신 undefined 가 생성됩니다.
• ~연결된 점의 전파: $ b 및 c 속성이 undefined 인 경우 $ a?.b.c.d 는 throw되지 않습니다. ~ Ryan은 읽을 수 없습니다.
• ~ 괄호가 있는 경우 전파: b (a?.b).c 도 throw되지 않습니다~ Ryan은 읽을 수 없습니다.
• ~ 메서드 호출에서도 전파가 발생합니다. $ c 호출이 null 를 반환하면 a?.b.c().d 는 undefined 를 반환합니다. ~ Ryan은 읽을 수 없습니다.
• delete 연산자가 지원됩니다.
• 대괄호 구문 a?.[x] 이 지원됩니다.
• 함수 호출 구문 func?.(...args) 은 메서드가 아닌 호출(!)에도 지원됩니다.

지금부터 2단계 사이에 해당 영역에서 변화가 있을 것으로 예상합니다.

나는 coffeescript가 옳았다고 생각한다.

a?.bc는 b가 정의되지 않은 경우 발생합니다.

?() 및?[0] 둘 다 좋습니다.

• 연결된 점의 전파: b 및 c 속성이 정의되지 않은 경우 a?.bcd가 throw되지 않습니다.
• 괄호가 있는 경우 전파: b가 정의되지 않은 경우 even (a?.b).c는 throw되지 않습니다.
• 전파는 메서드 호출에서도 발생합니다. c 호출이 null을 반환하면 a?.bc().d가 undefined를 반환합니다.

그 점들은 나에게 정확하지 않은 것 같다. 제안서에서:

a?.b.c().d      // undefined if a is null/undefined, a.b.c().d otherwise.
                // NB: If a is not null/undefined, and a.b is nevertheless undefined,
                //     short-circuiting does *not* apply

와, 완전히 잘못 읽었습니다. 네가 옳아. 업데이트 중

원래 제안에서 @algesten :

a?.()

b?.[0]

달콤한. 연산자는 ?. 와 비슷할 수 있습니다.

여기에 몇 가지 추가 대화가 있습니다: https://github.com/estree/estree/issues/146

잘 적용될 수 있는 인용문: «간단한 것을 쉽게 만들고 어려운 것을 가능하게 하십시오 . 따라서 아마도 가장 일반적인 경우를 잘 지원하고 복잡하거나 드문 경우를 건너뛰고(최소한 초기에는) 더 긴(기존) 구문을 사용하여 "수동으로" 수행할 수 있습니다.

내 2센트만

let a = b?.c?.d?.e;

에게:

let a;
try{
   a = b.c.d.e;
}catch(e){
   a = undefined;
}

@cedvdb 완전히 다른 의미 - getter에서 throw된 예외는 병합을 일으키지 않아야 합니다.

@RyanCavanaugh 예 .. 나는 이것을 생각하지 못했습니다.

이것이 지금 구현의 레이더에 있습니까, 아니면 TS 팀이 ES 제안이 더 진행되기를 기다릴 것입니까?

우리의 짧은 목록에 있습니다. 우리는 여전히 몇 가지 질문/우려 사항이 있지만 다음 달에 이에 대한 움직임을 볼 수 있을 것입니다.

@mhegazy 의 의견이 어디에서 왔는지 확실하지 않습니다. TC39 제안에 대한 공개 질문의 수가 너무 많아 여기서 의미 있는 작업을 수행할 수 없습니다. null 및 undefined 가 상호 작용하는 방식과 실제로 지원되는 구문에 대한 특정 질문을 먼저 해결해야 합니다. 2단계는 절대 최소값이며 런타임 동작에 대한 영향을 고려할 때 3단계를 선호합니다.

이것은 단순히 코드가 작동합니까?

a == undefined ? expression : undefined

expression 는 ax, a[x], a(x), delete 도 여기에서 생성될 수 있음을 의미합니다.

그러면 a?.b?.[c]?.(d) 가 생성됩니다.

a == undefined ? (a.b == undefined ? (a.b[c] == undefined ? a.b[c](d) : undefined) : undefined) : undefined

모든 RyanCavanaugh의 규칙을 통과할 것 같습니다.

== 연산자를 싫어하면 a === undefined || a === null 수도 있습니다.

@zh99998 '' 와 0 도 동일하기 때문에 $ == 를 미워해야 _가_ 있습니다. 런타임 동작은 이제 다소 복잡해지고 있는 (typeof value === 'object' || typeof value === 'function' || typeof value === 'symbol') && value !== null 에 대한 일종의 확인이어야 한다고 거의 주장됩니다.

@RyanCavanaugh 가 말했듯이 적어도 2단계 또는 3단계로 진행되는 TC39 제안 까지는 진행되지 않을 것입니다.

== 는 null 이고 undefined 는 다음과 같습니다.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness

크롬 콘솔에서 통과한 테스트:

'' == undefined
false
0 == undefined
false

@kitsonk undefined는 null로 강제 변환하고 그 반대도 마찬가지입니다. 다른 값은 undefined 또는 null로 강제 변환되지 않습니다.

잘못된 값과 혼동하는 것 같습니다. 0 및 ""는 실제로 거짓이지만 null이나 undefined로 강제 변환되지 않습니다.

== 는 강제를 의미합니다. null == 0 는 undefined를 제외하고는 null로 강제 변환할 수 없기 때문에 false입니다. undefined == 0 도 마찬가지입니다.

또 다른 예는

    if(!NaN) console.log("NaN is falsy") // NaN is falsy
    if(false == NaN) console.log("NaN coerces to false")
   else console.log("NaN doesn't coerce to false");// NaN doesn't coerce

당신은 사진을 얻을.

삼항 연산자를 사용하려는 시도를 많이 보았지만 동일한 속성을 여러 번 참조하는 모든 구현은 예기치 않은 부작용을 초래할 수 있습니다.

다행히 JavaScript에는 IIFE가 있으므로 접근자의 결과를 함수 매개변수에 저장하고 원하는 만큼 참조하고 두 번 이상 평가하지 않을 수 있습니다. 아래 예제에서는 ?. 연산자가 포함된 표현식 대신 여러 번 호출할 수 있는 coalesce 람다를 만듭니다.

언어 구현자가 고려해야 할 한 가지는 표현식 중간에 있는 배열 및 함수 호출입니다. 컴파일러가 이러한 상황을 감지하고 병합 호출 끝에 해당 표현식을 추가할 수 있다고 생각합니다.

const coalesce = (x: any, y: string) => x == null ? null : x[y];

const x = {
    y: {
        z: "Hello, World!!!"
    },
    f: () => "Foo!",
    a: ["Array!"]
};

// x?.y?.z
const value1 = coalesce(coalesce(x, 'y'), 'z');

// x?.f()
const value2 = coalesce(x, 'f')()

// x?.a[0]
const value3 = coalesce(x, 'a')[0]

"coalesce"라는 이름의 실제 전역이 필요하지 않습니다. 이 코드는 모든 표현식에 직접 인라인될 수 있습니다. 그러나 이름을 지정하면 부풀림을 줄일 수 있습니다.

나는 연산자에 사용되는 구문이나 언어 구현자가 표준을 기다리기를 원하는지 그다지 걱정하지 않습니다. 다른 접근 방식을 보여줄 것이라고 생각했습니다.

또한 ?? 연산자가 필요합니다. C#에서 이것은 모든 null 표현식을 오른쪽에 있는 것으로 대체합니다.

string x = null ?? "Hello";
````

In JavaScript, it is more idiomatic to use `||` to replace "falsey" values with the value on the right. 

```javascript
var x = null || "Hello";

불행히도 진실성은 너무 많은 극단적인 경우를 포착합니다( 0 , false 등). null 병합( ?. ) 연산자로 작업하면 null -ness에 특정한 것을 원할 것입니다.

const x = { y: "" };
const result1 = x?.y || "default";  // I'd expect "default"
const result2 = x?.y ?? "default";  // I'd expect "" 

@jehugaleahsa , coalesce를 사용한 예제에서는 이전 검사가 null을 반환한 경우 함수 호출 및 멤버 액세스가 발생하지 않도록 방지하는 방법이 있어야 합니다. x?.f() 예제에서 x가 null이면 f가 호출되지 않아야 합니다.

@bschlenk 나는 동의하지 않는다고 생각합니다. null is not a function 와 같은 메시지와 함께 실패해야 한다고 생각합니다. 하지만 그건 제 몫이 아닙니다.

연산자를 구현하는 가능한 방법을 자세히 설명하는 최근 댓글의 급증은 약간 이상합니다.
구현은 아마도 해결된 문제일 것입니다.

관심이 있다면 ?. 연산자의 동작과 매우 유사한 idx 라이브러리 가 있지만 계획된 연산자에 대한 많은 세부 정보도 무시합니다. 어쨌든, 컴파일 출력에 대한 사양은 이 항목이 구현될 수 있는 방법에 대해 궁금해하는 사람에게 흥미로울 것입니다.

TS는 그런 것을 출력할 수도 있고 완전히 다른 것을 출력할 수도 있지만, 저는 그것이 우리가 여기서 기다리고 있다고 생각하지 않습니다. 여기에서 ES 제안이 한 방향 또는 다른 방향으로 이동할 때까지 TS가 운영자를 얻지 못할 것이라고 여러 번 말했습니다.

여기 와 여기 에 나열된 몇 가지 미지의 사항이 있는 의미 체계입니다.

우리가 이것을 올바르게 구현하고 || 및 ? ... : ... 가 무엇을 하는지 알아내기 위해 여기에 또 다른 100개의 주석이 필요하지 않으므로 안심하십시오. @noppa 가 언급했듯이 우리는 ES 사양이 완료되기를 기다리고 있습니다.

https://github.com/babel/babel/pull/5813 ( babylon PR 과 함께)이 방금 Babel의 preset-stage-1 에 병합되었습니다. 물론 사양은 아직 1단계이지만 앞으로 나아가는 데 도움이 될 것입니다.

내가 틀릴 수도 있지만 이 스레드에서 tc39 제안에 대한 명백한 링크를 보지 못했으므로 여기에 미래의 독자를 위한 것입니다. https://github.com/tc39/proposal-optional-chaining

참고로 선택적 연결은 다음 주 TC39에서 진행됩니다. https://github.com/tc39/agendas/blob/master/2017/07.md

@jehugaleahsa 내 생각에 당신이 옳다고 생각하며 다음 주 TC39에서 ?? 를 선보일 예정입니다. 여기에서 제안을 따를 수 있습니다: https://github.com/gisenberg/proposal-nullary-coalescing

TC39에서 옵셔널 체이닝이 다루어진 것을 보니... 평결은 어땠나요?
Typescript에서 이것을 앞으로 옮기기에 충분하기를 바랍니다 😉

@markwhitfeld 메모 요약 에서 :
Optional Chaining Operators: 1단계에 머물며 다양한 옵션에 대한 더 명확한 정의와 피드백에 대한 답변으로 나중에 다시 돌아올 것입니다.

전체 메모: https://github.com/rwaldron/tc39-notes/blob/master/es8/2017-07/jul-27.md#13iia -optional-chaining-operator

연산자가 어떻게 작동해야 하는지에 대해 여전히 미해결 질문이 있으므로 아직 TypeScript에 추가할 수 있는 상태가 아닌 것 같습니다.

그 메모에서 위원회는 제시된 옵션이 어떻게 작동하는지 전혀 모르는 것 같습니다. 저는 그들이 토론하기 전에 토론하기로 계획했던 제안에 대해 배우려고 했을 것이라고 생각했을 것입니다. 엄격한 null 검사를 활성화할 수 있을 때까지 시간이 더 걸릴 것 같습니다.

나는 그들이 옵션 2/4(어쨌든 제안의 현재 상태)와 함께 가기를 바랍니다.

2014년 7월 15일 - 2017년 9월 4일, 아직 없음

@frankfvb 당신은 분명히 문제를 읽지 않았습니다.

TypeScript에서 이 기능의 기능에 직접적인 영향을 미칠 ECMAScript 제안 에 대한 추가 진전이 있을 때까지 핵심 팀이 현 시점에서 구현하는 것이 현명하지 않을 것이라고 믿게 한 많은 논의가 있었습니다.

ECMAScript 표준 위원회의 마지막 회의에서 제안은 구현 방법에 대한 몇 가지 매우 근본적인 질문이 있기 때문에 1단계 에 머물고 있습니다. 어렵고 빠른 규칙은 아니지만 TypeScript는 3단계 제안만 구현합니다. 그것이 매우 중요하고 TypeScript에서 잠재적으로 사용이 표준의 발전을 주도한다고 믿는 경우 2단계 제안을 구현하는 경우가 있습니다.

사람들이 그것에 대해 더 명확하게 말할 수 있는지 모르겠습니다.

앞서 말했듯이 이것은 우리의 짧은 목록에 있습니다. 우리는 TC39가 연산자의 의미에 대한 일종의 합의에 도달하기를 기다리고 있습니다. 우리는 그것을 내놓고 사용자를 깨뜨리는 것을 싫어할 것입니다.

이것은 TC39 토론을 다시 설명하는 스레드가 아닙니다.

제안서에 무게를 두고 싶다면 적절한 장소에 가서 의견을 말하십시오 . 나도 의견이 있지만 이 스레드에 넣어도 아무 소용이 없습니다.

나는 현재의 필요를 충족시키는 간단한 것을 만들었습니다. 각 링크가 속성 이름인 체인에서만 작동하므로 예를 들어 배열의 요소에 액세스하는 것은 지원되지 않습니다.

TypeScript에서 정말 간단한 Elvis 연산자 구현하기

또한 lodash/underscore가 있는 경우 이미 _.get(Book, 'author.name.firstName') 를 사용하여 원하는 작업을 수행할 수 있습니다.

편집: _.get() 메소드의 유형 문제로 인해 이것은 나쁜 조언인 것 같습니다. 아래 댓글 참조

@tolgaek , _.get 에는 잘못된 타이핑이 있습니다. 이 더 나은 타이핑 (저자 때문에 아직 병합되지 않음 )을 사용하더라도 typescript는 객체의 깊이가 1인 경우에만 결과 유형을 확실히 추론할 수 있습니다. 다른 모든 경우에는 any 입니다.

반면에 elvis 연산자를 사용하면 typescript가 깊이에 관계없이 객체의 결과 유형을 유추할 수 있습니다. 이것이 내가 elvis 연산자를 기대하는 이유입니다.

알겠습니다. 입력 문제가 있는지 몰랐습니다. @BjornMelgaard 감사합니다

@mhegazy 이 기능을 먼저 구현하고 실험 기능으로 표시할 수 없습니까? 실험적인 기능에서 사양이 변경되면 사람들이 문제가 없을 것이라고 생각합니다.

Elvis는 그렇게 오래 기다리지 않습니다.

Babel7에 도착했습니다. Typescript, 우리는 느리게 실행되고 있습니다. 누가 이것을 가능하게 해주세요.
:)

@gs-akhan the Babel 플러그인은 몇 개월 전 제안의 이전 버전을 구현합니다. 그 이후로 제안서에 변경 사항이 있었고(연산자가 구문 분석되는 방식에 대한 상당한 변경을 포함하여) 기능이 2단계(3단계는 고사)에 도달하기 전에 더 많은 변경 사항이 있을 것이므로 현재 babel로 작성된 모든 코드 플러그인은 실제 기능이 출시될 때 중단될 수 있습니다. Babel은 사양 작성자 및 기타 이해 관계자가 제안된 기능을 시험해 볼 수 있도록 제안된 기능이 안정화되기 전에 의도적으로 구현합니다. Babel이 기능을 구현했다고 해서 미래에 브레이킹 체인지가 필요하지 않은 방식으로 구현될 수 있다는 의미는 아닙니다.

@alangpierce 말이 되네요. 감사 해요

나는 이것이 정말, 정말 좋은 오퍼레이터라는 것을 알지만, 규칙이 정리되기 전에 사용할 수 있게 하는 것은 총알이며 우리는 그렇게 하지 않을 것입니다. 연산자의 런타임 동작은 여전히 ​​유동적입니다. 오늘 코드를 작성하면 즉시 명확하지 않은 방식으로 내일 작동을 멈출 수 있습니다. 드문 충돌, 데이터 손상, 누가 알겠습니까? 이제 조금만 참으면 앞으로 몇 개월 동안 많은 고통을 피할 수 있습니다.

사양이 준비될 때까지 이 티켓이 잠겨 있어야(닫히지 않아야 함)해야 한다고 생각하기 시작했습니다.

스펙은 언제쯤 나오나요?

@oliverjanik 현재 초안 사양은 여기 에서 찾을 수 있습니다. 다음 TC39 회의 (9/26-9/28)에서 제안을 2단계로 진행하기 위한 의제가 있습니다. 그 때 이 슬라이드 를 보여드리겠습니다. 조기에 검토하고 피드백을 제공하려는 사람들은 제안서 리포지토리 에 문제를 제출하세요.

우리를 위해 이 문제를 옹호해 주신 @gisenberg 에게 감사드립니다! 혼란을 피하기 위해 TC39 회의에서 사용할 수 있는 교환원 주변의 옵션을 정리하는 데 도움이 되는 요약 슬라이드 자료를 만들까 생각했지만 이미 완료했습니다. 멋진 일!
TC39 대화(및 슬라이드 데크)에 도움이 될 수 있는 다른 한 가지는 아마도 다른 언어에서 연산자의 의미와 구문을 살펴보는 것입니다. 다른 언어가 Javascript에서 어떻게 작동해야 하는지를 반드시 지시해서는 안 되지만, 혼동을 피하기 위해 연산자를 다른 언어의 연산자와 유사하게 유지하는 것이 도움이 될 것입니다.
다음주도 잘 부탁해!!!

다시 한 번 주제에서 벗어나서 죄송합니다. 하지만 여기 Flow에서 _.get 와 같은 안전한 getter 함수에 대해 다소 작동하는 유형 정의를 추가할 수 있다는 점에 대해 일부 사람들이 흥미롭게 생각할 수 있다고 생각했습니다.

예: flowtype.org/try

가장 예쁜 코드는 아니며 null과 undefined를 올바르게 구분하지 못하지만 그 외에는 꽤 잘 작동하는 것 같습니다.

AFAIK에서 TS에서 누락된 유일한 것은 $NonMaybeType 와 같은 것입니다.
물론 이 연산자의 필요성을 없애는 것은 아닙니다. 저는 그냥 멋지다고 생각했습니다.

이것은 최근 TC39 회의에서 대괄호 대 점 대 호출 액세스 및 의미론적 동작( undefined / null 오른쪽 표현식의 부작용에 대한 예측 가능성)에 대한 구문 일관성에 대한 우려로 인해 2단계에 도달하지 못했습니다. x.?b() x.b 이 number )

(썩은 과일을 던지려면 이 댓글에 🎉 투표)

알려주셔서 감사합니다. 정말 짜증나네요. 더 간단하지만 여전히 유용하도록 범위를 좁힐 필요가 있습니까?

더 간단하지만 여전히 유용하도록 범위를 좁힐 필요가 있습니까?

이것은 TC39가 직면한 도전입니다. 짜증나긴 하지만 사람들이 이 일을 겪을 수 있어서 기쁩니다. 상당히 복잡한 수준의 구문을 도입하는 것은 정말 어렵습니다. 사실 이 경우 언어의 약한 타이핑으로 인해 실제로 해결해야 하는 상당한 양의 엣지 케이스가 발생하거나 💥 다음과 같은 코드가 발생합니다. 누구에게나 좋지 않습니다. 이런 연산자를 도입하면 실제로 범위를 좁힐 수 있다고 생각하지 않습니다. 구현자가 90%의 경우를 처리하는 것이 더 쉬울 것이지만 ¯\_(ツ)_/¯ 가 나머지 10%에 대해 유효한 코드라고 생각하지 않습니다.

여러분, 3년 이상 후에, 위원회에 "엿먹어라"라고 말하고 TypeScript에 관용적인 것이 무엇이든 우리 자신의 방식으로 할 때라고 말하고 싶습니다. 어쨌든 이 기능은 정적 입력 없이는 제대로 작동하지 않습니다.

TC39 제안과 명시적으로 호환되지 않는 구문으로 TypeScript 구현을 만듭니다. ES가 safe-nav 연산자를 얻으면 TypeScript에는 두 가지 옵션이 있습니다. 하나는 ES와 호환되는 엉터리 의미 체계가 있고 다른 하나는 유형 시스템에 연결됩니다. 이는 "유형"과 함께 TS 안전 탐색 연산자를 사용할 수 없다는 것을 의미하며 괜찮습니다.

@notsnotso Typescript는 JS를 깨뜨리지 않아야 합니다. 이것이 Coffeescript의 목적입니다.

아마도 좋은 해결책은 다음과 같습니다.

• 매우 간단한 구현? 참을성이 없는 개발자를 위한 연산자, 실험적 기능(예: 데코레이터), 경고 포함 - 나중에 코드가 손상될 것입니다.
• 표준이 작성될 때 3년을 더 기다리십시오. 비실험 기능으로 구현하십시오. 튜토리얼을 작성하십시오. 무엇을 깨뜨릴 수 있습니까? 정적 타이핑을 사용하는 경우에도 사람들이 새로운 연산자 구현으로 코드를 컴파일할 때 경고를 작성할 수 있습니다.
  "TypeScript에 관용적인 것은 무엇이든 우리 자신의 방식으로 하십시오"는 경우가 아닙니다. 왜냐하면 3년 안에 사람들은 t elvis가 js에서와 같은 방식으로 작동하지 않는다는 문제에 직면하게 될 것이기 때문입니다.

솔직히 말해서 이것이 가지 않았다는 사실에 놀라지 않습니다. 내 원본에서
포스트에서 인덱싱, 함수 호출 등에 대한 모호성을 지적했습니다.
솔직히 ?. 생각하면 할수록 아닌 것 같아
undefined 가 있으므로 JavaScript에 속합니다.

이 문제를 해결한 범용 유틸리티를 훨씬 더 선호합니다.
그리고 더. 내가 가진 한 가지 생각은 인라인 try/catch 과 같았습니다.
표현식( let x = try a.b.c else 0 )을 다음과 같은 연산자와 결합하여
"falsey"(예: x || 1)가 아니라 "null"(예: x ?? 1)인지 확인합니다.
따라서 try a.b.c ?? 0 else 0 와 같이 결합합니다. 말이 많네, 네,
그러나 기본적으로 다음과 같이 말합니다. abc를 평가해 보고 결과가 null 이거나
undefined , 0을 반환합니다. a 또는 b가 undefined 이고 예외가 발생하면
그것을 잡아 0을 반환합니다.

대안은 else 절을 선택 사항으로 만드는 것입니다. 기본값은
undefined . 그런 다음 let x= (try a.b.c) ?? 0 식을 작성할 수 있습니다. 그것은 매우 컴팩트하고 모호성을 피하고 더 많은 것을 제공합니다.
다른 문제를 해결할 수 있는 범용 솔루션.

나는 우리가 이것을 대신해야 한다고 말하는 것이 아닙니다. 내가 말하는 모든 것은 거기에 있습니다
?. 의 대안이며 우리는
JavaScript 언어와 잘 맞는 것을 찾으십시오.

2017년 10월 5일 목요일 오전 7시 51분, Dmitry Radkovskiy [email protected]
썼다:

@notsnotso Typescript는 JS를 깨뜨리지 않아야 합니다.
Coffeescript는 다음을 위한 것입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/16#issuecomment-334441781 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABTgPilbZfuKc2egdBrYfdTHHeDl3F6Sks5spMLLgaJpZM4CNapf
.

@zlumer 좋은 농담. 즉, TS 특정 기능은 Javascript를 중단하지 않습니다.

@jehugaleahsa 당신의 제안이 마음에 들고, 다른 언어에서도 찾을 수 있습니다. TS용으로 괜찮을 것 같네요.

ECMAScript가 연산자를 수락할 때까지 기다려야 한다는 강한 필요성을 정말로 이해하지 못한다고 말하겠습니다. TypeScript는 클래스, 모듈, 람다를 모두 ECMAScript에 도입하기 훨씬 전에 추가했습니다. 사실 TypeScript의 명시된 목표 중 하나는 실험적인 JS 기능을 시험하는 것이었습니다. 자체 구현을 제공하는 TypeScript는 의심할 여지 없이 위원회에서 이러한 논의를 알리는 데 도움이 될 것입니다.

위원회가 결국 다른 방향으로 가기 전에 여러분은 획기적인 변화를 기꺼이 받아들였습니다. 저는 이 기능이 왜 그렇게 다른지 잘 모르겠습니다.

async/await도 초기 단계에서 TypeScript에 도입되었습니다.

즉, TS 특정 기능은 Javascript를 중단하지 않습니다.

"TS 특정 기능"과 같은 것은 없을 것입니다. 자세한 내용은 TypeScript 디자인 목표 를 확인하세요.

_{TypeScript는 ES가 밝은 길로 가기 전에 도착합니다. 기존의 것이 있을 수 있습니다.그들은 단지 호환성을 위해 보관됩니다.}

TypeScript는 클래스, 모듈, 람다를 모두 ECMAScript에 도입하기 훨씬 전에 추가했습니다.

그리고 특히 모듈은 여전히 ​​혼란을 일으키지 않는 거대한 재앙입니다. TypeScript 팀이 _mistake_의 예로 반복해서 사용하고 너무 일찍 총을 던진 예입니다. 저희도 이제 개인 필드가 어렴풋이 나타나는데 지난 5년 동안 private 에 대해 다시 한 번 감사했지만 혼란이 끊이지 않을 것입니다.

다시 말하지만, 데코레이터는 플래그 아래에서 사용할 수 있지만 이제 데코레이터가 실제로 3단계에 도달하므로 TypeScript에 대한 재구현 및 코드 손상이 필요합니다. 그렇기 때문에 이러한 일들은 _할 수 없는_ 것입니다.

async/await도 초기 단계에서 TypeScript에 도입되었습니다.

ECMAScript 제안이 3단계에 도달하면

아무도 잘못 행동하지 않지만 이 대화가 서클(깃발이 있었다면? 예 우리는 깃발을 알고 있음) 또는 주제에서 벗어나(TS가 JS가 되지 않는다면? 아니요 5년 후에도 우리는 변하지 않을 것입니다.) 그것에 대한 우리의 마음), 우리는 그것을 가질 필요가 없습니다. 우리는 약 3년 동안 ES 위원회가 의미 체계를 잠그면 정확히 이를 구현할 것이라고 말했습니다.

다시 한 번 제안 리포지토리는 https://github.com/tc39/proposal-optional-chaining 이며 진행 상황을 확인할 수 있습니다. 우리는 오프라인에서 작업하여 다음 TC39 회의에서 제안의 기회를 개선하기 위해 노력할 것입니다. 왜냐하면 이 회의도 통과되기를 정말로 원하기 때문입니다.

업데이트: 오늘 오후 TC39에서 스테이지 2에 도달했습니다!!!

선택적 연결은 3단계입니다.

기념 목적으로 만 이 잠금을 간단히 해제합니다.

만세!

스팸하지마세요...

감정을 표현하는 이모티콘을 보낼 수 있습니다.

스팸하지마세요...

감정을 표현하는 이모티콘을 보낼 수 있습니다.

게다가 이렇게 이모티콘 카운트가 올라가는 걸 보는 재미도 쏠쏠하다. 이슈 댓글이 이렇게 빨리 인기를 얻는 것을 본 적이 없습니다!

실시간 업데이트 영상을 작게 녹화했습니다 https://youtu.be/JLBrgPjeGhc

누군가 이 일을 구독 취소할 수 있습니까?

@DanielRosenwasser 농담이 아니거나 구독을 취소하고 싶지만 방법을 모르는 사람을 위해 오른쪽 사이드바에서 이 버튼을 찾고 있습니다.

이메일에 링크가 있다는 것은 말할 것도 없습니다.

_{농담이었습니다. 제안서를 작성 중입니다.}

이 문제를 잠금 해제한 후 @RyanCavanaugh :

이 땅을 드디어 보게 되어 정말 기쁩니다! 🎈 🎉

일치하는 VSCode 빠른 수정을 기다릴 수 없습니다 😆

@RyanCavanaugh는 아마도 이 스레드를 구독하지 않을 것이고 나는 무례하고 싶기 때문에 나는 @RyanCavanaugh 로 갈 것입니다! (그리고 좋은 측정을 위해 @DanielRosenwasser )

@kitsonk 바보 가 되지 마세요. 사람들은 자유롭게 구독을 취소하고 괴롭힘을 당하지 않습니다.

@kitsonk , RyanCavanaugh 또는 DanielRosenwasser가 이 스레드를 구독 취소하는 이유는 무엇입니까? Ryan이 이 문제의 잠금을 해제하고 Daniel이 귀하 위에 세 개의 댓글에 응답했습니다.

구독을 취소한 경우에도 스팸으로 알림 피로를 더 많이 유발할 필요가 없습니다.

분명히 GitHub는 냉소적인 유머를 위한 끔찍한 장소입니다.

이 새로운 언어 기능의 불쾌한 세부 사항을 알아낸 TC39의 챔피언에게 큰 감사를 드립니다!

내 생각에 @kitsonk 는 그저 농담을 하고 있었던 것 같아요. 마치 제가 그랬던 것처럼요. 우리가 흥분에 대해 약간 바보짓을 하고 있는 동안, 이것은 CoC에 따라 상황을 예의 바르게 유지하라는 부드러운 알림입니다.

@DanielRosenwasser
내가 이것을 시도해야 할 수 있습니까? 또는 @rbuckton 에는 또 다른 지점이 존재합니다 🙋🏻‍♂️

알겠습니다. https://github.com/microsoft/TypeScript/commits/optionalChainingStage1 🤦🏻‍♂️

예, 불행히도 그것은 상당히 구식입니다.

이 문제가 5년 전에 열렸습니다. :놀랐다:

@rbuckton

예, 불행히도 그것은 상당히 구식입니다.

내가 이것을 시도해 볼 수 있습니까?

@jhpratt @MatthiasKunnen 죄송합니다. GitHub에서 우리 모두가 동일한 컨텍스트를 공유하지 않는다는 사실을 잊었습니다. 나는 여기에서 오랫동안 여기저기 돌아다녔고 Ryan 및 Daniel IRL과 함께 시간을 보냈고 최근에 내가 오해한 내부 농담을 일으킨 이벤트에 잠시 참여했습니다. 사과.

이 전체 문제는 TypeScript의 디자인 원칙에 대한 흥미로운 고고학을 보여줍니다. Ryan은 TypeScript가 ECMAScript에서 심각하게 고려되기 이전의 구문을 실제로 고려했을 때 이 문제를 제기했습니다. TypeScript가 내부적으로 언어에 심각한 영향을 미치는 ES2015 구문을 예측하는 몇 가지 교훈을 배우고 있던 시기였습니다. 팀은 TC39 3단계 제안이 있을 때까지 포함을 고려하지 않기로 결정했습니다.

@RyanCavanaugh 가 이 문제를 해결할 수 있고 그가 제안으로 발생한 일에 가깝다는 것을 알고 있지만 팀이 2014년에 구현한 것이 현재 Stage 3 제안과 100% 호환되지 않았을 것이라고 생각합니다. . 따라서 확실히 축하할 일이지만 제안서의 동작과 완전히 일치하지 않는 안전한 탐색 연산자가 포함된 5년의 TypeScript 코드가 없다는 점에도 감사합니다.

🙏

Waiting for TC39 라벨 을 제거해야 하는 시점인가요? 🤔

Waiting for TC39 라벨 을 제거해야 하는 시점인가요? 🤔

추가 ship-it

와우

마침내. 말 그대로 옵셔널 체이닝 y'day에 대해 물어보고 있었고, 3단계가 언제일지 궁금해하고, bam! 그것을 통과하기 위해 노력한 모든 사람들에게 감사합니다!

이 스레드를 어떻게 음소거합니까? :)

@opnksyn 스팸성 흥분에 신경 쓰지 않는다면 이 문제가 종료되었을 때 알림을 받는 기능이 있습니다. 이렇게 하면 방금 작성한 것과 같은 알림에 모든 댓글이 표시되지 않습니다. 😄

이미 정의된 방출 솔루션이 있습니까?
다음과 같은 것이 흥미로울 수 있습니다.

function __chain<T extends object, U>(value: T|null|undefined, callback: (value: T) => U): U|undefined {
    if (value !== null && value !== undefined) {
        return callback(value);
    }

    return undefined;
}

type Foo = { x?: { y?: { z?: () => number } } }

const foo: Foo|null = { }

// foo?.x?.y?.z?()
const value = __chain(foo, _a => __chain(_a.x, _b => __chain(_b.y, _c => __chain(_c.z, _d => _d()))));

나는 불필요한 함수 범위를 생성하지 않기 때문에 Babel이 하는 것을 선호합니다:

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
    : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
    : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
    : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
    : _foo$x$y$z.call(_foo$x$y);

나는 불필요한 함수 범위를 생성하지 않기 때문에 Babel이 하는 것을 선호합니다:

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
  : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
  : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
  : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
  : _foo$x$y$z.call(_foo$x$y);

동의합니다, @ExE-Boss. 불필요한 함수 범위를 만드는 것을 피하는 것이 이상적이라고 생각합니다(컴파일된 코드가 약간 못생기더라도)

컴파일된 코드에 대해 이야기할 때 ES 사양에 대한 성능과 준수는 가독성보다 확실히 우위에 있어야 합니다.

Babel이 컴파일한 코드가 단순 == null 대신에 삼중 등호를 사용하여 null 및 void 0 모두와 비교되는 이유가 있습니까?

Babel이 컴파일한 코드가 단순 == null 대신에 삼중 등호를 사용하여 null 및 void 0 모두와 비교되는 이유가 있습니까?

@proteria 방금 __Babel__ 에 대한 선택적 연결 코드를 간단히 살펴보았습니다. loose 옵션 을 전달하고 진실한 값으로 설정 하면 엄격한 평등 검사를 생성하지 않는 것 같습니다.

이는 document.all (또는 현학적으로 말하면 [[IsHTMLDDA]] 내부 슬롯 ) 때문입니다. 이는 이전 버전과의 호환성을 위해 언어에서 특별한 대우를 받는 단점입니다.

document.all == null // true
document.all === null || document.all === undefined // false

선택적 연결 제안에서

document.all?.foo === document.all.foo

하지만 document.all == null ? void 0 : document.all.foo 는 void 0 를 잘못 반환합니다. 느슨한 모드에서는 대부분의 사람들이 document.all 를 처리할 필요가 없기 때문에 단순성/성능/생성된 코드 크기를 위해 사양의 이 세부 사항을 무시합니다.

확실히 document.all 케이스가 특별할 수 있습니까? 많은 추가 코드가 필요하지 않으며 개체와 속성을 확인하는 데 몇 줄만 있으면 됩니다.

document.all 를 변수에 할당할 수 있다는 점과 이것이 사용되는 위치를 추적하려면 유형 시스템이 필요하다는 점을 제외하고는 기본적으로 Babel이 다음과 같이 출력합니다.

(_prop = prop) === null || _prop === void 0 ? void 0 : _prop./* do stuff */;

나는 그것을 알고 있다. Babel에는 유형 시스템이 없지만 TypeScript에는 있습니다. 아마도 내가 말한 것처럼 간단하지 않을 수 있지만 사용을 추적할 수 있는 특정 상황에 대한 코드가 이미 있다고 상상합니다.

실제로 document.all 변수를 추적하기 위해 유형 시스템이 필요하지 않습니다. 특수 동작은 실제로 document.all 가 아니라 $ HTMLAllCollection 에 있기 때문입니다.

따라서 instanceof HTMLAllCollection 수표만 하면 금상첨화입니다.

예, 하지만... === null || === void 0 만 할 수 있는데 왜 instanceof 를 했을까요? 확실히 그게 더 간단합니다.

확실히 - document.all 를 추적하기 위해 유형 시스템이 필요하지 않다는 점을 지적한 것입니다. :)

개인적으로 나는 그것을 깨고 누가 불평하는지 보도록 말하고 싶지만 사양에 있으므로 그냥 고수하는 것이 가장 쉽습니다.

@noppa 컴파일 타임에 수행할 수 있습니다. foo instanceof HTMLAllCollection 가 true 이면 foo === null || foo === void 0 , 그렇지 않으면 foo == null _안전하게_ 방출할 수 있습니다.

@G-Rath 좋든 싫든, 더 이상 사용되지 않는다는 것이 작동하지 않아야 함을 의미하지는 않습니다. TypeScript는 JavaScript와 계속 호환되어야 합니다.

@jhpratt 하지만 이는 현재 TypeScript Design Non-Goals 에 위배됩니다.

또한 HTMLAllCollection 가 할당될 수 있는 모든 항목에 대해 foo === null || foo === void 0 를 수행해야 합니다. any 또는 object , 그래서 나는 그것이 정말로 가치가 있다고 생각하지 않습니다.

나는 당신이 목표가 아닌 것을 언급하고 있다고 생각합니다 (5)

프로그램에 런타임 유형 정보를 추가하거나 의존하거나 유형 시스템의 결과에 따라 다른 코드를 내보냅니다. 대신 런타임 메타데이터가 필요하지 않은 프로그래밍 패턴을 권장합니다.

물론 유형에 따라 다른 코드를 내보내는 데 동의하지만 코드 크기를 줄이기 위한 것일 뿐입니다. 지적했듯이 HTMLAllCollection 를 확인하는 것만큼 간단하지 않습니다.

공정하게 말해서, TS는 유형 정보를 사용하는 잠재적인 축소자를 거부했습니다. 이것은 (일종의) 관련이 있습니다 == null 를 내보내는 주된 이유는 유형 정보를 기반으로 코드 크기를 줄이는 것입니다.

이것이 구현되지 _않으면_ lang 팀이 Babel의 "loose" 옵션과 유사한 옵션을 tsconfig에 추가하면 좋을 것입니다.

신속하게 확인한 후 terser 는 자동으로 foo === null || foo === undefined 를 foo == null 로 변환합니다. 이는 이 극단적인 경우로 인해 안전하지 않습니다.

이것이 구현되지 않았다면 lang 팀이 Babel의 "loose" 옵션과 유사한 옵션을 tsconfig에 추가하면 좋을 것입니다.

이와 관련하여 우리 중 많은 사람들이 브라우저 제약에 대해 걱정할 필요가 없는 빌드 도구와 모바일 애플리케이션에 TypeScript를 사용합니다!

사실, 우리는 TS와 Babel을 함께 사용하므로 아마도 이러한 옵션 중 하나는 연산자를 Babel/기본 런타임으로 전달하는 것이어야 합니다!

@fbartho

사실, 우리는 TS와 Babel을 함께 사용하므로 아마도 이러한 옵션 중 하나는 연산자를 Babel/기본 런타임으로 전달하는 것이어야 합니다!

이 댓글이 이해가 안됩니다. 연산자를 Babel에 전달하기 위해 추가 옵션이 필요하지 않습니다. Babel용으로 TypeScript를 설정했다면 이미 noEmit: true 가 있고 이것은 이미 Babel로 _모든 것_을 전달합니다.

@Zarel Babel의 TypeScript 구현에는 네임스페이스 및 const 열거형을 포함하여 우리 코드베이스가 이미 의존하고 있던 몇 가지 기능이 누락되었습니다. 방출이 활성화된 TSC를 사용하고 두 번째 변환으로 Babel을 적용합니다. (우리는 네임스페이스를 제거하기 위해 노력하고 있지만 일치하지 않는 모든 기능을 제거할 수 있을지는 불확실합니다)

이 스레드에 오는 사람들은 초기 단계 3 발표 에서 시작하고 거기에서 시작하는 주석을 읽어야 합니다(모든 것을 로드하는 직접적인 방법 없이 수많은 사용자 콘텐츠를 숨긴 GitHub를 비난하세요)

훌륭한 기능 - "선택적 연결" / "안전한 탐색". 특히 TypeScript 엄격 모드에서. 이것이 곧 구현될 것이라는 소식을 듣게 되어 매우 기쁩니다. ❤️

이것은 저를 여기로 데려왔고 그것이 지원되기를 바랍니다. 그냥 사용 사례:

TypeScript 3.7에서 예상됩니다.

document.querySelector('html')?.setAttribute('lang', 'en');

VS

현재 TypeScript 3.5에 있습니다.

const htmlElement = document.querySelector('html');
if (htmlElement) {
  htmlElement.setAttribute('lang', 'en');
}

오류 없이 작동합니까? 아니면 여전히 TypeError: Cannot read property 'setAttribute' of null. 입니까? ? 작전. null / undefined 이후에 추가 체인을 취소해야 합니다.

class Test {
  it() {
    console.log('One');
    document.querySelector('html')?.setAttribute('lang', 'en');
    console.log('Two');
  }
}
new Test().it();

나는 다음을 기대한다:
html 요소가 존재하지 않는 경우(null). 콘솔은 One 및 Two 를 기록해야 하며 setAttribute 메서드는 호출되지 않습니다. (오류 없음).
제가 제대로 이해한건가요?

@domske 참고로 이것은 TS 기능이 아닙니다. JS 기능입니다.

TC39 제안 에 따르면 구문은 다음과 같습니다.

document.querySelector('html')?.setAttribute?.('lang', 'en');

토론이 다시 순환하기 시작하여 잠긴 상태로 돌아갑니다.

100개 이상의 긴 GitHub 스레드에 댓글을 남기고 싶어하는 사람이라면 누구나 먼저 이전 댓글을 모두 읽기로 약속합니다. 아마도 귀하의 질문과 그에 대한 답변이 그곳에 있을 것입니다!