Cucumber-js: 기능 요청: `this` 키워드를 사용하지 않는 UI

나는 그것이 당신이 항상 world 를 인수로 받아들인다는 것을 의미하며 그것이 API 변경이라는 것에 동의합니다.
--ui exports 및 --ui tdd 및 --ui bdd 가 있는 모카와 마찬가지로 큐큐도 가능합니다.
기본적으로 단계가 세계에서 호출/적용되는지 또는 첫 번째 인수로 수락하는지 결정하는 프로젝트 변수입니다.

나는 이것이 장기적으로 가치가 있다고 생각하지 않습니다. 예, => 를 사용할 수 없는 1줄 단계에 좋습니다. 제 경험상 이런 단계는 거의 없었습니다. ES6에 컨텍스트를 유지하지 않는 화살표 기능이 포함되어 있지 않다는 사실에 놀랐습니다.

이것은 또한 모든 비동기 작업에서 .bind(this) 을 멍 때리는 것을 없애거나 원하는 경우 var that = this 로 멍키를 제거합니다.

이것을 피하기 위해 단계 정의 안에 굵은 화살표를 사용할 수 없습니까?

또 하나의 이점(IMHO) - 사람들이 세계에 대한 상속 트리에서 벗어나 JS의 더 나은 기능을 더 잘 지향하도록 도와줍니다.

이것을 좀 더 설명해 주시겠습니까? / 예를 들어 주시겠습니까?

간단히 말해서, 저는 컨텍스트를 클래스로 표현하는 방식을 기피하는 프로그래머 학교에 속해 있습니다. 더 많은 사람들이 OOP의 어두운 면에 노출될수록 이 학교는 더 커집니다. 화살표 기능이 컨텍스트를 유지 하지 못하도록 막는 JS 커뮤니티의 움직임은 이 움직임의 강점을 보여주는 한 예입니다.

종교적인 논쟁에 끼어들지 않고 - 난 그냥 라이브를 믿고 라이브하자, 당신은 수업을 사용하고 싶어? 엄청난. 저를 강제하지 마십시오 :-)

제 일반적인 느낌은 작은 변화가 될 수 있다는 것입니다. 가장 잘 수행될 수 있다고 생각하는 일반적인 방향을 알려주시면 기꺼이 할게요 ;-)

단계를 정의할 때 클래스가 아니라 함수를 정의하므로 논리적으로 this 는 그 자리에 없습니다.

이것이 OOP 패러다임이 아닌 FP 패러다임의 상황이라고 생각합니다.

@osher 나는 @charlierudolph 가 당신에게 클래스를 사용하도록 강요하고 싶지 않다는 의심의 이점을 줄 수 있다고 생각합니다. 즉, 실질적인 이점을 제공하지 않는 한 이 패키지를 사용하는 모든 곳에서 API 변경 사항을 강제로 통합(중단)해서는 안 됩니다.

@charlierudolph 내 생각에 "JS의 더 나은 능력" @osher 는 FP, Functional Programming을 의미합니다.

IMHO 이 변경은 단계 정의를 조금 더 간단하고 논리적으로 만들 것입니다. 기본적으로 다음 줄을 제거합니다. const thisWorldNotThisStep = this

모든 비동기 함수에 대해 .bind(this) 를 사용할 필요가 없으며 단계 정의 내에서 화살표 함수를 사용하는 한 const self = this 패턴을 사용할 필요가 없습니다.

문제(큰 문제는 아님)는 단계 정의 내에서 this 가 단계가 아니라 세계를 참조한다는 것입니다. 이는 직관적이지 않습니다.

괜찮아. 모든 사람이 함수형 프로그래머는 아니지만 브레이킹 체인지 도입을 방지하기 위해 세계를 첫 번째 매개변수로 전달하는 옵션을 만드는 것에 대해 어떻게 생각하시나요?

defineSupportCode(({setWorldInjectionStrategy}) => {
  setWorldInjectionStrategy('this') // default
  setWorldInjectionStrategy('argument') // makes world be the first argument to steps and hooks 
})

나는 세계/컨텍스트를 주입한다는 아이디어에 전적으로 동의합니다. 단계의 매개변수가 있습니다. 이 프로젝트를 시작으로 모든 JS 생태계는 ES6에서 허용하는 새로운 기능을 완전히 수용하도록 움직이고 있으며 이는 좋은 일입니다 ❤️

Express나 Koa와 같은 다른 도구를 보면 현재 요청 컨텍스트를 this 로 설정하고 미들웨어의 첫 번째 매개변수로 설정합니다(오이 단계와 동일). 이 솔루션은 기능의 전통적인 사용과 ES6 화살표 기능의 사용을 허용합니다.
첫 번째 매개변수로서의 컨텍스트의 또 다른 이점은 다음과 같습니다.

@charlierudolph가 제안한 솔루션의 경우 이것이 장기적으로 작동할 수 있다고 생각하지 않습니다. 이렇게 하면 커뮤니티가 둘로 나뉩니다. 모든 오이 예제는 모든 설치에서 작동하지 않으며 문서는 두 개로 복제됩니다. 멋지지 않습니다.

브레이킹 체인지 걱정은 모르겠지만 v2는 이런 종류의 변경을 소개하기에 완벽한 시기입니다. 기다림은 다른 전공을 만들거나 기다리게 할 것입니다.

Before 및 After 를 world 주입하도록 변경하는 것은 어떻습니까?

defineSupportCode(function({After, Before, Given}) {
  let world;

  // Asynchronous Callback
  Before(function (w, scenarioResult, callback) {
    world = w;
    callback();
  });
  After(function (world, scenarioResult, callback) {
    callback();
  });

  Given('I access the world', () => {
    assert(world); // Yay!
  });
});

