Today, I spent longer than I feel comfortable admitting solving a supposedly simple problem in my EmberJS application. Since this particular issue was so frustrating and undocumented I'm going to share my experiences in case someone else comes across the same hair-pulling nightmare in the future.
The application in question is a private dashboard system which allows clients to create and manage their own business profiles. It's getting close to launch so I decided it was time to spice up the UI with some nice error messages that are helpful to the user. The idea was to highlight the fields that have errors and display a message underneath explaining why there was an error. In Rails (or any other framework) this would be very easy or even built right into the form helper in some cases. In EmberJS? Seemingly straightforward, but it turned into an afternoon of rabbit holes and head-banging against my desk.
Ember, or rather Ember Data has error helpers built right into the models. Actually figuring out how to use those helpers is another story altogether. I wasn't able to find any tutorials and the API documentation wasn't clear on what to use. There was also no indication as to what formatting errors should be in. The Rails Application I was developing against output data in the following format:
I'm not overly fond of the layout, but it seems fairly standard in rails applications. Checking my models for errors was bringing back absolutely nothing so it was time to do some digging around the source code. An assumption lead me to search the Rest Adapter file since that's where all the Ajax requests are handled.
Sure enough, from the code above you can see that anything in the
errors attribute is returned as a DS.InvalidError. Unfortunately, this code is not part of the adapter by default. It's actually commented out and put there as suggested functionality if you need it. After patching that code into my adapter I then had to update the API output. Luckily this version of the API has never been released to the public yet and our applications that currently use it internally are in private Beta and heavily tested. I added a helper to my Rails application controller which is easily tested and keeps the output consistent.
A very simple snippet of code. All it does it make sure the errors field is set. This allows us to change it to any other field name in the future to update all errors output in one go. It also defaults to a 500 http status code unless one is passed through. To use the code is very straight forward.
Okay, so now I've figured out the issue and patched the adapter. The API is outputting the correct formatting now so everything should just work as expected. Wrong. You didn't think Ember would be that kind, did you? Here is the below pseudo code that I expected to work after these changes:
The actual code is a lot more complex, but this demonstrates that I was essentially iterating over each of the errors on the
name field and displaying it inside a label tag. The actual output in the application was
I started inspecting the Ajax response objects in the chrome console and the output was as I expected. The
DS.InvalidError object that I was returning was in the following format:
This is exactly what I expected. I even triple checked my
each block and it didn't make sense why "can't be blank" was coming out as "[Object object]". I went digging around the source code some more and turns out the DS.InvalidError object is not actually used, and instead is used to create a
DS.Error object which then gets attached to
DS.Error object is in the following format.
I'm not 100% sure of the design choice behind that object formatting. All I can assume is that each error block is global and assigned to the fields when needed which is why they have the attribute attached. Once I figured this out the fix was quite simple.
Grey Hairs Ahoy!
Finally everything was working as expected. This was originally a quick form to add a new Business profile which should have taken no more than 10-20 minutes of my time. I ended up taking closer to 2 hours which pushed back some other features from getting launched. On the upside, if I ever need to use these kind of model error validations again on other projects I will be able to write them instantly without any worries.
I think I covered all the major points but feel free to comment if you're having the same issue and this doesn't solve it. Also, if you managed to solve this another way without cutting years off your life I'd love to hear about it.