1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380
|
# Wisper
*A micro library providing Ruby objects with Publish-Subscribe capabilities*
[](http://badge.fury.io/rb/wisper)
[](https://codeclimate.com/github/krisleech/wisper)
[](https://github.com/krisleech/wisper/actions)
[](https://coveralls.io/r/krisleech/wisper?branch=master)
* Decouple core business logic from external concerns in Hexagonal style architectures
* Use as an alternative to ActiveRecord callbacks and Observers in Rails apps
* Connect objects based on context without permanence
* Publish events synchronously or asynchronously
Note: Wisper was originally extracted from a Rails codebase but is not dependent on Rails.
Please also see the [Wiki](https://github.com/krisleech/wisper/wiki) for more additional information and articles.
**For greenfield applications you might also be interested in
[WisperNext](https://gitlab.com/kris.leech/wisper_next) and [Ma](https://gitlab.com/kris.leech/ma).**
## Installation
Add this line to your application's Gemfile:
```ruby
gem 'wisper', '~3.0'
```
## Usage
Any class with the `Wisper::Publisher` module included can broadcast events
to subscribed listeners. Listeners subscribe, at runtime, to the publisher.
### Publishing
```ruby
class CancelOrder
include Wisper::Publisher
def call(order_id)
order = Order.find_by_id(order_id)
# business logic...
if order.cancelled?
broadcast(:cancel_order_successful, order.id)
else
broadcast(:cancel_order_failed, order.id)
end
end
end
```
When a publisher broadcasts an event it can include any number of arguments.
The `broadcast` method is also aliased as `publish`.
You can also include `Wisper.publisher` instead of `Wisper::Publisher`.
### Subscribing
#### Objects
Any object can be subscribed as a listener.
```ruby
cancel_order = CancelOrder.new
cancel_order.subscribe(OrderNotifier.new)
cancel_order.call(order_id)
```
The listener would need to implement a method for every event it wishes to receive.
```ruby
class OrderNotifier
def cancel_order_successful(order_id)
order = Order.find_by_id(order_id)
# notify someone ...
end
end
```
#### Blocks
Blocks can be subscribed to single events and can be chained.
```ruby
cancel_order = CancelOrder.new
cancel_order.on(:cancel_order_successful) { |order_id| ... }
.on(:cancel_order_failed) { |order_id| ... }
cancel_order.call(order_id)
```
You can also subscribe to multiple events using `on` by passing
additional events as arguments.
```ruby
cancel_order = CancelOrder.new
cancel_order.on(:cancel_order_successful) { |order_id| ... }
.on(:cancel_order_failed,
:cancel_order_invalid) { |order_id| ... }
cancel_order.call(order_id)
```
Do not `return` from inside a subscribed block, due to the way
[Ruby treats blocks](http://product.reverb.com/2015/02/28/the-strange-case-of-wisper-and-ruby-blocks-behaving-like-procs/)
this will prevent any subsequent listeners having their events delivered.
### Handling Events Asynchronously
```ruby
cancel_order.subscribe(OrderNotifier.new, async: true)
```
Wisper has various adapters for asynchronous event handling, please refer to
[wisper-celluloid](https://github.com/krisleech/wisper-celluloid),
[wisper-sidekiq](https://github.com/krisleech/wisper-sidekiq),
[wisper-activejob](https://github.com/krisleech/wisper-activejob),
[wisper-que](https://github.com/joevandyk/wisper-que) or
[wisper-resque](https://github.com/bzurkowski/wisper-resque).
Depending on the adapter used the listener may need to be a class instead of an object. In this situation, every method corresponding to events should be declared as a class method, too. For example:
```ruby
class OrderNotifier
# declare a class method if you are subscribing the listener class instead of its instance like:
# cancel_order.subscribe(OrderNotifier)
#
def self.cancel_order_successful(order_id)
order = Order.find_by_id(order_id)
# notify someone ...
end
end
```
### ActionController
```ruby
class CancelOrderController < ApplicationController
def create
cancel_order = CancelOrder.new
cancel_order.subscribe(OrderMailer, async: true)
cancel_order.subscribe(ActivityRecorder, async: true)
cancel_order.subscribe(StatisticsRecorder, async: true)
cancel_order.on(:cancel_order_successful) { |order_id| redirect_to order_path(order_id) }
cancel_order.on(:cancel_order_failed) { |order_id| render action: :new }
cancel_order.call(order_id)
end
end
```
### ActiveRecord
If you wish to publish directly from ActiveRecord models you can broadcast events from callbacks:
```ruby
class Order < ActiveRecord::Base
include Wisper::Publisher
after_commit :publish_creation_successful, on: :create
after_validation :publish_creation_failed, on: :create
private
def publish_creation_successful
broadcast(:order_creation_successful, self)
end
def publish_creation_failed
broadcast(:order_creation_failed, self) if errors.any?
end
end
```
There are more examples in the [Wiki](https://github.com/krisleech/wisper/wiki).
## Global Listeners
Global listeners receive all broadcast events which they can respond to.
This is useful for cross cutting concerns such as recording statistics, indexing, caching and logging.
```ruby
Wisper.subscribe(MyListener.new)
```
In a Rails app you might want to add your global listeners in an initializer like:
```ruby
# config/initializers/listeners.rb
Rails.application.reloader.to_prepare do
Wisper.clear if Rails.env.development?
Wisper.subscribe(MyListener.new)
end
```
Global listeners are threadsafe. Subscribers will receive events published on all threads.
### Scoping by publisher class
You might want to globally subscribe a listener to publishers with a certain
class.
```ruby
Wisper.subscribe(MyListener.new, scope: :MyPublisher)
Wisper.subscribe(MyListener.new, scope: MyPublisher)
Wisper.subscribe(MyListener.new, scope: "MyPublisher")
Wisper.subscribe(MyListener.new, scope: [:MyPublisher, :MyOtherPublisher])
```
This will subscribe the listener to all instances of the specified class(es) and their
subclasses.
Alternatively you can also do exactly the same with a publisher class itself:
```ruby
MyPublisher.subscribe(MyListener.new)
```
## Temporary Global Listeners
You can also globally subscribe listeners for the duration of a block.
```ruby
Wisper.subscribe(MyListener.new, OtherListener.new) do
# do stuff
end
```
Any events broadcast within the block by any publisher will be sent to the
listeners.
This is useful for capturing events published by objects to which you do not have access in a given context.
Temporary Global Listeners are threadsafe. Subscribers will receive events published on the same thread.
## Subscribing to selected events
By default a listener will get notified of all events it can respond to. You
can limit which events a listener is notified of by passing a string, symbol,
array or regular expression to `on`:
```ruby
post_creator.subscribe(PusherListener.new, on: :create_post_successful)
```
## Prefixing broadcast events
If you would prefer listeners to receive events with a prefix, for example
`on`, you can do so by passing a string or symbol to `prefix:`.
```ruby
post_creator.subscribe(PusherListener.new, prefix: :on)
```
If `post_creator` were to broadcast the event `post_created` the subscribed
listeners would receive `on_post_created`. You can also pass `true` which will
use the default prefix, "on".
## Mapping an event to a different method
By default the method called on the listener is the same as the event
broadcast. However it can be mapped to a different method using `with:`.
```ruby
report_creator.subscribe(MailResponder.new, with: :successful)
```
This is pretty useless unless used in conjunction with `on:`, since all events
will get mapped to `:successful`. Instead you might do something like this:
```ruby
report_creator.subscribe(MailResponder.new, on: :create_report_successful,
with: :successful)
```
If you pass an array of events to `on:` each event will be mapped to the same
method when `with:` is specified. If you need to listen for select events
_and_ map each one to a different method subscribe the listener once for
each mapping:
```ruby
report_creator.subscribe(MailResponder.new, on: :create_report_successful,
with: :successful)
report_creator.subscribe(MailResponder.new, on: :create_report_failed,
with: :failed)
```
You could also alias the method within your listener, as such
`alias successful create_report_successful`.
## Testing
Testing matchers and stubs are in separate gems.
* [wisper-rspec](https://github.com/krisleech/wisper-rspec)
* [wisper-minitest](https://github.com/digitalcuisine/wisper-minitest)
### Clearing Global Listeners
If you use global listeners in non-feature tests you _might_ want to clear them
in a hook to prevent global subscriptions persisting between tests.
```ruby
after { Wisper.clear }
```
## Need help?
The [Wiki](https://github.com/krisleech/wisper/wiki) has more examples,
articles and talks.
Got a specific question, try the
[Wisper tag on StackOverflow](http://stackoverflow.com/questions/tagged/wisper).
## Compatibility
See the [build status](https://github.com/krisleech/wisper/actions) for details.
## Running Specs
```
bundle exec rspec
```
To run the specs on code changes try [entr](http://entrproject.org/):
```
ls **/*.rb | entr bundle exec rspec
```
## Contributing
Please read the [Contributing Guidelines](https://github.com/krisleech/wisper/blob/master/CONTRIBUTING.md).
## Security
* gem releases are [signed](http://guides.rubygems.org/security/) ([public key](https://github.com/krisleech/wisper/blob/master/gem-public_cert.pem))
* commits are GPG signed ([public key](https://pgp.mit.edu/pks/lookup?op=get&search=0x3ABC74851F7CCC88))
* My [Keybase.io profile](https://keybase.io/krisleech)
## License
(The MIT License)
Copyright (c) 2013 Kris Leech
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the 'Software'), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
|