0
0
mirror of https://github.com/PostHog/posthog.git synced 2024-12-01 04:12:23 +01:00
posthog/.storybook/public/mockServiceWorker.js

303 lines
8.9 KiB
JavaScript
Raw Normal View History

chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
/* eslint-disable */
/* tslint:disable */
/**
* Mock Service Worker (0.47.3).
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
* @see https://github.com/mswjs/msw
* - Please do NOT modify this file.
* - Please do NOT serve this file on production.
*/
const INTEGRITY_CHECKSUM = 'b3066ef78c2f9090b4ce87e874965995'
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
const activeClientIds = new Set()
self.addEventListener('install', function () {
self.skipWaiting()
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
})
self.addEventListener('activate', function (event) {
event.waitUntil(self.clients.claim())
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
})
self.addEventListener('message', async function (event) {
const clientId = event.source.id
if (!clientId || !self.clients) {
return
}
const client = await self.clients.get(clientId)
if (!client) {
return
}
const allClients = await self.clients.matchAll({
type: 'window',
})
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
switch (event.data) {
case 'KEEPALIVE_REQUEST': {
sendToClient(client, {
type: 'KEEPALIVE_RESPONSE',
})
break
}
case 'INTEGRITY_CHECK_REQUEST': {
sendToClient(client, {
type: 'INTEGRITY_CHECK_RESPONSE',
payload: INTEGRITY_CHECKSUM,
})
break
}
case 'MOCK_ACTIVATE': {
activeClientIds.add(clientId)
sendToClient(client, {
type: 'MOCKING_ENABLED',
payload: true,
})
break
}
case 'MOCK_DEACTIVATE': {
activeClientIds.delete(clientId)
break
}
case 'CLIENT_CLOSED': {
activeClientIds.delete(clientId)
const remainingClients = allClients.filter((client) => {
return client.id !== clientId
})
// Unregister itself when there are no more clients
if (remainingClients.length === 0) {
self.registration.unregister()
}
break
}
}
})
self.addEventListener('fetch', function (event) {
const { request } = event
const accept = request.headers.get('accept') || ''
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
// Bypass server-sent events.
if (accept.includes('text/event-stream')) {
return
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}
// Bypass navigation requests.
if (request.mode === 'navigate') {
return
}
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
// Opening the DevTools triggers the "only-if-cached" request
// that cannot be handled by the worker. Bypass such requests.
if (request.cache === 'only-if-cached' && request.mode !== 'same-origin') {
return
}
// Bypass all requests when there are no active clients.
// Prevents the self-unregistered worked from handling requests
// after it's been deleted (still remains active until the next reload).
if (activeClientIds.size === 0) {
return
}
// Generate unique request ID.
const requestId = Math.random().toString(16).slice(2)
event.respondWith(
handleRequest(event, requestId).catch((error) => {
if (error.name === 'NetworkError') {
console.warn(
'[MSW] Successfully emulated a network error for the "%s %s" request.',
request.method,
request.url
)
return
}
// At this point, any exception indicates an issue with the original request/response.
console.error(
`\
[MSW] Caught an exception from the "%s %s" request (%s). This is probably not a problem with Mock Service Worker. There is likely an additional logging output above.`,
request.method,
request.url,
`${error.name}: ${error.message}`
)
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
})
)
})
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
async function handleRequest(event, requestId) {
const client = await resolveMainClient(event)
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
const response = await getResponse(event, client, requestId)
// Send back the response clone for the "response:*" life-cycle events.
// Ensure MSW is active and ready to handle the message, otherwise
// this message will pend indefinitely.
if (client && activeClientIds.has(client.id)) {
;(async function () {
const clonedResponse = response.clone()
sendToClient(client, {
type: 'RESPONSE',
payload: {
requestId,
type: clonedResponse.type,
ok: clonedResponse.ok,
status: clonedResponse.status,
statusText: clonedResponse.statusText,
body: clonedResponse.body === null ? null : await clonedResponse.text(),
headers: Object.fromEntries(clonedResponse.headers.entries()),
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
redirected: clonedResponse.redirected,
},
})
})()
}
return response
}
// Resolve the main client for the given event.
// Client that issues a request doesn't necessarily equal the client
// that registered the worker. It's with the latter the worker should
// communicate with during the response resolving phase.
async function resolveMainClient(event) {
const client = await self.clients.get(event.clientId)
if (client.frameType === 'top-level') {
return client
}
const allClients = await self.clients.matchAll({
type: 'window',
})
return allClients
.filter((client) => {
// Get only those clients that are currently visible.
return client.visibilityState === 'visible'
})
.find((client) => {
// Find the client ID that's recorded in the
// set of clients that have registered the worker.
return activeClientIds.has(client.id)
})
}
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
async function getResponse(event, client, requestId) {
const { request } = event
const clonedRequest = request.clone()
function passthrough() {
// Clone the request because it might've been already used
// (i.e. its body has been read and sent to the client).
const headers = Object.fromEntries(clonedRequest.headers.entries())
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
// Remove MSW-specific request headers so the bypassed requests
// comply with the server's CORS preflight check.
// Operate with the headers as an object because request "Headers"
// are immutable.
delete headers['x-msw-bypass']
return fetch(clonedRequest, { headers })
}
// Bypass mocking when the client is not active.
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
if (!client) {
return passthrough()
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}
// Bypass initial page load requests (i.e. static assets).
// The absence of the immediate/parent client in the map of the active clients
// means that MSW hasn't dispatched the "MOCK_ACTIVATE" event yet
// and is not ready to handle requests.
if (!activeClientIds.has(client.id)) {
return passthrough()
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}
// Bypass requests with the explicit bypass header.
// Such requests can be issued by "ctx.fetch()".
if (request.headers.get('x-msw-bypass') === 'true') {
return passthrough()
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}
// Notify the client that a request has been intercepted.
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
const clientMessage = await sendToClient(client, {
type: 'REQUEST',
payload: {
id: requestId,
url: request.url,
method: request.method,
headers: Object.fromEntries(request.headers.entries()),
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
cache: request.cache,
mode: request.mode,
credentials: request.credentials,
destination: request.destination,
integrity: request.integrity,
redirect: request.redirect,
referrer: request.referrer,
referrerPolicy: request.referrerPolicy,
body: await request.text(),
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
bodyUsed: request.bodyUsed,
keepalive: request.keepalive,
},
})
switch (clientMessage.type) {
case 'MOCK_RESPONSE': {
return respondWithMock(clientMessage.data)
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}
case 'MOCK_NOT_FOUND': {
return passthrough()
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}
case 'NETWORK_ERROR': {
const { name, message } = clientMessage.data
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
const networkError = new Error(message)
networkError.name = name
// Rejecting a "respondWith" promise emulates a network error.
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
throw networkError
}
}
return passthrough()
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}
function sendToClient(client, message) {
return new Promise((resolve, reject) => {
const channel = new MessageChannel()
channel.port1.onmessage = (event) => {
if (event.data && event.data.error) {
return reject(event.data.error)
}
resolve(event.data)
}
client.postMessage(message, [channel.port2])
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
})
}
function sleep(timeMs) {
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
return new Promise((resolve) => {
setTimeout(resolve, timeMs)
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
})
}
async function respondWithMock(response) {
await sleep(response.delay)
return new Response(response.body, response)
chore(correlation): funnel story with correlation events and properties (#6389) * chore(correlation): funnel story with correlation events and properties This commit: 1. adds msw so we can easily mock the API requests 2. starts msw on storybook page load 3. adds the `mockServiceWorker.js` to storybook public folder so it can be loaded by the frontend 4. adds a Funnel story that defines the funnel and correlation responses Note that we also define types for requests and responses. These could be shared with the actual application code, so we can explicitly couple the application changes to updating storybooks, i.e. to help avoid stories going stale. The requests and responses are quite basic, but they are sufficient to be able to easily see and make changes. It has a requirement that it should be easy for anyone else who comes to the code to easily parse and be able to make updates. We don't want these to be rotten stories but *the place* that people go to first when making their changes. Having simple handwritten request/responses also introduces the stability needed to, for example, use regression tests. Changes are deliberate. * refactor(storybook): move funnel stories to their own file This also does quite a bit of cleaning up of the storybook and funnel story code. Trying to come down on an acceptable way to manage the sample data. * dev(storybook): specify public dir when building storybook I'm hoping this means that chromatic will function properly :pray: * chore: add back the withApi decorator * setup msw first * dev(storybook): Make posthogjs work in chromatic * dont use as cast for response types * make hot module reload work
2021-10-13 06:45:51 +02:00
}