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
app.featurepeek.com. 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.
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:
- Approve the FeaturePeek OAuth app in your organization settings.
- 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.
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
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.
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.