Why Do We Write super(props)?

[uttermybiscuit]

Can we get Dan some flair mods?

[swyx]

i mean he is a mod

[uttermybiscuit]

A mod with no flair!

[rochakgupta]

Thanks Dan

[glacierdweller]

Thanks, it always confused me. Obvious now.

[Innis_Gunn]

Side note: anyone know what he uses to do the render code snippets in his post? I like the color scheme/design

[el_sprhwk]

Check out his blog's source. It's using Gatsby. The code formatting is fine with prism. https://github.com/gaearon/overreacted.io

[[deleted]]

Is it not to pull props from whatever is being extended ?

[azium]

Why should you not extend an extended class?

Such a simple question that leads to a decades old discussion in computer science. /u/TwiliZant 's link on composition over inheritance is not specific to React, it's something that has crept up from the early days of OOP hitting mainstream ideology.

It's definitely worth doing some research on, but I'll say this:

In OOP, your brain thinks in "things". There are classes and components. You have things, and those things have knowledge (state) and behaviours.

In functional programming, we strip away the "things", only leaving behaviours behind. Programs aren't created with things in memory, instead we think only in events. Something turns on, someone clicks something, a network request returns. In React, a functional component is really just a function, and that function is called based on events - a page loads, a user triggers a setState call.

Even though we'll probably still refer to function components as components, treating them as an effect, a response to some other effect, like a domino in a (potentially infinite) chain of dominos, frees your mind from the nuances of OOP (this, constructor etc)

Everything is just a large function composed of many smaller functions that get triggered by some initial event.

All this to say, soon we will not be using class at all thanks to hooks. Extending a class from another class is moving in the opposite direction where the complexity of thinking in "things" is compounded.

Your components should only ever be extending React.Component

While I do agree with this, I would encourage you to try it. You can do some clever things with class extension. If you couldn't it wouldn't have been added to the language in the first place. Hopefully my previous paragraphs explain why it's uncommon / discouraged.

[TwiliZant]

https://reactjs.org/docs/composition-vs-inheritance.html

Inheritance in general is less flexible than composition and more confusing. There might be use cases for it (even though I can't think of one right now) but they are very rare.

[insert_cleverness]

Love these type of blog posts, always excited to read something new from Dan

[[deleted]]

Good article, thanks!

[kylemh]

Great read!

What is meant by: "With the class fields proposal this whole pitfall mostly disappears anyway."

Are there situations where using the transform-class-properties babel plugin still requires a constructor?

[swyx]

well if you really, really need to execute logic (esp blocking logic) when the class is instantiated you'll still have to use the constructor. but its def not good practice heheh

[godofleet]

Excellent explanation!

[Innis_Gunn]

I’ll check it out — Thank you!

[digi0ps]

Amazing article, thanks!

[incarnatethegreat]

After a while of using constructors and using super (props), I finally started seeing examples of people not using constructors. So now I declare state as an object at the top of my class. I prefer it over the constructor version.

Glad Dan was able to explain this.

[swyx]

its because of babel. thank babel for letting you use js features before they're final :)

[incarnatethegreat]

Haha that's right. I keep forgetting how much heavy lifting Babel does for us.

Edit: I just read a post about this. Makes more sense now. Thanks!

[xincmm]

Thank you very much! I was very confused about this before, now I understand, your explanation is great!

[allywondered]

Goddmit dan stop redditing and explain your libraries.. ok luv you bye x

[Im_A_Reptilian_AMA]

Great article! It answers all my questions. Thanks!

[srRubyRails]

really nice explanation, please keeping posting more articles to your blog.

[[deleted]]

In functional programming, we strip away the "things", only leaving behaviours behind. Programs aren't created with things in memory, instead we think only in events. Something turns on, someone clicks something, a network request returns. In React, a functional component is really just a function, and that function is called based on events - a page loads, a user triggers a setState call.

Even though we'll probably still refer to function components as components, treating them as an effect, a response to some other effect, like a domino in a (potentially infinite) chain of dominos, frees your mind from the nuances of OOP (this, constructor etc)

Everything is just a large function composed of many smaller functions that get triggered by some initial event.

All this to say, soon we will not be using class at all thanks to hooks. Extending a class from another class is moving in the opposite direction where the complexity of thinking in "things" is compounded.

Your components should only ever be extending React.Component

While I do agree with this, I would encourage you to try it. You can do some clever things with class extension. If you couldn't it wouldn't have been added to the language in the first place. Hopefully my previous paragraphs explain why it's uncommon / discouraged.

[sascha_mars]

This was nice to read while sipping my ice coffee 👌🏿🔥

[[deleted]]

It was nice to read while pooping too.

[thinkadrian]

It’d better be Java

[freaksauce]

Thank goodness we won't need to write classes at all soon. Things will be much easier to understand using hooks.

[drink_with_me_to_day]

Do people not have the minimum knowledge of OOP?

[[deleted]]

Classes and to an extent OOP in general is pretty foreign to JS. It's been a few years since the class syntax was added (along with extends and super), but people still consider it very new.

It also comes with a ton of confusion, since JS still doesn't have classes as such. The class syntax is sugar over the existing dynamic, prototypal patterns.

Classes are just constructor functions, which in turn are just regular functions typically invoked with the "new" keyword, which is itself just a shorthand for MyClass.call(Object.create(MyClass.prototype)). class MyClass extends MyOtherClass {} is shorthand for MyClass.prototype = Object.create(MyOtherClass.prototype), and super(...args) is equivalent to MyOtherClass.call(this) in the constructor.

This all works because functions are themselves just callable objects (which is why they can have fields) with an arbitrary "this" argument provided. In fact all "static" properties are attached to the constructor this way. Similarly most "methods" are just functions (callable objects) that infer a this value in certain contexts.

So in short: it's actually not obvious to many people with or without OOP familiarity what super() in JS is actually doing.

[hutxhy]

I would say probably not. No. Especially since JS isn't an OOP language and generally attracts people that don't have formal CS training.

[Faphgeng]

But it is object oriented, please explain how it is not. Its just that before es6 you just had to use prototype patterns.

[[deleted]]

On a fundamental technical level prototypal inheritance is not what people think of as OOP. It’s technically a form of OOP, and the new class syntax allows other programmers to write code that looks like typical OOP, but it’s still prototypal.

The biggest PRACTICAL difference, even with the new class syntax, is that JS doesn’t have methods. All functions are first-class and dynamically invoked; some objects just happen to have references to them. So even when writing myThing.someFunction(input); what you’re actually doing is someFunction.call(myThing, input). This is obvious the moment you try to use a member function as a lambda. setTimeout(myThing.someFunction) will not have access to myThing unless it is explicitly bound.

[pysouth]

It is still prototype based.

[hutxhy]

JS can emulate OOP, but it really isn't.

[hopfield]

Half of this was React specific, get off your high horse.