Pre-production testing for iframed experiences

Search Best Practices - Integration
1

Hello,

Testing an iframed version of an Answers experience is an important part of our development process. I wanted to start a conversation on best practices, and am interested if there’s anything we can do to make it simpler, or more of an out of the box workflow.

Here’s what I’ve been doing:

Approach 1:

  • Create a iframe.html file in the output directory with an answers container and js snippet.
  • Update jambo config preservedFiles to preserve iframe.html

This isn’t too difficult, but the files can’t be committed because we don’t want to actually publish the iframe.html page. If you need anything custom on the iframe.html page there isn’t a good way to preserve those customizations.

Approach 2:

  • Create iframe.html somewhere else in the repo and commit it
  • Invoke serve separately on a different port to serve iframe.html
    This has the advantage of letting us commit the file, however because it’s on a different port iframe.js doesn’t set the src for the iframe correctly. It’s possible the logic there could be updated so this works?

Other problems:
Another thing that has caused difficulty is the default behavior of serve which strips the .html suffix of pages. This breaks certain behaviors, for example if you search for test query on a universal page, then a link in the vertical navigation component will look like: http://localhost:8080/vertical.html?query=test+query, when you click the link however, serve will redirect from /vertical.html to /vertical and in the process strip the query param. We’ve instead been serving the site with python -m SimpleHTTPServer. It looks like there’s a cleanUrls config option that could also be disabled: GitHub - vercel/serve-handler: The foundation of `serve`.

To summarize, some specific changes that I think would be helpful:

  • update iframe.js logic to correctly calculate iframe url when accessed locally on a different port than the main answers experience
  • include default configuration for serve to disable cleanUrls behavior

But anything else that makes this easier would be appreciated. The things I’ve brought up also only help with local development, I don’t know of a good way to do this at all in the code editor / preview experience.

Thanks!

2

Hi Ben,

Thanks for your thoughtful post. I think we should certainly add the cleanUrls config for the serve command. That will help both local development and development in the code editor. The stripping of the .html and query params is confusing and does not give a true sense for how the links will work once the site is published. For the second approach you listed, what behavior are you seeing when the iframe src is set? Is it erroneously using the Production URL versus the Staging one?

As a team we don’t currently have a best practice for testing iFrame integrations. I think some of us use Approach 1. Others use a CodePen site to represent iframe.html. One thing you might try is a combination of the two approaches. Locally, at least, you could check-in the iframe.html file outside desktop. You could then modify one (or more) of the CI scripts to copy this file into the desktop directory before serve is run. You’d want to limit this change to the CI scripts that are used for Preview and not the generation of the actual, published artifacts. Spruce may be able to shed some light on which CI scripts are used for one versus the other.

3

The approach of customizing the CI scripts to copy a file into the desktop sounds good. Is that something that could be incorporated into the default setup for an answers repository? This kind of testing is something we want to do on all of the iframe experiences that we do custom development for.

Re: the behavior in the second approach, if I’m using ./ci/serve.sh to serve the answers experience at http://localhost:8080 then I create an html page with:

<div id="answers-container"></div>
<script src="http://localhost:8080/iframe.js"></script>

and serve it on http://localhost:8000 then the iframe src will be set to /index.html?&referrerPageUrl=. Because the index.html is being served on a different port this 404s.