Should formData be present for "traverse" and "reload" navigations?

[domenic]

Consider the following case:

1. Start on /page1.
2. Submit a POST form to /page2.
3. The navigate handler intercepts this. You have e.navigationType === "push" and e.formData containing the form data. You use this to do something interesting on the server and do e.respondWith() to fill in the resulting page with the results.
4. The user navigates to /page3.
5. The user presses back. This will fire a navigate event with e.navigationType === "traverse". But what should e.formData contain?

A very similar scenario involves replacing step 4 and 5 with "the user presses reload", which will fire a navigate event with e.navigationType === "reload".

Arguments for it being null:

• Traversal navigations aren't really form submissions; only pushes can be form submissions
• It being null avoids situations where the reload/traverse causes something interesting to happen on the server twice, because the navigate handler didn't think to guard against e.navigationType !== "push".
• People seem to really not like resubmission behavior, to the extent of creating the whole post/redirect/get system. Maybe nulling out the form data on further submissions is a lite form of a post/redirect/get which people would appreciate.

Arguments for it being the originally-submitted form data:

• The navigate handler might need this form data to construct the appropriate stuff to fill the page with.
• This gives the developer the option of how to handle the situation. E.g. they could guard against such traversals, or they could pop up a "confirm resubmission" dialog, or they could check if the submission is to an idempotent route vs. a mutating one, or...
• Anyone who cares about avoiding resubmission is probably doing post/redirect/get, or its app history counterpart, anyway. So they would not encounter this problem; only people who want resubmission would get into this situation.

[tbondwilkinson]

I want to say no, that formData is an ephemeral component of the first-submission event, and further navigational events should not contain it. If you want to store parts of the form data for later retrieval, you can do that explicitly by copying it somewhere (or even to history state).