[Enhancement Request]: Ability to define virtual fields within Simple Schema about meteor-simple-schema HOT 5 CLOSED

I understand the use case. Virtual fields are inherently "a collection2 thing" since they rely on transform, but it's possible that we could rethink the options "API" such that they are defined in SS definitions (similar to how denyUpdate, etc. are inherently related to collections, but C2 has you define them in the schema definition object.

Specifically, I'm thinking of something like this:

var c = new Meteor.Collection("c", {
  schema: new SimpleSchema({
    creatorEmail: {
      type: String,
      virtual: function (doc) {
        return getCreatorEmail(doc.createdBy);
      }
    }
  });
});

This would require a way to tell the simple-schema package to ignore definitions that are virtual. I'm not sure I'm sold on doing it yet, but we can keep this open as a proposal.

from meteor-simple-schema.

You're right, it would also contextually make sense to keep it in c2.

As I am progressing on my first "rather complicated" meteor app (coming
from javaee), I see this multiple times. It may not always be the case
but for the current app, my schemas often share properties that can
otherwise be reused and be represented in other ways. Virtualfields
would have been a great fit for the use case. Currently, I'm trying to
pass those properties through some common utility functions after I
retrieve them. Trying to keep them reactive, though is the harder part
which seems to require even further abstraction. In the end, the code
becomes harder to follow and maintain.

On 01/16/2014 08:07 PM, Eric Dobbertin wrote:

I understand the use case. Virtual fields are inherently "a
collection2 thing" since they rely on transform, but it's possible
that we could rethink the options "API" such that they are defined in
SS definitions (similar to how |denyUpdate|, etc. are inherently
related to collections, but C2 has you define them in the schema
definition object.

Specifically, I'm thinking of something like this:

var c = new Meteor.Collection("c", {
schema: new SimpleSchema({
creatorEmail: {
type: String,
virtual: function (doc) {
return getCreatorEmail(doc.createdBy);
}
}
});
});

This would require a way to tell the simple-schema package to ignore
definitions that are virtual. I'm not sure I'm sold on doing it yet,
but we can keep this open as a proposal.

—
Reply to this email directly or view it on GitHub
#49 (comment).

from meteor-simple-schema.

Oh, now I get this. Brilliant!

On 01/16/2014 08:07 PM, Eric Dobbertin wrote:

I understand the use case. Virtual fields are inherently "a
collection2 thing" since they rely on transform, but it's possible
that we could rethink the options "API" such that they are defined in
SS definitions (similar to how |denyUpdate|, etc. are inherently
related to collections, but C2 has you define them in the schema
definition object.

Specifically, I'm thinking of something like this:

var c = new Meteor.Collection("c", {
schema: new SimpleSchema({
creatorEmail: {
type: String,
virtual: function (doc) {
return getCreatorEmail(doc.createdBy);
}
}
});
});

This would require a way to tell the simple-schema package to ignore
definitions that are virtual. I'm not sure I'm sold on doing it yet,
but we can keep this open as a proposal.

—
Reply to this email directly or view it on GitHub
#49 (comment).

from meteor-simple-schema.

@serkandurusoy, after checking out the code for the collection-helpers package, I'm thinking about deprecating virtual field support entirely and having people use that package instead. I think it's a better method. I also opened an issue for a collection-helpers enhancement which, if added, would I think meet your needs.

from meteor-simple-schema.

Sounds very logical and I'm sure everyone would benefit from the gains introduced by such decision.

from meteor-simple-schema.