Syntax for attaching metadata to a shape using API
Hi
I am trying to attach metadata to a shape widget created from javascript through the API.
Widget is created correctly when there is no metadata, but creation fails as soon as metadata is part of the widget definition. I have interpreted the metadata definition from this post:
I have tried several combination with and without aphostrophes, but none of them works.
Can anyone out there give me a hint on what is wrong with the code?
Page 1 / 1
Hi @Geir Ølnes,
Thanks for reaching out.
In your example, e‘TEST’] needs to be replaced by your application id as explained in the documentation. You can find your application id in the app configuration page.
Please note that Metadata is an instable feature. We do not recommend using this feature in a production environment at the moment.
Thanks for the reply.
The documentation you point to describes both using a text string and the application id as a key.
The documentation of the SDK defines metadata like this
WidgetMetadata
Ƭ WidgetMetadata: { {x:string]: any; }
In this description, the key is any string. Is there a hidden restriction that the key string needs to be the application id?
I am not sure I understand what the application id is. Is it the Client ID from the …./settings/user-profile/apps page for my plugin?
@Geir Ølnes
Thanks for the reply.
The documentation you point to describes both using a text string and the application id as a key.
The documentation of the SDK defines metadata like this
WidgetMetadata
Ƭ WidgetMetadata: { gx:string]: any; }
In this description, the key is any string. Is there a hidden restriction that the key string needs to be the application id?
I am not sure I understand what the application id is. Is it the Client ID from the …./settings/user-profile/apps page for my plugin?
Yes. That’s the one.
It is you app’s ID. The documentation can be confusing… in someplace’s you’ll see it called App ID. in other’s its Client ID or clientId --
The metadata is currently stored on a widget under each application. You can read other app’s metadata from the console, or from your application, but you can only write metadata under your app ID.
BUT !! Caution!! METADATA HAS RECENTLY BROKEN and support has maybe been abandoned by the platform team. Updated metadata (any values changed after the initial metadata write) will not persist on a widget after a board (browser) is refreshed.
Thanks @Max Harper
Works according to your description
@Max Harper do you have a link where I can read more about the fact that Metadata API is no longer supported?
Miro didn’t stop the support for metadata, the team has been facing lots of issues while trying to fix the current functionality. This is taking much longer than expected and requires a deep re-engineering of some foundations that are used for metadata. The team is still working on this and I will let you know when the fix is finalised and deployed.
Because this issue has been running for months now and that we know it impacts our users, we preferred to be honest and recommend new development to not rely on metadata until it is fixed.
Sorry for the inconvenience.
Anthony
@Marijn Huizendveld@Geir Ølnes
What @Anthony Roux wrote is the situation. He works on the platform for Miro. I’m just a developer on the platform - I don’t work for Miro. They know the inner workings. I’m just intimately aware of the state of the API/SDK because we’re developing on it full time.
Our team builds custom tools on top of Miro for enterprise clients and for marketplace. Building and maintaining those Miro apps and integrations means we work with API/SDK daily and our clients and their software is reliant on the stability of supported features — which also means we are exposed to fluctuations in any stability of those features. When the current metadata capabilities began to faulter last week, our app users and us developers noticed it immediately…. Like bricks being removed from the foundation of a house.
In our correspondence with the Miro platform team we discovered there wasn’t a definitive, certain outlook or timetable to resolve metadata’s functionality. This lead to the ‘caution’ post above. Because - it seems helpful to let people know the current state of certain and uncertain things, so they can plan accordingly. Because things are uncertain - In the caution post above, I used the word “maybe” as an attempt to convey the uncertainty. That it’s not entirely clear when metadata will work again.
As to ‘certain’ workarounds … For example- in our apps, where we used to update widget metadata, in some cases (where the widget ID is not important), we simply delete the old widget and create a new widget with new metadata (Miro will retain the first written state of metadata) — it’s an insufficient bandaid on the current metadata situation, as it won’t work for all our cases/needs — but it is at least certain(for now…from what our tests are showing) — The only real certain solution we have right now, for all of our needs, is to reroute our development efforts toward external database solutions for state management /metadata.
As we can infer from @Anthony Roux description of the metadata challenge… It looks like there might be a fix… but the outlook is uncertain. While the outlook is uncertain- i encourage you to keep the caution in mind.
As of today it seems that metadata has become an entirely transient function. Yesterday metadata worked with programmatically created widgets, but could not be updated. Today no metadata is stored. They are lost on reload of the board.
Metadata is THE way to connect data from a back office analytical program to visualisation in Miro. This part of my development is now stuck untill metadata is stored and can be reloaded.
@Anthony Roux or someone else at Miro, can you give us a time when metadata will be fixed, at least in the order of months ahead?
As of today it seems that metadata has become an entirely transient function. Yesterday metadata worked with programmatically created widgets, but could not be updated. Today no metadata is stored. They are lost on reload of the board.
@Geir Ølnes do you face this for all widgets or specific ones? Are you using it through Web SDK or REST API?
The team is working it right now, I don’t have an ETA but it is at the top of our priority. As I mentioned it is a highly complex issue this is why it is taking time to fix.
I am currently working with frames and shapes. I have not tested with other widget types.
Knowing it is a top priority issue keeps me calm. As long as I know it will be fixed in a reasonable time I can manage.
Any update on the metadata situation? I’m building some plugins and would love to be able to store metadata on widgets. If that’s not possible, I can probably use a workaround for now, even if it’s not ideal.