Apollo/GraphQl-类型必须为输入类型 [英] Apollo / GraphQl - Type must be Input type

查看:205
本文介绍了Apollo/GraphQl-类型必须为输入类型的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在学习过程中一直与所有人保持联系,并将Apollo和graphQL集成到我的一个项目中.到目前为止,一切正常,但是现在我尝试进行一些更改,并且在输入类型和查询类型方面苦苦挣扎.我觉得这比应该的要复杂得多,因此我正在寻求有关如何处理自己情况的建议.我在网上找到的示例始终都具有非常基本的模式,但现实总是更加复杂,因为我的模式很大,看起来如下所示(我将仅复制其中一部分):

Reaching to you all as I am in the learning process and integration of Apollo and graphQL into one of my projects. So far it goes ok but now I am trying to have some mutations and I am struggling with the Input type and Query type. I feel like it's way more complicated than it should be and therefore I am looking for advice on how I should manage my situation. Examples I found online are always with very basic Schemas but the reality is always more complex as my Schema is quite big and look as follow (I'll copy just a part):

type Calculation {
    _id: String!
    userId: String!
    data: CalculationData
    lastUpdated: Int
    name: String
}

type CalculationData {
    Loads: [Load]
    validated: Boolean
    x: Float
    y: Float
    z: Float
    Inputs: [Input]
    metric: Boolean

}

然后定义输入和负载,依此类推...

Then Inputs and Loads are defined, and so on...

为此,我想要一个变体来保存计算",所以在同一文件中我有这个:

For this I want a mutation to save the "Calculation", so in the same file I have this:

type Mutation {
    saveCalculation(data: CalculationData!, name: String!): Calculation
}

我的解析器如下:

export default resolvers = {
    Mutation: {
        saveCalculation(obj, args, context) {
            if(context.user && context.user._id){
                const calculationId = Calculations.insert({
                    userId: context.user._id,
                    data: args.data,
                    name: args.name
                })
                return Calculations.findOne({ _id: calculationId})
            }
            throw new Error('Need an account to save a calculation')
        }
    }
}

然后我的突变如下: 从"graphql-tag"导入gql;

Then my mutation is the following : import gql from 'graphql-tag';

export const SAVE_CALCULATION = gql`
    mutation saveCalculation($data: CalculationData!, $name: String!){
        saveCalculation(data: $data, name: $name){
            _id
        }
    }
`

最后,我使用Mutation组件尝试保存数据:

Finally I am using the Mutation component to try to save the data:

<Mutation mutation={SAVE_CALCULATION}>
    {(saveCalculation, { data }) => (
        <div onClick={() => saveCalculation({ variables : { data: this.state, name:'name calcul' }})}>SAVE</div>
    }}
</Mutation>

现在出现以下错误:

[GraphQL错误]:消息:Mutation.saveCalculation(data :)的类型 必须为输入类型,但必须为:CalculationData!.,位置:未定义, 路径:未定义

[GraphQL error]: Message: The type of Mutation.saveCalculation(data:) must be Input Type but got: CalculationData!., Location: undefined, Path: undefined

从我的研究和一些其他SO帖子中,我了解到除了查询类型外,我还应该定义输入类型,但是输入类型只能使用标量类型,但是我的架构取决于其他架构(而不是标量).当最后一个输入只有标量类型时,是否可以根据其他输入类型来创建输入类型?我有点迷失了,因为它似乎有很多多余之处.非常感谢您提供有关最佳做法的指导.我相信 Apollo/graphql 可以为我的项目带来长期的帮助,但是我必须承认,它比架构复杂时所实现的想法要复杂得多.在线示例通常使用字符串和布尔值.

From my research and some other SO posts, I get that I should define Input type in addition to the Query type but Input type can only avec Scalar types but my schema depends on other schemas (and that is not scalar). Can I create Input types depending on other Input types and so on when the last one has only scalar types? I am kinda lost cause it seems like a lot of redundancy. Would very much appreciate some guidance on the best practice. I am convinced Apollo/graphql could bring me quite good help over time on my project but I have to admit it is more complicated than I thought to implement it when the Schemas are a bit complex. Online examples generally stick to a String and a Boolean.

推荐答案

来自规范:

字段可以接受参数来配置其行为.这些输入通常是标量或枚举,但有时需要表示更复杂的值.

Fields may accept arguments to configure their behavior. These inputs are often scalars or enums, but they sometimes need to represent more complex values.

一个GraphQL输入对象定义了一组输入字段.输入字段可以是标量,枚举或其他输入对象.这样,参数就可以接受任意复杂的结构.

A GraphQL Input Object defines a set of input fields; the input fields are either scalars, enums, or other input objects. This allows arguments to accept arbitrarily complex structs.

换句话说,您不能将常规GraphQLObjectType用作GraphQLInputObjectType字段的类型,而必须使用另一个GraphQLInputObjectType.

In other words, you can't use regular GraphQLObjectTypes as the type for an GraphQLInputObjectType field -- you must use another GraphQLInputObjectType.

使用SDL写出架构时,必须创建一个Load类型和一个LoadInput输入似乎是多余的,尤其是当它们具有相同的字段时.但是,在幕后,您定义的类型和输入将变成非常不同的对象类,每种对象具有不同的属性和方法.有些功能是GraphQLObjectType所不具备的,例如GraphQLObjectType所特有的(例如接受参数),反之亦然.

When you write out your schema using SDL, it may seem redundant to have to create a Load type and a LoadInput input, especially if they have the same fields. However, under the hood, the types and inputs you define are turned into very different classes of object, each with different properties and methods. There is functionality that is specific to a GraphQLObjectType (like accepting arguments) that doesn't exist on an GraphQLInputObjectType -- and vice versa.

试图代替另一个来使用,就像试图将一个方形的钉子放在一个圆孔中一样. 我不知道为什么需要一个圆.我有一个正方形.它们都具有直径.为什么我需要两个?"

Trying to use in place of another is kind of like trying to put a square peg in a round hole. "I don't know why I need a circle. I have a square. They both have a diameter. Why do I need both?"

除此之外,有充分的实际理由将类型和输入分开.这是因为在很多情况下,您将公开许多类型的字段,而这些类型不会在输入中公开.

Outside of that, there's a good practical reason to keep types and inputs separate. That's because in plenty of scenarios, you will expose plenty of fields on the type that you won't expose on the input.

例如,您的类型可能包括派生字段,这些字段实际上是基础数据的组合.或者它可能包含与其他数据之间的关系的字段(例如User上的friends字段).在这两种情况下,都没有必要使这些字段成为作为某个字段的参数提交的数据的一部分.同样,您可能不想在其类型对应项上显示某些输入字段(想到的是password字段).

For example, your type might include derived fields that are actually a combination of the underlying data. Or it might include fields to relationships with other data (like a friends field on a User). In both these case, it wouldn't make sense to make these fields part of the data that's submitted as as argument for some field. Likewise, you might have some input field that you wouldn't want to expose on its type counterpart (a password field comes to mind).

这篇关于Apollo/GraphQl-类型必须为输入类型的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