그런 식으로 before 단계에서 world 변수를 캡처할 수 있습니다. 각 단계 정의를 엉망으로 만들지 않습니다.

다음으로 기존 작업 방식을 유지하면서 deprecated 메시지를 생성합니다. 또는 그렇게 하지 않더라도 해당 접근 방식을 사용하고 자신이 무엇을 하고 있는지 알고 싶은 사람들을 위해 옵션을 남겨두십시오.

온라인에서 발견된 스니펫의 호환성에 대한 논쟁이 설득력 있는 논쟁이 될까봐 두렵습니다.

--ui 플래그 또는 setWorldInjectionStrategy('argument') 가 있더라도 모든 온라인 토론과 그러한 변경에 적합한 소란을 제공하는 주요 버전의 브레이킹 체인지로 더 잘 전달되는 문제가 됩니다. 혼란을 없애는 데 도움이 됩니다.

그래서 나는 cuke의 다음 버전에서 그것을 하는 것에 투표하고, 그것이 릴리스될 때까지 ...makedoing합니다.

카나리아 버전 또는 숨겨진 플래그는 초기에 사용하고 피드백할 멋진 프로모션이 될 것입니다.

대체 FP 인터페이스를 공개하고 싶습니다.

다음은 어떻습니까? (약속 친화적임을 설명하기 위해 async/await 사용)

import {initialize, Given, Before} from 'cucumber/fn'

// specify a function that returns the initial context:
initialize(async () => ({ a: 42 }))

Before({ timeout: 10 }, async (ctx) => {
  await doStuff(ctx.a)
})

Given(/^a step passes with {number}$/, async (ctx, number) => {
  const newA = await computeStuff(ctx.a, number)
  // tell cucumber about the new context:
  return Object.assign({}, ctx, { a: newA })
})

기능적 단계 정의를 제공하는 오이 -fp를 함께 해킹했습니다. 이미 몇 가지 개선 아이디어가 있습니다. 피드백 환영합니다!

나는 우리가 이 문제를 닫고 사람들이 그 작은 라이브러리를 실험하도록 제안합니다. 언젠가 우리는 그것을 Cucumber.js로 가져올 수 있을 것입니다.

@jbpros 테스트에서 화살표 기능을 사용할 수 있도록 또 다른 종속성을 설치하지 않는 것이 좋습니다.

이것은 실제로 모든 사람이 스스로 구현하는 것이 매우 간단해야 합니다. 다음 코드 스니펫은 사용할 수 없게 만드는 큰 경고와 함께 (기능적으로) 매우 잘 작동합니다.

// Don't rely on `this` in step definitions. It's 2021 for crying out loud.
const definitionFunctionWrapper = (fn) =>
    function(...args) {
        return fn(...args.slice(0, -1), this);
    }

모든 단일 단계 정의라는 경고는 이제 추가 매개변수로 인해 다음 오류를 기록합니다.

    Error: function uses multiple asynchronous interfaces: callback and promise
       to use the callback interface: do not return a promise
       to use the promise interface: remove the last argument to the function

이 문제를 해결하기 위해 추가 매개변수를 추가하려고 하면

function has 3 arguments, should have 1 (if synchronous or returning a promise) or 2 (if accepting a callback)

오이-js가 필요로 하는 모든 것은 함수 인수 검사를 비활성화하는 옵션이며 이 문제는 사라질 것입니다. 실제로 두 번째 생각에 오이는 단계 정의 함수의 인수 수에 따라 콜백이 필요하다고 가정하기 때문에 테스트 시간이 초과되는 것처럼 보입니다. 그러나 반환된 약속에 우선 순위를 부여하면 이 문제를 해결할 수 있습니다.

@andyearnshaw 귀하의 의견에 감사드립니다. "stepdef의 화살표 기능에 대한" 종속성에 대한 귀하의 우려를 들었습니다. 이 라이브러리는 기본적으로 상태 비저장 단계 정의를 얻기 위해 개인적으로 사용하는 솔루션입니다. 관심 있는 사람을 위해 패키지로 만들었습니다.

코어에서 이러한 순수한 stepdef API에 대한 지속적인 논쟁에 대한 임시 솔루션으로 고려하십시오(믿거나 말거나). 내가 말했듯이 이것은 어느 시점에서 핵심에 착륙할 수 있는 실험이며 실제로 그것을 사용하는 사람들의 피드백을 정말 감사하게 생각합니다. 견인력이 충분하다면 오이에 통합하는 것이 더 나은 논거가 될 것입니다.

또한 tap() 및 강제 읽기 전용 컨텍스트와 같은 몇 가지 다른 (작은) 유용한 기능 도구를 제공하고 있습니다.

stepdef 함수에 대한 arity 검사는 확실히 이 lib에서 (매우 추악한 방식으로) 우회해야 하는 문제입니다. CLI와 프로그래밍 방식 모두에서 이 기능을 끄는 옵션은 이 작업(및 잠재적으로 다른 사용 사례)에 매우 유용합니다. 그렇게 하고 싶지만 현재로서는 시간이 부족한 자원입니다.

그 동안 arity 검사를 수정하기 위해 오이-fp에서 자유롭게 영감을 얻으십시오.

@jbpros 훌륭합니다. 그리고 당신이 거기에

@andyearnshaw 하 맞습니다. 설명 감사합니다. 나는 우리가 이 아이디어를 버려서는 안 되며 이 문제를 공개적으로 유지하는 것이 아마도 일을 투명하게 유지하는 좋은 방법일 것이라는 데 동의합니다.