Filter which properties are shown

[OscarGodson]

Right now I have a CurrentUserModel and a UserModel. the CurrentUserModel is just a UserModel minus properties I don't want to show in responses like group memberships such as user settings like email_notifications. It would be neat if you could do something like:

// UserModel fetches
UserModel.first(id, {
  includes: ['foo', 'bar'],
  properties: {
    hide: ['email_notifications']
  } 
});
// GroupModel fetches with UserModel's being eagerly loaded
GroupModel.first(id, {
  includes: ['users'],
  properties: {
    users: {
     hide: ['email_notifications']
    }
  } 
});

[OscarGodson]

Actually, when I wrote this I thought I could just have a CurrentUserModel and I made one, but then I realized that I can't do this because it's going to try and look for a current_user table :\

[mde]

We haven't implemented this, but subclassing models in an ORM is something you can do (although it's complicated: http://blog.thirst.co/post/14885390861/rails-single-table-inheritance).

It sounds like what you're really wanting is a way to specify what fields get returned in a serialization. This is essentially the "scenario-based serialization" we've talked about a lot. We already handle specific scenarios for validation, and it makes sense to do the same thing for serialization.

[marcellodesales]

Right now I'm looking for a way to hide the property type.

{
  "createdAt": "2015-05-26T21:12:58.373Z",
  "userName": "mdesales",
  "content": "The document can be just like this...",
  "id": "0907B712-FB7F-4D4A-8708-452C01B29F9C",
  "type": "Document"
}

Is there a way to do that?

[OscarGodson]

@marcellodesales I actually had to write some kinda crazy code which we call our create-response component which turns model data into a response that I can actually send to clients. One of the things it does is removes the type property (as well as others like password). I clone the model object, loop through each property recursively through associations, turn to snake_case, and if it's on the blacklist I remove it.

It'd be nice if model did this sort of thing itself and created client ready responses, but I do realize that's probably out of the scope of the project. If you'd like @marcellodesales I can send you the custom component that's pretty specific to our app but maybe you can alter it to fit your needs. Hit me up at oscar@getpiggybank.com and I'll send you the code.

[marcellodesales]

Hi @OscarGodson

That would be awesome! StrongLoop's LoopBack does exactly that... We can set which properties should be hidden or not...

I will email you! It definitely would help... But hey, why don't we work to get a feature request to this project? I think this is a valid feature it should support...

thanks a lot for the message!

[danfinlay]

I recently contributed to a rails project a bit, and so I was exposed to their pattern of "Serializers". A serializer becomes a function that takes a payload of models and returns a JSON result, exists in app/serializers/yourModelName.js, and is automatically applied when you call this.render() from a same-titled controller.

This is a pretty clever pattern, and it might be a nice addition to Geddy as a whole.

[mde]

@FlySwatter This is exactly what we're talking about with scenario-based serialization. Is this a part of Rails, or AR?