Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion of a stable reflection API #341

Closed
jhollinger opened this issue Oct 3, 2023 · 3 comments
Closed

Discussion of a stable reflection API #341

jhollinger opened this issue Oct 3, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@jhollinger
Copy link
Contributor

As a follow up to the discussion in #294, things like auto-preloading of ActiveRecord associations could be done through Blueprinter extensions if there was some kind of reflection API available (think ActiveRecord's reflections or columns_hash).

I've been experimenting with such an extension and have a good handle on what kind of info it needs from Blueprinter (essentially "give me all the associations for view X recursively"). But I don't want to design something overly-specific, so I'm hoping to gather some feedback. As a point of reference, here's some POC work:

This is non-invasive to Blueprinter, aside from requesting all the associations from the view. The duplication of the Blueprinter class and view isn't ideal.

q = Widget.
  where(...).
  order(...).
  preload_blueprint(WidgetBlueprint, :extended)

render json: WidgetBlueprint.render(q, view: :extended)

Here's a centralized version without the duplication. === is used to match objects passed to render, and the result of the block is passed to the render pipeline. Vaguely like a centralized transformer.

# config/initializers/blueprinter.rb

Blueprinter.configure do |config|
  config.generator = Oj
  config.on_render ActiveRecord::Relation do |scope, blueprint, view|
    scope.preload_blueprint(blueprint, view)
  end
end

Very curious to hear back, either about this kind of extension or extensions in general. Thoughts I've been having are:

  • Building a formal reflection API vs switching existing attrs/methods from private to public?
  • Are there other obvious kinds of extensions people would want to build? (Preloading for other ORMs, doc generators, etc?)
@sandstrom
Copy link

Sounds like a good idea!

Apart from preloading, doc generation (which you've also mentioned) is a good candidate. Another one would be generating fixtures dynamically (for use in client-side tests).

@lessthanjacob lessthanjacob added the enhancement New feature or request label Jan 7, 2024
@njbbaer
Copy link
Contributor

njbbaer commented Jan 29, 2024

@jhollinger Can this issue be closed with the introduction of #357 and #358?

@jhollinger
Copy link
Contributor Author

A reflection API was added in 1.0; closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants