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

Unable to add custom fields #25

Open
ockam opened this issue May 6, 2019 · 14 comments
Open

Unable to add custom fields #25

ockam opened this issue May 6, 2019 · 14 comments

Comments

@ockam
Copy link

ockam commented May 6, 2019

Using onCreateNode in gatsby-node, I’m trying to use a transformer to compile and denormalize some data and then add this new value to the node with createNodeField. The process work fine but the fields object is not appended on my graphql schema.

@rexxars told me (on the Slack channel) that this was intentional, but I really need the ability to transform data at compile time.

@marvinwu
Copy link

+1 , with disabling the createNodefield( if it is intentional ) took away the quite a lot of the flexibility

@zielinsm
Copy link

zielinsm commented Jan 2, 2020

Any updates here? This doesn't seem to be fixed yet, making things more complicated than they could be.

@gristleism
Copy link

Just spent two hours this morning trying to debug my build, etc... until finally realizing that this was apparently an issue. I think that if this is an intentional decision it should at least be documented somewhere more obvious.

@evenwestvang
Copy link
Member

You are completely correct @gristleism – we should document this limitation.

@danieljb
Copy link

danieljb commented Apr 2, 2020

Hi Sanity team, is there a specific reason for this restriction? As marvinwu and zielinsm pointed out this limits a lot of Gatsby’s awesome functionality.

Some of our projects make extensive use of Gatsby’s node system and Sanity would be an awesome fit with its dynamic content types. But not being able to actually work on top of the Sanity-created nodes lead to a lengthy debugging session and afterwards to strange workarounds in a test setup.

Any chance we can make the custom fields functionality work?

@kmelve
Copy link
Member

kmelve commented Apr 11, 2020

To clarify: It's not intentional, we just haven't gotten around to fixing this yet. I've put it on the backlog of things to do. No ETA at the moment I'm afraid.

@rexxars
Copy link
Member

rexxars commented Apr 12, 2020

I agree that this is confusing - especially that you get no error/warning.
This is intentional from Gatsby, however: We're declaring the schema types up front - so when you want to only add the field on a single node, that doesn't necessarily make much sense - two nodes of the same type could have a field which returns very different data.

There is a newer API which you can use to add fields to a type, however:

// In your `gatsby-node.js`:
exports.createResolvers = ({createResolvers}) => {
  createResolvers({
    // `SanityBlogPost` being the type name you want to extend
    SanityBlogPost: {
      // `happiness` being the field name you want to add
      happiness: {
        // type is the _GraphQL_ type name, so you can do `String!` for "non-null string", `Int` for integer, `SanityCategory` for a document or object of type  `SanityCategory`.
        type: 'String',
        resolve(source, args, context, info) {
          return 'is customization through GraphQL'
        }
      }
    }
  })
}

There is more info on this API in the Gatsby docs

@daydream05
Copy link

Just ran into this issue.

@rexxars Thank you! I think that should be added to the docs since createNodeFields is very popular in a lot of Gatsby projects. Will create a PR when I have the time!

@aaronadamsCA
Copy link

Per the Sanity Kitchen Sink, you can also use Gatsby's createSchemaCustomization API to add fields to Sanity types:

exports.createSchemaCustomization = ({ actions, schema }) => {
  actions.createTypes([
    schema.buildObjectType({
      name: "SanityPost",
      interfaces: ["Node"],
      fields: {
        isPublished: {
          type: "Boolean!",
          resolve: (source) => new Date(source.publishedAt) <= new Date(),
        },
      },
    }),
  ]);
};

This has the added benefit of giving you sort and filter functionality for your fields, which doesn't happen when you add them with createResolvers.

@turistua
Copy link

turistua commented Aug 5, 2020

I'm strugging with the same isssue and trying to find workarounds.

I'm running the website which should have either Sanity or other CMS integration, and need to unify data schema. Slug field is created using createNodeFiled() for second CMS, and I can't do the same for Sanity (as all other in the topic). I'm trying to map field created by createNodeFiled to something, and can't have access to source.fields object.

Have anyone tried to add a resolver where have access to source.fields object?

@aaronadamsCA
Copy link

@turistua If I'm understanding your question correctly, you can find document fields as properties of source in a custom resolver you provide using the createTypes or createResolvers API methods. Examples of both are above, and you'll find (somewhat outdated) Gatsby docs here:

I use createTypes because I want to be able to filter/sort by the fields I create, which you won't get if you use createResolvers.

I've experienced some race conditions, however these may be a problem with this plugin as opposed to with Gatsby itself (#83), it's hard to say.

@kelvinauta
Copy link

Oh god! 5 hours working :(
Wish I had seen this before

@AbdallahAbis
Copy link

Any updates on this?
The above solutions using createSchemaCustomization or createResolvers wouldn't work for sanity reference fields, the source arg doesn't return the formatted reference field. check this for more info #146
Plus, Gatsby recommends using createNodeField rather than createSchemaCustomization or createResolvers here

@raae
Copy link

raae commented Jun 16, 2022

I believe setting infer to false (aka. @dontInfer) when creating the schema is the cause.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests