Added view_names method in Blueprinter::Base

[wollistik]

[mcclayton]

Hey @wollistik, could you please describe the use case you have for this? The core maintainers team would like to compile a list of how you and others might use this feature to determine adoption of this. Thanks!

[wollistik]

Hi @mcclayton ,

I have several use cases for this:

1. We have an versioned API based on request headers, so the Controller-Action is always the same (and so the Blueprinter class we use). We are naming the Blueprinter views based on the version (e.g v1, v2, etc.) and then determine the requested version by comparing all available views in the Blueprint. Currently we use a hack with blueprint.send(:view_collection).views.keys, but this feels not right.
2. We use the same hack for running smoke tests for all Blueprinter classes we have and want to test the views defined there. Yes, proper testing all views would be better, but we have a legacy app and quite a lot of Blueprinter classes there, sosmoke tests are better than no tests at all.

[dlcarter]

Thank you for your use cases. There are a number of other related PRs and concerns we are taking into consideration. We are looking into how to best consolidate these approaches into one implementation. This effort can be tracked with https://github.com/procore/blueprinter/projects/2#card-57792153

[saxxi]

@dlcarter imo this PR could get along well with dynamic views (which would be amazing if ever implemented):

• Static views for known sets of data
• Dynamic views where the is the caller to "decide" which fields are needed

(BTW thanks for this project 🙏)

[plypkie-mb]

@mcclayton -

FYI we are doing something similar. We are generating TypeScript interfaces based on the views in the blueprint, and for part of that we have:

view_names = blueprint_class.send(:view_collection).views.keys.reject { _1 == :identifier }

As an additional note, we also want to be able to inspect the included_view_names of each view, which we use to determine inheritance in our generated TypeScript types.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lessthanjacob]

We've recently merged a PR authored by @jhollinger that adds a reflection API to each Blueprinter class that might be useful here (#357):

# Returns a Hash mapping a "view" key to an instance of Blueprinter::Reflection::View 
# (which encapsulates the relevant view collection)
(pry)> TaskBlueprint.reflections.keys
=> [:identifier, :default, :compact, :extended]

Immediately, it's not clear that reflections.keys are just the view names, but we could add a similar helper method to the one you've implemented in this PR to Blueprinter::Reflection for that (there's some history in linked PR as to why we decided against naming this Reflection#views, as well as why we opted not to expose the "internal" classes as part of this).

That said, I don't think it'd be unreasonable to continue with this current approach though, especially since we already expose a Base.view? method.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.