Skip to content

feat[client-js]: Adds React Router v8 sample app for @okta/okta-react-client-js - #322

Draft
BenjaminTruong-okta wants to merge 3 commits into
feat/client-js-opt-in-supportfrom
feat/client-js-router-v8-sample-app
Draft

feat[client-js]: Adds React Router v8 sample app for @okta/okta-react-client-js#322
BenjaminTruong-okta wants to merge 3 commits into
feat/client-js-opt-in-supportfrom
feat/client-js-router-v8-sample-app

Conversation

@BenjaminTruong-okta

@BenjaminTruong-okta BenjaminTruong-okta commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Exercises the opt-in loader factories (createFetchLoader, createTokenLoader, createLoginCallbackLoader) end-to-end against a real Okta org, and resets the sign-in flow's stuck inProgress state on a back/forward-cache restore so an abandoned redirect doesn't block starting a new one.

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

…/client-js

Exercises the opt-in loader factories (createFetchLoader, createTokenLoader,
createLoginCallbackLoader) end-to-end against a real Okta org, and resets the
sign-in flow's stuck `inProgress` state on a back/forward-cache restore so an
abandoned redirect doesn't block starting a new one.

Co-Authored-By: Claude Code
{
path: '/resource',
element: <Resource />,
loader: createFetchLoader(fetchClient, () => userInfoUrl),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think using the userInfo URL is a bit confusing. It's an OAuth endpoint, so a developer should use OAuth2 to request it, not a FetchClient. Maybe instead use a static JSON blob and can be hosted via vite to illustrate this?

"strict": true,
"forceConsistentCasingInFileNames": true,
"module": "ESNext",
"moduleResolution": "Bundler",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is Bundler required for this to work? Bundler is usually not recommended

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yeah, react-router@8.3.0's package.json only defines an exports map (no main/module/types fallback), so classic "Node" resolution can't find its types at all

Comment thread test/apps/client-js-router-v8-app/vite.config.js Outdated
…rinfo endpoint

Hand-building the userinfo URL bypassed the SDK's own OAuth2Client/Credential
userInfo() methods, which resolve the endpoint from OIDC discovery metadata.
Swap the sample's /resource route to a plain static JSON file so it just
demonstrates createFetchLoader without duplicating SDK logic.
…m vite.config.js

A clean build doesn't reproduce this react-router warning - it was vestigial
from an earlier scaffolding iteration. Restore the unconditional onwarn throw,
matching test-harness-app's convention.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants