Will there be support for switching from staticView to the dynamic macro view on demand?
Our goal is to use staticView as a performance optimization for macros that are primarily viewed but occasionally interacted with.
In the proposed design, a macro initially renders dynamically, generates a snapshot, and subsequently renders as static ADF. However, many of our macros support user interactions such as filtering, sorting, and other data manipulations that require the dynamic iframe experience.
Would it be possible to programmatically switch from a rendered staticView snapshot to the dynamic macro view (for example, via a “Switch to interactive mode” button)?
A possible workflow would be:
-
The page initially loads the ADF snapshot for fast rendering.
-
The user clicks a button to enter interactive mode.
-
The dynamic macro loads and allows filtering, sorting, and other interactions.
-
When the user changes the state, the application updates the snapshot.
-
Future page loads again benefit from the updated static snapshot.
As an additional optimization, would it make sense to support preloading the dynamic iframe in the background while displaying the static snapshot? This would allow an almost instant transition to interactive mode without waiting for the iframe to initialize after the user clicks the button.
What are the expected Forge Function costs for keeping staticView snapshots up to date at scale?
One of our concerns is that snapshot maintenance appears to shift rendering costs from page views to snapshot generation and refresh operations.
In real-world scenarios, snapshot updates may be triggered by page updates, macro configuration changes, user actions, scheduled jobs, or changes in external data sources. For apps with many macro instances across large customer sites, this could result in a significant number of snapshot refreshes.
Is the expectation that these refresh operations will be performed through Forge Functions (e.g. scheduled triggers, event triggers, or other Lambda-like execution mechanisms)?
If so, could Atlassian provide guidance on:
-
The expected cost model for maintaining snapshots at scale.
-
The impact on Forge invocation quotas and usage limits.
-
Recommended patterns for minimizing invocation costs.
-
Whether there are plans for platform-level optimizations (e.g. bulk updates, event aggregation, built-in caching, or other mechanisms) to reduce the operational cost of keeping snapshots fresh.
We are particularly interested in understanding whether large apps with thousands of macro instances could end up generating substantial Forge usage solely for snapshot maintenance.
How should applications handle concurrent usage and snapshot ownership when multiple users interact with the same macro?
One concern we have is how staticView behaves when multiple users are working with the same page and macro.
For example:
-
User A opens the macro in interactive mode and changes filters, sorting, or other view settings.
-
The application generates and stores an updated snapshot.
-
User B opens the same page later.
In this scenario:
-
Is the updated snapshot expected to become the new default view for all users?
-
Should snapshots be considered shared page-level state or user-specific state?
-
What is the recommended approach when user interactions modify only the presentation of the data rather than the underlying data itself?
We are concerned that one user’s view customization could unintentionally affect the experience of other users if snapshots are shared across all viewers.
Does Atlassian envision any platform support or recommended patterns for handling this type of collaborative scenario?