Option to use client-side generated UUIDs

[adambiggs]

If a model has been given a @uuid() method, it'll be used in the constructor to generate @cid, and also set @id to the same value right away (without waiting for @save()).

This allows records to be created by relation.coffee without needing to wait for server-generated IDs to associate them. I use this for scenarios where a controller needs to build a few (unsaved) related records which it may or may not send to the server depending on user actions.

Example usage with node-uuid:

# Enable for all models
Spine.Model.extend uuid: -> uuid.v1()

# Enable for a single model
class Client extends Spine.Model
  @configure 'Client', 'name'
  @uuid = -> uuid.v1()

Here's what it can do:

PhoneNumber.belongsTo 'client', Client
Client.hasMany 'phone_numbers', PhoneNumber

# Records can be related before they're saved
new_client = new Client
  name: 'John Doe'
phone1 = new PhoneNumber
  name: 'Home'
  number: '1-444-555-6666'
  client_id: new_client.id

# Nested relations can be created by an instance constructor
new_client = new Client
  name: 'John Doe'
  phone_numbers: [
    { name: 'Home', number: '1-444-555-6666' },
    { name: 'Cell', number: '1-443-553-4444' }
  ]
# An unsaved Client instance will be created with an ID, 
# and the Photo model will be refreshed with 2 new related records.

Everything works as usual if the @uuid() method is missing.

[aeischeid]

This is one of those I don't have a direct need for, but seems like it would be useful.

Since one of the appeals of spine is approachable source code I think documenting this well is important if we want to include it as it would have potential to confuse. As it is I think the id vs cid stuff can get a little perplexing for people new to spine or client side MVC in general.

[adambiggs]

As it is I think the id vs cid stuff can get a little perplexing for people new to spine or client side MVC in general.

Agreed. Not only that, but it seems to me that the whole idea of waiting for id to be returned from the server goes against Spine's asynchronous UI philosophy. In a perfect world we wouldn't need cid, and the id would never change once a record is created...

I wonder if it would be practical to add node-uuid as a core dependancy and make client-side UUIDs the default behaviour in a future version of Spine (#434).

[cengebretson]

I really like the idea of a being able to plugin different modules/code to override the default id creation. One question on this, does this end up breaking the @isNew function (which is used in the @save function to call either create/update)?

If we are setting up the @id value immediately I think spine would treat everything as already saved and always end up calling the update method. Curious how you are handling that... thanks!

[adambiggs]

I haven't noticed any changes. @isNew uses @exists, which returns undefined if a record can't be found in the model store for the passed ID. So even though new Client().id is a real UUID, everything still works as expected:

new Client().isNew() # true
new Client().save().isNew() # false

[cengebretson]

Now that I think about it, that makes sense, as long as its not stored in the @records array it should be considered new...

[aeischeid]

Think we could bring this in. Mostly could use content of pull request description for documentation it looks like.