Posted store is set to true even when data is invalid

[shellicar]

Description The posted store returned from the superForm function is set to true whenever the form is submitted, even when it fails to submit with a success result.

This worked up until version 2.7.0, and seems to have broken in 2.8.0.

MRE

<script>
// ...
const { form, errors, message, posted, enhance } = superForm(data.form);
</script>

<pre>{JSON.stringify({
    posted: $posted
})}</pre>

[ciscoheat]

The intent of posted is to be true as soon as the form has been posted.

[shellicar]

I'm not sure I understand your response. What is the definition of posted? Surely the sequence is submitting -> posted? How can the form be posted if it was never submitted?

The way it has always worked is that unless the form is posted to the server, posted is not set to true. If the data is invalid with client-side validation, then there is no submission and therefore posted is not true. If the cancel function is called during onUpdate, it is also not set to true. At least when the SPA mode is set to true.

This change completely breaks the functionality that I have been depending on and has been that way since I started using the library in 1.x.

If the data is not posted to the server because of errors, then it is not posted, correct? If this was intended to change or be "fixed", why is it not noted in the release notes for 2.8.0? And if so, what store can I use to determine if the form has been submitted succesfully to the server?

[ciscoheat]

You expect too much, it's an open source project. Please contribute some falling tests if you've found a regression.

[shellicar]

For what it's worth this is currently my favourite library, and I really appreciate all the work and effort that is going in it, and to maintain it.

It seems like you think I am being unreasonable. I am reporting what I believe is a bug. I felt that your initial response was quite dismissive, and made it seem like it wasn't a bug or was by design, so I provided more information and seek clarification. What expectations do you think I have that are too much?

I am willing to conceded that the behaviour I am depending on is not specifically intended in SPA mode. I am probably in the minority when it comes to the way that I use sveltekit & superforms. But there doesn't seem to be enough information on what the posted store is intended for use for and how it behaves in certain situations.

I have spent a lot of time investigating every bug I encounter in order to make sure it is a bug, even tracking down the exact version change that it happened in. And testing things out in the REPLs (which are often quite buggy) to make sure it's not something weird going on in my machine.

I'd be happy to contribute if it helps improve the library, although my time is quite limited at the moment. If you can point me in the right direction for writing some tests, I'll have a look when I have a chance.

[ciscoheat]

You seem to expect no regressions and that the documentation and changelog should be fully updated, which is unrealistic for an open source project with a single maintainer and a few very kind sponsors.

You say your time is quite limited, well, it's the same for others. But that's how it is with OSS, you pay with your time.

superForm and superValidate are the two functions that should be used for testing the posted store, here they are: https://github.com/ciscoheat/sveltekit-superforms/tree/main/src/tests

[ciscoheat]

The posted store is too inconsistent between server and client validation, and SPA mode. It will be deprecated in v2 and removed in v3. Use a status message or return custom data in the form action to handle the form post status.