내가 가장 좋아하는 제안 :( 요즘은 정말 this 무료 프로그램을 작성할 수 있습니다.

참고로 TC39 제안: https://github.com/tc39/proposal-pipeline-operator

제안이 아직 0단계가 아니라는 것은 아닙니다. 언어 의미 체계 및 기타 세부 사항에 추가되는 경우 변경될 수 있습니다.

이것은 내가 생각하기에 (Enum 및 모듈 시스템과 같은 오래된 제품을 제외하고) 처음이지만 이것을 구현하는 typescript가 더 많은 가시성을 제공하고 나머지 ecma 생태계에서 이에 대한 수요를 높일 수 있습니까?

https://vanslaars.io/post/create-pipe-function/...에서 영감을 얻은 누락된 파이프라인 연산자에 대한 해결 방법을 공유하고 싶었습니다

동기식 감소 기능이 있는 SyncPipe

// SyncPipe with synchronous reduction
type SyncPipeMapper<T, U> = (data: T | U) => U;
type SyncPipeReducer<T, U> = (f: SyncPipeMapper<T, U>, g: SyncPipeMapper<T, U>) => SyncPipeMapper<T, U>;
type SyncPipe<T, U> = (...fns: SyncPipeMapper<T, U>[]) => SyncPipeMapper<T, U>;
function createSyncPipe<T, U>(): SyncPipe<T, U> {
    const syncPipe: SyncPipeReducer<T, U> = (f: SyncPipeMapper<T, U>, g: SyncPipeMapper<T, U>) => (data: T) => g(f(data));
    return (...fns: SyncPipeMapper<T, U>[]): SyncPipeMapper<T, U> => fns.reduce(syncPipe);
}

// Example:
function testSyncPipe(num: number): number {
    const addOne: SyncPipeMapper<number, number> = (data: number): number => {
        return data + 1;
    }
    const syncPipe: SyncPipe<number, number> = createSyncPipe();
    const syncWaterfall: SyncPipeMapper<number, number> = syncPipe(
        addOne,
        addOne,
        addOne,
    );

    // Does the equivalent of num+3
    const lastnumber: number = syncWaterfall(num);
    return lastnumber;
}

비동기식 감소가 있는 AsyncPipe

// AsyncPipe with asynchronous reduction
type AsyncPipeMapper<T, U> = (data: T | U) => Promise<U>;
type AsyncPipeReducer<T, U> = (f: AsyncPipeMapper<T, U>, g: AsyncPipeMapper<T, U>) => AsyncPipeMapper<T, U>;
type AsyncPipe<T, U> = (...fns: AsyncPipeMapper<T, U>[]) => AsyncPipeMapper<T, U>;
function createAsyncPipe<T, U>(): AsyncPipe<T, U> {
    const asyncPipe: AsyncPipeReducer<T, U> = (f: AsyncPipeMapper<T, U>, g: AsyncPipeMapper<T, U>) => async (data: T) => g(await f(data));
    return (...fns: AsyncPipeMapper<T, U>[]): AsyncPipeMapper<T, U> => fns.reduce(asyncPipe);
}

// Example:
async function testAsyncPipe(num: number): Promise<number> {
    const addOne: AsyncPipeMapper<number, number> = async (data: number): Promise<number> => {
        return data + 1;
    }
    const asyncPipe: AsyncPipe<number, number> = createAsyncPipe();
    const asyncWaterfall: AsyncPipeMapper<number, number> = asyncPipe(
        addOne,
        addOne,
        addOne,
    );

    // Does the equivalent of num+3
    const lastnumber: number = await asyncWaterfall(num);
    return lastnumber;
}

비동기식 감소가 있는 파이프(단순화됨)

나는 이것을 가장 많이 사용합니다.

// Pipes with asynchronous reduction
type PipeMapper<T> = (data: T) => Promise<T>;
type PipeReducer<T> = (f: PipeMapper<T>, g: PipeMapper<T>) => PipeMapper<T>;
type Pipe<T> = (...fns: PipeMapper<T>[]) => PipeMapper<T>;
function createPipe<T>(): Pipe<T> {
    const pipePipe: PipeReducer<T> = (f: PipeMapper<T>, g: PipeMapper<T>) => async (data: T) => g(await f(data));
    return (...fns: PipeMapper<T>[]): PipeMapper<T> => fns.reduce(pipePipe);
}

// Example:
async function testPipe(num: number): Promise<number> {
    const addOne: PipeMapper<number> = async (data: number): Promise<number> => {
        return data + 1;
    }
    const pipe: Pipe<number> = createPipe();
    const waterfall: PipeMapper<number> = pipe(
        addOne,
        addOne,
        addOne,
    );
    // Does the equivalent of num+3
    const lastnumber: number = await waterfall(num);
    return lastnumber;
}

도움이 되셨기를 바랍니다.

@PublicParadise 너무 많은 상용구 :p

언어에서 이 연산자의 일부 변형을 확실히 보고 싶지만 현재 상태에서 ECMAScript의 두 가지 다른 제한에서 비롯된 필요성 인식이 필요합니다.

첫 번째는 언어로 해결하거나 해결하기가 매우 어렵습니다. 내장 객체를 위생적인 ​​방식으로 확장할 수 없다는 것입니다.

그러나 두 번째는 언어 수준 지원이 전혀 필요하지 않으며 실제로 수정될 수 있습니다. 표준 라이브러리는 친절하게 빈혈이라고 부를 수 있습니다.

최대 최소는 완전한 실패입니다.

언어로 Array.prototype.flatMap 를 얻는 데 몇 달, 몇 달이 걸리는 이유는 무엇입니까?

그것은 하나의 방법이고 처음부터 거기에 있어야 하고 추가되어야 하는 것이 분명해야 합니다.

아마도 Array.prototype 는 6년 안에 groupBy 방식을 갖게 될 것입니다.

이제 이것은 TC39 제안에 도움이 될 몇 가지 babel 구현을 가지고 있습니다.

• https://github.com/michaelmitchell/babel-plugin-pipe-composition
• https://github.com/miraks/babel-plugin-pipe-operator

지금 1단계에요

그렇다면 이 미인이 TS에 들어갈 가능성은? F#과 일치합니다. <3

예외가 있지만 제안이 TypeScript 및 유형에 _중요한 경우 제안은 일반적으로 TypeScript의 TC39 Stage 3 에 도달할 때까지 구현되지 않습니다. 이는 심각한 파손 및 회귀가 발생하지 않을 만큼 충분히 안정적이지 않기 때문입니다.

핵심 팀 중 어느 누구도 아직 이 문제에 대해 언급하지 않았지만 제 생각에는 3단계 이전에 구현을 위해 고려될 만큼 _중요하지 않을 것입니다. 가장 좋은 초점은 TC39에서 챔피언과 제안을 지원하는 것입니다.

TS에 이 연산자를 연결하여 플러그인이 있는 babel이 이를 처리할 수 있도록 하는 옵션만 있다면.
또는 post-css와 같은 자체 구문 플러그인이 있습니다. 기본 연산자를 기다리는 몇 년은 너무 많습니다.

@garkin : 여기서 문제는 TS가 이해하지 못하는 임의의 코드와 잘 결합되지 않는 형식 안전성을 제공하는 작업을 수행하기 위해 코드를 이해해야 한다는 것입니다. 매크로를 가져오지 않는 한(#4892), 이 경우 이해할 수 있는 코드로 컴파일됩니다. 그러나 표준 라이브러리의 상당수가 여전히 atm을 입력하기가 어렵기 때문에 로드맵에서는 아직 기대하지 않습니다.

이제 Babel이 타이프스크립트를 이해하므로 Babel을 통해 실행할 수 있습니다.
타이프스크립트

2017년 10월 26일 19시 1분에 "Tycho Grouwstra" [email protected]에서 다음과 같이 썼습니다.

@garkin https://github.com/garkin : 여기서 TS가 해야 할 과제는
유형 안전성을 제공하는 작업을 수행하기 위해 코드를 이해합니다.
이해하지 못하는 임의의 코드와 잘 결합됩니다. 얻는 것이 아니라면
매크로(#4892 https://github.com/Microsoft/TypeScript/issues/4892 ),
어떤 경우에는 이해하는 코드로 컴파일됩니다. 하지만 난하지 않을거야
로드맵에서는 아직 표준의 몇 비트가
라이브러리는 여전히 atm을 입력하기 어렵습니다.

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-339748284 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAZQTO6UiVHbrM6SRwaBhm8obaa3R7e9ks5swMkCgaJpZM4OzVEg
.

이제 Babel이 타이프스크립트를 이해하므로 Babel을 통해 실행할 수 있습니다.
타이프스크립트

그래도 빌드 시간은 두 배 :p

typescript가 Babel 플러그인이면 좋을 것입니다. 그럴 필요가 없습니다.
두 프로그램을 통해 파이프

2017년 10월 26일 20시 16분에 "AlexGalays" [email protected]이 다음과 같이 썼습니다.

이제 Babel이 타이프스크립트를 이해하므로 Babel을 통해 실행할 수 있습니다.
타이프스크립트

그래도 빌드 시간은 두 배 :p

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-339769856 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAZQTEArBw8jj0BcZFM2yLj5ErfbtNrgks5swNqagaJpZM4OzVEg
.

@graingert : 좋은 옵션입니다. 조사하겠습니다.
불행히도 VisualStudioCode, Webstorm 및 기타 IDE에서 사용되는 typescript Language Service API에서는 작동하지 않습니다.

"TS 플러그인"과 관련하여 예를 들어 TS 구문을 이해하고 명령문과 동일한 형식의 강력한 형식을 생성하는 파이프 연산자를 위한 간단한 (사전) 변환기를 사용하여 원하는 결과를 쉽게 얻을 수 있습니다. 유형 검사 등으로 잘 컴파일됩니다.

이에 대한 웹팩 구성은 다음과 같을 수 있습니다.

module: {
        rules: [
            { test: /\.ts$/, loader: 'ts-pipe-operator', enforce: 'pre' },
            { test: /\.ts$/, loader: 'ts-loader' },
            ...
        ]
 }

@garkin이 지적한 유일한 문제는 TS 서비스가 트랜스파일된 부분을 원본 소스 파일과 연관시킬 수 없다는 것입니다. 그러면 서비스를 사용하는 IDE가 이미 연산자를 인식하더라도 제대로 작동하지 않습니다(ES Next 구문 활성화 또는 기타).

소스 파일과 컴파일러에 제공되는 트랜스파일된 결과 사이에 적용할 누적 소스 맵을 지원하기 위해 TS 서비스에 대한 NFR(또는 이미 하나가 있을 수 있음)을 생성하면 이 플러그인과 다른 플러그인이 영향을 미치지 않고 가능할 것입니다. 나머지 커뮤니티와 가장 중요한 것은 핵심 팀이 처리해야 하는 복잡성을 추가하지 않는 것입니다.

또한 #13940이 이것과 얼마나 관련되어 있는지 말할 수 없지만 더 복잡한 플러그인을 향한 좋은 시작인 것 같습니다. 그러나 최소한의 (사전) 변환기는 대부분의 경우 프로젝트 컨텍스트가 필요하지 않기 때문에 소스 맵 접근 방식이 여전히 훨씬 간단한 대안인 것 같습니다. 명령문 원시 텍스트를 가져온 다음 제어 흐름이 트랜스파일된 부분에 대한 특정 I/O 유형을 암시할 수 있는 방식으로 다시 작성합니다.

마지막으로 이런 종류의 플러그인과 관련하여 _official_ 스레드(있는 경우)를 알려줄 수 있는 사람이 있습니까?

Flow+Babel 및 Post-CSS 특수 플러그인 올림픽보다 새로운 제안을 도입하는 차분한 방법과 모놀리식 Typescript 및 LessCSS 도구를 훨씬 더 선호합니다.

그것은 커스터마이징이 가능하고 단편화를 부추기는 대가로 새로운 기능을 얻는 속도와 전문 분야입니다.

파이프 오퍼레이터는 기능적 세계로 진입하는 마약과도 같아서 이상한 말을 하고 바라게 만든다.

따라서 #14419와 몇 가지 유용한 실용적인 의미가 이미 있습니다. ts-loader 와 통합하는 것이 어렵지 않아야 합니다.

tsconfig.json 변환기 통합(단순한 tsc 아닌 Language Service API) #14654가 _단기적으로_ 거부되었습니다.

11976은 Linting 전용 도구처럼 보이는 Language Service 플러그인에 대해 논의하고 있습니다.

16607은 이러한 플러그인을 변환기로 확장하는 것을 제안했습니다.

@PublicParadise 또는 lodash의 flow 또는 Rambda의 pipe ?

어쨌든, 이것은 TS에서 지원되는 것을 보는 것이 매우 굉장할 것입니다. 저는 JS가 지원하는 기능적 패턴(특히 TS의 유형 추론)을 좋아하지만 일부 패턴은 잘 읽히지 않습니다. RxJS 및 IxJS와 같은 대형 TS 라이브러리가 프로토타입 확장/상속보다 포인트 없는 기능 구성으로 이동하고 있기 때문에 이는 매우 클 것입니다. 이를 통해 트리 쉐이킹 및 사용자 정의 연산자 지원이 훨씬 향상됩니다.

@felixfbecker 당신은 ramda의 pipe 합니까? 다시 시도해야 하지만 역사적으로 ramda는 JS-first lib이므로 매우 동적이고 입력하기 어렵습니다(lodash와 같은). TS가 함수 반환 값에서 추론하는 데 많은 어려움을 겪었다는 사실 때문에 복합적입니다. 최근에 수정되었지만 확실하지 않음)
lodash 는 잘못 설계되어 하나의 큰 네임스페이스에 변경 가능한 기능과 변경할 수 없는 기능을 혼합하여 사용하지 않습니다.

당신의 기능과 사슬이 아주 이상하지 않다면 그것은 실제로 잘 작동합니다:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/b67c928904f03d0911c99ab938b14bc2e59cad40/types/lodash/index.d.ts#L7819 -L7855

당신의 기능과 사슬이 아주 훌륭하지 않다면 그것은 실제로 잘 작동합니다.

여기에서 '매우 미친 것이 아닙니다'라는 자격을 부여하겠습니다. 함수에 제네릭이 있으면 문제가 해결됩니다(https://github.com/types/npm-ramda/issues/86 참조), 예: R.pipe(R.identity) .

또한 제안이 Stage 1이라는 점을 분명히 합시다. 핵심 팀은 Stage 3 이전에 도입하는 것을 더욱 부끄러워하고 있습니다. 데코레이터도 그 예의 일부입니다. 비록 그것들이 _experimental_로 표시되어 있지만, 우리 모두는 계속해서 그 플래그를 활성화하고 그것들을 사용하여 우리의 모든 프로덕션 코드를 작성했습니다. 제안은 이제 반등했고 구문 및 의미 체계에 몇 가지 근본적인 주요 변경 사항이 있습니다. 이는 핵심 팀을 곤경에 빠뜨리는 코드를 리팩토링해야 한다는 것을 의미합니다. 모든 사람이 릴리스하는 날 구문이 손상되거나 레거시 항목을 유지하는 경우 컴파일러의 다른 변경 사항으로 인해 두 구문을 지원하는 것이 어려울 수 있으며 결국에는 이전 항목을 제거하고 싶지만 언제.. 💥 💥

따라서 이와 같은 표준 기반 기능을 사용하는 가장 좋은 방법은 여기서 TypeScript의 지원 또는 지원 부족에 대해 토론하는 것이 아니라 친근한 지역 TC39 담당자를 찾아 이 기능이 귀하에게 매우 중요하고 GitHub에서 위에 링크된 제안 대화. 시맨틱이 더 빨리 해결되고 3단계에 더 빨리 도달할수록 우리 모두가 더 빨리 좋은 것을 가질 수 있습니다!

이제 rxjs 에 lettable 연산자가 있으므로 Typescript에 있는 훨씬 더 멋진 기능이 될 것입니다.
https://github.com/ReactiveX/rxjs/blob/master/doc/lettable-operators.md

TS 팀의 누군가가 이 요청에 대해 설명해 줄 수 있습니까?

그들은 ES Next 및 Suggestion 태그를 지정했습니다 ... ES Next 제안에 대해 언급한 다른 위치와 이를 구현하는 시기 및 방법을 인용할 수 있습니다.

그들로부터의 코멘트는 아무것도 바꾸지 않을 것입니다. 그들이 커뮤니티에 알려지기를 기다리며 뒤에서 비밀리에 작업하고 있다고 생각하십니까? 추가할 사항이 없으면 문제에 대해 입력하지 않는 경우가 많습니다... 이미 말한 내용에 추가할 사항이 없습니다.

이 시점에서 나는 언어를 확장하는 플러그인을 갖는 것이 매우 유용할 것이라고 믿습니다. 언어 핵심의 일부가 아닌 기능을 추가하면 이러한 플러그인의 일부가 됩니다.

@aminpaks 나는 그것이 곧 babelification으로 이어질 수 있기 때문에 그 아이디어를 정말로 사랑하지 않습니다(바벨의 탑에서와 같이 우수한 트랜스파일러 Babeljs가 아니라 😀)

플러그인은 유형 수준 동작을 의미하므로 프로그램의 의미를 이해하기 어려워지고 소스 수준 종속성을 처리하려면 TypeScript에 현재 부족한 여러 복잡하지만 매우 유용한 기능이 필요합니다.

가능한 모든 곳에서 이것을 _사랑_ 하고 싶은 만큼 TS가 새로운 기능을 구현하고 표준을 고수하는 데 좀 더 유보적인 접근 방식을 취하고 있다는 사실이 기쁩니다. 이러한 입장은 표준에서 벗어나는 것에 깊은 관심을 갖고 있지만 브라우저 공급업체/JS 엔진 채택에 앞서(그러나 반드시 표준화보다 앞서는 것은 아님) 변환이 제공하는 고급 기능을 즐기는 나와 같은 사람들에게 TS를 전반적으로 더 매력적으로 만듭니다. 섬세한 균형을 잡는 동작입니다.

개인적으로 나는 bind-operator를 희생시키면서 파이프라인 연산자를 선호하지 않습니다. 가독성이 정말 중요합니다.

주어진:

function* where<T>(items: Iterable<T>, predicate: (item:T)=>boolean){
  for (let item of items){
    if(predicate(item)) yield item;
  }
}

바인딩 작업:

[1,2,3]::where(x=>x>2)

파이프라인 작업:

[1,2,3]|>(_)=>where(_,x=>x>2)

ts-team은 3단계까지 신경쓰지 않는 것이 맞습니다. 그리고 그때에도 3단계 제안은 여전히 ​​철회될 수 있습니다(예: SIMD). 플러그인을 가질 수 없다는 것은 유감입니다. "위험"은 개별 개발자에게 전가됩니다. 플러그인에 대한 다른 사용 사례도 많이 있으며, 특히 typescript가 포함된 .vue 파일과 같은 것을 지원합니다.

@MeirionHughes 동의합니다. 설탕을 전혀 사용하지 않는 것보다 파이프라인 연산자를 사용하는 것을 선호하지만 함수가 자동으로 수정되고 이를 활용하여 라이브러리가 구축되는 언어에서 영감을 받았습니다. 또한 파이프라인 메서드가 파이프라인 값의 _not_ 구성원이라고 가정합니다.

그럼 당신은

function where<T>(predicate: (item: T) => boolean): (items: Itererable<T>) => Itererable<T> {
  return function* () {
    for (const item of items) if (predicate(item)) yield item;
  };
}

function select<T, R>(projection: (item: T) => R): (items: Itererable<T>) => Itererable<R> {
  return function* () {
    for (const item of items) yield projection(item);
  };
}

그리고 당신은 쓸 것입니다

[1, 2, 3] |> where(x => x > 2) |> select(x => x ** 2);

그러나 JavaScript는 자동 커리 기능을 하지 않으며 할 수도 없기 때문에 커링을 염두에 두고 설계된 라이브러리에서만 잘 작동하는 것 같습니다.

나는 이것에 대해 오해할 수 있습니다. 저는 제안에 대해 최신 정보가 아닙니다.

그러면 기본적으로 커리 유틸리티 기능을 제공하는 새 라이브러리가 새 표준이 될 수 있습니다.

@AlexGalays 이것이 통과하면 그럴 가능성이 있다고 생각합니다. JavaScript를 OCaml로 바꾸려는 파괴적인 음모의 일부가 아닌 한 모든 것이 잘 됩니다.

@MeirionHughes 귀하의 예가 정확하지 않습니다. where 함수는 this 를 전혀 사용하지 않으므로 bind 연산자가 작동하지 않습니다. 바인드 연산자는 또한 형식 안전성에 대해 많은 미해결 질문을 가지고 있습니다. where 는 클래스 메서드처럼 this 에서 개인 속성에 액세스할 수 있습니까? 그렇지 않다면 this 를 사용하는 요점은 무엇입니까? 그렇다면 사유 재산을 변경하는 것은 갑자기 사유 재산의 목적을 완전히 무너뜨리는 엄청난 변화입니다.
또한 구문이 읽기 어렵다고 명시하지만 예를 들어 bind-operator 예제에서는 괄호를 생략하지만 파이프라인 예제에서는 불필요한 괄호를 추가합니다. 그리고 파이프라인 연산자는 물론 바인딩용으로 작성된 함수에서는 전혀 작동하지 않지만 rxjs 연산자, ramda 또는 lodash/fp와 같은 커리 함수에는 잘 작동합니다.

@aluanhaddad 모든 fp 라이브러리 외에도 RxJS는 프로토타입의 연산자(대부분 트리 흔들기 및 일반 유형 안전과 관련된 많은 문제가 있음)에서 커리 함수로서의 연산자로 이동한 널리 사용되는 라이브러리의 예입니다. 대부분의 라이브러리는 아마도 지금 당장은 그런 식으로 선택하지 않을 것입니다. 왜냐하면 우리는 이에 대한 좋은 구문을 가지고 있지 않기 때문입니다.

@felixfbecker 당신이 옳았고 파이프로 연결되는 결과 함수를 중첩하는 @aluanhaddad 의 예가 내 마음을 완전히 바꿨습니다.

파이프라인 지원을 조금 더 일찍 받기 위해 사용자 지정 변환기를 생각했거나 구현하고 있는 사람이 있습니까? 겉보기에는 단순히 babel transpile _just_ 파이프라인 부분 자체가 있는 사용자 지정 변환기를 통해 수행할 수 있습니다. 그런 다음 https://github.com/cevek/ttypescript 를 통해 실행할 수

가능성이 있습니까? 사용자 정의 변환을 사용하여 TypeScript 도구와 같은 작업을 유지하면서 Babel 지원 지원 구문을 사용하시겠습니까?

아마도? 0-2개의 제안만 처리하는 사전 설정이 있습니다: https://www.npmjs.com/package/babel-preset-proposal-typescript - 타이프스크립트로 보내기 전에 이것을 넣어야 함을 의미합니다. 당신은 intellisense하지만 아마도 지루할 것입니다. 그러나 https://github.com/cevek/ttypescript#visual -studio-code를 사용하면 문제를 해결할 수 있습니다.

@MeirionHughes 도움이 되었다니 기쁘네요 ❤️.
이제 임의 프로토타입의 메서드를 커리 함수로 변환할 수 있도록 #6606만 필요합니다!

TypeScript는 이제 babel 변환입니다. TypeScript가 통과하기 전에 파이프라인에서 디슈가링을 시퀀스하는 방법이 있어야 한다고 생각합니다. 그래도 언어 서버에서 어떻게 작동하는지 모르겠습니다.

TS #22816에 대한 자체 호스팅 구현을 추가했습니다.

파이프라인 연산자를 추진하는 사람 중 한 사람으로서 간청합니다. 더 발전할 때까지 TypeScript에서 이것을 구현하지 _마십시오_. 우리는 여전히 근본적으로 서로 호환되지 않는 두 가지 잠재적인 제안에 대해 토론하고 있으므로 TypeScript는 이것을 너무 일찍 구현하면 세계에 고통을 호소하고 있습니다.

이 제안에 관심이 있다면 여기에서 리포지토리를 살펴보고 참여하십시오. https://github.com/tc39/proposal-pipeline-operator/ 피드백을 환영합니다! 그리고 우리는 다양한 제안에 대해 Babel 플러그인을 작업 중이므로 (TypeScript가 아닌) 프로젝트에서 시도해 볼 기회가 있을 것입니다.

그러나 제안은 아직 TypeScript와 같은 것에 착륙할 준비가 되지 않았습니다.

우리는 확실히이 병합 아닙니다.

https://github.com/babel/babel-eslint 와 같이 Babel에서 지원하는 기능을 계속 사용할 수 있고 TypeScript에서 지원하지 않는 기능이 제거된 후에도 유형 검사가 작동하도록 할 수 있습니까?

@masaeedu 네! 이것

@MeirionHughes 부분 적용 제안으로 더 쉬워집니다.

[1,2,3] |> where(?, x=>x>2)

@bernatmv : fwiw 오늘날 작동하는 것과 가까운 것이 있습니다.

@tycho01 하지만 TypeScript에는 없고 2.8개의 타이핑을 얻을 때까지: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/25067

@jeremejevs @bernatmv 실제로 R.__ 는 npm-ramda 에서 codegen을 사용하여 입력되었습니다. 2.8을 사용하는 더 나은 방법 환영합니다!

저는 Javascript와 TypeScript(2주)에 다소 익숙하지 않으므로 더 간단한 솔루션이 있다면 저를 용서해 주십시오. 그러나 아래는 파이프라인 운영자가 없을 때 생각해 낸 것입니다. 원래 2, 3, 4 등의 유형 매개변수와 함께 작동하는 pipe 의 여러 오버로드를 시도했지만 C#에서와 같이 TypeScript 오버로드 해결이 작동하도록 하는 방법을 알아낼 수 없었습니다. pipe1<A,B> , pipe2<A,B,C> , pipe3<A,B,C,D> 다른 함수를 사용할 수 있지만 인수의 수에 따라 함수 이름을 선택해야 하므로 작업하기가 어렵습니다. 원했다. 아래에서 제안한 것보다 더 간단한 유형 안전 솔루션이 있습니까? 무제한의 매개변수를 허용할 수 있는 재귀 유형 정의가 있습니까? 조건 유형을 올바르게 사용하고 있습니까?

type LastOf<
    A,
    B=never,
    C=never,
    D=never,
    E=never,
    F=never,
    G=never,
    H=never,
    I=never,
    J=never> =
    [B] extends [never] ? A :
    [C] extends [never] ? B :
    [D] extends [never] ? C :
    [E] extends [never] ? D :
    [F] extends [never] ? E :
    [G] extends [never] ? F :
    [H] extends [never] ? G :
    [I] extends [never] ? H :
    [J] extends [never] ? I :
    J;

export function pipe<A, B, C=never, D=never, E=never, F=never, G=never, H=never, I=never, J=never>(
    a: A,
    mapA: (a: A) => B,
    mapB?: (b: B) => C,
    mapC?: (c: C) => D,
    mapD?: (d: D) => E,
    mapE?: (e: E) => F,
    mapF?: (f: F) => G,
    mapG?: (g: G) => H,
    mapH?: (h: H) => I,
    mapI?: (i: I) => J
): LastOf<A, B, C, D, E, F, G, H, I, J> {
    if (mapB === undefined) {
        return mapA(a) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapC === undefined) {
        return mapB(mapA(a)) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapD === undefined) {
        return mapC(mapB(mapA(a))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapE === undefined) {
        return mapD(mapC(mapB(mapA(a)))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapF === undefined) {
        return mapE(mapD(mapC(mapB(mapA(a))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapG === undefined) {
        return mapF(mapE(mapD(mapC(mapB(mapA(a)))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapH === undefined) {
        return mapG(mapF(mapE(mapD(mapC(mapB(mapA(a))))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapI === undefined) {
        return mapH(mapG(mapF(mapE(mapD(mapC(mapB(mapA(a)))))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    return mapI(mapH(mapG(mapF(mapE(mapD(mapC(mapB(mapA(a))))))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
}

test("map once", () => {
    const result = pipe(
        2,
        i => i * 10);
    expect(result).toBe(20);
});

test("map twice", () => {
    const result = pipe(
        2,
        i => i * 10,
        i => `the answer is ${i}`);
    expect(result).toBe('the answer is 20');
});

test("map three times", () => {
    const result = pipe(
        2,
        i => i * 10,
        i => -i,
        i => ({ a: i, b: -i }));
    expect(result).toEqual({ a: -20, b: 20 });
});

나는 lodash/fp의 _.flow가 이미 이것을 입력했다고 생각했습니다.

2018년 5월 9일 수요일 22:19 jmagaram에서 알림 @github.com이 다음과 같이 썼습니다.

저는 Javascript와 TypeScript(2주)에 다소 익숙하지 않으므로 양해해 주십시오.
더 간단한 솔루션이 있다면 나. 하지만 아래는 내가 나온 것입니다
파이프라인 운영자가 없는 경우. 나는 원래 가지고 시도
2, 3, 4 등 유형에서 작동하는 파이프의 다중 과부하
매개변수가 있지만 TypeScript 오버로드를 가져오는 방법을 알 수 없습니다.
C#에서와 같이 작동하는 해상도. 우리는 다른 기능을 가질 수 있습니다
pipe1 , pipe2 및 pipe3 하지만 이것은 얼마나 많은 수에 따라 함수 이름을 선택해야 하므로당신이 원하는 주장.
허용할 수 있는 재귀 유형 정의가 있습니까?매개변수의 무제한?

유형 LastOf = [B] 확장 [결코] ?
나 :[D] 확장 [결코] ?
디 :[F] 확장 [결코] ?

기능 파이프 ( 에이: 아,mapA: (a: A) => B,mapB?: (b: B) => C,mapC?: (c: C) => D,mapD?: (d: D) => E,mapE?: (e: E) => F): LastOf { const b = mapA(a);스위치(mapB) {정의되지 않은 경우: b를 LastOf로 반환 ; 기본: {const c = mapB(b);스위치(mapC) {정의되지 않은 경우: c를 LastOf로 반환 ; 기본: {const d = mapC(c);스위치(mapD) {정의되지 않은 경우: d를 LastOf로 반환 ; 기본: {const e = mapD(d);스위치(mapE) {정의되지 않은 경우: e를 LastOf로 반환 ;기본값: MapE(e)를 LastOf로 반환 ; }}}}}}}}

test("한 번 매핑", () => {
const 결과 = 파이프(
2,
나는 => 나는 * 10);
기대(결과).toBe(20);
});

test("두 번 매핑", () => {
const 결과 = 파이프(
2,
나는 => 나는 * 10,
나는 => the answer is ${i} );
기대(결과).toBe('답은 20입니다');
});

test("세 번 매핑", () => {
const 결과 = 파이프(
2,
나는 => 나는 * 10,
나는 => -나,
나는 => ({ a: 나는, b: -i }));
기대(결과).toEqual({ a: -20, b: 20 });
});

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

나는 방금 lodash를 보았고 당신이 맞습니다. 흐름 함수는 많은 매개변수를 받아들이고 강력한 형식을 갖습니다. 순수한 TypeScript에서 수행되는 것처럼 보이지 않습니다. 모든 오버로드에 대해 형식 정의 파일을 사용합니다. 이것이 TypeScript에서 모든 작업을 수행하는 것보다 나은지 나쁜지 잘 모르겠습니다.

@jmagaram all TS는 일반적으로 추론으로 인해 더 쉽게 만들지만 작동하면 작동합니다.

@jmagaram 다소 단순한 순수 typescript 대안은 다음과 같을 수 있습니다.

interface IPipe<T> {
    readonly value: () => T;
    chain<R>(fn: (x: T) => R): IPipe<R>;
}

function pipe<T>(val: T): IPipe<T> {
    return {
        chain: fn => pipe(fn(val)),
        value: () => val
    };
}

사용법은 여전히 ​​매우 깨끗하고 강력한 형식입니다.

pipe(["Hello", "There"])
    .chain(map(x => `${x}!`))
    .chain(xs => {
        ...
    })
    .value()

사용자 지정 연산자를 추가할 수 있는 기능에 정말 감사드립니다. F#에는 이에 대한 좋은 접근 방식이 있습니다.

그 동안 다음은 래핑 없이 더 간단한 접근 방식입니다.

function pipe<T1>(first:T1):T1
function pipe<T1, T2>(first:T1, second:(a:T1) => T2):T2
function pipe<T1, T2, T3>(first:T1, second:(a:T1) => T2, third:(a:T2) => T3):T3
function pipe<T1, T2, T3, T4>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4):T4
function pipe<T1, T2, T3, T4, T5>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5):T5
function pipe<T1, T2, T3, T4, T5, T6>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6):T6
function pipe<T1, T2, T3, T4, T5, T6, T7>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7):T7
function pipe<T1, T2, T3, T4, T5, T6, T7, T8>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7, eigth:(a:T7)=>T8):T8
function pipe<T1, T2, T3, T4, T5, T6, T7, T8, T9>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7, eigth:(a:T7)=>T8, ninth:(a:T8)=>T9):T9
function pipe<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7, eigth:(a:T7)=>T8, ninth:(a:T8)=>T9, tenth:(a:T9)=>T10):T10
function pipe(first:any, ...args:Function[]):any {
    return (
        args && args.length 
        ? args.reduce(
            (result, next) => next(result),
            first instanceof Function ? first() : first
        )
        : first instanceof Function ? first() : first
    );
}

이것은 다음을 제공합니다.

( 자세한 내용은 여기를 참조하십시오 )

즉, @graingert +1 맞습니다. lodash는 이미 구성을 위해 이것을 가지고 있습니다(파이프는 아님):

const getUpperName = 
   _.flow(
      (p: Person) => `${p.FirstName} ${p.LastName}`,
      (s: string) => s.toUpper()
   )

또는 대신 Object.prototype에 파이프를 추가할 수 있습니다.

Object.prototype.pipe = function<Self, Result>(this:Self, next:(value:Self) => Result):Result {
    return next(this)
}

대신 다음을 허용합니다.

( 자세한 내용은 여기를 참조하십시오 )

이것이 다른 사람들을 돕기를 바랍니다!

--enable-pipeline-operator 컴파일 플래그로 Firefox에 도착했습니다.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Pipeline_operator

몰락한 영웅을 위한 1분간의 침묵, 바인드 연산자 :: , 사악한 |> 위해 닫혔습니다 😢

글쎄, 나는 |> 선호하기 때문에 보는 사람의 눈에 있다고 생각합니다 :D

왕 만세!

그리고 여기에서 나는 그것이 헛된 꿈이라고 생각했습니다.

파이프라인은 본질적으로 Identity Monad의 간단한 사용 사례입니다. 또한 pipe 는 일반적으로 반대로 compose 반면 pipeline 는 즉시 호출되는 pipe 에 가깝습니다.

어쨌든 Typescript에서 이것을 볼 수 있기를 기대합니다.

파이프라인이 있으면 도움이 되지만 컴파일러 변환기를 통해 사용자 지정 연산자(이름에 특수 문자가 포함될 수 있고 첫 번째 매개변수가 왼쪽에 있는 함수)를 정의하는 기능을 제공하는 것이 가능할 것이라고 생각합니다. 저와 함께 이 작업을 시도하는 데 관심이 있거나 이에 대한 배경 지식이 있는 사람이 있습니까?

2018년 8월 10일 금요일 02:53 Babak [email protected]에서 다음과 같이 썼습니다.

파이프라인은 본질적으로 Identity Monad의 간단한 사용 사례입니다. 또한,
파이프는 일반적으로 역으로 구성되는 반면 파이프라인은 파이프와 비슷합니다.
바로 호출됩니다.

어쨌든 Typescript에서 이것을 볼 수 있기를 기대합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-411824741 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFXUx5rwM9wVrpAkHK2BNYkyy74HtWU5ks5uPGkNgaJpZM4OzVEg
.

--

중위 함수 ftw

2018년 8월 9일 목요일, 23:35 Ben Beattie-Hood, [email protected]
썼다:

파이프라인이 있으면 도움이 될 수 있지만
사용자 정의 연산자(이름이
특수 문자를 포함하고 첫 번째 매개변수가 왼쪽에 있음)
컴파일러 변환기. 저와 함께 시도하는 데 관심이 있거나
이것에 대한 약간의 배경?

2018년 8월 10일 금요일 02:53 Babak [email protected]에서 다음과 같이 썼습니다.

파이프라인은 본질적으로 Identity Monad의 간단한 사용 사례입니다. 또한,
파이프는 일반적으로 역으로 구성되는 반면 파이프라인은 파이프와 비슷합니다.
바로 호출됩니다.

어쨌든 Typescript에서 이것을 볼 수 있기를 기대합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment -411824741
,
또는 스레드 음소거
<
https://github.com/notifications/unsubscribe-auth/AFXUx5rwM9wVrpAkHK2BNYkyy74HtWU5ks5uPGkNgaJpZM4OzVEg

.

--

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

typescript에 대한 중위 함수에 대한 아이디어는 거의 typescript만큼 오래되었습니다. https://github.com/Microsoft/TypeScript/issues/2319

많은 사람들이 이것을 정말 원하지 않는다는 것을 알고 있지만 TypeScript는 3단계가 아닌 한 추가 연산자를 구현해서는 안 된다고 생각합니다. 상황은 바뀔 수 있으며 물론 몇 가지 예외가 있습니다.

커뮤니티에서 아이디어를 탐색하고 인기도를 측정할 수 있도록 컴파일러 변환기로 시도해 볼 가치가 있다고 생각합니다. 다른 함수형 언어에서는 잘 정의된 기능이므로 탐색하는 것이 안전할 수 있습니다.

@BenBeattieHood 우리는 이것을 babel에서 구현하는 중이므로 거기에서 테스트할 수 있습니다. 컴파일러 변환기에서 테스트한다면 우리가 고려하고 있는 파이프라인 연산자의 몇 가지 형태가 있으므로 현재 제안을 확실히 살펴보십시오.

나는 그것이 어떻게 사용되는지에 대해 많은 생각이 필요할 것이라고 생각합니다. 특히 다음과 같은 타이핑과 관련하여:

function where<T>(predicate: (x: T) => boolean) {
  return function* (items: Iterable<T>): Iterable<T> {
    for (const item of items) {
      if (predicate(item)) {
        yield item;
      }
    }
  };
}

[1, 2, 3] |> where(x=>x> 1)

현재 where(x => x > 1)([1,2,3]) x가 무엇인지 추론할 수 없습니다. 위의 내용은 :: op가 승리하기를 바랐던 한 가지 이유입니다. 왜냐하면 (언뜻 보기에는) typescript가 this 가 무엇인지 추론하는 것이 훨씬 더 쉬워 보이기 때문입니다.

또는 다른 방식으로 볼 수도 있습니다. 출시되면 TS가 가지고 있는 추론 문제 중 일부를 우선적으로 처리합니다 👍

사양 및 babel 뉴스를 팔로우하면 사양이 아직 설정되지 않았습니다. 2개의 제안이 있습니다. 사양이 확정되면 타이프스크립트 팀에서 지원을 추가할 것이라고 확신합니다.

중위 함수 ftw

iirc JS는 이러한 "메소드"를 호출합니다.

iirc JS는 이러한 "메서드"를 호출합니다.

@tycho01 당신의 의견은 아마도 뺨을

@BenBeattieHood 우리는 이것을 babel에서 구현하는 중이므로 거기에서 테스트할 수 있습니다. 컴파일러 변환기에서 테스트한다면 우리가 고려하고 있는 파이프라인 연산자의 몇 가지 형태가 있으므로 현재 제안을 확실히 살펴보십시오.

Babel 파서는 이제 스마트 파이프라인 제안을 지원합니다.

https://github.com/babel/babel/pull/8289

업데이트가 있습니까?

업데이트가 있습니까?

🤦‍♂️ TypeScript는 3단계에 도달할 때까지 제안을 구현하지 않습니다. 파이프라인 운영자 는 현재 1단계이며 심각한 문제가 있습니다. 해당 정보는 이 스레드에서 여러 번 제공되었습니다.

심각한 문제의 예를 들어 주시겠습니까?

아마도...

⚠ 경고: 파이프라인 구문의 세부 사항은 현재 불안정합니다. 고려 중인 두 개의 경쟁 제안이 있습니다.

네, 그것이 제가 심각한 문제라고 생각하는 것입니다.

Waiting for TC39 상태의 모든 스레드가 원을 그리며 이동하는 경향이 있으므로 이 스레드를 잠그려고 합니다.

핑!