Abandon classes

Right now all (all I’ve seen) exercises use and require classes to be exported. In fact, a simple static function would suffice. As seen in this example:

Before

class Bob {
  hey(message) { … }
}

export default Bob;

After

export default (message) => { … }

Instead of focusing on the important part, developers are forced to apply this pattern. I’d also argue that it promotes a bad habit of classes overuse.

Maybe there is a hidden reason, in that case, please let me know of it.

[xarxziux]

I know I’m a little late to this discussion, but having gone a little way down both the student and mentoring routes I’d like to express my opinions on this.

In very general, simplistic terms, there are two types of exercises: those that ask you to accept a value and return an answer, and those that ask you take some initial state and return an interface that performs some operations on that state. The first exercise on the track, Leap, is an example of the first kind. The Queen Attack exercise falls into the second category as you have to provide the functions white(), black(), canAttack() and toString() on the initial board definition.

Taking the first exercise, in some languages this is a one-liner and it could be in JavaScript too, but there’s a disconnect between the requirements and the unit tests - you could have code that solves the problem but isn’t framed correctly to pass the unit tests. Why should you have to declare a function that sets some internal state and then add a prototype that operates on that state, when you could simply expose a one-line function that performs the same action? OOP design has its place, but this isn’t it.

Therefore I would like to propose a change to the design philosophy of the exercises on this track;

• If the exercise can be solved by taking a value and returning another value, then the unit tests should only expect the student to export a function.
• If the exercise specifically asks you to accept some initial state and then provide operations on that state then the unit tests should expect the student to export a class.

FP and OOP both have their strengths and weaknesses. Adopting the philosophy above would, I believe, teach student that JavaScript readily supports both paradigms but would also encourage them to use the right tool for the right job.

[matthewmorgan]

Thanks to @tejasbubane and @xarxziux for the considerable effort exerted to make this happen. +++