Hey @kchan,
I do not have any expectations how the respective modules are implemented. They could be part of something like @forge/bridge, after all, flags, modals/dialogs have to be displayed from the context of the top window.
Flags: A forge app should be able to create flags as displayed at https://atlassian.design/components/flag/examples. As a user of flags I want to provide a title, a message, the type of flag and if it automatically dismisses.
Dialogs/Modals:
Ideally, we can create new windows from the context of the top window object, i.e., we can have “full screen”(or very large in width and height modals/dialogs) iframes which can contain Custom UI. Possibly, this just loads another module which contains another custom UI created by e.g. create-react-app.
At a minimum, I would expect dialogs which allow user interaction as shown at https://atlassian.design/components/modal-dialog/examples, such that I can display warning, confirmation, danger dialogs.
Use cases:
Flags: We have apps that show flags after certain actions, for example, after a user saves their changes.
Dialogs: We have apps that show a dialog before a user proceeds with “dangerous” actions, e.g., getting the system/app/component into a state which will require restoring from backup. Another app uses dialogs to query for additional details and asks the user for input by showing e.g. a userpicker.
Surely some components of our apps can and will be redesigned to not rely on flags and dialogs, given future Forge limitations. However, I can safely assume that this is not possible for all components that our current Server/DC only apps use. A result would still be achievable without flags and dialogs, but the user experience will be decreased.
I have gathered a few more “blockers” or at least questions w.r.t. current Forge design:
-
The iframe contains attributes to define a sandbox="allow-forms allow-scripts allow-same-origin". As such, actions like navigation on the top frame are currently not possible. If my app shows a link to e.g. a Confluence page, then the page change would occur within the iframe, instead of the top level window.
-
Server/DC and Cloud in the top level window provide context parameters, e.g., AJS.Meta which is not available in the Forge iframe when using Custom UI. The backend receives information when called via @forge/bridge. How can I choose the correct language for I18n in a custom UI? How can I efficiently query for additional variables that define the context of the page, user, etc.?
-
Given the currently available Forge features, my ideal app creation workflow would look like this in the future:
- Create a frontend-module with
create-react-app or similar. Reuse available components from Atlaskit. Share the frontend-modules between Cloud and Server/DC app.
- Define a service which allows to choose between Forge or Server/DC backend for all frontend to backend communication. Inject the correct service based on DI (e.g. Inversifyjs).
- Define separate backends for Forge and for Server/DC.
- Use the available integrations to show the created frontend-modules to the user (Forge —> Custom UI, Server/DC —> reuse the idea of using an iframe as we see it today in Forge).
- Provide a bridge for Server/DC which allows iframe <—> iframe, and iframe —> backend communication, similar to what
@forge/bridge provides.
- Ship the same Cloud and Server/DC app to customers as I’m able to reuse all of my frontend code and waste less time in fixing Server/DC or Cloud specific shenanigans.
)