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.
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.
@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ā¦
I was going to comeback fix up the custom widget css. I wanted to prove my logic first.
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.
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. . 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.
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.
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.
Pete
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.
Edit:
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.
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
This is the same thing that happened to me and prompted the discussion. I was not able to find a rollback function. Your best bet is to reach out to Tulip support to see if they can help you out.
@Pete_Hartnett I understand, that the versioning is a bigger thing and needs some effort.
At least these features seems to be possible to me and are crucial:
Renaming a Widget
Adding a Description
Flag āDisplay / Hideā Widget in App Builder
to provide widgets in development to get used by mistake
to force using a newer version (copy) of a widget
to keep the selection clean
archiving widgets
no deletion, so old apps with this widget will work fine
It starts getting messy in our environment, and I have no clue how to go on, without producing more messā¦
We spent much of the fall developing a unified approach to versioning for all child assets. This work is in the late design stages right now, and we would love to share with you, and get your thoughts if you are interested. Shoot me an email at pete(dot)hartnett@tulip.co and we can schedule a half hour to walk through our current thinking.
Custom widgets are a slightly lower priority asset over things like connectors, so a resolution here is a little further out, but we designed a pattern explicitly that would support custom widget versioning.
. My only request is to update knowledge base with big bold lettersā¦ āYou cannot change a widget after creating a snapshotā
