Here is the scenario:
"errors": {"title": ['cannot be blank']}
Using a recent version of Ember-Data, what are the status flags that should be set on my object?
I’m seeing isError === true and isValid === true and the errors object attached to my record is empty.
I would handle this kind of logic on the client side. In my case, I have some components that you can set as required, min/max length, etc. and throw formatted errors to the user instead of sending them to the server. It makes the app much more responsive and gives you more fine-gained control over behavior.
Obviously, the validation needs to also exist on the server, but I would suggest designing your app so that it can’t make illegal requests. After that, “succeed” or “fail” is about as specific as your ember data handlers need to be.
Kind of sucks to duplicate the validation logic , but I don’t know of a more elegant way. I generally think of the client and server as two independent systems that just need to configured to play nice.
Hope this helps!
thanks for the feedback @kylecoberly.
I agree that client side validation provides a better experience, but there is just no way that everything can be client side. The most basic example of this is validating the uniqueness of an attribute, which requires server-side feedback.
Funny enough, I managed to sort of my issue.
It turns out that the ic-ajax library overrides the default RESTAdapter’s ajax method, but does handle error states properly (I think?).
Once I reopened the RESTAdapter and redefined the ajax method Ember-Data started working as expected.
Glad your issue is fixed! That’s good intel on ic-ajax.
I think how I would handle the uniqueness issue is by using AJAX (separate from Ember Data) to query the database, trigger a flag on success, and not allow a form to be submitted until the flag was true. Still gives you the flexibility to do what you need to do server-side, and lets Ember Data stick to what it’s good at. It also gives you a chance to do that kind of validation in real-time, which a double-plus-good UX on desktop. Might be a little messier on mobile because of all the extra HTTP traffic, but not impossible to work around.
Cheers!