Best practice? Hidden component for temporary data?

I find I use a lot of textinput fields to store temporary data. I also found I can’t make them invisible using the visibility option without loosing the data stored in them.

What is best practice for hiding text ipunt that won’t mess up my design? Or is there a better way to store temporary data with another component?

For instance when I use arbitrary javascript component and need to store different values and also have fields to run all different scripts.

Hi @Meibe ,

Make the size of the text input to 1 by 1, if you have app bar, it is nice place to put it behind that.

If you want the data to available throughout other screens, use user’s collection, if you want them to be available to all users, use app settings.

2 Likes

Hi @Meibe,

In addition to @Yongki 's advice: you can also change the colors to make input invisible.

Fortunately it is possible to access inputs on the other screens, so I usually create a separate screen for inputs. This screen isn’t connected to anything, I call it starting from letter A (so that it is the first in the list).

Best,
Victor.

5 Likes

Thank you. Both good ways to do this. I’d rather not have 1 by 1 or invisible components on my views so I went with the new view approach. However the persistence of data in text inputs (which is great sometimes) tripped me up when I need some values to default to certain things. And setting default value or using on view load action on a view that never loads doesn’t work. Setting the values on view load on my main form didn’t work either.

What I’ll do is I’ll have a separate view as @Victor suggests but I’ll name it like preloadFormA that always opens before FormA and auto links it on view load. It goes really fast without animations but I have a little loading lottie at the center and all my temp values if you scroll down just in case.

Just thought I post this if another n00b finds this post in the future.

Hey there @Meibe

I try to stay as consistent as possible with my hidden inputs. I almost always have a 20px margin below the app bar and the initial content of a screen so I place my hidden inputs there, covered by an invisible rectangle (so that the inputs can’t be clicked). Just as @Victor stated, transparency on the colors.

By doing it this way, I always know where my hidden inputs are, they’re easy to edit when needed on that same screen, and the rectangle above prevents users from changing the values.

2 Likes

Just in case - not sure if anyone noticed it.

When using Adalo apps from Web browser, “transparent” Inputs on the page still can get input focus. E.g. if you have 6 inputs on the page, 2 of them “transparent” (used for storing temporary data), and if a user uses Tab key to quickly switch between the elements, this user will eventually get to a transparent input.
You can try it by yourself in the Preview.

It is less problematic for mobile apps (though still user may tap on the input occasionally).

This issue is one of the reasons I prefer putting inputs on a separate screen.

Best,
Victor.

Hi @Flawless, @Victor.

Do you have any experience with this issue I am facing?

I am hiding components behind an invisible rectangle, but if the text or input box or list expands with contents then the top rectangle does not inherit this new size. Do you find this? Or have any work around on mind?

I am trying to disable to a number of input boxes with via the use of a toggle.
I can achieve the same by use of conditional actions on each element but rather this quick solution of a rectangle over the top - PWA will not be used so I am not concerned for focus shifting with tab key.

Thanks for any insight you have