You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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).
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
orcolumns_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.
Here's a centralized version without the duplication.
===
is used to match objects passed torender
, and the result of the block is passed to the render pipeline. Vaguely like a centralized transformer.Very curious to hear back, either about this kind of extension or extensions in general. Thoughts I've been having are:
The text was updated successfully, but these errors were encountered: