Closed thebrianbug closed 5 months ago
Yep, agree with this!
But related to programmatic sign-in, did you see how I implemented it in the e2e tests in this repo? Not sure if that is useful to you.
I would also include the setting of the Clerk store in the window object in
hooks.client.ts
in the package documentation.
Hmm. Maybe we should even do this ourselves... is there ever a case where you would not want window.Clerk
to be available?
No, I can't think of any. Others may come up with a situation, but I wouldn't go without it personally.
I don't think a change needs to be made here. I'm already setting window.Clerk()
inside initializeClerkClient()
, exactly the way you were.
Interesting... it's not being set as a global for me. I'll try again and see what's going on, maybe there's a difference in access to window object from a package.
Closing, I've confirmed that in 0.3.0 we are still exporting Clerk to the window object, so I don't need access to the store itself. Others might, but this works for my needs
Background
To be able to be used in serious applications, users should be able to programmatically sign in. This can be useful both for customizing sign-in flows, but (more imporatantly for me) to also to allow for reliable e2e testing.
The way that Clerk suggests to support this is by exporting the clerk instance to the window object. I can achieve this in v0.2.0 with the code below:
hooks.client.ts
This allows me to write a programmatic sign-in helper like the one below. I wish that the Clerk team would provide a more reliable programmatic sign-in method, but for now, this is what they support.
Let's bring back the exported clerk variable, and also consider adding a test that verifies that is is exported properly for use in e2e tests. I would also include the setting of the Clerk store in the window object in
hooks.client.ts
in the package documentation.Request
Restore the external export of the Clerk store, which was removed here.