Ref uses algebra `idProp` (getIdProps) as ID interface

[BigAB]

trafficstars

This is a question more than an issue

Currently a Ref uses the idProp returned from getIdProps(connection)[0] to decide the interface for getting the ID of the reference. For example if you have an algebra like this:

new set.Algebra(
  set.comparators.id("_id")
);

Then your ref will be able to access the referenced object using .value and the referenced objects ID using ._id.

  assert.ok(monthlyOSProject.osProjectRef._id === "qwe123", "osProjectRef id is correct");

The interface is dynamic, in the sense that you access the id baed on the referenced objects type (algebra to be specific) and what it considers the ID.

Is this really what we want?

Or should Ref objects have a consistent interface value and id where id behaves like value, returning the proper value from the referenced object (in this case osProjectRef.id would return osProject._id.

Also, how would this work with compound ids?

[justinbmeyer]

I 60% think it's what you want because in every other situation, you'd write something._id. Also, the old can.Model had something similar to forcing id no matter what and it would trip people up. I think documenting this right will help confusion.

40% of me thinks that it should be .id so there's a standard interface.

Sent from my iPhone

On Nov 29, 2016, at 12:42 AM, Adam L Barrett [email protected] wrote:

This is a question more than an issue

Currently a Ref uses the idProp returned from getIdProps(connection)[0] to decide the interface for getting the ID of the reference. For example if you have an algebra like this:

new set.Algebra( set.comparators.id("_id") ); Then your ref will be able to access the referenced object using .value and the referenced objects ID using ._id.

assert.ok(monthlyOSProject.osProjectRef._id === "qwe123", "osProjectRef id is correct"); The interface is dynamic, in the sense that you access the id baed on the referenced objects type (algebra to be specific) and what it considers the ID.

Is this really what we want?

Or should Ref objects have a consistent interface value and id where id behaves like value, returning the proper value from the referenced object (in this case osProjectRef.id would return osProject._id.

Also, how would this work with compound ids?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[justinbmeyer]

We might be able to provide both _id and id

Sent from my iPhone

On Nov 29, 2016, at 12:42 AM, Adam L Barrett [email protected] wrote:

This is a question more than an issue

Currently a Ref uses the idProp returned from getIdProps(connection)[0] to decide the interface for getting the ID of the reference. For example if you have an algebra like this:

new set.Algebra( set.comparators.id("_id") ); Then your ref will be able to access the referenced object using .value and the referenced objects ID using ._id.

assert.ok(monthlyOSProject.osProjectRef._id === "qwe123", "osProjectRef id is correct"); The interface is dynamic, in the sense that you access the id baed on the referenced objects type (algebra to be specific) and what it considers the ID.

Is this really what we want?

Or should Ref objects have a consistent interface value and id where id behaves like value, returning the proper value from the referenced object (in this case osProjectRef.id would return osProject._id.

Also, how would this work with compound ids?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.