This recaptcha instance has been already rendered

[weidonglian]

Hi @sarneeh
I really like this library that does solve problems existent in other libraries, especially regarding multiple instances and react-router.
This bug only exists in React >18, I have tried React 17 which works well.
Repeat: https://codesandbox.io/s/jovial-cookies-uclvr5?file=/src/App.js
Thanks for your attention.
WD

[weidonglian]

Here is what I got about the rendering failure loop. To be honest, everything seems to be working well even the below error.

index.tsx:211 Uncaught (in promise) Error: This recaptcha instance has been already rendered.
    at index.tsx:211:1
    at new Promise (<anonymous>)
    at p.r.renderExplicitly (index.tsx:210:1)
    at p.<anonymous> (index.tsx:125:1)
    at callCallback (react-dom.development.js:13122:1)
    at commitUpdateQueue (react-dom.development.js:13143:1)
    at commitLayoutEffectOnFiber (react-dom.development.js:23263:1)
    at commitLayoutMountEffects_complete (react-dom.development.js:24578:1)
    at commitLayoutEffects_begin (react-dom.development.js:24564:1)
    at commitLayoutEffects (react-dom.development.js:24502:1)

[weidonglian]

Not sure what happened: The below ready's callback is triggered over and over again.
setState could use the stateChange instead of changing the state ready to true. It should not trigger if the state has become ready. This could also optimize the performance.

window.grecaptcha.ready(() => {
      this.setState({ ready: true }, () => {
        if (!explicit) {
          this.renderExplicitly();
        }
        if (onLoad) {
          onLoad();
        }
      });
    });

[jgoz]

This issue manifests when <Recaptcha> is used inside of a <StrictMode> tree in React 18.

[weidonglian]

Okay, did not realize that, in that way, it won't have any impact on a production build.

[jgoz]

@weidonglian True, but IMO it should still be fixed. StrictMode is intended to reveal potential issues, especially with future React versions/rendering modes and I think it's highlighting a legitimate problem here around side effects.

[weidonglian]

@weidonglian True, but IMO it should still be fixed. StrictMode is intended to reveal potential issues, especially with future React versions/rendering modes and I think it's highlighting a legitimate problem here around side effects.

Absolute! Agreed, I did not mean it should not be fixed, sorry for the confusion. Just before it is fixed, it won't be a blocker, since if I ignore the console output, then it seems to be working quite well.
I really want this to be fixed!

[jsardev]

Fixed in 1.12.1. Thank you @jgoz 🎉

[steve-taylor]

@sarneeh It still happens in React 18 in strict mode. I'm using 1.12.1. Also, I'm using Next.js. The error occurs when I perform a client-side navigation to a page that renders a reCAPTCHA after already having been on any page that rendered a reCAPTCHA. This isn't reproducible with strict mode disabled.

Stack trace:

Uncaught (in promise) Error: reCAPTCHA has already been rendered in this element
    at recaptcha__en.js:140:275
    at r._renderRecaptcha (index.esm.js?6a6d:1:1191)
    at eval (index.esm.js?6a6d:1:2200)
    at new Promise (<anonymous>)
    at r.renderExplicitly (index.esm.js?6a6d:1:1976)
    at p.eval (index.esm.js?6a6d:1:1122)
    at callCallback (react-dom.development.js?3c4a:13923:1)
    at commitUpdateQueue (react-dom.development.js?3c4a:13944:1)
    at commitLayoutEffectOnFiber (react-dom.development.js?3c4a:23364:1)
    at commitLayoutMountEffects_complete (react-dom.development.js?3c4a:24688:1)
    at commitLayoutEffects_begin (react-dom.development.js?3c4a:24674:1)
    at commitLayoutEffects (react-dom.development.js?3c4a:24612:1)
    at commitRootImpl (react-dom.development.js?3c4a:26823:1)
    at commitRoot (react-dom.development.js?3c4a:26682:1)
    at finishConcurrentRender (react-dom.development.js?3c4a:25981:1)
    at performConcurrentWorkOnRoot (react-dom.development.js?3c4a:25809:1)
    at workLoop (scheduler.development.js?ba31:266:1)
    at flushWork (scheduler.development.js?ba31:239:1)
    at MessagePort.performWorkUntilDeadline (scheduler.development.js?ba31:533:1)

[jasan-s]

this issue still exists and should remain open. turning strict mode is not optimal solution

[jsardev]

@jasan-s No worries I know it still exists 😄