Skip to content

Conversation

@hantran-co
Copy link
Contributor

  • Install Posthog snippet
  • Will create events/actions once Faisal completes Jan's new web design

@hantran-co hantran-co requested a review from urmauur November 9, 2023 07:24
@hantran-co
Copy link
Contributor Author

@urmauur
Hey can you help me check this error, this snippet works on my local but not sure why it is built unsuccessfully

Screenshot 2023-11-09 at 2 29 54 PM

@freelerobot freelerobot mentioned this pull request Nov 13, 2023
1 task
@hiento09
Copy link
Contributor

image

Copy link
Contributor

@louis-jan louis-jan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@hiento09 hiento09 merged commit a1eaa93 into main Nov 13, 2023
@hiento09 hiento09 deleted the Ashley/Install_Posthog branch November 13, 2023 10:01
@dan-menlo
Copy link
Contributor

@urmauur Hey can you help me check this error, this snippet works on my local but not sure why it is built unsuccessfully

Screenshot 2023-11-09 at 2 29 54 PM

I've also experienced this issue, but it doesn't seem to affect building on Prod

@urmauur
Copy link
Member

urmauur commented Nov 13, 2023

@dan-jan we move to env, will DM you regarding .env

@dan-menlo
Copy link
Contributor

dan-menlo commented Nov 13, 2023

@imtuyethan @hiento09 I encountered this issue when running yarn start.

  • Is the common practice to disable GTM in dev environment?
  • Or do we have a dev branch GTM_ID?

I saw the GTM_ID specified in .env.example, but we should either provide a dev env GTM_ID, or it'll be quite tough for contributors if they have to specify their own.

image

@dan-menlo
Copy link
Contributor

@dan-jan we move to env, will DM you regarding .env

I think my concern is with contributors who might want to git clone Docs and add to it. We should not require them to have a GTM_ID filled from .env, otherwise it adds difficulty and will deter contributions.

Is it still best practice in 2023 to check for window.hostname before firing GTM/Google Analytics?
https://stackoverflow.com/questions/40297763/how-to-disable-google-analytics-on-localhost

@dan-menlo
Copy link
Contributor

dan-menlo commented Nov 13, 2023

@hiento09 @louis-jan @imtuyethan @urmauur Btw, for Docs, I actually would recommend having hard-coded Posthog and GTM IDs.

  • There should only be one Jan.ai docs site
  • .env injections are better for self-hosted apps, where GTM, Posthog are designed to be different
  • We can track when lazy forkers just fork and deploy our site (it will happen)

Hard-coding Analytics IDs ironically helps us find out when lazy forkers just deploy a docs site. I don't intend to prevent that, but it would be nice to be able to track that from our analytics. We can then see traffic stats by domain (including localhost, as a measure of dev documentation activity).

@urmauur
Copy link
Member

urmauur commented Nov 13, 2023

Hi @dan-jan not sure if we hardcode the GTM-ID, when someone fork the Jan docs and deploy to their web example, what happen if they still using our GTM-ID, but if we worried someone to contribute to Jan docs, i think we can add default something like this

googleTagManager: { containerId: process.env.GTM_ID || "XXX", },
and
{ apiKey: process.env.POSTHOG_PROJECT_API_KEY || "XXX", appUrl: process.env.POSTHOG_APP_URL || "XXX", // optional enableInDevelopment: false, // optional }

so even someone missing .env still can run yarn start

cc @louis-jan

@dan-menlo
Copy link
Contributor

Sounds good! My first objective is to make sure someone can contribute, without a .env. The "lazy forker" is less important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Archived in project

Development

Successfully merging this pull request may close these issues.

7 participants