ruby-grape / ruby-grape/grape-entity

Deep merging of nested exposures and presenter exposures (with :using option)

Open
#154 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature question
Dominant language
Ruby
Stars
729
Forks
154
PR merge metrics
No merged PRs in 30d

Description

Suppose this case:

class GeneralInfo < Grape::Entity
  expose :gender, :age
end

class Student < Grape::Entity
  expose :info, using: GeneralInfo
  expose :info do
    expose :grade
  end
end

Student.represent({info: { gender: 'male', age: 25 }, grade: 5 }, serializable: true)
# => {:info=>{:grade=>5}}

But I assume info[:gender] and info[:age] to be exposed too. Also:

class Person < Grape::Entity
  expose :info do
    expose(:gender) { |obj| object[:info][:gender] }
    expose(:age) { |obj| object[:info][:age] }
  end
end

class Student < Person
  expose :info do
    expose :grade
  end
end

Student.represent({info: { gender: 'male', age: 25 }, grade: 5 }, serializable: true)
# => {:info=>{:gender=>"male", :age=>25, :grade=>5}}

Since we decided not to rewrite previously defined exposures in #151 then more consistent behavior would be make these cases act identical. It's good to think of presenter exposures (with :using option) as a nested exposures incapsulated in the separate classes.

Ones who want an old rewriting behavior should use conditional exposures (:if, :unless options).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review issue #151 and the existing nested-exposure behavior before choosing an implementation approach. Reproduce both examples from this issue, then define the expected merged result for presenter exposures using :using and inherited exposures; done means both cases behave consistently without rewriting previously defined exposures.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.