We have a number of Atlassian Connect Express apps (for both JIRA and Confluence) that consume and use AUI v7.9.9 as follows:
AUI packages locally installed from npm (npm install @atlassian/aui)
The main layout template (layout.hbs) includes the JS/CSS bundles from /node_modules/@atlassian/aui/dist/aui/{css/aui.min.css, js/aui.min.js} in script/link tags
Client-side app code relies on the presence of the window.AJS global (a side-effect of aui.min.js)
A couple of years ago (almost) when AUI 8.x was released, the packaging of AUI changed and the /dist/aui/aui.min.{js, css} bundles were replaced with /dist/aui-prototyping.{css, js}.
However at the time the 7.x ā 8.x Upgrade Guide warned:
The āprototypingā bundle of AUI is not intended to be used in production systems
ā¦but for various reasons couldnāt get this working and ended up reverting back to AUI 7.9.9.
Fast forward to today, and AUI 9.x is here. So weāre just checking back in to see if there have been any improvements to consuming AUI for Atlassian Connect Express?
Specifically:
Is including the aui-prototyping.* bundles in production systems still discouraged?
Is 9.x now easier to consume directly through native imports than 8.x was, or would the same issues still exist?
Are Typescript definitions (*.d.ts) available for AUI yet?
Hoping that in two years there has been some progression on this front, as weāre increasingly uncomfortable still using AUI 7.x in our apps now that there have been two major versions since.
There have not been any deliberate changes to improve consuming AUI via Node or for Connect. The situation is similar to how it was last time we discussed it.
Using the aui-prototyping.{js,css} files in production is discouraged due to their page weight. With that said, it may be worth testing and checking whether it has a significant impact on performance metrics in your app.
The Server Platform team are maintaining AUI for use in Server products and apps. Improving usage through Node is not planned, nor is defining types for the library. Itās not likely the team will commit to significant changes to the shape of the Node package in the next few months.
What changes to the AUI library would the most valuable to you? What are the most significant blockers? Perhaps there are changes we could discuss and plan with the Server Platform team.
Appreciate that AUI was not primarily intended for Connect apps, and understand that it isnāt currently a focus.
What changes to the AUI library would the most valuable to you? What are the most significant blockers?
I guess Iād turn that question around and ask: what guidance would Atlassian give to developers building Connect apps that:
are not built in React (rules out using AtlasKit),
need to show an alert or error to the user (i.e. want to align with the ADG, but donāt need the whole component library for their UIā¦just one or two components)
Thatās the situation we find ourselves in with our apps (we only use the messages component). We also have common client-side code that we share between our Server, DC and Cloud versions, so being able to standardise on the same component library (AUI) is ideal.
Understand that with Forge just around the corner, things will change again (although itās not quite clear to us yet what the migration process will be for moving our existing customers from Connect ā Forge; so itās possible that weāre going to continue running our existing Connect apps until it makes sense for us to move to Forge).
If I were to list in order of priority the things weād like to be able to achieve with AUI (or any other non-React based component library), it would be:
Ability to import just the components we need
Not rely on a global AJS object to exist
Support for Typescript (*.d.ts definitions)
The last one isnāt critical (since we only use a few components, we can easily write our own definitions).
I must admit my ignorance at how Connect apps are built and what APIs are available. Iām asking internally and will see what advice comes back specific to this scenario re: adding a message to your page.
Re: the ability to import just the components you need + not rely on the AJS global, Iāll see what could be done. I predict some complexity to make it work across all of AUI, and build tooling would likely be a requirement.
e.g., if you import { messages } from '@atlassian/aui', would you expect that to bring in any CSS, too? We would need some way to manage the expectations around what code and how much code a given import brings in.
For me personally, since weāre using Webpack to build our app (and we already use css-loader etc.), my natural inclination would be simply:
import { messages } from '@atlassian/aui';
import '@atlassian/aui/path/to/messages.css';
ā¦but as you point out, that makes some assumptions about the build tooling being used.
Iām not normally one to jump on the āwebcomponents solves everything!ā bandwagon, but I do wonder if perhaps this might be a good case for publishing AUI as a set of custom elements (with styling baked into the shadow DOM).
That would obviously preclude IE (doesnāt support custom elements), but it would provide a way of consuming ADG components in a totally framework/build-agnostic manner, e.g.
<!-- import the custom element (includes all styles & behaviour) -->
<script type="module" src="node_modules/@atlassian/aui/spinner.js"></script>
...
<!-- use it -->
<aui-spinner size="large" filled></aui-spinner>
Anyway, appreciate that this is not a simple challenge to solve in a way that suits everybody; so Iām looking forward to hearing what advice comes back.
Thanks again for taking the time to engage on this.
Weāre in the same boat (trying to upgrade AUI 7 to AUI 9) and are currently weighing our options. Since we always used aui-experimental in AUI 7, it doesnāt look like the aui-prototyping files would be significantly larger.
Maybe we could also modify the AUI build to only include the modules we actually need in the aui-prototyping files? Has anyone tried that?