Skip to content

Migration from version 1.0 to 2.0

Juha Paananen edited this page Apr 10, 2018 · 3 revisions

There are some breaking changes in the 2.0.0 release. Here's a summary and instructions for migrating your application.

Event methods

Event.value now contains the event value instead being a function that returns the event value. Similarly* methods and the Event.hasValue method have been converted to boolean properties. So, if you use subscribe, withHandler, flatMapEvent or any other method where you have to handle Event objects, convert your method calls to property references. For instance: event.isError() becomes just event.isError.

EventStreams are always asynchronous

You can no longer rely on Bacon.once(...).onValue(f) calling f synchronously. Hopefully you didn't before this either.

It's no longer possible to create an EventStream that responds synchronously. If you try to create one using fromBinder or other constructors, the resulting stream will automatically convert your replies to asynchronous.

Note that Property initial/current value is still delivered synchronously, so you can use Bacon.constant(..) to deliver a constant value synchronously.

Property.flatMap returns Property

Property.flatMap* methods now return a Property instead of an EventStream. This shouldn't be an issue and if you have p.flatMap(..).toProperty() you can now simply omit the .toProperty() part.

If you have p.flatMap(..).toProperty(initValue) you can use p.flatMap(..).startWith(initValue) instead for supplying a initial value.


If you use a library that requires Bacon.js 0.7 or 1.0, the library needs to change. The suggested way is to change the library thus that it either

  1. Works with both 1.0 and 2.0 versions and has Bacon.js as a peerDependency with a suitable version range. See Baret for example. Some libraries may need to include a little hack to support both 1.0 and 2.0 versions of Bacon, because the Event object methods have been converted to properties.
  2. Has separate versions for 1.0 and 2.0. It's still very much advisable to use peerDependencies to avoid the situation of having two distinct instances of Bacon in your application.
You can’t perform that action at this time.