Skip to content

[Feat]: Switching tabs in a tabbed container - persist the user inputs of components #1502

@umutyorulmaz

Description

@umutyorulmaz

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

Activity

changed the title [-][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[/+] on Feb 4, 2025
changed the 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[/-] [+][Feat]: Switching tabs in a tabbed container - persist the user inputs of components[/+] on Feb 13, 2025
FalkWolsky

FalkWolsky commented on Feb 13, 2025

@FalkWolsky
Contributor

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

moved this to 🆕 New in Lowcoderon Feb 13, 2025
umutyorulmaz

umutyorulmaz commented on Feb 13, 2025

@umutyorulmaz
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

ComponentsDedicated to Frontend Visual ComponentsJavascript FrontendPull requests that update Javascript code

Projects

Status

🆕 New

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    [Feat]: Switching tabs in a tabbed container - persist the user inputs of components · Issue #1502 · lowcoder-org/lowcoder