Global: Standardize List Refresh After Mutation (addRecord/create/update/delete) Across All ObjectUI Scenarios

[hotlong]

After thorough code analysis of the entire ObjectUI codebase, I identified this as a platform-level architectural design deficiency, not just a single bug. Here's the complete assessment:

5 Root Causes Identified

#	Root Cause	Affected Packages	Severity
1	No unified event-driven refresh model — DataSource.create/update/delete completes silently; no active views are notified	@object-ui/types, all consumers	🔴 Critical
2	ListView lacks imperative refresh() API — onAddRecord is fire-and-forget, parent cannot signal re-fetch	plugin-list	🔴 Critical
3	refreshKey not propagated — ObjectView.handleFormSuccess increments its own refreshKey, but renderListView renders a ListView with an independent refreshKey	plugin-view ↔ plugin-list	🔴 Critical
4	Schema-level refreshAfter not universally honored — only works in RecordDetailView actions, not in addRecord, bulk ops, lookup quick-create, etc.	plugin-view, plugin-detail, plugin-list	🟡 High
5	Duplicated manual fetchData/setRefreshKey boilerplate — User, Org, Role, Permission pages each hand-roll their own refresh logic	apps/console	🟡 Medium

3-Phase Solution Proposed

Phase	Scope	Key Deliverables
P0 — Immediate Fix	Pass refreshKey through renderListView → ListView + add refreshTrigger prop	Fixes the reported bug
P1 — Imperative API	ListView exposes ref.refresh() via forwardRef + useImperativeHandle; abstract useListRefresh hook	Any parent can trigger refresh
P2 — Event Bus	DataSource.onMutation() subscription; all views auto-refresh on relevant object mutations	Salesforce/Retool/Airtable parity

Industry References

The issue includes design comparisons with:

• Salesforce Lightning — refreshApex / force:refreshView event bus
• Retool — query.trigger() invalidation
• Appsmith — onSuccess → listQuery.run() action chaining
• Airtable — Optimistic insert + server-confirm sync