feat[client-js]: Adds opt-in React Router loaders for @okta/okta-client-javascript

[BenjaminTruong-okta]

Adds a @okta/okta-react/client-js subpath exporting createFetchLoader, createTokenLoader, and createLoginCallbackLoader - React Router v6.4+ data-router loader factories that wrap @okta/auth-foundation, @okta/oauth2-flows, and @okta/spa-platform (0.6.0 beta) as an alternative to the okta-auth-js-based API.

createLoginCallbackLoader resumes the auth code flow via AuthorizationCodeFlowOrchestrator.resumeFlow(), which exchanges the code and stores the resulting credential itself, then redirects to the original URI. This replaces the component for apps using the new SDK's data router.

The new peer SDKs are declared as optional peerDependencies so the default @okta/okta-react bundle has no dependency on them; a dedicated Rollup target and ESLint import-boundary rule keep the two bundles isolated from each other.

Jest's jsdom environment doesn't implement a spec-compliant Fetch API, which the data router's loader/redirect handling depends on - added undici (plus its Node-native web API polyfills) via a new setupFiles entry so the loader tests exercise real Request/Response objects.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Adding Tests
• Build related changes
• CI related changes
• Documentation changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

Reviewers

[jaredperreault-okta]

Suggested change

	export function createFetchLoader(
	fetchClient: FetchClient,
	getResource: GetResource,
	init?: RequestInit,
	) {
	return async (args: LoaderArgs): Promise<Response> => {
	return fetchClient.fetch(getResource(args), init);
	};
	}
	export function createFetchLoader(fetchClient: FetchClient) {
	return async (url: string | URL | Request, init?: RequestInit): Promise<Response> => {
	return fetchClient.fetch(url, init);
	};
	}

[jaredperreault-okta]

I think the "create loader" should essentially just bind to an orchestrator instance. The params can be provided to the loader itself to override at the specific route

Suggested change

	export function createTokenLoader(
	orchestrator: AuthorizationCodeFlowOrchestrator,
	params?: TokenOrchestrator.AuthorizeParams,
	) {
	return async (): Promise<Token> => {
	const token = await orchestrator.getToken(params);
	if (!token) {
	throw new Response('Unauthorized', { status: 401 });
	}
	return token;
	};
	}
	export function createTokenLoader(
	orchestrator: AuthorizationCodeFlowOrchestrator
	) {
	return async (params?: TokenOrchestrator.AuthorizeParams): Promise<Token> => {
	const token = await orchestrator.getToken(params);
	if (!token) {
	throw new Response('Unauthorized', { status: 401 });
	}
	return token;
	};
	}

[BenjaminTruong-okta]

I made this change, but it requires the loader to be wrapped: (loader: () => fn(...)) instead of assigning them directly because they are no longer valid react router loaders on their own

[jaredperreault-okta]

I wonder if it makes more sense to have a createLoadersFromOrchestrator method that returns both the tokenLoader and loginCallbackLoader since they both accept the same input (orchestrator) and they probably need to interact with the same orchestrator instance to work. Then recommend this pattern is used it instead

function createLoadersFromOrchestrator (orchestrator: AuthorizationCodeFlowOrchestrator) {
  return {
    tokenLoader: createTokenLoader(orchestrator),
    loginCallbackLoader: createLoginCallbackLoader(orchestrator),
  }
}

// usage
const { tokenLoader, loginCallbackLoader } = createLoadersFromOrchestrator(orchestrator)

[BenjaminTruong-okta]

see here

[jaredperreault-okta]

This looks good! I like the direction it's heading

I was poking around the react-router docs and found a few links that may be relevant:

• https://reactrouter.com/start/data/data-loading
• https://reactrouter.com/start/framework/data-loading#client-data-loading
• https://reactrouter.com/how-to/fetchers#loading-data

It seems like react-router has 3 "modes": framework, data and declarative. Let's make sure our loader offerings work for each (if possible)
I know I told you to support v6, but it might be worth it to only support v7 and 8. The API surface area seems to be a lot cleaner, and the download stats actually don't mention 6: https://www.npmjs.com/package/react-router?activeTab=versions

[BenjaminTruong-okta]

@jaredperreault-okta i think these loaders are fundamentally incompatible with declarative mode, where the <Route> has no loader property - consumers will just have to call the fetchClient/Orchestrator directly.
These loaders are built for data mode, so that works, and also no changes are required for use in framework mode, but that will require a little more app-side wiring. Added an example in the readme and can make a sample that demonstrates that in a subsequent PR.

[jaredperreault-okta]

You shouldn't need an external dependency for this. You can use the types available from node.

see https://github.com/okta/okta-client-javascript/tree/master/tooling/jest-helpers/browser