Better motivate no-class rule

[danielnixon]

It might be useful to give examples of where classes lead to unsoundness to help motivate the no-class rule.

Here's an example derived from https://medium.com/free-code-camp/typescript-and-its-types-f509d799947d that still applies to TS 3.9:

// eslint-disable-next-line functional/no-class
class Box {
  constructor(public readonly width: number, public readonly height: number) {}
  // eslint-disable-next-line functional/functional-parameters
  get area(): number {
    // eslint-disable-next-line functional/no-this-expression
    return this.width * this.height;
  }
}

type IArea = {
  // eslint-disable-next-line functional/prefer-readonly-type
  area: number; // area is not readonly
};

const ia: IArea = new Box(10, 100);

// eslint-disable-next-line functional/immutable-data, functional/no-expression-statement
ia.area = 5; // TypeError: Cannot set property area of #<Box> which has only a getter```

[RebeccaStevens]

If you'd like to make a PR for this change, we can add it.

[jcrqr]

Quick question about the no-class, how are you creating errors without extending the Error class or how'd you suggest to do it?

[RebeccaStevens]

@crqra Errors can be anything, they don't have to be an instance of Error.
For example, an error could just be a string, a number or something like this:

const error = {
  type: "general error",
  message: "Something went wrong."
}

Though in practice, it is usually best to just use Error.
Personally, when I tend to create a new subdirectory for my error classes and just turn off the no-class rule for that subdirectory.

If you want to take it a step further, you can blackbox the classes.
To do so, none of the error classes should be exported, instead each should be associated with an exported function that will return a new instance of the error.
This will then make it so from the perspective of the rest of the code, everything is still functional.

[jcrqr]

@RebeccaStevens What I was doing was something similar, using functions like:

const buildSomeError = (some: string) => Error(`there was some error: ${some}`)

Having all classes in a sub-dir or single file and just export the functions looks much better because you can implement the actual "type" of error, like ValidationError which is much more clear and actionable to whoever gets them down the road.

Thank you for the concise reply, was very helpful!