What is holding up the uniqueness validator?

By: Brian Cardarella
checklist

ember-validations has nearly all of the validator rules one needs. One glarring omission is the Uniqueness validator.

Not as straight forward as one would think

Before we even talk about the complication with implementing the remote validator, we should talk about if uniqueness should be both a remote and local validator.

Imagine you are working with ember-data, you attempt to create a new record with an email test@example.com. If you already have a record with that value for email in ember-data’s store should uniqueness first defer here before we hit remote? This ends up being a strange thing because what if you have not persisted that first record yet. Do we only run uniqueness checks against local records that have been persisted? And how exactly would this fit in if you are mixing your validations into the controller instead of the model?

If the email example isn’t working for you, imagine you are adding a bunch of line items to a parent record. None of these line items have been persisted yet. And you don’t want to allow your users to add another until the current one they are working on is “valid”. Validating uniqueness locally is all of a sudden very valuable. But also very complex to implement properly.

No standard yet

If the local validator is too complex of an animal to tackle perhaps the remote validator implementation will be easier. It is, in part at least. We can rely on Ember.run.debounce to ensure the the remote validator doesn’t fire too frequenly when many changes are happening to the value of a property. (i.e. entering text into a field)

But where do we send this request for uniqueness? This is where I am currently hung up. I really don’t want to implement a backend api expectation into ember-validations. I was hoping that something like json-api would define this for me then I could rely upon that as a starting expected endpoint. But I don’t think this is anywhere on their radar.

This being said, there is a possible solution. One of my co-workers Lin Reid has put together a PR for introducing remote uniqueness to ember-validations. It is lacking tests (hint hint, Lin!) but I think this is moving in the right direction.

To summarize, uniqueness is not forgotten. It is just a pain in the ass to do properly. Personally, I would prefer not to implement an API have people buy into it now and have to change it (or be locked into it) a few months from now.