As a temp solution used this:

this.post('records', new Object({ ...data }));

from datasource-rest.

Will there be any real fix for this? Because spreading the object is just a quickfix I presume.

from datasource-rest.

I think this issue should be reopened as it's not fixed.

from datasource-rest.

I opened a PR to fix this in apollographql/apollo-server#5070.

from datasource-rest.

I just came across this workaround mentioned by @fantactuka , which shouldn't be used anymore, specially if this was posted 2 years ago as an issue and it hasn't been solved yet. Is there going to be a fix for this soon?

from datasource-rest.

Yeah, we faced the same problem in our team. How can we help to fix it ?

from datasource-rest.

This is what I did to avoid running into this issue entirely, though it would be nice if the library could properly handle it itself:

class BaseApi extends RESTDataSource {
  willSendRequest(request){
        if (request.body && typeof request.body === 'object') {
      request.body = { ...request.body };
    }
  }
}

from datasource-rest.

two years in, can we please at least get this issue reopened?

from datasource-rest.

The actual reason behind this error:

when Javascript is trying to cast an object to a string.

Javascript will try to call the toString() method of that object. most of the Javascript objects havetoString()method inherited from Object.prototype. but some of them that have a null prototype, not have toString() method so the Javascript will fail to convert those objects to a string primitive. and can't convert object to primitive error will rise.

to create a null prototype Object in Javascript use this method

let travel = Object.create(null)

The solution

travel = {...travel}

from datasource-rest.

I have the same problem, the object is not parsed here part of my code:

//resolver.js
const resolver = {
  Mutation: {
    async addInvite(_root, {invite}, { dataSources }) {
      return await  dataSources.invitesAPI.addInvite(invite);
    }
  }
};
//datasource.js
const INVITES_PATH = 'invites'

class InviteDataSource extends RestDataSource {
  constructor() {
    super();
  }  
  async addInvite(invite) {
    return await this.post(invite)
  }
}

This is not the real code, but the logic is the same. For some reason invite is not recognized as an object, it doesn't pass the following test in RESTDataSource.ts

//RESTDataSource.ts
   // We accept arbitrary objects as body and serialize them as JSON
   if (
      options.body !== undefined &&
      options.body !== null &&
      (options.body.constructor === Object ||
        ((options.body as any).toJSON &&
          typeof (options.body as any).toJSON === 'function'))
    ) {
      options.body = JSON.stringify(options.body);
      options.headers.set('Content-Type', 'application/json');
    }

invite is a valid object, maybe created with Object.create, but I think it should be stringified.
To solve this I have to recreate object doing something like this:

//resolver.js
const resolver = {
  Mutation: {
    async addInvite(_root, {invite}, { dataSources }) {
      return await  dataSources.invitesAPI.addInvite({...invite});
    }
  }
};

from datasource-rest.

Following as I am facing the same issue in a project I recently embarked on.

from datasource-rest.

Were you able to find a fix for this?

from datasource-rest.

Hi guys,

Trying to play with mutations and ?m facing the same problem.

Sounds like the check in the RestDataSource is not absolutely correct. In fact, by checking that option.body.toJSON is a method, means that you expect that the object has a "custom toJSON" behavior.

What is strange is that you don't call it in the if body :)

I would personally expect something like

if (options.body !== undefined && options.body !== null && typeof(options.body) === 'object') {

    options.headers.set('Content-Type', 'application/json');
      
    options.body = ((options.body as any).toJSON 
                    && typeof (options.body as any).toJSON === 'function')
        ? options.body.toJSON()
        : JSON.stringify(options.body);
      
} 

do you mind if I create a PR with the suggested change ?

from datasource-rest.

+1 for @fantactuka's solution here: spreading the object into a new object works.

from datasource-rest.

Thanks very much for reporting this! We think this is a great idea, and would definitely review a docs PR. If you (or anyone else) is interested in working on this, that would be great - thanks!

from datasource-rest.

Yeah that's just a stopgap solution to make up for being unable to trace a tangle through spaghetti code.

from datasource-rest.

I am having same issue

from datasource-rest.

+1, Please reopen the issue

from datasource-rest.

Does anyone have a proposal for the change they'd like to see here? @jfreyre's #68 is the closest to an actual suggestion. A PR is certainly welcome, so long as it's backwards-compatible and comes with tests!

from datasource-rest.

I am also having the same issue.

from datasource-rest.

I reiterate @abernix 's note — happy to review a backwards-compatible tested PR.

from datasource-rest.

But yeah don't use any of that to fix the glaring issues you leave developers to deal with.

from datasource-rest.

But yeah don't use any of that to fix the glaring issues you leave developers to deal with.

The only time you can demand fixes is when you pay for a product.

This is still open-source, don't forget it.

As much as I'd like the team to fix many issues that affects my work too, and despite having been completely ignored by them in the issues I opened, I am not mad at them because this is still OSS.

from datasource-rest.

Not trying to come off demanding fixes. Trying to point out how ridiculous it is when a company raises 22 million US dollars on a platform to make developers lives easier and expects other developers to fix their issues for free. Apollo should use some of that 22 million to fix it, either internally, or with a bounty program. Not to close issues that affect people only to reopen them years later saying "fix it yourself pls".

Also, my team does pay for Apollo. Not this library specifically, no, we pay for noisy Slack notifications.

This level of support would be acceptable from a project ran by someone in their spare time. Not one with a large VC backing that also gets funding from subscriptions.

from datasource-rest.

@mikew You'll be happy to know that after 9 months of Apollo Server having no full-time staff, this project has returned to having active maintenance, and it's certainly my intention to not allow it to be left unstaffed again.

This does seem like an issue worth fixing. There are no full reproductions given above, though. For example, in @topekTopperson 's original post, there's no information on what the TravelSeason type is or how you create one.

I'll be happy to reopen and evaluate this issue if somebody can provide a full reproduction (eg, a git repo or codesandbox.io link with full instructions on how to see the issue for myself) of it!

from datasource-rest.

Hello people,
sorry for my absence in this topic but I am not using Apollo Server anymore so that is why I didn't provide more examples / PR or whatever.
I have been tracking this issue though and I think that @mikew has a very good point here :)

I just hope that this lack of reproduction is not an excuse now.
When you asked developers here for that PR, missing codesandbox was not an issue, suddenly it is.
I had even that impression that this problem was understood by others.
Anyway I am looking forward for that fix just because it was me who started this 😄

from datasource-rest.

It's possible that my colleagues who responded previously understood the particular bug on a deeper level than I did.

I am a very simple person who loves the stages of "there's something broken that I can see on my computer, let's go fix it" and does not love the stages of "somebody told me that something is wrong but I have to do a lot of work to see it broken for myself". I'm newly back to focusing on open source for the first time in years, and I hope that folks will be happy with my ability to improve the project when given clear examples of what the problem is. The tradeoff is I'm going to make a lot of comments of the form "sorry, I don't understand how to reproduce this, please give me a reproduction", but I promise that if you do give me that reproduction I'm pretty likely to get you what you want relatively quickly :)

from datasource-rest.