Hey Team,
This functionality makes custom widget based solutions extremely un-scalable. I understand the vision, but given the lack of progress on the topic I think this is objectively worse than allowing them to be modified. There are threads about improvements here. 1. 2. 3. 4.
Is there any timeline on Custom Widget versioning?
In the absence of this. Should customers be using like a “pass through” widget and pasting in HTML as a static value input to a CW? That way version history would lock. Are there any concerns with this approach?
Hi Team,
I’m creating different Custom Widgets at the moment.
I noticed that when a Custom Widget is used in a deployed app, you can’t modify it (to improve or fix issues).
I think it could be really useful to have the possibility to publish a custom widget (in order to use it in an App) but to still have access to a development version to modify/improve and then publish again.
In other words, it could be good to have the same versioning system for Custom Widgets as we have with Apps.
Paul
Hi @danielpomeranz and @paul.genoud,
There is a workaround that we can take that’s a half step towards versioning (and akin to the solution proposed by @danielpomeranz ) . Essentially, we could add an account setting to allow for editable published custom widgets that is default off, and can be toggled on/off.
There isn’t a timeline on this, but if there’s enough interest in this post, the team can take a look at reprioritizing.
Short term, we could unblock this for you, please DM me if you’re interested.
Sincerely,
Jake
2 Likes
