PSA : Widget is being used in a published app and cannot be modified

I was happily developing some custom widgets for my app, having tulip player side by side testing and modifying as I went.
But last Tuesday to my distress I got this message. :sob: :sob:

custom widget locked

But wait, I have not published my app. I have not finished my testing!

I contacted support, deleted any test stations I had and did everything I could think of to revert this to no avail. All the while screaming at the computer “I did not publish you!!”

Turns out creating a snap shot of the app also causes the custom widget to be un-editable. It kind of makes sense now.

I really wish I could call this a bug, but I can understand why Tulip have taken this path. So I’m posting this a PSA for any procrastinating developers (like me).
I guess I have to fully test my custom widget before using it in any app. :thinking:

@Rakitha You can duplicate the widget and continue to develop it, if you’d like. You’ll just need to replace Custom_text_field_v1 with custom_text_field_v2 in your app. Will this unblock you?

@freedman oh yes, that will work.
But my dilemma is, I have aprox 100 instances of this custom widget in my App. Each has at minimum 5 props. So we are talking 500 items to modify. Oh and the triggers… :grimacing:
I was going to comeback fix up the custom widget css. I wanted to prove my logic first.

Hey @Rakitha -

This is a good discussion to be having right now, we are actively working through what versioning might look like for custom widgets (along with a few other asset types in Tulip). Our current thought is that going into a widget that is already being used in a published app would create a new version of that widget in the background so you don’t end up with pete_test_widget_v1, pete_test_widget_v2, pete_test_widget_v3…

The issue with this approach is it wouldn’t necessarily resolve your usecase where you want those changes to be automatically deployed to a published app. If we did enable this functionality, how should we handle:

  • Cases where props were added or removed? What about events?
  • What about cases where there are the same props and events, but maybe the events signify something different in v2, than they did in v1?

Pushing changes to components being used in apps really circumvents all that we look to achieve with app versions. When you publish an app, we never want anything in that version to change. Having said that, we will find a good solution that resolves your pain point.

Keep the great ideas coming-

Hi @Pete_Hartnett ,
I totally agree with locking a custom widget once it is used in a published app. It just caught me off guard when Tulip locked me out for creating a snapshot. I really wish there was a resolution for my issue, but in the back of my mind I know there shouldn’t be a loop hole like that. :slight_smile: . My only request is to update knowledge base with big bold letters… “You cannot change a widget after creating a snapshot”

Since you asked, my 2 cents with regards to version controlling custom widgets. :upside_down_face:

I would imagine it to be how other programming sw deal with compiled libraries.
This means publishing apps and publishing custom widgets are two different things.
The custom widget must be published first (locked out) before it can be used in an App.

Then during app building we have to chose a specific custom widgets to use in that particular App from a list of published widgets. The system will default to latest version of the widget, but users may chose to use an older version. This will be done in a “custom widget manger” tab.

Once a widget is added to the app the version of the widget is fixed to that app. If a new version of a custom widget is published, it has no influence on any apps regardless if it is published or not, until the developer makes the decision to update (pull in) the newer version to that app.

In the case of a prop being added or removed, or major changes Tulip has to sort of “hope” the developers do the sensible thing. Tulip could potentially warn if a prop is added/ removed or if the data type changes. But there will be so many edge cases. What if we deliberately want to change a prop from INT to Number? It should be allowed. IMO if we want an open customizable platform we have to also bare the responsibility. We cant have it both ways. The only safety net is the developer must make the decision per widget per app if they chose to upgrade or downgrade.
Maybe a built in code compare (diff checker) will be helpful.

Definite YES for background version numbers… not _V1, _V2. Well if there is process to publish (release) custom widgets, naturally there will be some meta data associated with the release.

1 Like

Hey @Rakitha -

Thanks for expanding on your thoughts in so much detail! This is the exact kind of feedback that really drives the direction and approach we take in the product. I shot your feedback to our engineering teams working through the technical details right now.

There are a number of different approaches we could take where widgets are stable once released in a published app AND they can be iterated on. This is an issue that has persisted with connectors for years, but is just starting to become more painful with the addition of custom widgets in ~may.

Your feedback is incredibly valuable! Keep it coming.

1 Like

I was going to create a thread regarding being able to edit widgets in unpublished “Snapshotted” apps, but found this thread, so I’ll add my two cents here.

In general, it would be nice to be able to modify widgets in published apps as detailed above in the thread, but at very least, the ability to edit a widget if an app has only been “Snapshotted” and not published would be extremely helpful.

In my instance, I’m using a custom widget to modify (a duplicate of) our packaging app to allow for variable case sizes.

There the operator scans or manually enters the product to a specific case, app logic is fired to verify that the product is from the correct work order, passed inspection, is not already listed as ‘packed,’ etc. Once all fields are filled with the valid product numbers, a case label is generated and the product is listed as packed in a Tulip table.

After a hands-on test with the floor manager, I realized that some slight modifications need to be made to the logic on the custom widget side. Because I’m making major changes to the app workflow, I created a snapshot in case I break anything (though the app is an unpublished duplicate), so unfortunately, now I have to duplicate my widget to modify it, then reintegrate it into the app again.

One thing that could be helpful at least, regarding having to duplicate a widget and edit it then replace it in app, is if there was the ability to copy and paste event triggers between widgets if they are derived from the same base widget (and have the same trigger event names). This would at least speed up the process of replacing my existing widget with the duplicate as it would allow me to just copy paste the Tulip app logic over.

1 Like

Hey @richard.vaughn -

Totally understand the pain. There is a bit of work going on around versioning across all Tulip assets and so it was decided to hold off on throwing a versioning layer on Custom Widgets until we could apply the same approaches across all of those asset types.

If I had to guess, this will be one of the next features to come to custom widgets, but there isn’t currently ongoing engineering work towards that end.


Been thinking about this and not sure you guys have settled on a versioning approach but it might be helpful to take a look at how AWS Lambda does it. Lambda function versions - AWS Lambda