$ npm install --save validatable-record

const ManRecord = ValidatableRecord({
  name: null,
  age: null
}, {
  name: {
    presence: true
  },
  age: {
    presence: {
      message: "is invalid"
    }
  }
});
class Man extends ManRecord {
}
const man = new Man({
  name: "Justine";
  age: 25
});
man.validate() // == true

// Of course you can use `Immutable.Record` methods
man.size        // 2
man.get('name') // "Justine"
man

A few month ago, I created a small module composed of Immutable.js and validate.js. This is a kind of implementation of my approach to the thought about where do you put your validation logic in a front-end application. The field of massive front-end application architecture is totally different from your hobby apps if you value things like scalability or maintainability.

Where to put your own validation logic in your application is not actually a small concern. However, at the beginning phase of front-end application development, the validation logic is often not seemed to be important. In this kind of situation, the view layer tends to have a role of validation, because it is pretty usual for lots of people to think that validation is only the job of view layer.

There is no correct answer to “Where should I put my own validation logic?”, because it really depends on cases, but the sure thing is that the validation logic in view layer should not be the one which relates to your business rule.

Let’s think about a common validation rule like “Your name must not contain special characters”. It is mostly a sort of requirement by infrastructure layer which usually includes things like database, external API server, and so on. However, the validations like “You cannot order this item more than one” or “Free shipping is not available in your membership” are different. These are unique to business rules of your own application. Uniqueness is that, whether the rule is required only because of your business rule or not.

Business rules as domain layer are never affected by other ones such as view layer and infrastructure layer, because view and infrastructure are just implementations which provide your own business as a software and implementations never change what your business rule is. In this concept of layered architecture, validation logic in almost all cases is better to be a part of domain layer. Validation is one of the business rules which compose your application as a domain, not as infrastructure or view.

validatable-record is a small module built with Immutable.js and validate.js in order to define immutable record model with validation rules. Unlike ActiveModel in RoR, there is no standard built-in model validation module in JavaScript, so almost all the time if you would like to put your validation logic in a part of domain model, you will have to write write your own implementation. In the situation, validatable-record is available as one approach to built-in model validation.

const ManRecord = ValidatableRecord({
  name: null,
  age: null
}, {
  name: {
    presence: true
  },
  age: {
    presence: {
      message: "is invalid"
    }
  }
});

// You can use ManRecord as Immutable.Record
class Man extends ManRecord {
  ...
}

const man = new Man({
  name: "Justine";
  age: 25
});

// You can check if the instance is valid or not
man.validate() // == true

// Of course you can use `Immutable.Record` methods
man.size        // 2
man.get('name') // "Justine"
man.get('age')  // 25

ValidatableRecord returns Immutable.Record enhanced with validate.js by taking constraint rules as a second argument. Of course, you can still use methods in Record. You can also get the given error message after validation. More about on https://www.npmjs.com/package/validatable-record.

What I would like to stress in this article with my approach of validatable-record is, scaling front-end application sometimes needs serious planning on responsibility of every layers. Developing front-end application is getting easier than before today, but still software engineers are required to think deeply about architecture from the view point of scalability and maintainability. I would be grad if this article could take you one step back and re-think about your own great application architecture on front-end.