Multiple re-renders when using auth info within a RequiredAuthProvider

[deepjoy]

Components using useAuthInfo were experiencing 3 unnecessary re-renders on mount, even when there were no authentication state changes. This was caused by the implementation pattern in useClientRef which used lazy initialization in the render phase.

[deepjoy]

Here is code that shows the behavior

import { RequiredAuthProvider, useAuthInfo } from '@propelauth/react';
import React, { StrictMode } from 'react';
import ReactDOM from 'react-dom/client';


let count = 1;
const TestComponent = () => {
  useAuthInfo();
  console.log('rerender', count++);
  return <div>Test Component</div>;
};
const AUTH_URL = '...';
if (!AUTH_URL) {
  throw new Error('AUTH_URL is not set');
}
ReactDOM.createRoot(document.getElementById('root')).render(
    <StrictMode>
     <RequiredAuthProvider authUrl={AUTH_URL}>
       <TestComponent />
     </RequiredAuthProvider>
    </StrictMode>
);

Also attaching the project in case this depends on specific versions
my-react-app.zip

❯ node --version
v24.11.0

❯ npm --version
11.6.1

[deepjoy]

output in latest chrome for the above case

[andrew-propelauth]

Thanks for writing in - we took a look and believe what you are seeing is a consequence of running locally and having StrictMode enabled. StrictMode will trigger additional re-renders and rerun effects/ref callbacks which can compound in cases like this.

We ran the latest @propelauth/react library alongside the code you provided with StrictMode removed and only see one render:

I believe we have some time scheduled on Monday so also happy to chat about it further then!

[deepjoy]

Thanks for the quick reply. Yup in the example re-renders are limited to StrictMode. The React team has some documentation about how this is a early warning for issues in production mode.

There is one other side effect of this that our team has observed on local development environments, with HMR(Hot module reloading) enabled each time we save a change (triggering hmr), the react auth library makes 6 additional calls to the refresh_token endpoint. This quickly reaches the QPS limits per browser/session and start recieving 429 responses from Propel in test environments.

Once the 429 (too many requests) condition is reached we need to cool off for about a minute before we make further changes in our code.

[andrew-propelauth]

Can you confirm, are you seeing this with the latest @propelauth/react library or are you using the PR that you opened? When we tested that PR but found that it was making extra requests since it initializes more than one client.

At the moment when we test with the latest @propelauth/react we see two fetches (initially) and then one extra fetch periodically, which is what we would expect.

We also took a look at your traffic around that time and I’m not sure what we’re seeing there is explainable by a few additional fetches per reload. I could definitely be wrong though, let’s dig in more on monday - it’d be helpful for us to just see it live to diagnose it better

[deepjoy]

Thanks for getting on the call to take a look. Yes. the cases above are all using the latest version of @propel/react. I tried this PR out on local using pnpm link.

I see a 429 too many requests error in production code as well. I'm trying to figure out what is causing the re-render(probably unrelated) but propel/react having non-react state seems to overwhelm the logs.

It seems similar to the strict mode usage above. i.e. requests are sent to refresh_token multiple times per re-render and this quickly reaches the rate limit.

I'll keep digging to figure out whats going on in my app to cause the re-renders as well. Cheers.