[bug] Incorrect view used during render

[jhollinger]

Is there an existing issue for this?

• I have searched the existing issues

Is this a regression?

• Yes, this used to work before

Current Behavior

I've traced this issue back to #503. One could debate whether it's a "bug" or not, but it's hitting our own codebase really hard.

class WidgetBlueprint < Blueprinter::Base
  fields :id, :name

  view :extended do
    field :code do |widget, options|
      code = options.dig(:code_cache, widget.code_id) || NullCode
      # CodeBlueprint better have whatever view is set in options!
      CodeBlueprint.render_as_hash(code, **options)
    end
  end
end

class CodeBlueprint < Blueprinter::Base
  fields :id, :name
end

# Raises 'Blueprinter::BlueprinterError: View 'extended' is not defined' on CodeBlueprint
WidgetBlueprint.render(widget, view: :extended)

IMHO the above is an anti-pattern, but realistically it's pretty common. What if we put the view name in a different, unused option key (e.g. :view_name, :parent_view)?

Expected Behavior

No response

Steps To Reproduce

See above

Environment

Any

Anything else?

No response

[lessthanjacob]

Great catch! Certainly feeling the pain of these generic options blobs more and more 😅.

If we feel as though this is undesirable, I think that it'd be reasonable to alter the key name with the expectation that folks need to explicitly provide it to the next blueprint wherever this behavior would be desirable.

Ideally, the this information should be available without having to pass it around via options, but that refactor may be more impactful than we'd want it to be. Let me take a look, though, in any case.