Toolbar production stats/data in localhost

[mariusandra]

Describe the solution you'd like

I would like to browse a dev version of my gatsby/docusarus/next/cra/etc website on http://localhost:3000 and have the toolbar show statistics for the production site.

How should this work? When initing posthog-js I should tell it that I'm in dev mode and which host it should used instead of "localhost:3000" when getting the stats.

Any preference on the API for this?

Here's a proposal:

posthog.init('MY_TOKEN', {
    api_host: 'https://app.posthog.com',

    // option 1: replace every domain
    dev_mode: 'https://kea.js.org',

    // option 2: replace domain(s) explicitly
    dev_mode: {
        "http://localhost:3000": "https://kea.js.org",
        "http://localhost:3000/blog": "https://blog.kea.js.org"
    }
})

I'm just not convinced of the "dev_mode" key. Any thoughts on it?

Describe alternatives you've considered Create a bunch of test events in localhost and see stats about them. Not nearly as fun.

Additional context This would make the toolbar 🔥🔥🔥 when developing locally.

Thank you for your feature request - we love each and every one!

[timgl]

Could just automatically do a query like this: [{"key":"$current_url", "operator":"icontains","value":"/demo"}] so there's no need to even specify urls? In the rare cases that events do overlap across domains we could give an option in the toolbar to specify a domain if you're on localhost, but I don't think that's urgent

[mariusandra]

There are a few issues with this.

1) You can have multiple pages like /demo and /store/featured-item/demo and /catalog/shirts/demo and whatever. Without replacing "contains" with "starts with", someone, somewhere, will get weird data. Especially with urls like "/index.html"

2) It's very likely that one day you will be logged out on app.posthog.com (or wherever you host it). In this case the toolbar would not open and posthog-js will track all the random localhost pageviews and events you generate. This will just add a lot of noise.

Explicitly saying "I'm developing now" will prevent both cases.

[timgl]

1. That's a fair point. We do have the concept of $pathname but it's only sent with $autocapture at the moment but could send it everywhere. Alternatively we could query with a regex that correctly gets the start of the path, as Postgres allows you to do that.
2. We already capture random noise from localhost at the moment. I think that's a separate issue to this.

My reason for pushing in a direction that works out of the box is that each bit of configuration we add to make PostHog work is another 10-30% of people that drop out, and a lot of questions on slack from people who have set it up incorrectly. It'd be magical if you just add our vanilla snippet, and instantly it works both in localhost and production.

[mariusandra]

I'm with you re: reasoning. We could add some intelligence and do if url =~ "localhost" then dev_mode!, assuming we get the URL/pathname lookup right. Still I believe there should be a way to explicitly enable this as well. For example for branch deploys, staging environments, etc.

Using a $pathname property in every event would be great... and it'll solve most problems I guess. However there are still sites that do crazy stuff with the URL (e.g. dev: localhost:3000, prod: example.com/blog), so having a way to override this somehow makes sense.

[timgl]

Yep totally agree! also think this isn't required for soft launch unless you disagree?

[mariusandra]

I made a PR that sends $host and $pathname with all events in posthog-js.

I can push out a new release once I figure out what's the deal with the beacon/batching/etc situation.

Re: soft launch and the options. I think the order that makes sense is to still create an option that can be set and does whatever URL transformations are needed. Then add logic that enables it if running under localhost... instead of just enabling it for all in localhost and providing no way to opt out.

Something like this:

posthog.init('MY_TOKEN', {
    api_host: 'https://app.posthog.com',

    // option 1: search for $pathname instead of $current_url
    // enabled automatically if the host contains 'localhost'
    // disabled otherwise
    dev_mode: true,

    // option 2: search for the full $current_url, but replace the hostname with this:
    dev_mode: 'https://kea.js.org',

    // option 3: replace domain(s) explicitly however you want to
    dev_mode: localPath => productionPath
})

I just don't know if this should be called dev_mode or something else.

[timgl]

Hm instead of doing this in the snippet (which is going to be hard to convince/explain to people to setup correctly), why don't we do this in the toolbar itself? That way it's much easier to configure. You already have the globe with the url next to it, so if you're on localhost it just allows you to select a domain that you want to search for instead? Maybe I'm missing something

[mariusandra]

That's an interesting idea and could make some things simpler, yet I'm afraid it'll complicate some other things (and not just the interface):

• Where to store this "localhost:3000 is actually kea.js.org" info? DB or localstorage? If in db, should it be per-user or per-team and can anyone override it? If locally, do you need to re-enter this every other time you use the toolbar when your cache gets cleared or you switch devices? What if it's "localhost:3001" because you forgot you had "yarn start" running in a different terminal window?
• What about if you're just in the default "button mode" and click "heatmap"... and... crickets? We could pop up a clippy who guides you through the "setup", yet better to ignore this totally.
• What if you really want to say "send no events on this domain, ever, just let me use the toolbar"?

The snippet as discussed above would work fine for 99% of the cases (dev mode is "off" normally, and "on" if url =~ "localhost"), so there's nothing to update in the snippet. Just those who need extra power to muck with the URL due to some already complex situation can for sure manage the extra complexity of this option.

[timgl]

Ah okay, so your proposing that if I have a normal setup (localhost:3000 and posthog.com for example) it would work automatically, but if you have a more complicated setup you can add some stuff to the init? That makes sense to me

[mariusandra]

Yeah, what it looks like I'm now proposing is to have a dev_mode option to alter the url when asking for stats/actions/etc. If left undefined, this option would default to "true" if the host is localhost and "false" under all other situations.

If it's false, everything works like now. If it's true, we'll just search with $pathname and disable all event captures. If it's a string, we replace the host with the string If it's a function, we replace the url with custom logic

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[posthog-bot]

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.

[mariusandra]

This is still relevant if we want to focus more on developers. Having a toolbar running locally on your dev site with production data from the heatmap could be very interesting for developing, and especially for experiments/flags.