You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While rearchitecting accounts.js 1.0 I've played around the concept of Map Providers.
Basically in Accounts.js we have multiple types of authentication services (password, magic link, oauth, sms, etc..) which implement the same known interface and while most of them are hosted in the monorepo the design allows the user to create and provide its own authentication service. That means that injecting all of them into shared services like AccountsServer (which is part of the core module) is not an option, because this way the user would not be allowed to create its own auth service.
To solve this issue I'd like to introduce the concept of Map Providers: a type of provider which acts similarly to Javascript Maps where the map is constructed by declaring new providers which add certain keys to the Map.
Basically you would inject the AuthenticationServicesToken like this:
exportconstAuthenticationServicesToken=newInjectionToken<AuthenticationServices>('AuthenticationServices');// AuthenticationServices is either a Map or a Map-like objectconstructor(@Inject(AuthenticationServicesToken)publicservices: AuthenticationServices<CustomUser>){
and other modules like the password module would provide the various elements like this:
Another way we could look at this is the concept of Interface Providers, where each element of the Map must implement a known interface in order to extend the associated provider:
// services is a Map/Map-like Object where each element of the Map implements the AuthenticationServiceInterfaceconstructor(@Inject(AuthenticationServiceInterface)publicservices: Map<string,AuthenticationServiceInterface<CustomUser>>){
But the downside of this approach is that you will have to go through each and every element of the array every time you look for a certain authentication service because you won't have a key.
With the current feature set the various modules which implement the different authentication services cannot provide the new authentication service on their own: after including the module the user has to manually provide the AuthenticationServicesToken.
The text was updated successfully, but these errors were encountered:
While rearchitecting accounts.js 1.0 I've played around the concept of Map Providers.
Basically in Accounts.js we have multiple types of authentication services (password, magic link, oauth, sms, etc..) which implement the same known interface and while most of them are hosted in the monorepo the design allows the user to create and provide its own authentication service. That means that injecting all of them into shared services like
AccountsServer
(which is part of the core module) is not an option, because this way the user would not be allowed to create its own auth service.To solve this issue I'd like to introduce the concept of Map Providers: a type of provider which acts similarly to Javascript Maps where the map is constructed by declaring new providers which add certain keys to the Map.
Basically you would inject the
AuthenticationServicesToken
like this:and other modules like the password module would provide the various elements like this:
Another way we could look at this is the concept of Interface Providers, where each element of the Map must implement a known interface in order to extend the associated provider:
The downside of this approach is that I'm not sure if you can use Typescript interfaces as Injection Tokens.
Instead of a Map/Map-like object we could even inject an array:
But the downside of this approach is that you will have to go through each and every element of the array every time you look for a certain authentication service because you won't have a key.
With the current feature set the various modules which implement the different authentication services cannot provide the new authentication service on their own: after including the module the user has to manually provide the
AuthenticationServicesToken
.The text was updated successfully, but these errors were encountered: