I think the title is self-explanatory. The use case I encountered is a field that is used as a search input. When the user clears it, I have no built-in way of reacting to this to reset the displayed results.
I know a possible workaround would be the very useful and versatile Change Detection custom widget (if you don’t know this one, I really recommend to check it out), but it is rather inconvenient to have to setup this for such a simple task.
After all this time, I’m still usually confused about how Tulip handles empty lists VS null VS empty string VS unset variable values (especially with table queries) and I always have to double-check! I guess they cannot change the behavior without breaking a world-record worthy number of apps Still, I think refining the UX could actually make the app editor perfectly usable regarding that behavior if they find a way to make the difference between all these cases more visible (ideally graphically with icons, colors etc.).
Thanks for reminding me I wanted to get at least one feedback before doing this.
To be fair, this is not TULIPs fault.
First you initialize a variable. This only means, there is a space, with a name, where you can store data of a specific type.
Then you can store some data there and “nothing” can also be a value. An empty string.
You can imagine it as a null value being “I don’t know, we didn’t decide yet” vs an empty string beeing “here is actually nothing”.
Linke no number at all means “we did’t count yet” while 0 means “we checked and found zero items”.
@thorsten.langner You are completely right - Tulip cannot do much about the values. But it would be very helpful if it was more clear what the “empty” field is currently - whether it is “nothing” or null. Being in low-code/no-code environment, it can be really hard to read that value.