Present with multiple entities

[adamgotterer]

The response would be the combination of two entities. I've run into this issue with things like pagination blocks. I've had to hack around with body to get something like:

{
  "users": [...],
  "pagination": {
    "page": 1,
    "num_pages": 1000
  }
}

Would be interesting to have a "present multi" feature. Maybe something along the lines of:

present_multi [[ @coupons, with: Entities::Users], [ @pagination, with: Entities::Pagination, root: 'pagination' ]]

Would love to start a discussion and hear other peoples thoughts?

[dblock]

It's a common pattern that a lot of people like in their API. I would extend the existing present and evaluate the right-hand-side parameter type to figure out whether this is a multiple or a single present type.

[adamgotterer]

Do you like the array syntax?

present [[ @coupons, with: Entities::Users], [ @pagination, with: Entities::Pagination, root: 'pagination' ]]

[dblock]

Not as much as I like hashes :)

Seems like all those array structures are redundant. This could be a 2-parameter function

def present(variable, * options)
...
end

present @coupons, with: Entities::Users, root: 'pagination'

[adamgotterer]

How would you know when the first entities options ends and the second begins?

[dblock]

In Ruby this is called splat. It's one of my personal favorite features :)

[adamgotterer]

I'm familiar with splat. So please excuse my ignorance, but I'm not sure I follow how the syntax would work with multiple variables and options? My array syntax lets you customize the present for each variable separately. Can you convert this example?

present [[ @users, with: Entities::Users, root: 'users' ], [ @pagination, with: Entities::Pagination, root: 'pagination' ]]

[dblock]

I guess I didn't include the most important part in my answer :)

{
   users: present @users, with: ...
   pagination: present @pagination, with ...
   ...
}

Rather than a top-level present.

[adamgotterer]

That makes a lot more sense :) Definitely cleaner then mine. I'll see if I have some time over the next week or so to implement.

[dblock]

@adamgotterer I'll be releasing a new Grape version soon, LMK how close/far this is.

[adamgotterer]

I haven't had a chance to work on this yet, been pretty busy. When is the next version out?

[bobbytables]

@dblock @adamgotterer Are you thinking that in the resource you'd have

get '/users' do
  {
    users: present @users, with: UserEntity,
    pagination: present @pagination, with: PaginationEntity
  }
end

Just trying to get a feel for this feature.

[dblock]

Yes, that would look good!

[bobbytables]

I feel this breaks a few things in terms of "who's responsible for what". The grape entities, from my point of view, is the view layer in grape. While this syntax makes sense, I feel like it's giving mixed responsibility for the resource. Because now it relies on how you format data in 2 places.

I think a better solution could be an entity method that excepts "top-level" exposures OR
allow resources to do multiple present calls.

present @users, with: UserEntity
present @pagination, with: PaginationEntity

Would yield:

{
  users: [...]
  pagination: {...}
}