ESLint plugin: code pureness

Hi JS (ok, ES) people!

Working on current project (Redux + React, ES6) we faced the issue with code pureness.

Say if the method receives all the variable data through parameters and there is no variable data injection from the outside, the method is pure. So if we run the method with similar parameters 1000 times in different environments, we get same result.

Constants could be used by that method; it’s ok. The principle is, constants could reside inside the method, however we prefer to inject ’em because of architecture and code reusability.

Why do we need the code to be pure?

  1. Replay-ability. Imagine you have initial Store state “A”, and after 20 consequent Actions it becomes state “B.” Imagine you recorded all the Action with their parameters. If you reset the Store to “A” and replay that Action sequence, you expect the Store state to be “B”.
    This won’t happen if the Store becomes data from different sources, not only from Actions.
  2. Testability: if the method is pure, you can cover it by unit-tests with no need to mock any data.
  3. Data trace-ability, or easiness to debug the code. If you have one source for data appearing in the Store, it’s easier to debug the code.

Some examples

distort() {
  this.x += Math.random() * 10 - 5;
  this.y += Math.random() * 10 - 5;

The method above is not pure. Math.random() brings variable data from the outer world. How should you unit-test it? Are you gonna mock the Math.random()?

distort(dx, dy) {
  this.x += dx;
  this.y += dy;

// later in another module
function _getRandom() {
  return Math.random() * 10 - 5;

ball.distort(_getRandom(), _getRandom());

We made the method pure. Now we can set the ball coords to {20, 20}, call ball.distort(3, -2) and be sure that ball coords are {23, 18}. Sounds like good scenario for unit tests! This could also help in debugging.

The ESLint plugin

Hope you are already aware about JS/ES code linting. Briefly, it’s the script you run against your *.js or *.es file and it reports if something does not conform rules you’ve set up. For instance, ESLint can report that line 12 contains 9 spaces but we expect 8 spaces there.

The ESLint utility supports many rules by itself and you can extend the list by adding plugins.

I created the one for verifying code pureness.
You can set up rules that forbid

  • using this or that expressions (standard like Math.random() or project-specific),
  • invoking new ...(),
  • importing several modules.

All the rules could be applied to different (configurable) files.

Hope it helps in bringing the light to your application architecture.

Feel free to use, contribute and raise issues on GitHub.