arg parameters in resolve don't inherit from Object

Given a resolve function that looks like

resolve: (root, args, request) => {
  test =  { uuid: '1234', description: 'lead singer of the Doors' };
  console.log('result: ' + Object.prototype.hasOwnProperty.call(args.person, 'description'));
  // XXX This fails!:  console.log('result: ' + args.person.hasOwnProperty('description'));
  console.log('result: ' + test.hasOwnProperty('description'));
  return db.personUpdate(request.user, args.person);
}

If I try to use args.person.hasOwnProperty('description') I get the error hasOwnProperty is not a function. I’m forced to use Object.prototype.hasOwnProperty.call per this issue in another module

Note that if I create an object similar to args.person I don’t get an error. See the test example in the code snippet.

I’m not enough of a javascript guru to say why this is happening, but it is a gotcha for when I"m attempting an update, where I merge the update with the existing object depending on what attributes are set in the update. My unit tests for the database pass (e.g. just like the test object above), but then fails when I attempt have graphql-express use my database.

I’ve checked, and there is no attribute ‘hasOwnProperty’ on args.person, per the Mozilla description of Object.hasOwnProperty

[nfantone]

@IvanGoncharov Thanks for pointing me to the appropriate issue! Sad to see that it’s closed, though.

I recognize that it rather futile now, but I believe your argument for not using plain Object suffers from lack of common sense vs. technical purity. Removing widely used methods from the most commonly used type in JS is only asking for trouble and generating incompatibilities with pretty much everything else out in the wild.

And I still haven’t heard/read any real tradeoffs of this approach.

And I don’t think we would change anything since it’s a big breaking change because following is valid at the moment:

This is a rehash of the argument in your original response. To me, this reads dangerously close to: “It’s not us doing it wrong, it’s everyone else”.

[nfantone]

@wincent This is a problem when you pass your coerced objects around as inputs to other libraries/tools that you don’t control.

This happened to me today when using dynamo-data-types to convert GraphQL inputs into DynamoDB representations. The module uses obj.hasOwnProperty, which raised an exception. This can happen any time, any where from sources that are out of reach for users. Having to wrap my inputs with ad-hoc objects, like { ...myGraphQLInput }, feels hackish and unsafe.

What’s the real benefit around stripping objects from their prototypes?