remix
remix copied to clipboard
[Bug]: `reloadDocument` prop on `Form` does not mimic browser behavior
What version of Remix are you using?
1.0.6
What version of Node are you using? Minimum supported version is 14.
17.1.0
Steps to Reproduce
- Clone my reproduction repository
npm installnpm run dev- Open the browser DevTools Network tab
- Submit the form ( request is a
POST) - See the error show up
- Refresh the page ( request is a
POST) - See the error be present still on the page ( as the
POSTwas retried ) - Enable JS on the page by setting
hydratetotrueinapp/routes/index.tsx - Submit the form ( request is a
POST) - See the error show up
- Refresh the page ( request is a
GET) - See the error has disappeared ( as request was not a form submission )
- Set the
reloadDocumentprop onForminroutes/index.tsxtotrue - Retry steps 5 - 13 and notice
reloadDocumentdoesn't make a difference
Expected Behavior
I would expect the request in step 12 to be a POST, just like it was without JS. Perhaps this should be the default behavior, or otherwise it could be opt-in?
Actual Behavior
The request in step 12 is a GET, even when using reloadDocument
As mentioned by @kentcdodds in Discord:
Originally Ryan had made it so a refresh would trigger the request again in a useEffect and I complained because it was unexpected. He told me that's what the browser does without JavaScript and I said I didn't care and that this is unexpected for users of modern apps. He agreed.
Really the crux of my question is: -> When JS is enabled, the form error disappears after a refresh. A refresh does not reattempt the submit using the old data. -> When JS is disabled, the form error stays after a refresh. A refresh reattempts the old request Where does the difference between these two come from and is there any chance they will be aligned in the future? Or is this a bad idea?
@jensmeindertsma I'm going through old issues to see what's fixed, and I see your reproduction repository doesn't exist anymore.
Is this still an issue for you?
This issue has been automatically closed because we haven't received a response from the original author 🙈. This automation helps keep the issue tracker clean from issues that are unactionable. Please reach out if you have more information for us! 🙂