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

TypeScript issue when renaming fields at object type level #91

Open
jferrettiboke opened this issue Mar 19, 2019 · 8 comments
Open

TypeScript issue when renaming fields at object type level #91

jferrettiboke opened this issue Mar 19, 2019 · 8 comments
Labels
type/docs Relates to knowledge transfer matter (refs, guides, tuts, examples, ...)

Comments

@jferrettiboke
Copy link

I'm using Stripe so I created a Card object type.

Screenshot 2019-03-19 at 14 54 11

I adapted the Card object type to exactly what Stripes returns and this works great, however, I want to rename some fields. When I do so this is what happens:

Screenshot 2019-03-19 at 14 55 15

If I hover the the red line it says: Property 'exp_month' does not exist on type '{ brand: string; exp_year: string; id: string; last4: string; }'..

But if I do this (I left the field that Stripe returns plus my renamed field), it works:

Screenshot 2019-03-19 at 14 54 51

Can we rename fields at the object type level or do we have to do it in the parent? Any idea how to solve this?

@tgriesser
Copy link
Member

The issue is that without any types configured via typegenAutoConfig for the "Card" object, Nexus can't know what root is supposed to be. I need to add more documentation for this, but for now yo can take a look at this issue and this issue for more info.

I've also been considering adding a way of defining the types at runtime and/or maybe also having a way of specifying the root type manually, e.g.

import { objectType } = from 'nexus/generics'

export const Card = objectType({
  name: "Card",
  definition<CardType>(t) {
    t.id('id')
  }
})

By the way, I'm curious - are you using TypeScript or JavaScript in these examples?

@jferrettiboke
Copy link
Author

I like your proposal. However, it would be awesome if Nexus would allow us to do something similar to nexus-prisma.

const Card = stripeObjectType({
  name: "Card",
  definition(t) {
    t.stripeFields([
      "id",
      "brand",
      "last4",
      { name: "exp_month", alias: "expMonth" },
      { name: "exp_year", alias: "expYear" }
    ])
  },
})

By the way, I'm curious - are you using TypeScript or JavaScript in these examples?

I'm using TypeScript with Yoga2.

@jferrettiboke
Copy link
Author

@tgriesser I already figured out how to solve my issue based on what you said. However, I am getting errors in some of my resolve functions.

As a quick example, this resolver is complaining. My intention is to avoid to rewrite all the interfaces by my own, and use as much as possible from other third-party libraries instead, in my case Stripe, in order to keep my interfaces up-to-date. So, I wanted to override the Stripe interface for the customer object but sadly interfaces can be overridden in TypeScript. I tried many things but I didn't get it working yet. ATM, I have this. Could you check this out and let me know how we can solve this kind of issues within Nexus?

If Nexus could allow us to make something like nexus-prisma, we could be able to create our own smart nexus-prisma-like objects to extend third-party libraries in a very friendly manner.

@Weakky
Copy link
Member

Weakky commented Mar 23, 2019

You can use the Omit type to remove the fields you want to override

import { core } from 'nexus'
export interface Customer extends core.Omit<Stripe.customers.ICustomer, 'name' | 'lastName'> {
 name: string
 lastName: string
}

@jasonkuhrt jasonkuhrt added type/docs Relates to knowledge transfer matter (refs, guides, tuts, examples, ...) type/feat Add a new capability or enhance an existing one labels Sep 3, 2019
@jasonkuhrt
Copy link
Contributor

jasonkuhrt commented Sep 3, 2019

Marking this as both docs and enhancements. We need better docs on backing types. But we might also want to explore a richer backing types DSL.

@jasonkuhrt jasonkuhrt removed the type/feat Add a new capability or enhance an existing one label Sep 5, 2019
@jasonkuhrt
Copy link
Contributor

Actually going to focus this issue to just be docs

However, it would be awesome if Nexus

@jferrettiboke feel free to re-open a feature request/discussion.

@tonyfromundefined
Copy link

#216

@philostler
Copy link

I've just bumped into a requirement which is similar to this that I'm struggling to resolve. I'm not renaming, but generating field A off field B but I don't wish to expose field A which I currently have to do.

I can't see anything in the docs to easily solve this. What's the current status of this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/docs Relates to knowledge transfer matter (refs, guides, tuts, examples, ...)
Projects
None yet
Development

No branches or pull requests

6 participants