Visit helper not returning correct content upon using `this.replaceWith` for redirection about ember-cli-fastboot-testing

[dnalagatla]

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

[ryanto]

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?

[hoIIer]

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

[SergeAstapov]

@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.