Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@bsRecord's record being wrong isn't reported properly in bsb's output #42

Closed
justgage opened this issue Jun 28, 2018 · 8 comments
Closed
Labels

Comments

@justgage
Copy link

justgage commented Jun 28, 2018

For instance this name should be a string, not an int

record:
image

graphql string
image

How bsb reports it:
image

It doesn't even tell me what file it's in, let alone the line number :/.

@justgage justgage changed the title @bsRecord type being wrong in record isn't reported properly in bsb's output @bsRecord's record being wrong isn't reported properly in bsb's output Jun 28, 2018
@thangngoc89
Copy link

thangngoc89 commented Jun 28, 2018

@justgage try to run the bsb command separately in the terminal. Reason-scripts is eating the error report. And from the information available, there is nothing wrong with the ppx, it’s working as intended. The graphql query result is a string ==> this has type string. But somewhere wanted ==> your record type

@mhallin
Copy link
Owner

mhallin commented Jun 29, 2018

What's the type signature for the Id.fromString function, and what does the id field return?

@justgage
Copy link
Author

@thangngoc89 I would say it's still not very clear:
image

@mhallin The Id.fromString is just id => string where id is an abstract type. However this isn't the part that's breaking in this example.

Maybe the real thing that's making this output unclear is the error pretty printer?

@mhallin
Copy link
Owner

mhallin commented Jul 7, 2018

Ah, sorry for the irrelevant question. I see the problem now, and yes that's a bug in the record decoder, I suppose. Thanks for reporting this!

@mhallin mhallin added the bug label Jul 7, 2018
@justgage
Copy link
Author

justgage commented Jul 8, 2018

No problem @mhallin!

@Anahkiasen
Copy link

Anahkiasen commented Aug 26, 2018

Having the same issue on a much more basic level:

Data.re

type total = {
  month: string,
  amount: int,
};

type account = {
  id: int,
  name: string,
  overdraft: int,
  totals: array(total),
};

type accounts = array(account);

App.re

open Data;

module GetAccounts = [%graphql {|
    query FetchAccounts {
        accounts @bsRecord {
            id
            name
            overdraft
            totals {
                month
                amount
            }
        }
    }
|}];

With this schema:

type Total {
    month: String!
    amount: Int!
}

type Account {
    id: ID!
    name: String!
    overdraft: Int!
    balance: Int!
    savings: Int
    expenditures: [Expenditure!]!
    totals: [Total!]!
}

type Query {
    accounts: [Account!]!
}

Gets me this:

  We've found a bug for you!
  (No file name)

  This has type:
    string
  But somewhere wanted:
    int

error Command failed with exit code 2.

Is this the correct way to type an array of records? Or do I need to type all existing fields in the record type and not just the ones I use in the query?


UPDATE: This solved it, seems nested types need to be hinted explicitely?

module GetAccounts = [%graphql {|
    query FetchAccounts {
        accounts @bsRecord {
            id
            name
            overdraft
-            totals {
+            totals @bsRecord {
                month
                amount
            }
        }
    }
|}];

@mhallin
Copy link
Owner

mhallin commented Aug 30, 2018

Yeah, every subselection will need an @bsRecord directive.

Another issue with your data model is that the ID type is decoded into a string, but your account type has the ID as an integer.

@mhallin
Copy link
Owner

mhallin commented Oct 31, 2018

The original issue - incorrect source location for record fields - is fixed in version 0.2.8.

@mhallin mhallin closed this as completed Oct 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants