I decided to give the "decouple" approach a try, as it fits my needs better.
I took the approach of creating an Authenticator trait which allows tokens to be generated asynchronously (as approached to the delegate, which requires sync). I believe the crates should still work as before for anyone not using a custom Delegate trait, as Hub::new accepts an instance of Authenticator, which is implemented for yup_oauth2::authenticator::Authenticator.
yup-oauth2 is no longer a required dependency, and can be disabled if a user should choose to do so by using default-features = false.
The only breaking change introduced is err parameter from the Delegate::token method. Given that the Authenticator implementation can handle any yup-oauth2 errors internally, it doesn't seem necessary for Delegate::token to also handle this.
There's a default implementation of Authenticator for String (user-provided oauth tokens) and () (no token at all - this seems like a good idea for APIs which do not use need oauth2)
I decided to give the "decouple" approach a try, as it fits my needs better.
I took the approach of creating an
Authenticatortrait which allows tokens to be generated asynchronously (as approached to the delegate, which requires sync). I believe the crates should still work as before for anyone not using a customDelegatetrait, asHub::newaccepts an instance ofAuthenticator, which is implemented foryup_oauth2::authenticator::Authenticator.yup-oauth2is no longer a required dependency, and can be disabled if a user should choose to do so by usingdefault-features = false.The only breaking change introduced is
errparameter from theDelegate::tokenmethod. Given that theAuthenticatorimplementation can handle anyyup-oauth2errors internally, it doesn't seem necessary forDelegate::tokento also handle this.There's a default implementation of
AuthenticatorforString(user-provided oauth tokens) and()(no token at all - this seems like a good idea for APIs which do not use need oauth2)