Form persistence
Hello! I was wondering a couple of things on the topic of form persistence.
In the past, there has been an attempt at integrating such a feature directly in the library, with this PR https://github.com/TanStack/form/pull/561, but it is now closed.
This is a feature that I would love to see available, but I found some mixed messages about what the plan is for it. In some messages, like https://discord.com/channels/719702312431386674/1100437019857014895/1345113530936066149, it seems to just be a feature coming later, but in other messages like https://discord.com/channels/719702312431386674/1404490027538452511 and https://discord.com/channels/719702312431386674/1100437019857014895/1392775060800143370, the suggestion seems to go more towards doing it on the user side, with the help of listeners.
So my question really is simply about clarifying whether it makes more sense for users to implement this on their side, or if there are still plans to provide an API for it in the future. And if the idea to provide this from the library is still alive, is there already something ongoing that I couldn't find, or were you hoping somebody would be willing to either revive the original PR or start a new one?
8 Replies
adverse-sapphire•2w ago
I think an official API would be great for it. The problem is that it's currently not a priority, so the library probably won't have that feature for a while. That's why the threads here go into the user side of things to solve it.
I'd appreciate it if you could elaborate a bit on how you'd use the persistence. It can help make sure that most use cases are covered when we come around to actually adding it to the library
quickest-silverOP•2w ago
Thanks for your quick response!
I totally understand, this is likely not a feature everybody needs and is for more advanced use cases, so it makes sense to prioritize it lower.
To answer your question then, currently we use form persistence to give our users some security in case of problems.
In our app, users can spend a long time (sometimes hours) writing long contents and often they would not be regularly saving their work. Or simply move away from their computer with unsaved changes. And if anything happens during that time, whether it's an app crash or even something like their computer turning off, they would lose their unsaved content.
To help address this, we ended up building our own persistence feature around react-hook-form, that basically saves the form into localStorage on every change, so we can restore it if necessary. And when the user saves, we would remove the data from the storage, so that we don't keep stale data, and we don't fill up the storage unnecessarily. We also have some cleanup function that will run if there were no change in a very long time, in case the user never went back the the form and the data removal never happens through user action.
I think we could port our custom solution around TanStack Form, but if we create a wrapper around
useAppForm for reusability, I suspect it will be at the expense of the nice type safety you provide. We could directly use the listeners to implement this as well, but we have dozens of forms throughout the app, and it would be quite repetitive. formOptions can help, but then we would need to create a wrapper around it for when we need to use the listeners for other things as well.
I was curious to try and build this feature in a fork, see what I can achieve, but I saw discussions about making it a separate package, mirroring the approach of tanstack/query, but all this was before the API changes you made just before v1, etc... So I was not sure in what direction to go 😅
I also have limited time available, so I was not sure if it made sense to even try if something else was on the way.adverse-sapphire•2w ago
interesting … would you mind sharing this rhf wrapper‘s snippets? I‘m curious what the API you implemented looks like
I‘ll also read up on the tanstack query persistence you mentioned. Perhaps there‘s something to learn there that can be used for tsf
quickest-silverOP•2w ago
I can try to share it a bit later if you really want it, but honestly I would not take any inspiration from it, our current implementation is why I was hoping for an option provided by the library 😅
When I said "port our solution around TanStack Form", I meant user side, for our specific project, not to integrate into the library. Basically it's a custom hook around a useEffect. When we mount the form, we check if the key exists in the storage and if it does and is not expired, we call rhf's
When I said "port our solution around TanStack Form", I meant user side, for our specific project, not to integrate into the library. Basically it's a custom hook around a useEffect. When we mount the form, we check if the key exists in the storage and if it does and is not expired, we call rhf's
reset function, with the values from the storage. Else we use the regular default values.
About the tanstack query persistence, it was referenced in a comment of the original PR by one of the maintainers here https://github.com/TanStack/form/pull/561#issuecomment-1887969927. But it's 1.5 years old, so I'm not sure if still relevant today.dependent-tan•2w ago
This is so funny - I just mentioned this to the team unrelated to this comment.
Still relevant - we're looking on bringing this work back
adverse-sapphire•2w ago
I thought it was this thread that made you ask in the first place!
Well, great timing either way
quickest-silverOP•7d ago
Awesome! Alright so if I understand correctly you're gonna have somebody working on it somewhat soon, there is no reason for me to try to dive in it?
adverse-sapphire•7d ago
it's a big project, but yes, it'll be in the works. Whether or not you want to tackle it now depends on when you need it