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

feat(clerk-react): Support for fallback prop #4723

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

BRKalow
Copy link
Member

@BRKalow BRKalow commented Dec 5, 2024

Description

Introduces a new fallback prop to Clerk's components. This lets users render a placeholder while Clerk is loading and the component mounts. Use to avoid layout shift and improve the loading UX.

Usage:

<SignIn fallback={<>Loading...</>} />

fixes SDKI-795

Checklist

  • pnpm test runs as expected.
  • pnpm build runs as expected.
  • (If applicable) JSDoc comments have been added or updated for any package exports
  • (If applicable) Documentation has been updated

Type of change

  • 🐛 Bug fix
  • 🌟 New feature
  • 🔨 Breaking change
  • 📖 Refactoring / dependency upgrade / documentation
  • other:

Copy link

changeset-bot bot commented Dec 5, 2024

🦋 Changeset detected

Latest commit: 67e8e2e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 8 packages
Name Type
@clerk/clerk-react Minor
@clerk/chrome-extension Patch
@clerk/elements Patch
@clerk/clerk-expo Patch
@clerk/nextjs Patch
@clerk/remix Patch
@clerk/tanstack-start Patch
@clerk/ui Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copy link

vercel bot commented Dec 5, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
clerk-js-sandbox ✅ Ready (Inspect) Visit Preview 💬 Add feedback Dec 10, 2024 3:47pm

@@ -6,7 +6,7 @@ import {
SignUp as BaseSignUp,
UserProfile as BaseUserProfile,
} from '@clerk/clerk-react';
import type { OrganizationProfileProps, SignInProps, SignUpProps, UserProfileProps } from '@clerk/types';
import type { ComponentProps } from 'react';
Copy link
Member

Choose a reason for hiding this comment

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

🥇

Comment on lines +31 to +33
if (!elementToWatch && selector) {
elementToWatch = root?.querySelector(selector);
}
Copy link
Member Author

Choose a reason for hiding this comment

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

There's most definitely a smarter way to do this, it's not the most efficient to re-query on each observed mutation, but given that it's scoped to the time the component mounts to the time the clerk-js mount happens it shouldn't be running too many times...

Comment on lines +25 to 27
if (!clerk.loaded && !options?.renderWhileLoading) {
return null;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

I added rendering of the fallback here initially, instead of allowing the component to render, but the fallback element was then injected twice.

* Used to orchestrate mounting of Clerk components in a host React application.
* Components are rendered into a specific DOM node using mount/unmount methods provided by the Clerk class.
*/
export class ClerkHostRenderer extends React.PureComponent<
Copy link
Member Author

Choose a reason for hiding this comment

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

This is largely unchanged from the previous Portal component. I renamed it to avoid confusion with React's portal primitive.

/>
);
}, 'SignIn');
export const SignIn = withClerk(
Copy link
Member Author

Choose a reason for hiding this comment

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

The diff for each component is mostly identical. I might take a pass at trying to DRY this up, but defaulting to avoiding too much abstraction.

/**
* Used to detect when a Clerk component has been added to the DOM.
*/
function waitForElementChildren(options: { selector?: string; root?: HTMLElement | null; timeout?: number }) {
Copy link
Member Author

Choose a reason for hiding this comment

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

This is somewhat of a brutce-force way of detecting when one of our components mounts. Instead of trying to plumb through some sort of event or callback to internal clerk-js components, I'm instead using a MutationObserver here to detect changes to the DOM. When the root element of the renderer has children (injected by clerk-js) we can assume the component has mounted.

Comment on lines +519 to +521
const rendererRootProps = {
...(shouldShowFallback && fallback && { style: { display: 'none' } }),
};
Copy link
Member Author

Choose a reason for hiding this comment

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

ClerkHostRenderer always has to render, which is why we can't use Suspense, so to ensure the fallback and the component aren't mounted at the same time, we apply display: none to the renderer while the fallback is loading.

@BRKalow BRKalow requested a review from a team December 10, 2024 03:43
Copy link
Member

@alexcarpenter alexcarpenter left a comment

Choose a reason for hiding this comment

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

Looking good to me so far!

const { customPages, customPagesPortals } = useUserProfileCustomPages(props.children);
return (
<Portal
<ClerkHostRenderer
Copy link
Member

Choose a reason for hiding this comment

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

Missing the rendering of fallback here for UserProfile

Copy link
Member

Choose a reason for hiding this comment

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

67e8e2e

@alexcarpenter alexcarpenter requested a review from a team December 10, 2024 15:37
);
},
'UserProfile',
{ component: 'UserProfile', renderWhileLoading: true },
Copy link
Member

Choose a reason for hiding this comment

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

In which scenario do we want this to be false ?

const shouldShowFallback = mountingStatus === 'rendering' || !clerk.loaded;

const rendererRootProps = {
...(shouldShowFallback && fallback && { style: { display: 'none' } }),
Copy link
Member

Choose a reason for hiding this comment

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

for accessibility reasons maybe we should go with <div hidden> instead of a css rule ?

Copy link
Member

@alexcarpenter alexcarpenter Dec 10, 2024

Choose a reason for hiding this comment

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

@panteliselef whats the reasoning? Wouldn't hidden be equivalent since the browsers default style for hidden is display: none?

default

Copy link
Member

Choose a reason for hiding this comment

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

styling wise yes, it's kind of nitpicking tbh, but afiak screen readers don't respect display:none; but respect hidden.

Copy link
Member

Choose a reason for hiding this comment

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

Got it, I think it should be alright, since its just hiding the container for the components to be rendered into until the components have loaded. The loading text sits outside of it, so it is accessible to users.

loading

Comment on lines +69 to +76
watcherRef.current = waitForElementChildren({ selector: `[data-clerk-component="${component}"]` })
.then(() => {
setStatus('rendered');
})
.catch(() => {
setStatus('error');
});
}
Copy link
Member

Choose a reason for hiding this comment

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

I'm sure this works, but do you think we should something on cleanup and disconnect the observer or don't update the state ?

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

Successfully merging this pull request may close these issues.

5 participants