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
email@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?
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.