When we switched out the auth lib there was an improvement suggestion from Noel:
Following up from my comments in this week's meeting, looking at the current PR it seems like src/authn/SolidAuthnLogic.ts is attempting to handle both Inrupt and Uvdsl libraries? If so, that's is good, here's a couple of comments:
I see that the Inrupt library was removed from the dependencies, but it's still used in some places using the "sessionAny". I'd strongly suggest to keep the dependency installed, and cast the variable to its actual type, rather than using any. Any should be avoided as much as possible.
The current implementation seems to rely on if/else logic inside of the same file. That is ok for now, specially if we can keep the external API for consumers the same. But ideally, we would have two different implementations of an interface, one for Inrupt and one for Uvdsl, and resolve the proper instance to use at runtime. This would also allow to add more adapters in the future. Even if that's not a goal right, it's also good for code organization. As Aad mentioned in the call, this is called the Adapter pattern. Though if that confuses you more than it helps, just take a look at how I've done it for my apps (each authentication library has its own class).
Another additional improvement is to make sure to lazy-load the authentication libraries. Basically, if someone is logging in with uvdsl, they don't need to download all the javascript of Inrupt's library. I also do that in my apps, in particular using dynamic imports (see the .lazy files).
I haven't looked at all the code in the PR, but it's not immediately clear to me how consumers of this library choose which authentication library to use. Ideally, we could have a login() function that takes an "authenticationLibrary" parameter (or "authenticator", as I call them in my code, etc.). That could default to uvdsl, but should be easy to replace with Inrupt.
When we switched out the auth lib there was an improvement suggestion from Noel: