Improve FluxUiComponent disposed store logging

[greglittlefield-wf]

Motivation

We have some warning logs in place for before FluxUiComponent(2) components attempt to subscribe to disposed stores.

These logs weren't very helpful, though, since they didn't contain a stack trace, component name, or store name.

Changes

• Add more information to logs
  • Add a utility to get a Dart component name from its Dart instance
• Add basic unit tests for this logging

Release Notes

Review

See CONTRIBUTING.md for more details on review types (+1 / QA +1 / +10) and code review process.

Please review:

QA Checklist

• Tests were updated and provide good coverage of the changeset and other affected code
• Manual testing was performed if needed
  • Steps from PR author:
  • Anything falling under manual testing criteria outlined in CONTRIBUTING.md

Merge Checklist

While we perform many automated checks before auto-merging, some manual checks are needed:

• A Client Platform member has reviewed these changes
• There are no unaddressed comments - this check can be automated if reviewers use the "Request Changes" feature
• For release PRs - Version metadata in Rosie comment is correct

[aviary-wf]

Security Insights

No security relevant content was detected by automated scans.

Action Items

• Review PR for security impact; comment "security review required" if needed or unsure
• Verify aviary.yaml coverage of security relevant code

---

Questions or Comments? Reach out on Slack: #support-infosec.

[greglittlefield-wf]

I wrapped both the assert and the log in this check so we could conditionally build a shared message instead of computing it unnecessarily. The control-flow of this method should be the same as it was before.

[todbachman-wf]

Would it be better to use a ContextualMessage and put storeNameOrType and shouldBatchRedraw in the context of the message instead?

[greglittlefield-wf]

I really wanted to do that, but unfortunately I'd have to depend on app_intelligence_dart to get that class (which we can't do since this is an OSS repo, but even if it weren't I'd be wary about).

It'd be nice if you could pass in a Map or some other core type and have it treat it the same as a ContextualMessage.

[todbachman-wf]

Ahh. I didn't realize that was an AID-specific class.

[todbachman-wf]

QA +1. The unit tests added should be sufficient for this change.

[greglittlefield-wf]

@Workiva/release-management-p

[rmconsole-wf]

+1 from RM