Support react-router 6 (#275)
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
Hi @jaredperreault-okta , is this PR going through your tests before being merged for a new okta-react version?
@Spartan-Hex-Shadow Yes. This will become a new major version release
@Spartan-Hex-Shadow Yes. This will become a new major version release
Wonderful, thanks!
@jaredperreault-okta any E.T.A on release?
@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)?
@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-routerseems to be moving towards the use ofactionandloaderfunctions 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 ofuseState/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/implementreact-routerin a certain way. Ideally this SDK should no influence on how you manage your<Route />s within your application. Currently I am considering exposing someLoaderfunction(s) rather than moving forward withSecureOutletas the loader approach seems more future-proof.I'm curious, have you experimented with the use of
action/loaderin 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.
Hi @jaredperreault-okta , any updates?
@Spartan-Hex-Shadow Some other tasks have taken my attention. I'll be revisiting this soon
@jaredperreault-okta Much appreciate, thank you so much.
@jaredperreault-okta any updates?