Next.js + App router + [lang] folder

[ChezMose]

Describe the bug The package does not work well with Next.js + App router + [lang] folder.

To Reproduce

1. Do to this online example: https://myapp.chezmose.com
2. Try to switch language (top left buttons) => the intercom widget disappear.
3. Try to switch again => an error occurs.

The same issue occurs if you have a separate layout.js file in a sub-folder. The intercom script does not seem to be able to re-attach itself.

Repository Here is a repository that reproduces the issue: https://github.com/ChezMose/MyApp

Expected behavior It succeeded in having it all work by putting the tag in a layout.js file in the the /app root folder (see try 3 in the repo). However this does not allow to have a lang attribute in the which is a no-go for SEO !

I believe there could be a way to re-attach the widget properly even if the layout file changes. Yes, as a workaround, I can always force a full-refresh when switching language, but that's kind of meh for Next.js website.

[devrnt]

Hi, seems like your repository is not available. I've no experience with the app directory in NextJS, but make sure that you're only calling react-use-intercom client-side

Please make the repository available or add a reproduction, then feel free to re-open

[ChezMose]

Hi, it obviously works better with a public repository ;) And yes, I know I have to use it client-side and recent version of Next.js won't let you do the other way.

Btw, this repo is the 'recommanded way' to build multilingual websites with Next.js, the structure with a layout.js in the [lang] folder is the new way to go.

[devrnt]

Thanks for the extended reproduction. I'm facing the same issue (duh).

It seems like this is not an issue in this library, but one from the underlying Intercom snippet itself. I suggest asking it the Intercom support or asking it on their forum.

I'll leave this issue open for now. Please come back if, after all , this actually is an issue in this library

[sudongyuer]

I also encountered the same problem, is there any progress?

[Anne-Gaelle-S]

Hello, I had the same problem, I made a call to hardShutdown (from useIntercom) just before calling router.replace for switching langage and it seems to work... Not sure if it can help but I wanted to share this here

[u3ih]

is there any update, i got same issue

[u3ih]

is there any update, i got same issue

For anyone who calls hardShutdown before calling replace and still encounters this issue, make sure to check if Intercom has loaded in your DOM before calling the function from useIntercom. It seems to work for me. You can use the following function to check for that:

export const checkIsLoadedIntercom = () => { return window.parent && ["#intercom-frame"].some((e: string) => { const t = window.parent.document.querySelector(e); if (t) { const n = t.getBoundingClientRect(); return n && n.width > 0 && n.height > 0; } return false; }); };

[SaveliiLukash]

Facing the same issue in our project, which is set up exactly as "Next.js + App router + [lang] folder", too.

We can confirm that this is, indeed, the issue of Intercom itself, since we don't use react-use-intercom at the moment, rather we have it installed using Intercom's own method for Web.

Seems like Intercom looses track of document because it saves its reference on init only, and after switching languages it never gets updated (old reference becomes null), which results in TypeError: parent is null.

What we do now in or project is setting window.Intercom = null and reinserting Intercom's script on every language change.

I think we'll migrate to react-use-intercom and use the hardShutdown method (which seems to be based on the same logic, but cleaner).

Hopefully Intercom fixes this. I think it's best to keep this GitHub issue open, very useful info for people who have to deal with this error that is brought upon us by non-open-source Intercom.

[Git-I985]

The problem really exists, with the same conditions, I spent 5 hours trying to solve it, now I will try to follow the advice of other people here, thank u guys

[tpudel]

Adding hardShutdown() before the route change fixed it for me! Thanks guys!