Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Yew router when pushing history breaks form submits #2331

Closed
3 tasks
Firstyear opened this issue Jan 6, 2022 · 12 comments
Closed
3 tasks

Yew router when pushing history breaks form submits #2331

Firstyear opened this issue Jan 6, 2022 · 12 comments
Labels

Comments

@Firstyear
Copy link

Firstyear commented Jan 6, 2022

Problem
When a form is submitted that triggers a yew router push_history event, and subsequent form that is rendered by yew is unable to be submitted.

Steps To Reproduce
Steps to reproduce the behavior:
To reproduce this, I have provided a minimised example in the following repository:

https://github.com/Firstyear/yew-sandbox

Expected behavior
Pushing a route to the history to change pages with yew_router should not break form submissions.

Screenshots

Environment:

  • yew-router = "0.16.0"
  • yew = "0.19"
  • browser = edge 96.0.1054.62 (Official build) (x86_64)
  • built with wasm-pack, see repo.

Questionnaire

  • I'm interested in fixing this myself but don't know where to start
  • I would like to fix and I have a solution
  • I don't have time to fix this right now, but maybe later
@Firstyear Firstyear added the bug label Jan 6, 2022
@Firstyear
Copy link
Author

Firstyear commented Jan 6, 2022

Tested on master rev f6f0e34d0f914821cbeb1a9cfbd8f201d2594b18 and it also fails there. (See branch latest of repro)

@voidpumpkin
Copy link
Member

@Firstyear I dont think action="javascript:void(0);" is supposed to work but maybe im wrong.
Usually the flow for submitting with forms and to cancel default functionality is to use event,prevent_default().
so in app1.rs you can:

...
 <form
                onsubmit={ ctx.link().callback(|e| {
                    e.prevent_default();
                    AppMsg::ChangeState
                } ) }
>
...
</form>

@voidpumpkin
Copy link
Member

Also im not sure what is going on here https://github.com/Firstyear/yew-sandbox/blob/main/src/manager.rs#L28
Consider using a yew_router::Redirect component https://yew.rs/docs/next/concepts/router#redirect

@Firstyear
Copy link
Author

Also im not sure what is going on here https://github.com/Firstyear/yew-sandbox/blob/main/src/manager.rs#L28 Consider using a yew_router::Redirect component https://yew.rs/docs/next/concepts/router#redirect

There are no examples of redirect on https://docs.rs/yew-router/latest/yew_router/ which is why I didn't know this existed. Everything refers to pushing history.

I dont think action="javascript:void(0);" is supposed to work but maybe im wrong.
Usually the flow for submitting with forms and to cancel default functionality is to use event,prevent_default().
so in app1.rs you can:

With the changes you suggested, this still doesn't work with push history. Main of the repro has been updated to show this.

              <form
                onsubmit={ ctx.link().callback(|e: FocusEvent| {
                    e.prevent_default();
                    AppMsg::ChangeState
                } ) }
              >

If anything removing the onaction actually causes more issues because then on the second form submit, it doesn't seem to invoke the onsubmit handler and then triggers the tradition submit which causes the route to bypass the yew router code causing a 404.

Using Redirect somehow actually makes the situation worse, where the submission to the form will redraw, but the redirect never actually commits and then breaks. You can see this in the "redirect" branch of the reproducer.

@Firstyear
Copy link
Author

Tested in chrome 96.0.4664.110 (Official Build) (x86_64) as well now.

@voidpumpkin
Copy link
Member

@Firstyear Ok sorry i completely missed what you are trying to do here. Dont use forms with submit buttons + push_route to navigate between pages. Try using yew_router::Link.

Unless this is just a simplification and in real code you have to navigate on submit press, then idk how to help.
Usually people do some fetching on submit and only after the fetch completed, they use push_route to navigate.

@voidpumpkin
Copy link
Member

Here are the docs: https://yew.rs/docs/concepts/router#navigation

@voidpumpkin
Copy link
Member

voidpumpkin commented Jan 6, 2022

2 more things regarding with your setup:
1:
I would suggest back button i would suggest using history.back() :

                ctx.link()
                    .history()
                    .expect_throw("failed to read history")
                    .back();
  1. Your rounting is broken because you have an invalid SPA setup. Try manually going to page /app1, you will see you get a 404
    This happens because rollup tries to serve index html from folder /app1 ahe it should be serving index.html from root /

@voidpumpkin
Copy link
Member

Please ask further questions in Discussions tab or in our discord.

I am closing this as this is not an issue that needs to be worked on.

@Firstyear
Copy link
Author

The thing is this previously worked with yew-router, so it's a regression actually. It also works if you don't use the router API and just signal for the components to be swapped.

It also breaks if you remove the form, and just use the button as per the example of "mycomponent". See the updated commits to the repro. Using "Link" however works, which confuses me even more.

The reason I wanted to use the form/submit is to allow an autofocus to the element so the user can press "enter" to proceed.

And yes, I have the miniserve now working in spa mode so that the route is not 404'ing.

@voidpumpkin
Copy link
Member

Ok im not sure how to handle this issue, Could you look into this @futursolo ?

@voidpumpkin voidpumpkin reopened this Jan 7, 2022
@voidpumpkin
Copy link
Member

No no sry i forgot this issue is related with his env setup

@yewstack yewstack locked and limited conversation to collaborators Jan 7, 2022
@voidpumpkin voidpumpkin converted this issue into discussion #2344 Jan 7, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Projects
None yet
Development

No branches or pull requests

2 participants