Safety guard when the self.class is not responding to method identifier

[navidemad]

Overview

Issue: #2869

Due to a recent change in the gem view_component
ViewComponent/view_component@451543a#diff-b69c75ffd85596e0b5fca1327059ecf3b2930f3f77004c78a268fa85e8ec8d9eL601

We were getting:
ActionView::Template::Error: undefined method identifier'`

The method identifier on their base class has been removed.
This pull request make sure it returns nil if it is not found.

[CLAassistant]

All committers have signed the CLA.

[joelhawksley]

👋🏻 ViewComponent maintainer here! FYI, this method should never have been used as it was marked private (and not documented in the API docs) ViewComponent/view_component@v3.14.0...v3.15.0#diff-b69c75ffd85596e0b5fca1327059ecf3b2930f3f77004c78a268fa85e8ec8d9eL601.

[fallwith]

Hi @navidemad, thanks very much for creating the GitHub Issue and submitting this fix. Very much appreciated. Your change looks good and will go out in our next agent release.

Hi @joelhawksley. Point well taken. Our preferred approach for gathering metrics and other information from a library is to leverage public APIs. We also often submit PRs against libraries and/or work with maintainers to deliver new or enhanced APIs whenever we need something that doesn't already exist. We don't always take the preferred approach and fall back on using private APIs or monkeypatching though. This can be for any one of several reasons, including shifting schedules and priorities that see us do something to get some coverage in place - especially when in response to a customer feature request - as quickly as possible. In the particular case of ViewComponent, I think we should revisit our instrumentation at some point and take another look at what is possible by consuming the ActiveSupport notifications the library produces. ViewComponent's own lib/view_component/instrumentation.rb, for example, uses self.class.source_location for the identifier. We ought to see if we can simply consume those notifications or if not at least make the same self.class.source_location call for the identifier. I will create a GitHub issue to remind us to look into doing so. For now, this PR is an improvement upon what we already have so I'll go ahead and merge it.

[joelhawksley]

@fallwith makes sense to me. I'd be open to formally exposing the source_location as a public API if you'd find it useful. Let me know!