Do not expose state through useForm().state since it is not reactive

[rodrigofariow]

Hi there @crutchcorn !

I got tricked into thinking that state returned by useForm was reactive.

This is not the case AFAIK, hence why you provide selectors.

However, this should be clear from a consumer point of view. If form.state is not reactive, it shouldn't even be provided?
People could do const formState = useStore(form.store, state => state) and this is surely reactive so there are no surprises.

To clarify my use case:

Thanks for your time 🦾

[crutchcorn]

Your concern is entirely understandable. However, the form.state makes testing easier et al for the FW agnostic core.

Is there anywhere in our docs where we could clarify not to use form.state?

I wouldn't be opposed to marking it as @deprecated

[rodrigofariow]

Hi @crutchcorn ,

Thanks for the quick response!
Either marking it as deprecated or naming it something like __state to indicate it is somewhat private. Adding @internal to jsdocs can also help.
Any pattern that you guys prefer that makes it more clear to the consumer that it's not an up to date variable and not meant to be used, except internally/for testing.
e.g:

• __state
• __private_state
• __internal_state

Any of these are clear to me and most devs that it's not meant to be used or at least it has some quirks around it. Then devs are encouraged to look at the docs, as soon as they see this.
It's also easier for you guys to clearly state on the docs that any variable using that pattern is for testing/internal use.

As for the placement on the docs, here feels that before talking about useStore, we should explain why state is not reactive (most likely perf afaik) and the tools we have to make it reactive when needed, such as useStore.
https://tanstack.com/form/latest/docs/framework/react/guides/basic-concepts#reactivity

Cheers!