There are a few common gotchas that are easy to fix if you know what to look for.

Your frontend loads within an iframe on a subdomain of Your app should account for this in order to function properly on FeaturePeek. That means that you shouldn't framebust or depend on the URL to match a domain that you own.

When in doubt, check your JavaScript console if something goes wrong when loading a FeaturePeek deployment. Console errors bubble up just like they would in your development or staging environments.

I'm not seeing my GitHub orgs or repos appear

During account creation, you may have inadvertently not granted OAuth access to your organization you'd like to use on FeaturePeek. If this is the case, you'll need to grant access, or request access if you are not an organization admin.

There are two steps you should take:

  1. Approve the FeaturePeek OAuth app in your organization settings.
  2. Grant or request organization access to FeaturePeek in your personal OAuth application settings.

If you're still unable to see the organization or repo you're looking to integrate with on FeaturePeek, please contact support.

My SPA can't load routes

If your app is a static project that uses the HTML5 pushState history API under the hood (for example, React Router with browserHistory), FeaturePeek's default file server will 404 when the file cannot be found. For example, if you use React Router with a route for /todos/42, your development server will respond to localhost:3000/todos/42 properly, but FeaturePeek serving a production build will not.

This is because when there is a fresh page load for /todos/42, FeaturePeek looks for the file build/todos/42 and does not find it. Your project needs to be configured to respond to a request to /todos/42 by serving index.html for any unknown paths.

In your peek.yml file, set the spa key to true. Once you commit and push this setting, your deployment will pick up this configuration change.

project settings

I can't log in to my app within FeaturePeek

A caveat of the OAuth 2 spec is that OAuth logins are not recommended to be embedded within an iframe. Depending on your browser settings, authentication may not go through as expected.

In Safari, this may happen if you have the Prevent cross-site tracking preference enabled. WebKit uses Intelligent Tracking Prevention that unfortunately limits logging in to a separate domain when within an iframe. Double-check that you have preference unchecked in Safari Preferences > Privacy, then relaunch your browser for the setting to take effect.

For more information, please read Auth0's document on Cross-Origin Authentication.

My Gatsby site loads as a blank white page

There's a bug in Gatsby that causes routes without a trailing slash (/) to redirect to their slash-containing counterpart. The 301 redirect happens over HTTP, not HTTPS — so when accessed in a frame, the browser throws a Mixed Content error that prevents the page from loading.

The simple workaround is when sharing links to your FeaturePeek deployment (or when setting the entry path), that you ensure your route contains a trailing slash.

Some of my page's subresources 404

If you are using Safari and notice that some of your JavaScript and/or CSS files are 404ing, then you are hitting a bug in WebKit. The bug incorrectly prohibits access to subresources when the crossorigin="anonymous" attribute is set, even when the subresources are loaded from the same origin.

To fix, simply remove the crossorigin attribute on tags pointing to relative files on the same origin. Specifying crossorigin on resources known to be on the same origin does nothing in the first place.

My deployments take too long to spin up

Pinging FeaturePeek only takes a few seconds, so if there's a noticeable slow-down, it's probably due to the build itself.

You should make sure that you are building your frontend in CI before running any tests. If your CI service supports concurrent jobs, move your build + ping FeaturePeek phase into a job that runs in parallel to your test job.

My service workers aren't activating

Service workers have the ability to intercept and modify every outgoing and incoming network request that occurs on the page. The primary use case for service workers is for fine-tuned cache control, to better support users on unreliable networks (e.g. mobile connections). If a user has a flaky wireless connection, a service worker could read from an offline cache so that the website would not appear to be offline.

On page load, FeaturePeek loads a JavaScript file relative to the root path of every deployment. This is how FeaturePeek is able to add functionality to the page without you needing to install runtime dependencies. Since service workers can interfere with loading resources on the network (and in turn, this required file), FeaturePeek unregisters any service workers that are installed on the app's domain.

Your app shouldn't depend on service workers for anything mission-critical anyway — since the vast majority of use cases are for supporting offline mode, disabling them shouldn't interrupt your workflow. Please reach out to support if your app doesn't work without service workers.