Manager Pattern
Implementation of the Manager pattern used by AdonisJS
Manager pattern is a way to ease the construction of objects of similar nature. To understand it better, we will follow an imaginary example through out this document.
Table of contents
Scanerio
Let's imagine we are creating a mailing library and it supports multiple drivers like: SMTP, Mailgun, PostMark and so on. Also, we want the users of our library to use each driver for multiple times using different configuration. For example:
Using the Mailgun driver with different accounts. Maybe one account for sending promotional emails and another account for sending transactional emails.
Basic implementation
The simplest way to expose the drivers, is to export them directly and let the consumer construct instances of them. For example:
import { Mailgun } from 'my-mailer-library'
const promotional = new Mailgun(configForPromtional)
const transactional = new Mailgun(configForTransactional)
promotional.send()
transactional.send()
The above approach works perfect, but has few drawbacks
- If the construction of the drivers needs more than one constructor arguments, then it will become cumbersome for the consumer to satisfy all those dependencies.
- They will have to manually manage the lifecycle of the constructed objects. Ie
promotional
and transactional
in this case.
Using a Manager Class
What we really need is a Manager to manage and construct these objects in the most ergonomic way.
Step1: Define a sample config object.
First step is to move the mappings to a configuration file. The config mimics the same behavior we were trying to achieve earlier (in the Basic example), but defines it declaratively this time.
const mailersConfig = {
default: 'transactional',
list: {
transactional: {
driver: 'mailgun'
},
promotional: {
driver: 'mailgun'
},
}
}
Step 2: Create manager class and accept mappings config
import { Manager } from '@poppinss/manager'
class MailManager implements Manager {
protected singleton = true
constructor (private config) {
super({})
}
}
Step 3: Using the config to constructor drivers
The Base Manager class will do all the heavy lifting for you. However, you will have to define certain methods to resolve the values from the config file.
import { Manager } from '@poppinss/manager'
class MailManager implements Manager {
protected singleton = true
protected getDefaultMappingName() {
return this.config.default
}
protected getMappingConfig(mappingName: string) {
return this.config.list[mappingName]
}
protected getMappingDriver(mappingName: string) {
return this.config.list[mappingName].driver
}
constructor (private config) {
super({})
}
}
Step 4: Move drivers construction into the manager class
The final step is to write the code for constructing drivers. The Base Manager uses a convention for this. Anytime the consumer will ask for the mailgun
driver, it will invoke createMailgun
method. So the convention here is to prefix create
followed by the camelCase driver name.
import { Manager } from '@poppinss/manager'
class MailManager implements Manager {
public createMailgun (mappingName, config) {
return new Mailgun(config)
}
public createSmtp (mappingName, config) {
return new Smtp(config)
}
}
Usage
Once done, the consumer of the Mailer class just needs to define the mappings config and they are good to go.
const mailersConfig = {
default: 'transactional',
list: {
transactional: {
driver: 'mailgun'
},
promotional: {
driver: 'mailgun'
},
}
}
const mailer = new MailManager(mailersConfig)
mailer.use('transactional').send()
mailer.use('promotional').send()
- The lifecycle of the mailers is now encapsulated within the manager class. The consumer can call
mailer.use()
as many times as they want, without worrying about creating too many un-used objects. - They just need to define the mailers config once and get rid of any custom code required to construct individual drivers.
Extending from outside-in
The Base Manager class comes with first class support for adding custom drivers from outside-in using the extend
method.
const mailer = new MailManager(mailersConfig)
mailer.extend('postmark', (manager, mappingName, config) => {
return new PostMark(config)
})
The extend
method receives a total of three arguments:
- The
manager
object is the reference to the mailer
object. - The name of the mapping inside the config file.
- The actual configuration object.
- The
callback
should return an instance of the Driver.
Driver Interface
The Manager class can also leverage static Typescript types to have better intellisense support and also ensure that the drivers added using the extend
method adhere to a given interface.
Defining Drivers Interface
Following is a dummy interface, we expect all drivers to adhere too
interface DriverContract {
send (): Promise<void>
}
Passing interface to Manager
import { Manager } from '@poppinss/manager'
import { DriverContract } from './Contracts'
class MailManager implements Manager<
DriverContract
> {
}
Mappings Type
The mappings config currently has any
type and hence, the mailer.use
method cannot infer correct return types.
In order to improve intellisense for the use
method. You will have to define a type for the mappings too.
type MailerMappings = {
transactional: Mailgun,
promotional: Mailgun
}
type MailerConfig = {
default: keyof MailerMappings,
list: {
[K in keyof MailerMappings]: any
}
}
const mailerConfig: MailerConfig = {
default: 'transactional',
list: {
transactional: {
driver: 'mailgun',
},
promotional: {
driver: 'mailgun',
},
}
}
Finally, pass the MailerMappings
to the Base Manager class
import { DriverContract, MailerMappings } from './Contracts'
class MailManager implements Manager<
DriverContract,
DriverContract,
MailerMappings
> {
}
Once mailer mappings have been defined, the use
method will have proper return types.
Mapping suggestions
Return type