New reset-behaviour

[v-morlock]

New reset-behaviour

[ciscoheat]

Hi, glad you like Superforms! I'm not sure I see the problem when resetForm is false, as it usually is in a CRUD editor like this (compared to a login/signup form). You update the "db" with db.name = form.data.name (a successful update), and the posted data is sent back to the form, reflecting the update. What do you expect to happen?

[v-morlock]

Hi, a crud form is exactly what I’m trying to accomplish (it just said „login“ because that’s what the template said initially).

You‘re right that „resetForm: false“ does as expected in case everything is implemented properly.

But as I tried to show in the example, the form won’t actually display what’s returned by the „loader“-function after the submit. Am I supposed to rewrite the data of the form object in my action?

My point is just that I would expect the form to actually display the latest content of the database after submitting, I think that’s what most users are used to, compare e.g. a traditional webapp where the page actually reloads after posting the form.

In practise this would e.g. make a difference when there’s an error in the update logic (some form accidentally not being updated), or if the backend rewrites some of the inputs.

[ciscoheat]

When I change resetForm to false and submit the form, I see the "Load ran" message, so you'll get the latest content from the load function (since applyAction is true as default).

[v-morlock]

Jup absolutely, but it's not displayed in the form... Look at the example where i "forgot" to store the mail Adress. When you click on save, the loader returns [email protected] as mailadress, but the form still displays the mailadress you've entered. I would want the form to always display what the loader returned last to reflect the correct state of the backend

[ciscoheat]

Since invalidateAll is true, it should update. I'll have to take a closer look.

[ciscoheat]

The example works for me locally, the email address is reset to the default by the load function, at least on Svelte 5. Can you check if it does the same for you?

[v-morlock]

I'm on svelte 4.2.11 and there it's showing the same behaviour as in the posted example, always keeping what's entered locally, no matter which value is being returned by the "loader".

I'm also kinda unsure about the rationale of the behaviour of "resetForm" - why would one want to keep resetting a form to it's initial state (= the data returned by the loader on first load) instead of resetting it to the data currently returned by the loader? Without reading the docs, i would have assumed the flags behave like this:

• resetForm: true → resets to the most recent value the loader returns once submitted
• resetForm: false → keeps the values entered locally, no matter what's being returned by the backend on submit (edit: or applies the values returned by the "action" - that behaviour makes sense and feels intuitive to me)

I'm sure there's a good reason things are implemented like that, but maybe you can quickly explain them to me? :) Thanks a lot!

[v-morlock]

Ah what i wrote is actually not fully correct, the form does indeed change the values with resetForm: false, but to the value of form.data that's returned by the action, not to the value returned by the loader

[ciscoheat]

There were some tricky logic behind this. The key is the applyAction option, which should be set to false in your case. Then it will not apply the form action, and the load function will not be overwritten by the updated form value. But, that logic was also not working, so it will be fixed in the next version.

Finally, resetForm can be useful if you have invalidateAll: false, in which case it will or won't reset without any load function.

[v-morlock]

Alright, thanks for having a look. It’s more about being able to instantly see when there‘s a bug in the server action during testing. Right now, I always need to do a full refresh to see whether the value was actually updated on the server.

I get why resetForm:false would always display what’s being returned by the action.

But, imho it would be totally reasonable that resetForm:true always resets to the latest data returned by the loader - what’s the reason against that?

Just can’t really think if a case where the data returned by the loader would change but you wouldn’t want to reflect that in the form when it gets resetted?

[ciscoheat]

Maybe the invalidateAll can take an extra option, which will prevent the form action data from being used. It's complicated behind the scenes, so I have to see if it works without breaking anything.

[v-morlock]

Not sure how the action data is involved when resetForm is on true, as it's resetting the form to the data that was passed to client-superValidate on first page load.

I'd imagine the simplest solution would be to change resetForm to always reset to the latest data returned by the loader, if that's possible somehow?

[ciscoheat]

The page store can be updated by several sources, not to mention that it's an asynchronous operation (not sure what updates first, PageData or ActionData) so it's complicated.

[v-morlock]

That makes sense, thanks for explaining!

[ciscoheat]

Good news, it was possible to add a new invalidateAll: 'force' setting, which prioritizes updating the form data from the load function, and also updates the reset data to the load function data too. No need for hacks or applyAction settings. Your suggestions made good sense, so I'm happy they were possible to add. Will be available soon.

[v-morlock]

thanks a lot, that's great to hear!

[ciscoheat]

Added now in 2.6.1, please try and see if it works for you.

[ciscoheat]

Closing this, as the tests are passing.