okta-react icon indicating copy to clipboard operation
okta-react copied to clipboard

Support react-router 6 (#275)

Open jaredperreault-okta opened this issue 1 year ago • 11 comments

OKTA-676780 Support react-router 6

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 avatar Apr 29 '24 12:04 jaredperreault-okta

Hi @jaredperreault-okta , is this PR going through your tests before being merged for a new okta-react version?

Spartan-Hex-Shadow avatar May 01 '24 13:05 Spartan-Hex-Shadow

@Spartan-Hex-Shadow Yes. This will become a new major version release

jaredperreault-okta avatar May 01 '24 15:05 jaredperreault-okta

@Spartan-Hex-Shadow Yes. This will become a new major version release

Wonderful, thanks!

Spartan-Hex-Shadow avatar May 01 '24 21:05 Spartan-Hex-Shadow

@jaredperreault-okta any E.T.A on release?

Spartan-Hex-Shadow avatar May 17 '24 19:05 Spartan-Hex-Shadow

@Spartan-Hex-Shadow I apologize for the delay on this, however I am trying to determine what the best course of action for this SDK is. react-router seems to be moving towards the use of action and loader functions on <Route />s rather than the component-based approach. Even this example holds the "auth state" outside of the React state foregoing the previously common pattern of useState/useContext. This something I have been pondering for a while; holding the auth state inside the app (React) state never quite seemed necessary to me. Ultimately a token's lifecycle is a function of time, therefore any value placed within the app state to represent the auth state is essentially a cached value of a point in time. I am trying to avoid positioning this SDK in a way which forces consumers to use/implement react-router in a certain way. Ideally this SDK should no influence on how you manage your <Route />s within your application. Currently I am considering exposing some Loader function(s) rather than moving forward with SecureOutlet as the loader approach seems more future-proof.

I'm curious, have you experimented with the use of action / loader in your React app(s)?

jaredperreault-okta avatar May 21 '24 13:05 jaredperreault-okta

@Spartan-Hex-Shadow I apologize for the delay on this, however I am trying to determine what the best course of action for this SDK is. react-router seems to be moving towards the use of action and loader functions on <Route />s rather than the component-based approach. Even this example holds the "auth state" outside of the React state foregoing the previously common pattern of useState/useContext. This something I have been pondering for a while; holding the auth state inside the app (React) state never quite seemed necessary to me. Ultimately a token's lifecycle is a function of time, therefore any value placed within the app state to represent the auth state is essentially a cached value of a point in time. I am trying to avoid positioning this SDK in a way which forces consumers to use/implement react-router in a certain way. Ideally this SDK should no influence on how you manage your <Route />s within your application. Currently I am considering exposing some Loader function(s) rather than moving forward with SecureOutlet as the loader approach seems more future-proof.

I'm curious, have you experimented with the use of action / loader in your React app(s)?

Hi Jarred. We have not. Our app is heavily based around components and we have began the process of addressing technical debt by upgrading to the latest versions of our third party packages but cannot do so for some as this package does not support react router 6. The SecureOutlet approach would work very well for us and would be a seamless code transition from SecureRoute So we would personally prefer that but ultimately recognize it is not up to us to decide if that happens or not.

Spartan-Hex-Shadow avatar May 26 '24 16:05 Spartan-Hex-Shadow

Hi @jaredperreault-okta , any updates?

Spartan-Hex-Shadow avatar Jul 09 '24 16:07 Spartan-Hex-Shadow

@Spartan-Hex-Shadow Some other tasks have taken my attention. I'll be revisiting this soon

jaredperreault-okta avatar Jul 15 '24 13:07 jaredperreault-okta

@jaredperreault-okta Much appreciate, thank you so much.

Spartan-Hex-Shadow avatar Jul 18 '24 03:07 Spartan-Hex-Shadow

@jaredperreault-okta any updates?

Spartan-Hex-Shadow avatar Sep 22 '24 04:09 Spartan-Hex-Shadow