Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify with-google-analytics example #43894

Merged
merged 16 commits into from Feb 7, 2023

Conversation

Josehower
Copy link
Contributor

@Josehower Josehower commented Dec 9, 2022

Documentation / Examples

  • Make sure the linting passes by running pnpm build && pnpm lint
  • The "examples guidelines" are followed from our contributing doc

First of all thanks for this amazing project and all the help you provide with these examples.

It seems there is code duplication in this example. After some tests locally seem to _document.js is not necessary for gtag to work properly.

dangerouslySetInnerHTML={{
__html: `
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());

dangerouslySetInnerHTML={{
__html: `
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());

I am aware of #40645 and I would like to ask @dave-hay, @SukkaW and @ijjk to consider this is still necessary. If so why then not move all content of the scripts from _app to _document?

In any case, I am open to adding here some comments explaining what is the reason for this code duplication if necessary.


Changes that come from #43897

  1. The event hashChangeComplete should be removed since /home and /home/#section is not new pageview, but just reference to the same page.

If we go from /home to /home/#section (with a button click or a link for example) this shouldn't trigger a new page visit on gtag.

For this reason, I think we should revert the changes from #36079. If there is a better argument of why this should stay I am also open to creating comments to clarify this on the example since I don't think should be the default behavior and not useful in most cases.

  1. The id="gtag-init" was added with no context to the example from Add id to inline gtag script #29530

If there is a reason for this id in the script to existing I am open to adding a comment that clarifies this since in my experience is not necessary at all.

Edit: Batching with #43897 as recommended by #43897 (comment)

@ijjk ijjk added the examples Issue/PR related to examples label Dec 9, 2022
@maxproske
Copy link
Contributor

FYI to maintainers, there's a PR open that's trying to add more to the _document.js. So it can be closed if this one is approved: #43838

@dave-hay
Copy link
Contributor

dave-hay commented Dec 9, 2022

@Josehower the reason for adding in _document.js was it resolved #40410, context below. If there have been updates to the framework since then that render this unnecessary then shouldn't be an issue to remove _document.js.

Describe the Bug

calling reportWebVitals when having google analytics setup using with-google-analytics results in Next.js-hydration event getting triggered BEFORE gtag is initialized.

This could be problematic in production if someone is just assuming gtag is always defined when reporting on web vitals.

Expected Behavior

When having google analytics setup using the with-google-analytics example, I would expect gtag to be defined for all events before triggering reportWebVitals.

@Josehower
Copy link
Contributor Author

Batching with #43897 as recommended by #43897 (comment)

@Josehower Josehower closed this Dec 10, 2022
@Josehower Josehower reopened this Dec 10, 2022
@Josehower Josehower changed the title Remove unnecessary _document.js Remove unnecessary code in _app.js and _document.js Dec 10, 2022
@SukkaW
Copy link
Contributor

SukkaW commented Dec 10, 2022

FYI to maintainers, there's a PR open that's trying to add more to the _document.js. So it can be closed if this one is approved: #43838

@maxproske @Josehower I just checked #43838 and I belive that PR is valid. Google Analytics does require a very lightweight inline script in the <head>. So _document is required for Google Analytics setup.

@karlhorky
Copy link
Contributor

karlhorky commented Dec 10, 2022

Google Analytics does require a very lightweight inline script in the <head>. So _document is required for Google Analytics setup.

Ok so if _document is required, maybe the suggestion in the description from @Josehower makes sense, to avoid the duplication mentioned in the description:

If [it's necessary to have _document] why then not move all content of the scripts from _app to _document?

If this is acceptable, the changes from #43838 could be also merged into this PR (or #43838 merged first, and then this PR rebased on that)

@SukkaW
Copy link
Contributor

SukkaW commented Dec 10, 2022

Ok so if _document is required, maybe the suggestion in the description from Josehower makes sense, to avoid the duplication mentioned in the description:

If [it's necessary to have _document] why then not move all content of the scripts from _app to _document?

Agree.

@Josehower Would you mind changing your PR to only remove gtag-init inside _app instead? So after #43838 and this PR merge, Google Analytics should work properly.

@karlhorky
Copy link
Contributor

karlhorky commented Dec 10, 2022

only remove gtag-init inside _app instead? So after #43838 and this PR merge, Google Analytics should work properly.

There would still be another change required - removing the duplicate code that is mentioned in the description of this PR:

dangerouslySetInnerHTML={{
__html: `
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());

dangerouslySetInnerHTML={{
__html: `
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());

@karlhorky
Copy link
Contributor

karlhorky commented Dec 10, 2022

Actually, I think the proposal by @Josehower was that all Google Analytics content be moved from _app to _document, so the parts below as well (why have these in _app when they can be in _document?).

Then the _app file can be removed completely.

const router = useRouter()
useEffect(() => {
const handleRouteChange = (url) => {
gtag.pageview(url)
}
router.events.on('routeChangeComplete', handleRouteChange)
router.events.on('hashChangeComplete', handleRouteChange)
return () => {
router.events.off('routeChangeComplete', handleRouteChange)
router.events.off('hashChangeComplete', handleRouteChange)
}
}, [router.events])

{/* Global Site Tag (gtag.js) - Google Analytics */}
<Script
strategy="afterInteractive"
src={`https://www.googletagmanager.com/gtag/js?id=${gtag.GA_TRACKING_ID}`}
/>
<Script
id="gtag-init"
strategy="afterInteractive"
dangerouslySetInnerHTML={{
__html: `
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', '${gtag.GA_TRACKING_ID}', {
page_path: window.location.pathname,
});
`,
}}
/>

@karlhorky
Copy link
Contributor

karlhorky commented Dec 10, 2022

only remove gtag-init inside _app instead?

Also, one more thing, there is another change in this PR aside from the gtag-init (because @maxproske suggested that the changes be batched - which probably created more confusion).

So this change to hashChangeComplete should also be considered (also described in the PR description), this has not been discussed yet:

Screenshot 2022-12-10 at 12 10 24

@Josehower
Copy link
Contributor Author

Josehower commented Dec 12, 2022

I manage to solve the issue with WebVitals reported on #40410 without the need of _document.js by adding the <script> on the <Head>

reproduction example of the fix: https://stackblitz.com/edit/nextjs-jyzaxg?file=pages/_app.js

This fix is also compliant with the suggestion done by @SukkaW on #43838 (review)

to summarize the changes proposed on this PR.

  1. Remove code duplication on _app.js and _document.js by removing _document.js
  2. Removing event hashChangeComplete since /home and /home/#section is not a new pageview but a reference to the same page and shouldn't be reported as different pages to google.
  3. Removing id="gtag-init" that was added from Add id to inline gtag script #29530 now that we are not using a inline script but a normal script the id seems to be unnecessary

EDIT: adding more context to change number 3

Comment on lines 30 to 31
// Disable any default-enabled advertising features (turn them on later when we get consent)
gtag('set', 'allow_google_signals', false);
Copy link
Contributor

Choose a reason for hiding this comment

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

IMHO we shouldn't add this in the PR:

  • It is not required to set up Google Analytics
  • Anyone who follows Google Analytics' instruction can add this easily

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is not part of the PR anymore. ill update the description, sorry for that

Copy link
Contributor Author

@Josehower Josehower Dec 16, 2022

Choose a reason for hiding this comment

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

https://github.com/vercel/next.js/pull/43894/files

maybe you are looking to an old version of the PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the commit that removes this code 4 days ago

581c0af

Copy link
Member

@ijjk ijjk left a comment

Choose a reason for hiding this comment

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

Thanks!

@ijjk ijjk requested a review from jankaifer as a code owner February 7, 2023 22:40
@ijjk ijjk changed the title Remove unnecessary code in _app.js and _document.js Simplify with-google-analytics example Feb 7, 2023
@ijjk ijjk merged commit 268dd6e into vercel:canary Feb 7, 2023
jankaifer pushed a commit to jankaifer/next.js that referenced this pull request Feb 14, 2023
<!--
Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change that you're making:
-->
## Documentation / Examples

- [x] Make sure the linting passes by running `pnpm build && pnpm lint`
- [x] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)

First of all thanks for this amazing project and all the help you
provide with these examples.

It seems there is code duplication in this example. After some tests
locally seem to _document.js is not necessary for `gtag` to work
properly.


https://github.com/vercel/next.js/blob/9d97a1e34a8a6e09eb127292c730d1a8df63ebb6/examples/with-google-analytics/pages/_app.js#L30-L34


https://github.com/vercel/next.js/blob/9d97a1e34a8a6e09eb127292c730d1a8df63ebb6/examples/with-google-analytics/pages/_document.js#L13-L17

I am aware of vercel#40645 and I would
like to ask @dave-hay, @SukkaW and @ijjk to consider this is still
necessary. If so why then not move all content of the scripts from _app
to _document?

In any case, I am open to adding here some comments explaining what is
the reason for this code duplication if necessary.

<hr/>

Changes that come from  vercel#43897

1. The `event` hashChangeComplete should be removed since `/home` and
`/home/#section` is not new pageview, but just reference to the same
page.

If we go from /home to /home/#section (with a button click or a link for
example) this shouldn't trigger a new page visit on `gtag`.

For this reason, I think we should revert the changes from
vercel#36079. If there is a better
argument of why this should stay I am also open to creating comments to
clarify this on the example since I don't think should be the default
behavior and not useful in most cases.

2. The `id="gtag-init"` was added with no context to the example from
vercel#29530

If there is a reason for this id in the script to existing I am open to
adding a comment that clarifies this since in my experience is not
necessary at all.


Edit: Batching with vercel#43897 as
recommended by
vercel#43897 (comment)

---------

Co-authored-by: JJ Kasper <jj@jjsweb.site>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
examples Issue/PR related to examples
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants