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.

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