Ideas, help, guidelines, and best practices for injecting code into Tulip apps using custom widgets.
3/4/2022: Welcome to the Custom Widget Hackathon!
This is a place to share what you are working on, awesome widget usecases, and more! During beta testing, this category is private to just those who are doing beta testing, but in the coming weeks we hope to make this public!
To get started with custom widgets, there are a few fantastic resources:
Custom Widgets Crash Course Video
Knowledge Base article
Custom Single Select Widget Build Video
Custom Gauge Widget Build
Here are some of the things we would LOVE you to post here:
- Finished widgets
- Widget painponts
- Widget ideas
- Any other issues. Our team will be monitoring this category answering and helping troubleshoot issues.
first of all i want to congratulate you for this new feature. It is the part that was missing in the past.
And i have a small question. Could you enable “anonymous” objects and object arrays as input propertys? With this we could build widgets that are not hard coupled to datatype definitions from tulip. I think that something like an “SerializeToJson” and/or “DeserializeFromJson” in the normal Tuliptriggers can do the Job.
I have found the same thing, because prop types are static, it forces you to make duplicate widgets (with slightly different props) that otherwise could be unified. I could see anonymous pros that you could then check the type of in JS and act accordingly. I will talk to our developers about the feasibility of this.
Keep the great ideas coming-
The usecase where we found this nice was making dynamic forms with a custom widget, pass in a json and it creates a form with labels and inputs. that json could be stored in a table to make the code even more modular.
Yes. My usecase would be to build an generic Table view with advaced functions. Do you have already build an workaround to build Json on the Trigger side? And is it planned to enable some function like this in the future?