ooops, forgot to include changes in 5.0.0

Read https://github.com/oskarhane/suber/releases/tag/v5.0.0 for changes.

Add 'origin' for middlewares

Breaking changes

Rename the _responseChannel property of a bus.self message to $$responseChannel to make it more clear that it's auto added and shouldn't be of any interest outside of Suber.

Changes

The middleware signature are being changed to

const mw = (send, originObject) => (channel, message, source) => {}

The origin object are mostly useful when in combination with createReduxMiddleware since a origin check is done here to make sure that we don't sent the same message into Suber twice: Suber -> Redux -> Suber.

Make API more sensible

It makes no sense to have createReduxMiddleware on a Suber instance.
Now it's a separate named export that takes a bus as an argument.

See README for usages.

No more global singleton

This is a release that removes the singleton pattern from Suber.

Breaking

• remove getBus()
• add createBus()

The function names describe the intent. Now a new bus is created every time where as it used to return a singleton bus.

See README for usages and new API.

Synchronous

Breaking

Make listener and middleware invocation synchronous.
This change makes it easier to use Suber as a testing helper in other applications.

Fix ordering issue with createReduxMiddleware

createReduxMiddleware used to send the action into Suber before passing the action to the next Redux middleware, creating timing issues.
Not any more.

Richer API

Two new bus methods are introduces in this release:

bus.reset()

Remove all subscribers on all channels on the bus.

bus.self(channel, message, fn)

a way to tell subscribers that you expect something back on a certain channel. Read more in the docs: https://github.com/oskarhane/suber#self
Example: say you want to fetch a github user and log the name but you want to keep the fetching somewhere else in the app (preferably in some middleware somewhere).
We assume some middleware (maybe redux-observable) subscribing on channel 'FETCH_USER'. How do we get the response back without storing it in redux and subscribing to the state?

Like this.

const b = getBus()
const cb = (data) => console.log(data.name) // Let's just log the name.

b.self('FETCH_USER', {id: 100}, cb)

The middleware receiving this request to fetch the user should now look for a _responseChannel property on the message to know on what channel to respond on. When it does, cb will pick that up and log the name.

One utility method

resetMiddlewares() - Remove all middlewares.

Double middleware support

What's new

• applyMiddleware - Add middleware to suber.
• applyReduxMiddleware - Any Redux middleware which handles side effects and dispatches new actions when done are now compatible for usage with suber.
• Subscribers fn calls are now being called async.
• Catch all messages on all channels with take('*', cb)
• Add compatibility tests for createReduxMiddleware and popular middleware like redux-observable and redux-saga.

Breaking changes

• Remove emitFn. Replaced by applyMiddleware which is broader and covers this use case.

First usable version

v1.0.1

1.0.1