2.1.1 • Published 9 years ago

hapi-mandrill v2.1.1

Weekly downloads
23
License
-
Repository
github
Last release
9 years ago

Build Status Coverage Status NPM Version Dependency Status NPM Downloads Issues HAPI 8.0 API Documentation

(C) 2014 Martin Wawrusch

HAPI plugin that exposes mandrill api - used to send transactional emails.

The rational behind this is that every single hapi app I created needs transactional emails, and it always involves plumbing code. With this module I provide the most common usecase with a well defined signature, and also expose the mandrillClient.

Usage

The key and templateNameMapping parameters are optional, but without a key nothing gets sent (useful for testing).

hapiMandrill = require 'hapi-mandrill'

pluginConf = [
    plugin: hapiMandrill
    options:
      senderName: "John Smith"
      senderEmail: "john@smith.com"
      key : null # Keep null for testing
      templateNameMapping: 
        "from" : "toInMandrill"
]

server.pack.register pluginConf, (err) ->
  #...

Send Mail

fnCallback = (err,result) ->
  # Do some stuff when done.

plugin = server.pack.plugins['hapi-mandrill']

plugin.send("Angelina Jolie","angelina@jolie.com", {some: "payload"},"Hello Angelina","angelina-template", fnCallback)

Logging

The plugin logs successful and failed sends. NOTE: If you want to disable this, or want different log tags let me know and I will make it customizable.

Template Name Mapping

Mandrill templates are often managed by third parties, you don't want them to break a core functionaly without testing it first yourself. For that reason, you can define internal template names and transform them to whatever you want to use in mandrill. To do so, set the 'templateNameMap' object to internal : external pairs. If none is defined, or a key is not found it will be passed verbatim.

Exposed Properties

plugin = server.pack.plugins['hapi-mandrill']

plugin.mandrillClient # Note this is null if you do not pass a key in options
plugin.send(...)
plugin.templateNameMapping = {...}

See also

and additionally

Contributing

  • Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet
  • Check out the issue tracker to make sure someone already hasn't requested it and/or contributed it
  • Fork the project
  • Start a feature/bugfix branch
  • Commit and push until you are happy with your contribution
  • Make sure to add tests for it. This is important so I don't break it in a future version unintentionally.
  • Please try not to mess with the package.json, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.

Copyright

Copyright (c) 2014 Martin Wawrusch

2.1.1

9 years ago

2.0.1

10 years ago

1.0.5

10 years ago

1.0.4

10 years ago

1.0.3

10 years ago

1.0.2

10 years ago

1.0.1

10 years ago