2.0 migration

peasy-js 2.0 introduces a few breaking changes to improve readability and intuitiveness of the api, while increasing closer parity between it and other peasy frameworks.

Below are the actors containing API changes:

• Commands
• Business Services
• Rules

Commands

Note: The following API changes are only applicable when using the Command.extend() function via the peasy-js constructor creation API. These changes do not affect prototypal or classical ES6 command inheritance.

Traditionally, command constructor parameters were specified via the params option. Mapped constructor arguments then became accessible via the this reference within the function implementations, as seen below:

peasy constructor creation api

var SubmitCommand = Command.extend({
  params: ['id', 'dataProxy'], // these are _handles_ to the arguments supplied to the command's constructor, and accessible via a _this_ reference within the function implementations.
  functions: {
    _getRules: function(context, done) {
      this.dataProxy.getById(this.id, function(err, item) {
        done(new CanSubmitOrderItemRule(item));
      });
    },
    _onValidationSuccess: function(context, done) {
      this.dataProxy.submit(this.id, function(err) {
        done();
      });
    }
  }
});

With peasy-js 2.0, command constructor paramaters are no longer specified via the params option, and their mapped arguments are no longer accessible via the this reference. Instead, a command's constructor arguments are supplied directly to each implemented command function, as can be seen below:

var SubmitCommand = Command.extend({
  functions: {
    _getRules: function(id, dataProxy, context, done) {
      dataProxy.getById(id, function(err, item) {
        done(new CanSubmitOrderItemRule(item));
      });
    },
    _onValidationSuccess: function(id, dataProxy, context, done) {
      dataProxy.submit(id, function(err) {
        done();
      });
    }
  }
});

As a result of these signature changes, you will need to change the function parameters of your commands.

It should be noted that this change does not affect command instantiation or invocation.

The benefits of these changes should become more obvious in the next Business Services changes section.

Business Services

Traditionally, the built-in CRUD command function parameters of Business Service were accessible via the this reference. This can be seen below:

peasy-js constructor creation API

var CustomerService = BusinessService.extend({
  functions: {
    _getRulesForInsertCommand: function(context, done) {
      var person = this.data;
      done(null, new ValidCityRule(person.city));
    }
  },{
    _getRulesForUpdateCommand: function(context, done) {
      var person = this.data;
      done(null, new ValidCityRule(person.city));
    }
  }
}).service;

ES6

class CustomerService extends BusinessService {
  constructor(dataProxy) {
    super(dataProxy);
  }
  _getRulesForInsertCommand(context, done) {
    var person = this.data;
    done(null, new ValidCityRule(person.city));
  }

  _getRulesForUpdateCommand(context, done) {
    var person = this.data;
    done(null, new ValidCityRule(person.city));
  }
}

While this design approach worked well, it decreased parity between the peasy-js framework and other peasy frameworks. In other peasy frameworks, the CRUD command function overrides explicitly accept/require the command constructor arguments to be supplied.

The new changes can be seen below:

ES6

class CustomerService extends BusinessService {
  constructor(dataProxy) {
    super(dataProxy);
  }
  _getRulesForInsertCommand(person, context, done) {
    done(null, new ValidCityRule(person.city));
  }

  _getRulesForUpdateCommand(person, context, done) {
    done(null, new ValidCityRule(person.city));
  }
}

peasy-js constructor creation API

var CustomerService = BusinessService.extend({
  functions: {
    _getRulesForInsertCommand: function(person, context, done) {
      done(null, new ValidCityRule(person.city));
    }
  },{
    _getRulesForUpdateCommand: function(person, context, done) {
      done(null, new ValidCityRule(person.city));
    }
  }
}).service;

With these changes, the signatures for these function definitions become clear and achieve closer parity between peasy-js and other peasy frameworks.

As a result of these signature changes, you will need to change the function parameters of your function overrides.

It should be noted that this change does not affect service instantiation or invocation.

Rules

Note: The following API changes are only applicable when using the Rule.extend() function via the peasy-js constructor creation API. These changes do not affect prototypal or classical ES6 rule inheritance.

Traditionally, rule constructor parameters were specified via the params option. Mapped constructor arguments then became accessible via the this reference within the function implementations, as seen below:

var ValidCityVerificationRule = Rule.extend({
  association: "city",
  params: ['city'], // these are _handles_ to the arguments supplied to the rule's constructor, and accessible via a _this_ reference within the _onValidate() implementation.
  functions: {
    _onValidate: function(done) {
      var validCities = ['New York', 'Rome', 'Paris', 'London', 'Tokyo'];
      if (validCities.indexOf(this.city) === -1) {
        this._invalidate("The city specified is invalid.");
      }
      done();
    }
  }
});

With peasy-js 2.0, rule constructor paramaters are no longer specified via the params option, and their mapped arguments are no longer accessible via the this reference. Instead, a rule's constructor arguments are supplied directly to the _onValidate function, as can be seen below:

var ValidCityVerificationRule = Rule.extend({
  association: "city",
  functions: {
    _onValidate: function(city, done) {
      var validCities = ['New York', 'Rome', 'Paris', 'London', 'Tokyo'];
      if (validCities.indexOf(city) === -1) {
        this._invalidate("The city specified is invalid.");
      }
      done();
    }
  }
});

As a result of these signature changes, you will need to change the onValidate parameters of your rules.

It should be noted that this change does not affect rule instantiation or invocation.