Connect to Forge Blocker - Custom UI Configure Entry Points for Shared Resources

We are using Custom UI to port our Jira Connect app to Forge. One of the blockers is that Forge Custom UI requires index.html as the only entry point for every resource.

As our connect app has 30+ modules, today this requires 30+ individual “builds” of micro-apps, each with a separate resource bundle. As resources cannot access the assets (image, css, js, etc) of any other resource, we have to deploy 30+ copies of shared assets into every resource bundle of this one app. Bad for user experience and deployment time.

We tried the hack/workaround by dynamically loading injecting a different page view depending on the context module key. This is not a complete solution as it does not work in every situation (e.g. on opening modals the context still has the original page moduleKey). Also this dramatically complicates simple pages like ‘view workflow post function’.

The request to Atlassian is to allow configurable entry points (other than index.html) for modules/resources so that a single resource bundle can have many html entry points. Please vote for https://jira.atlassian.com/browse/ECO-882

Regards,
Chris

2 Likes

I do a similar module key hack for multi-app monorepos.

With UI Kit 1 you could pass data into the code, eg…

// manifest.yml
function:
    - key: macro
      handler: macro.APP1
// macro.jsx
export const APP1 = render(foo)
export const APP2 = render(bar)

That stopped being possible with UI Kit 2 or Custom UI, so now need to do…

const context = useProductContext()
const app = appMatch[context?.moduleKey] // APP1

The problem with that approach is the context fetch is very unreliable and inconsistent within Forge at this point in time.

Thanks @nathanwaters, our prototype code looks similar having to fetch context first and then branch to the actual module code.

It feels like the forge design was focused on solving for the 1 page apps and didn’t focus enough on larger footprint apps. Every hello-world sample looks the same with one build/package per module. It would be nice to see an example of a real world Custom UI app that has a substantial number of front end modules. Isolated resources and a hardcoded index entry point seem like obvious findings to us, and we are a few years behind the curve in forge.

2 Likes