ravenx v2.0.0 Ravenx View Source

Ravenx main module.

It includes and manages dispatching of messages through registered strategies.

Link to this section Summary

Functions

Function to get a Keyword list of registered strategies

Dispatch a notification payload to a specified strategy

Dispatch a notification payload to a specified strategy asynchronously

Dispatch a notification payload to a specified strategy unlinked

Called when an application is started

Link to this section Types

Link to this type dispatch_type() View Source
dispatch_type() :: :sync | :async | :nolink
Link to this type notif_id() View Source
notif_id() :: atom
Link to this type notif_options() View Source
notif_options() :: map
Link to this type notif_payload() View Source
notif_payload() :: map
Link to this type notif_result() View Source
notif_result() :: {:ok, any} | {:error, {atom, any}}
Link to this type notif_strategy() View Source
notif_strategy() :: atom

Link to this section Functions

Link to this function available_strategies() View Source
available_strategies() :: keyword

Function to get a Keyword list of registered strategies.

Link to this function dispatch(strategy, payload, options \\ %{}) View Source

Dispatch a notification payload to a specified strategy.

Custom options for this call can be passed in options parameter.

Returns a tuple with :ok or :error indicating the final state.

Examples

iex> Ravenx.dispatch(:slack, %{title: "Hello world!", body: "Science is cool"})
{:ok, "ok"}

iex> Ravenx.dispatch(:wadus, %{title: "Hello world!", body: "Science is cool"})
{:error, {:unknown_strategy, :wadus}}
Link to this function dispatch_async(strategy, payload, options \\ %{}) View Source

Dispatch a notification payload to a specified strategy asynchronously.

This function should be used when the caller has an interest in the notification dispatch result, which must be received using Task.await/2. Keep in mind that this function links the notification dispatch task with the caller process, so if one fails the other will fail also.

If you simply want to dispatch an asynchronous notification without having any interest in the result, take a look at dispatch_nolink/3.

Custom options for this call can be passed in options parameter.

Returns a tuple with :ok or :error indicating the task launch result. If the result was :ok, the Task of the process launched is also returned

Examples

iex> {status, task} = Ravenx.dispatch_async(:slack, %{title: "Hello world!", body: "Science is cool"})
{:ok, %Task{owner: #PID<0.165.0>, pid: #PID<0.183.0>, ref: #Reference<0.0.4.418>}}

iex> Task.await(task)
{:ok, "ok"}

iex> Ravenx.dispatch_async(:wadus, %{title: "Hello world!", body: "Science is cool"})
{:error, {:unknown_strategy, :wadus}}
Link to this function dispatch_nolink(strategy, payload, options \\ %{}) View Source

Dispatch a notification payload to a specified strategy unlinked.

This function spawns a separated process for dispatching the notification in an unlinked way, meaning that the caller won’t be able to know the notification dispatch result. If you want to dispatch an asynchronous notification and receive its result take a look at dispatch_async/3.

Custom options for this call can be passed in options parameter.

Returns a tuple with :ok or :error indicating the task launch result. If the result was :ok, the PID of the notification dispatch process is also returned.

Examples

iex> {status, pid} = Ravenx.dispatch_nolink(:slack, %{title: "Hello world!", body: "Science is cool"})
{:ok, #PID<0.165.0>}

iex> Ravenx.dispatch_nolink(:wadus, %{title: "Hello world!", body: "Science is cool"})
{:error, {:unknown_strategy, :wadus}}

Called when an application is started.

This function is called when an application is started using Application.start/2 (and functions on top of that, such as Application.ensure_started/2). This function should start the top-level process of the application (which should be the top supervisor of the application’s supervision tree if the application follows the OTP design principles around supervision).

start_type defines how the application is started:

  • :normal - used if the startup is a normal startup or if the application is distributed and is started on the current node because of a failover from another node and the application specification key :start_phases is :undefined.
  • {:takeover, node} - used if the application is distributed and is started on the current node because of a failover on the node node.
  • {:failover, node} - used if the application is distributed and is started on the current node because of a failover on node node, and the application specification key :start_phases is not :undefined.

start_args are the arguments passed to the application in the :mod specification key (e.g., mod: {MyApp, [:my_args]}).

This function should either return {:ok, pid} or {:ok, pid, state} if startup is successful. pid should be the PID of the top supervisor. state can be an arbitrary term, and if omitted will default to []; if the application is later stopped, state is passed to the stop/1 callback (see the documentation for the c:stop/1 callback for more information).

use Application provides no default implementation for the start/2 callback.

Callback implementation for Application.start/2.