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

Visit helper not returning correct content upon using this.replaceWith for redirection #204

Open
dnalagatla opened this issue Nov 13, 2019 · 4 comments

Comments

@dnalagatla
Copy link
Contributor

Currently, the Visit helper returns <body><h1>Redirecting to ... as DOM content instead of the DOM of the route to which the initial route redirects using this.replaceWith.

The issue is happening at this returned value - https://github.com/embermap/ember-cli-fastboot-testing/blob/master/index.js#L86

As fastboot provides the html content based on the statusCode and if it is a redirection getting redirection text - https://github.com/embermap/ember-cli-fastboot-testing/blob/master/addon-test-support/index.js#L46

I think for testing the finalized body should be provided by using page.domContents().body as HTML content.

@ryanto
Copy link
Member

ryanto commented Nov 13, 2019

Hey @dnalagatla! Thanks for reporting this.

So I pulled up an old issue from the FastBoot repo about replaceWith and redirects, and it looks like replaceWith is designed to respond with a redirect: ember-fastboot/fastboot#54

I think maybe fastboot testing should support having visit() with a followRedirects: true option that can be useful for these scenarios. How does that sound?

Also, are you able to work around this issue today or is it blocking you?

@dnalagatla
Copy link
Contributor Author

I think maybe fastboot testing should support having visit() with a followRedirects: true option that can be useful for these scenarios. How does that sound?

Hi @ryanto, thank you for looking into this issue. I wasn't aware of that issue in Fastboot. That was useful to get some context.

The idea of passing followDirects option to visit sounds like a idea to me, would certainly work for scenarios at LinkedIn. As we return settled DOM after redirection in Fastboot.

We are not blocked on this issue, will be useful. I can work on a PR

@hoIIer
Copy link

hoIIer commented Aug 13, 2021

@ryanto I'm hitting this in a production fastboot app... still searching for how to handle it properly

@SergeAstapov
Copy link
Collaborator

@erichonkanen it's actually valid scenario that you do not get the DOM of the route to which the initial route redirects using this.replaceWith, it's by design how FastBoot (and server-side in general) works.

Each url in the web represents unique content hence when you do this.replaceWith - you redirect user to another page with another url (which by design a separate piece of content).

When app redirects browser to another url, it does so by sending 301/307/308/etc. status code and browsers respect that and navigate to the url retuned in Location response header.

I guess, in your case you either need to stick to the redirect (and let browser navigate to the new url and get content from it) or you need to switch from using this.replaceWith to rendering the content you want to render on that url (which means you don't redirect users).

Said above, this does not sound like an issue with this package.
However it may be an enhancement to have something like followRedirects: true option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants