Hello !
For advanced UI, there is currently no other option than using Custom UI. Yet, we’d like to keep using UI kit when possible.
Let’s imagine a Forge App using Custom UI for some of the modules. I’m wondering if there is a recommended way of sharing code between modules.
When creating a Custom UI module, we face the React limitation
Relative imports outside of src/ are not supported.
Let’s say we have
- a module in UI Kit (a Jira issue panel for example)
- two modules built with Custom UI (a Jira project settings and a Jira dashboard gadget for example)
How do we share code between those modules of the same app (a constants file for colors and a set of common business logic functions for example).
Duplicating the code would be ugly…
Is there any pointer on how to share some code ? Some best practices ?
Thanks !
1 Like
Just two random ideas, I haven’t thought too much about it:
- Symbolic links:
git
should be able to handle them just fine (even on Windows apparently) and Webpack probably won’t complain if you symlink your shared directory so that it appears inside src/
- An
npm
script in your custom UI package.json
that copies the shared files in a place from which they can be imported
Thanks @PaoloCampanelli !
Not sure about the symlinks portability, but I really like the idea of npm scripts.
We first started to use symlink (on a folder) and switched to use a mono repository a few years ago. (It may not work if you have developers using windows, not sure)
The symlinks worked fine until our code base grow too big.
If you are not yet familar with a mono repository, it contains multiple npm projects (package.json) within a single repository and you are importing your own packages as dependencies. (there are multiple ways to do it like npm / yarn workspaces)
We have not yet a production plugin version using forge, but there is a limitation you need to be aware of (if I remember correctly from our prototypes)
One Packages should either use UI Kit or Custom UI and not a mix of both.
To be complete, there is also the option to publish private repositories, but we didn’t go this route because it seemed too much work to manage the different versions.