Front-end development on Confluence Data Center?

Confluence Development Confluence Server
, ,
1

How to you pack your Javascript in Confluence/Jira Server/Data Center?

  • Old stack: WebWork - jQuery - Soy,
  • The iframe way (Remie’s answer below), which gives entire control to the dev and the ability to share resources between Cloud and DC, at the price of only integrating as iframes,
  • AUI + AtlasKit + React (provided by Confluence) + atlassian-webresource-webpack-plugin, but the past history has proven it difficult to maintain app compatibility when core products upgrade their provided libraries.

Various resources:

Is everyone scattered between following 3 ways? Is any of theses stacks “official”, ie the way Atlassian wants us to do?

1 Like
2

In order to avoid the mess surrounding Atlaskit (won’t go into it, but there are plenty of discussion in the community) I use React + my own component library based on radix-ui and reach-ui.

I also find the webresource-webpack-plugin quite useful, so I have stayed with a custom webpack configuration and a straightforward React build.

If I were to start today I would possibly look at either a NextJS-based app or a vite build. And invest in typescript from the start.

It really depends on what you are trying to build. If you need to display a custom field somewhere, then React is overkill.

1 Like
3

Ok, so there is a lot of things to unpack with regard to front-end development and Server/DC.

The most important first step is to acknowledge that formally, all Atlassian product teams try to adhere to the Atlassian Design Guidelines (formally ADG3). However, each team is free to choose how & when to adopt to this standard.

The Atlassian Design System itself comes with a limited set of React components, split of from AtlasKit. The Atlassian Design System team guarantees that these components are maintained and up-to-date with the Atlassian Design System guidelines, but it does not give that same guarantee for any of the other AtlasKit components.

This means that at this point, AtlasKit is no longer formally supported, as the remaining components on AtlasKit do not have a shared owner or guardian and are being maintained individually by several teams within Atlassian.

Now in addition, there is AUI which, contrary to popular believe, is still alive and kicking. AUI also adheres to the Atlassian Design Guidelines, but as of the latest release has implemented those principles using jQuery. All Server/DC products currently ship with some version of AUI and are not using AtlasKit or the Atlassian Design System components.

The Jira DC team has been working on a Front-End API which they acknowledged will also bring React as a dependency to Jira Server however there is no indication that this also means that AUI components will start using React. It mostly seems like a way to cater to the community to ship a React version that would allow you to use React based components (like DS or AtlasKit).

There is no formal statement about the preference of using AUI, DS or AtlasKit in Server/DC products. They all formally adhere to ADG and as such should be interchangeable. Obviously, this isn’t true, but :person_shrugging:

We have chosen to stick with DS / AtlasKit for now as we want to have a single front-end that both caters to Server/DC & Cloud and up until now consider AtlasKit to be the most up-to-date implementation of ADG for Cloud. It also removes the requirement to consider different AUI versions in older Server/DC systems.

In order to avoid any collisions, we are using iframes for all our UI extensions in Server/DC. We ship our own version of React & other front-end libraries that are running sandboxed in the iframe to ensure that we do not interfere with the host product. We created a polyfill for Atlassian Connect that runs on Server/DC and uses postMessage and a polyfill for AP to communicate between our iframe and the host product in the same way that we do in Cloud. Doing so has eliminated the need for the front-end to know whether or not it is running in Server/DC or Cloud and has removed a lot of development time as we can focus on creating a single interface.

It’s probably not the answer that you are looking for, but to sum it up:

  • All teams follow the Atlassian Design Guidelines
  • AtlasKit as a single component library no longer exists
  • Atlassian Design System team maintains a subset of AtlasKit components
  • All other AtlasKit components are (no longer) maintained by different teams
  • jQuery-based AUI is still the main component library for Server/DC and is actively developed
  • There will be a front-end library that will also support React in the future for Server/DC
5 Likes
4

We created a polyfill for Atlassian Connect that runs on Server/DC and uses postMessage and a polyfill for AP

I know this is a tangent but do you need to use postMessage given the IFRAME is on the same host or could your AP polyfill just make web requests directly to Jira?

Only asking because I want to do something similar.

5

There are a few things that you need to be doing on the host, like opening dialogs (to avoid in-frame modal), resizing of the iframe, navigation relative to the parent frame and have access to context (project key, issue ID, etc). As a result, we decided to just fully emulate the Connect behaviour on the host and have a skeleton AP polyfill that only handles the postMessage communications.

1 Like
6

Makes a lot of sense, thanks @remie !

7

Hi @remie!

Could you provide more details how exactly you created the polyfills and how you use iframe? Maybe a pseudocode or a gist?
I really like your solution but I’m not sure how implement that.

1 Like