Open
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
Inputted data (text inputs, radio selections etc.) within a tabbed container gets lost when the tabs are switched.
discord discussion:
https://discord.com/channels/1096896040159957084/1336379675743748097/1336415648049532960
Screen.Recording.2025-02-04.at.2.10.28.PM.mov
Expected Behavior
I expect data to be persisted when the "Destroy Inactive tabPane" toggled off
Steps to reproduce
Create a tabbed container and place any component in like radio or text input, fill it or do selection then switch tabs come back to the original tab you will see the selection or inputted data gets lost, toggle the "Destroy Inactive tabPane" setting at the tabbed container right panel and repeat again no change
Environment
Mac M chip, app version 2.6, tried on both local (deployed via docker ) and via web app.lowcoder interface
Additional Information
No response
Metadata
Metadata
Assignees
Type
Projects
Status
🆕 New
Activity
[-][Bug]: <title>[/-][+][Bug]: <title> switching tabs in a tabbed container does not persist the component data regardless of the "Destroy Inactive tabPane" toggle on or off[/+][-][Bug]: <title> switching tabs in a tabbed container does not persist the component data regardless of the "Destroy Inactive tabPane" toggle on or off[/-][+][Feat]: Switching tabs in a tabbed container - persist the user inputs of components[/+]FalkWolsky commentedon Feb 13, 2025
We "disagree" about the nature "Bug" of this subject. Why so...
As App Creator you can - but also would need to - make sure that the state of your app is persisted for changes like this.
To do so, most of the components offer you a "default value field". When a user makes changes, components offer you event handlers to react. So, in your displayed case you as App creator are indeed responsible to save the user input state via a data query, local storage or temporary state if this state is relevant for your app.
The option "Destroy Inactive tabPane" is meant to "destroy" the whole HTML structure of inactive tabs - to consume less memory, as many users have inside of tabs "whole mini-apps". Here it can contribute to the overall app speed and usability.
However, we let your issue here - but turn it to a Feature request, cause it can be as you say indeed wishful to remember already "by default" the user input states in the tabbed container. This is then another way of implementation and we can develop this as soon as we find time for it
umutyorulmaz commentedon Feb 13, 2025
All right, I must have misunderstood the function of 'Destroy Inactive TabPane' setting. I was thinking that; when it is off it lets the tabbed container persist data and when it is on it wipes off data when tabs are switched.
Yes I agree with you by default having the tabbed container to persist data might be useful for some use cases like building a form and submitting it from a different tab.
Also as you mentioned there is a workaround to persist data within the tabbed container using state variables and default values which I did that way in my implementation.