What we learned about custom widget, many props, and what not to do

We created a custom widget to be a text widget replacement with language translation. It takes in some json and parses it so if you input 44 it would display Hello World. It also text resizes so that if hello world in say Klingon would normally overflow your text box it sizes the text to stay in the box. It also adds a click event so you can use the text box as a button, and other things.

In our naivete we did it this way

And then we managed to crash our apps using it.

What we didn’t realize was happening is we would use say 15 of these custom widgets (with 10 props each) well for each prop there is a listener created, and as far as I can tell the listener is never released. So, if the user navigates through the app, each time it keeps loading more listeners. This will cause the app to crash pretty quick on an ipad.

The partial fix (hopefully Tulip can release the listener) is if you want to make a widget that you are going to use a lot, is to do it like this. (Only two props, one downside can’t easily use a variable to change the backgroud_color all in one go but small price to pay for not crashing)

This new version was put through a torture test @aaronbroussard @Alan.Madorin @kellen.linse and it took 10 times longer before it crashed.

4 Likes

Hi @mellerbeck,

thanks for sharing.

Would you mind sharing your code?

What part interests you, the language text box itself, or an example of a crashing widget.

The widget itself (with it’s listeners).

Hey @mellerbeck -

Would love to see the code on our end too! In our internal testing before release we ran dozens of concurrent widgets in an attempt to break the feature (or any other part of the infrastructure :slight_smile: ) and were largely unable to.

ps - This widget concept is freaking awesome, some more cool stuff is coming soon around multi-language support

Pete

This is a copy of an App for crash testing. More props makes it exhaust resources faster.