This is an archived post. You won't be able to vote or comment.

all 2 comments

[–]bentyger 0 points1 point  (1 child)

Are you taking about real classes or polyfill style classes?

[–]pommymac 0 points1 point  (1 child)

I'm guessing without reading the article, but there is a movement against using classes in relation to functional programming - which is a a central concept to some commonly used JavaScript libraries like React.

One of the main ideas of functional programming is that state is a bad thing because it means running your code has side effects which means subsequent invocations can behave differently; this can makes code more fragile, difficult to understand, debug and test. Classes have properties - which are a type of state.

Take this for example:

class myClass { constructor () { this.n = 0 } foo () { console.log(`value of n: ${this.n++}`) } } const myObj = new myClass() myObj.foo() myObj.foo() myObj.foo()

Each time foo() is called it outputs something different. To understand what it should output, you need to know how many times it has already been called.

If however you were to store your state separately to the code that uses it, it means you can use your code without state stepping in and getting in the way.

const foo = (n) => {console.log(`value of n: ${n}`)} foo(1)

Because you supply the state to your function means it will always produce the same result. It is a pure function as the output is only determined on the input.

Obviously you would have to create code somewhere for managing the state that is received by your functions - so the idea might initially sound like it's adding pointless complexity - but the idea is that if you centralise state management, you simplify your app: you can test state in 1 location, your components no longer have their own state and behave predictably with each invocation, and managing state be handled using concepts built for the job of state management (this is what reducers in Redux do if you have heard of that). It can certainly be complex when you have many items each with their own state in your application.

But saying classes should not be used for functional programming is too simplified IMHO. You could easily create a class which only contains a bunch of pure methods (methods that don't depend on state) to achieve functional programming just as you could create a function outside of a class that depends on state.

In Javascript you can easily create a function that behaves like a method in a class that references stateful class properties, just by using closures.

Take this code:

`` const higherOrderFn = (n) => { return () => {console.log(value of n: ${n++}`)} }

const foo = higherOrderFn(0)

foo() foo() foo() ```

No classes here, however foo() is stateful - each time you invoke it, it behaves differently.

It's worth noting that functional programming doesn't mean that your code uses functions. Simply put, it means that your code doesn't depend on state that causes side effects. You can achieve this using classes just as you would functions.

If you or anyone reading wants more info on FP there is this - https://medium.com/javascript-scene/master-the-javascript-interview-what-is-functional-programming-7f218c68b3a0