I have a Custom UI app which shows a form on a Confluence page, and allows the user to submit a response. I save this response using the storage api, to a variable which has the user’s accountId as its name.
I thought I read somewhere that Forge keeps track of app instances, so that I don’t need to, but if I put the form on a page, and submit a response, and then add the same form to another page, the previous response is used for the new form.
Is there something I need to do to distinguish between the two instances on two different pages?
I considered using the page id as an additional part of the variable name, but further down the line it’s possible that we’ll want to allow two copies of the app on the same page (asking for 2 separate pieces of information), so that wouldn’t work.
The Custom UI resolver has a
localId property in the
context argument which represents the unique ID for an instance of a component in the content.
Just for reference, the
localId property is also available on the
useProductContext hook when using UI Kit.
localId isn’t necessarily unique. When a macro is created on a page, it gets a new random
localId, but if a user copies a macro within a page or to another page, the
localId is copied as well.
So is it ok as long as people make sure they create a new one each time (e.g. by typing ‘/name’), rather than doing a copy-paste?
Yes, in that case the ID should always be unique.
@klaussner is correct here.
I found a few other threads about the same topic so I went ahead and created a bug report for this: [FRGE-1269] - Ecosystem Jira
Just one thing, I could only get the duplicated
localId when copying the macro on the same page or when copying a page containing the macro.
When I copied the macro across two different pages, the
localId on the target page was different.
Let me know if this is not the case for you.
I’ve been using the Chrome Developer Tools to check for the
Thank you for creating the bug report, @ccurti. The
localId that is provided in the context is always copied (even across pages) and differs from the
localid attribute on the
div because there are two different
localIds stored for every macro instance:
<!-- This `local-id` is provided in the context and is not unique when the macro is copied: -->
<!-- This `local-id` is shown in the Developer Tools: -->
Thanks @klaussner for pointing that out. I’ve updated the FRGE ticket with that information.