[Feature Request]'query Document'을 통해'operation Name'('name')의 기능을 설정합니다.`

묘사

현재 설정Query이나 조작명칭의 메커니즘을 볼 수 없습니다.MutationqueryDocument:

queryDocument :
    ValueSpec NonNull ObjectType result vars
    -> Document Query result vars
queryDocument spec =
    document
        (Operation
            { operationType = queryOperationType
            , name = Nothing
            , directives = []
            , spec = spec
            }
)
{-| On a pedantic note, perhaps `name` should be renamed `operationName` for transparency. -}

이 함수를 src/GraphQL/Request/Builder.elm로 명명하고 서명을 사용하여 다른 anonymousQueryDocument 함수를 만드는 것이 좋습니다.

 queryDocument :
    OperationName
    -> ValueSpec NonNull ObjectType result vars
    -> Document Query result vars

어느 곳, 어디

type alias OperationName = Maybe String

queryDocument는 밑줄을 친 알파벳 숫자가 아니라 숫자로 시작해야 한다. [a-Za-z] [0-9A-Za-z]*/나는 이 검사가 조회 검증 절차로 미룰 수 있다고 생각한다.OperationName:

anonymousQueryDocument:
    -> ValueSpec NonNull ObjectType result vars
    -> Document Query result vars
anonymousQueryDocument spec = queryDocument Nothing spec

queryDocument:
    OperationName
    -> ValueSpec NonNull ObjectType result vars
    -> Document Query result vars
queryDocument operationName spec =
    document
        (Operation
            { operationType = queryOperationType
            , name = operationName
            , directives = []
            , spec = spec
            }
        )

분명히 변화를 깨뜨렸다.다른 선택은 옛 행동을 anonymousQueryDocument 로 이동하는 것이 아니라 namedQueryDocument 새로운 함수일 수도 있다.상기 모든 내용도 anonymousQueryDocument에 적용된다.mutationDocument 나는 이렇게 하고 홍보를 발표하는 것을 개의치 않는다. 나는 단지 이것이 너(@jamesmacaulay)가 가고 싶은 방향이라는 것을 알 뿐이다.

토론 #1

@sunwukonga 구축기DSL을 사용하여 명명 조작을 만드는 방법을 제공하지 않았습니다. 왜냐하면 하나의 조작 문서에서 명명 조작이 필요한 상황을 생각해 내지 못했기 때문입니다.멀티태스킹 문서를 만들 수 있도록 DSL을 확장하는 것을 고려해 보았지만, API의 복잡성을 증가시키고 가치가 없는 것 같아서 그러지 않기로 결정했다.
용례가 무엇인지 여쭤봐도 될까요?명명 동작을 만들 수 있는 이유가 무엇입니까?

토론 #2

저는 Haskell의graphqlapi와elmgraphql을 통합하고 있습니다.어젯밤에graphqlapi는 접두사

토론 #셋

의 익명 검색을 받아들였다.지금은 이렇다. 적어도 나의 지점에서는 이렇다.
나는 왜 수술을 명명해야 하는지 좀 확실하지 않다는 것을 인정해야 한다.#operation-names규범에 규정된 관례에 따라

You'll need these optional parts (operationName, variables) to a GraphQL operation if you want to execute something other than a query or pass dynamic variables.

및 #post-request-operation

Name is only required if multiple operations are present in the query

올바른 작업입니다. 한 작업만 있으면 작업 이름을 지정할 필요가 없습니다.그러나 사례의 실용성이 부족하다는 것을 감안하여 문서를 간단하게 하나의 조작으로 제한하는 것은 더 좋고 현명한 선택인 것 같다. (이 옵션을 선택했다.)이상의 암시 돌변은 이름이 필요하지만, 마찬가지로 하나의 조작만 있으면 이름이 필요하지 않습니다.이와 유사하게 변수와 관련된 수요는 여러 조작의 상하문에서만 이루어진다.
그러나 규범적인 미래 확장을 바탕으로 각 문서의 조작 명칭과 여러 조작의 방어는 graphql github로 약 다음과 같다.2015년(총괄은 다음과 같다):
1. query 파일 형식으로 클라이언트(iOS, 안드로이드)에서 표준 해상도로 처리할 수 있는 형식으로 작업을 저장한다(발붙일 수 없는 이유인 것 같다).
2.graphql 서버에서 요청 문서를 저장하는 세계(내가 알기로는 어느 곳에서도 이루어지지 않았고 규범에서도 언급되지 않았다)에서 다음 명령을 사용하여 새로운 조회를 지정할 수 있다.
{
질의: 문서 ID: ######
operationName: "SomeOperationNameKnown 기존 참조 문서"
}
3. 일괄 처리 조작으로 시작 조작은 문서의 다른 조작을 호출할 수 있다(마찬가지로 규범에서 그것을 보지 못했고 실현하지 못했다. 비록 같은 저자github graphql가 이 논평에서 그것을 언급했지만).
1, 2, 3은 필요 없을 것 같다.이것은 적어도 나에게 있어서 조작명은 조작을 명확하게 선택하는 것이 아니라는 것을 의미한다. (비록 네가 바보스럽지만, 문서마다 여러 개의 조작이 포함되어 있지만, 그것들도 가능하다.)
따라서 조작명의 유일한 유틸리티(이때)는 오류 메시지를 되돌릴 때 문서에 얼마나 많은 조작이 있든지 간에 오류를 추적하는 가치 있는 피드백 메커니즘이 된다.
결국 모든 문서에 여러 개의 조작이 있고 특정한 조작 방법을 지정하는 것은 거대한 체계 구조의 선택인 것 같지만 아직 정해지지 않았다(...정해지지 않았다).
한 마디로 하면, 작업 이름은 추적 오류에만 진정으로 유용하기 때문에, 모든 검색에서 매우 유용하다. 한 요청에 여러 작업을 임의로 도입하는 것이 아니라.
위쪽:

... if you want to execute something other than a query or pass dynamic variables.

돌연변이에 대해서는 (구독이 있을 수 있음)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^.동적 변수의 컨텍스트에서도 예상됩니다(필요하지 않음)..graphql 규범을 엄격히 준수하고 간결하게 설명한다.

BOTH query keyword AND query name MUST be added to any mutation or any subscription, OR to any query that passes dynamic variables.

토론 #4

@sunwukonga 그래, 적어도 너의 행동을 명명하는 능력을 제공하는 것은 가치가 있다고 믿게 해줘.나는 이 때문에 함수를 추가할 것이다.
그러나 이 주장에 대해서는

BOTH query keyword AND query name MUST be added to any mutation or any subscription, OR to any query that passes dynamic variables.

나는 네가 읽은 문서에 대한 이해가 틀렸다고 믿는다.'Learn GraphQL' 문서는 좋은 학습 자원이지만, 실제 규범만큼 정확하지는 않습니다. #operation-names 와 the section of the spec on operations 을 보면, 익명 작업이 한 작업 문서에서만 단독으로 발생하기만 하면, 작업 이름은 항상 선택할 수 있습니다.사실 규범이 제시한 조작의 주요 예는 이름이 없는 돌연변이이다.

mutation {
  likeStory(storyID: 12345) {
    story {
      likeCount
    }
  }
}

토론 #5

그중에 한 번은 내가 틀려서 기뻤다.나는 페이스북의 엔지니어가 어떻게 이렇게 부정확하고 논리에 맞지 않는지 정말 알고 싶다.graphql.조직의 행동 명칭에 대한 묘사는 어휘 선택이 엉망일 뿐만 아니라 잘못된 것이다.지금까지 나는 이미 자동으로 그들이 일대일이라고 가정했다.고맙습니다. 이것은 제가 서버에서graphqlapi를 사용하는 것이 정확하다는 것을 더욱 확신하게 합니다.제가 꼼꼼히 지켜볼게요.http://facebook.github.io/graphql/October2016/장래
명명 버전과 그에 상응하는 anon 버전을 제공하기 위해 이 함수들을 다시 배열해 주시겠습니까?
어떤 것이 더 좋아요?
1. [Breaking change] 이름 매개 변수를

토론 #6

에 추가한 다음 queryDocument를 만들고 이름 매개 변수에 anonymousQueryDocument와queryDocument?

형식 서명을 보존하고name 인자로 만듭니다Nothing.name 매개 변수에서 queryDocument 호출namedQueryDocument을 사용하시겠습니까?

옵션 2는 기본값queryDocument이고 namedQueryDocument는 선택할 수 있는 내용의 확장이며 현재 서명에 의존하는 코드가 영향을 받지 않는다는 추가 장점도 있다고 생각합니다.Nothing #31 해결을 통해 오늘 이터레이션을 발표합니다.이거 얘기해줘서 고마워요, @sunwukonga!