Mutation sends field in attributes, not relationships

[timothyjoh]

I might be doing something wrong here, but here is my schema:

export const schema = {
  articles: {
    type: 'articles',
    fields: {
      title: 'string',
    },
    relationships: {
      field_template: {
        type: 'field_templates',
      },
      user: {
        type: 'users',
      },
    },
  },
  field_templates: {
    type: 'field_templates',
    fields: {
      field_context: {
        type: 'rich_text',
      },
      id: 'string',
    },
  },
  users: {
    type: 'users',
    fields: {
      name: 'string',
    },
  },
  rich_text: {
    type: 'rich_text',
    fields: {
      value: 'string',
      processed: 'string',
      formatted: 'string',
    },
  },
}

And here is my mutation code:

  const [addArticle, { isLoading, data, error, errors }] = useMutation(
    'node/article'
  )
  const result = await addArticle({
    title,
    field_template: { id: '2398729384-324239823942' },
  })

It always ends up sticking the field_template in the data.attributes instead of in the data.relationships section of the request.

I am using Drupal as a backend, and wondering if I am missing something you can see.

[jonahsol]

Hi @timothyjoh ,

I think you'll need to call useMutation with a key in schema, eg. useMutation('articles'). This will make a request to /articles.

[timothyjoh]

But the proper URL for my API is "node/article" so do I need to reflect that in the schema that way?

[aribouius]

Hey @timothyjoh, so a cursory glance at your example leads be to believe there might be a couple things going on.

• The way the schema is applied is interpreted is that the root keys map to your API endpoint name, ex.

  schema = { 
  articles: {} // -> applied to queries making requests to "/articles"
  }

• The type field maps to the JSONAPI type values used when parsing/serializing requests. Depending on how your API is configured, these may or may not be the same. For example, your API may have a /articles endpoint, but use a singular form for resource type values.

  schema = { 
  articles: {
  type: 'article'
  } 
  }

• Given that your endpoint is node/article, I believe the correct schema structure would look like:

  schema = { 
  article: {
  type: 'article' // or 'articles' if you use plural types
  } 
  }

• I'm not quite sure ATM whether your endpoint prefix is an issue, I believe it should be fine, but I'll need to test your example for a definitive answer.

• Probably unrelated to your reported issue, but I did notice the structure of your field_template primary id key. This library currently only supports integer and uuid primary keys, so attempting to fetch or update a resource with that ID format will fail. This on account of it requiring some light parsing of the endpoint URL to identify primary keys when building query objects.
  I have been giving thought to adding a configuration method to override the default matcher(s), thereby supporting non-standard resource ID's.

[aribouius]

Closing due to inactivity.

[HassanAzzam]

Just came across this and figured out that the schema key MUST have the same value as the resource type and the requested url.