The Wayback Machine - https://web.archive.org/web/20201222185202/https://github.com/thomashoneyman/purescript-halogen-realworld/issues/70
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Form `submit` event is not prevented #70

Closed
wryk opened this issue Aug 31, 2020 · 8 comments
Closed

Form `submit` event is not prevented #70

wryk opened this issue Aug 31, 2020 · 8 comments

Comments

@wryk
Copy link
Contributor

@wryk wryk commented Aug 31, 2020

The browser navigate the current page (from https://wryk.github.io/purescript-halogen-realworld/#/login to https://wryk.github.io/purescript-halogen-realworld/?#/login) when logging in, bypassing login app behavior and re-displaying the same login form. I can consistently reproduce this bug on both submit button click and enter keypress with Firefox 79 and Chromium 84 on the url without the empty query component (?).

This is because the app doesn't prevent native submit event behavior from the form (and instead rely on click event from the submit button to proceed with authentication). I can't explain why this is working when the url contains an empty query component.

The bug can be partially mitigated by using a button with type=button or properly by preventing default behavior of submit event. The later is usually the way forms are handled on SPA.

Purescript Halogen Realworld React Redux Realword
No event listener on form but one on submit button No event listener on submit button but one on form, allowing .preventDefault() on its submit event
image image

Others form may also be concerned by this problem.

@wryk wryk changed the title Form `submit` event are not prevented Form `submit` event is not prevented Aug 31, 2020
@thomashoneyman
Copy link
Owner

@thomashoneyman thomashoneyman commented Aug 31, 2020

Whoops! Good catch. Yes, I think we should add a preventDefault for submission.

@wryk
Copy link
Contributor Author

@wryk wryk commented Sep 1, 2020

I started to tackle this issue but I don't know how to correctly avoid boilerplate code inside components actions. I may ask some help later for that.

@thomashoneyman
Copy link
Owner

@thomashoneyman thomashoneyman commented Sep 11, 2020

Feel free to tackle this issue now, but as a heads up the forms will be switching to a new, Hooks-based version of Formless in the next month or two. Please go ahead if you'd like to, but the issue should be fixed then anyway :)

@wryk
Copy link
Contributor Author

@wryk wryk commented Sep 14, 2020

I have almost finished it but I don't see the point of integrating it if it is replaced right after. Thank you for letting me know.

I can't wait to see and learn the implementation with hooks :D

@toastal
Copy link
Contributor

@toastal toastal commented Nov 11, 2020

Shouldn't the Formless stuff validate on <form onsubmit=...> rather than overriding the <button type=submit onclick=...>?

@thomashoneyman
Copy link
Owner

@thomashoneyman thomashoneyman commented Nov 11, 2020

Yes, that would be the better approach when using a <form> element. Formless doesn't care which event triggers a submission, so either will work.

@toastal
Copy link
Contributor

@toastal toastal commented Nov 12, 2020

I say this because I'm trying to do something similar and am lost in a type error with all the row stuff :(

@thomashoneyman
Copy link
Owner

@thomashoneyman thomashoneyman commented Nov 13, 2020

I agree Formless is quite confusing. Fortunately for us all, the Hooks version of Formless is not far away and is considerably easier to use!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.