Inherit view definition when using inheritance

[hugopeixoto]

Enable field and view definitions on superclasses
to be used by subclasses:

class ApplicationBlueprint < Blueprinter::Base
  identifier :id
  field :created_at
end

class PersonBlueprint < ApplicationBlueprint
  fields :name, :age
end

Objects rendered with PersonBlueprint will contain fields id,
created_at, name, and age.

(Addresses issue #80)

[hugopeixoto]

This may not work when reopening the superclass:

class ApplicationBlueprint < Blueprinter::Base
  identifier :id
end

class PersonBlueprint < ApplicationBlueprint
  field :name 
end

class ApplicationBlueprint < Blueprinter::Base
  field :created_at 
end

Rendering Person in this case would not contain created_at, since it was defined after inheriting. Not sure if we should address this usecase, but it would be a bit harder to implement. We'd have to resolve the view definition at rendering time, since the parent class may be redefined at any time.

Not sure how this interacts with #94 , since that PR seems to redo the whole thing, but I've added integration tests that should cover the common use case.

[philipqnguyen]

This is great work!

I don't think we need to solve for the use case of re-opening the super class, at least not now.

You can ignore #94, I'm still experimenting with that PR (I might close it for now actually so it doesn't cause confusion)

[mcclayton]

I'll defer to @philipqnguyen for desired behavior, but due to the implementation of << in this class, we'd raise an error if a field name collides, however, in inheritance -- you'd expect those fields to be overridable.

[philipqnguyen]

I agree with @mcclayton

I don't even know if we need to raise an error here https://github.com/procore/blueprinter/blob/master/lib/blueprinter/view.rb#L22-L25

Perhaps we can just remove that error all together? I never thought that error to be useful, and I don't think it is the responsibility of blueprinter to protect users from their own mistakes.

[mcclayton]

I agree, would be nice to have some specs to ensure that the last defined field is the field implementation that gets set. Both in a single view with multiple duplicate field name implementations, as well for the case where multiple classes define a field, to ensure the lowest subclass implementation gets set.

[hugopeixoto]

Nice catch. I'll add the specs and remove the guard, then.

[hugopeixoto]

I added a spec for the subclassing scenario and modified the existing spec for the regular overriding scenario. Let me know what you think

[mcclayton]

Awesome, thank you so much @hugopeixoto!

[philipqnguyen]

We'll put this into 0.7.0

[toobulkeh]

🎉