0

Believe me when I say that if I had any other choice, I would take it, but I am at my wits end.

I'm working for a big corporation which already has a whole library dedicated to authorization. And the authorization works, for the most part, however, the way it works is by putting your app between the Authorization Component in the render function, like so. You cannot change the code of the Authorization Component.

You are also expected to use the library's own Redux store, and you can add reducers, but not middleware, to this library. You cannot touch this code. 

   <Provider store={importedStore}>
     <AuthorisedComponent
        organisationId={orgId}
        journeyConfig={journeyConfig}
        allowUnauthorised={true}
        data-selector="journey"
      >
        <YourApp/>
      </AuthorisedComponent>
   </Provider>

Here's where things get tricky - and a little... unconventional. AuthorizedComponent is making the API call to get the JWT token, so far, so good, but it is not storing the jwt token anywhere in memory, session storage, or local storage. Instead, it is storing it in an internal state which is not publicly accessible. I can, however, look at the source code.

I need that JWT token to make an API call in order to build this new feature.

What I've thought about doing is:

const ExtendedAuthorizedComponent = React.cloneElement(<AuthorizedComponent/>)
ExtendedAuthorizedComponent.prototype.handleLogin = new function.

I know this is an antipattern. I know you're not supposed to do this. But I'm running out of time and two wrongs are the only way to make this right.

סטנלי גרונן
  • 2,917
  • 23
  • 46
  • 68
Brian Boyko
  • 613
  • 6
  • 15
  • why not `class ExtendedAuthorizedComponent extends AuthorizedComponent { /* override here */}`? – Emile Bergeron Jun 17 '19 at 19:06
  • You'd think that'd work but since I'm using Typescript, ExtendAuthorizedComponent complains about not having things like state, props, etc. I think I might need to make some super() calls somewhere but it's rare that I extend classes (preferring functional paradigms when possible.) – Brian Boyko Jun 18 '19 at 21:41
  • While TypeScript may complain, you shouldn't change how you do things (and even more if it's a hack) just to satisfy it. Find a way where TypeScript understands the code you have and if you're facing problems, ask about this here. – Emile Bergeron Jun 18 '19 at 23:26
  • It's very weird that AuthorizedComponent would hold the JWT internally with no mechanism of accessing it OR making it otherwise usable. Does it accept any callback props? Any other sort of configuration? Does it create a context that you can use via a hook? Chances are, you're "using" the component wrong if this is the solution you've come up with. – Adam Jenkins Jan 03 '20 at 17:48
  • `You are also expected to use the library's own Redux store` - so the library has a redux store - is the token in the store? If so, there's your context and you can select the token from the store. – Adam Jenkins Jan 03 '20 at 17:51
  • The library's got it's own Redux store, but no component that depends on the library has access to the library's redux store values. Even if it did, the token is not in the Redux store. Yeah -- I know. It shouldn't surprise you that in the end, the code was such a mess of spaghetti that the entire project was scrapped as a failure, which is what I feared it would be. Luckily I was able to transfer out of there before the project failed. Let's never speak of this again. – Brian Boyko Jan 08 '20 at 11:44

0 Answers0