JSON API Errors Object

[sescobb27]

Hi, we are migrating to Ember 1.13 and Ember Data 1.13 but we are having issues with JSON API error objects in tests:

test('Error on contact us form submition', function (assert) {
  server.respondWith('POST', apiUrl + '/customer-supports', function (xhr) {
    xhr.respond(422, {
      'Content-Type': 'application/vnd.api+json'
    }, JSON.stringify({
      errors: [
        {
          status: '422',
          title: 'Error Sending Email, Please try again!!!',
          detail: 'Error Sending Email, Please try again!!!',
          source: {
            pointer: 'data/attributes/email'
          }
        }
      ]
    }));
  });

import Ember from 'ember';

export default Ember.Route.extend({
  actions: {
    contactUsFormSubmit: function () {
      customerSupport.save().catch((error) => {
        console.log(error);
      });
    }
  }
});

TypeError: ember$data$lib$system$model$internal$model$$get(...).add is not a function
    at InternalModel.ember$data$lib$system$model$internal$model$$InternalModel.addErrorMessageToAttribute (http://localhost:4200/assets/vendor.js:100040:75)
    at InternalModel.ember$data$lib$system$model$internal$model$$InternalModel.adapterDidInvalidate (http://localhost:4200/assets/vendor.js:100064:18)
    at ember$data$lib$system$store$$Service.extend.recordWasInvalid (http://localhost:4200/assets/vendor.js:101615:23)
    at http://localhost:4200/assets/vendor.js:102349:17
    at tryCatch (http://localhost:4200/assets/vendor.js:67605:14)
    at invokeCallback (http://localhost:4200/assets/vendor.js:67620:15)
    at publish (http://localhost:4200/assets/vendor.js:67588:9)
    at publishRejection (http://localhost:4200/assets/vendor.js:67522:5)
    at http://localhost:4200/assets/vendor.js:43997:7
    at Queue.invoke (http://localhost:4200/assets/vendor.js:11505:16)

the exception is thrown in internal-model.js when doing get(record, 'errors').add(attribute, message); in which record is equal to customerSupport model, attribute is equal to email and message is equal to 'Error Sending Email, Please try again!!!'

  addErrorMessageToAttribute: function (attribute, message) {
    var record = this.getRecord();
    get(record, 'errors').add(attribute, message);
  },

what are we doing wrong? thanks

[buritica]

hey @igorT would you happen to know how we can approach this?

[igorT]

cc @tchak @wecc

[courajs]

@sescobb27 This is a hunch, but did you put an 'errors' property on your model? By default it is an instance of DS.Errors which has an add method. If you've accidentally replaced this with your own errors property, the add method it's looking for would be missing. Can you include your model code as well?

[tchak]

Yes this looks definitely as errors being redefined on the model.

[sescobb27]

@DrSpaniel, we are using ember-validations from dockyard, and in did they modify the errors attribute in the models.

export default DS.Model.extend(EmberValidations.Mixin, {
    ...
})

[courajs]

@tchak Is there a way we can raise a warning if a user defines an errors attribute on a model?

[courajs]

@sescobb27 EmberValidations isn't meant to be mixed in with the model. Mix it into your controller or your component instead

[sescobb27]

@DrSpaniel 😞 so, do I need to copy/paste those validations in every controller where I need them? BTW thanks for yor help guys :)

[courajs]

@sescobb27 You can create a mixin with just that validations hash, then mix that into your controllers.

export default Ember.Controller.extend(EmailValidationsMixin, {
...
});

I work at dockyard btw, and we're talking right now about how we can make this clearer in the documentation

[tchak]

@DrSpaniel we can definitely add a warning if someone overrides errors object. @igorT @bmac are you ok with such warning?

[courajs]

I'd love a commit in ED, let me do the PR?
My intuition would be to warn on the entire list of properties. Any reason not to?
Maybe some should be warns, and others raise errors?

adapterError
attributes
dirtyType
errors
fields
hasDirtyAttributes
id
isDeleted
isEmpty
isError
isLoaded
isLoading
isNew
isReloading
isSaving
isValid
modelName
relatedTypes
relationshipNames
relationships
relationshipsByName
transformedAttributes

[tchak]

I am not sure about the general case...

And in your list there is a lot of static attributes/methods. I would not care much about them.

[oleg-andreyev]

@DrSpaniel you are saying that EmberValidation shouldn't be mixed with Model, but after reading this article, I have mixed feelings about it...

How then we can validate complex graphs?
Having ability to validate complex graph is a MUST HAVE feature.

/cc @bcardarella

[courajs]

@oleg-andreyev that's true, the post does leave an open ended question. I'm not sure we ever resolved it. The ember-validations repo would probably be a better place for that discussion though.

[courajs]

@bcardarella why not? It causes ED to crash if you do override it

[courajs]

@bcardarella in this case we're not overriding with an API compliant object though. We could check for API compliance and only warn if it doesn't match? My worry is that domain 'errors' properties are probably not uncommon, and we should guard against accidental overrides.
We could fix this so it doesn't crash, but it will still result in ED behaving differently than normal if you override the property.

[sescobb27]

@bcardarella @DrSpaniel what about overriding errors in ember-validation with a DS.Error instance object or with a Ember.ArrayProxy??

[courajs]

@bcardarella I think there's a case to be made for protecting the average developer from naively adding an errors property to their model without understanding the consequences

[sescobb27]

@bcardarella @DrSpaniel The thing is I didn't override the errors attribute but instead I have all my models mixed with ember-validations 'cause that's the most natural way of handling that, I will refactor my app in order to make those validations in our components, Controllers are going to be removed in coming releases, but maybe some other people are going to face this same issue as I did, that's why I think that complexity matter.

[rwjblue]

@rwjblue has made the same case to me

Super minor correction here: my suggestion was to extract a shared object (not in ember-data's repo) that can be used by both projects. I am not 100% certain that the current DS.Errors will do all of the things that ember-validations needs/wants (though it may, I haven't dug into it a bunch lately).

[rwjblue]

Ya, makes sense

[tchak]

Good news is, we are moving away from complex event mechanics in DS.Errors that could make harder to integrate with it (see #3853). By doing that we decorrelating DS.Errors from invalid state transitions.

[OpakAlex]

own API it's Ember way guys! More own api, and soon you will 0 users.

[runspired]

closing as we have no intent on changing the API of errors, the path forward is full deprecation and removal of @ember-data/model. Folks who wish to have a nicer errors experience today may either directly access and subscribe to errors from the cache and/or fully replace Model by implementing the instantiateRecord hook (or use an addon like ember-m3 which does so)