Hacker News Reader

Comment by anon9001 | Hacker News Reader

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

You've been tricked into thinking you're using a class, but you're really not. I understand it's a useful trick, but hooks are more idiomatic for JS as a language.

As a side note, one of the problems with JS is that the community often disagrees about what JS is: https://babeljs.io/blog/2018/07/27/removing-babels-stage-pre...

View on HN

I disagree. I think that's like saying C++ doesn't actually have classes, it's just syntactic sugar around structs of function pointers.

It may be technically correct, but C++ and now JS have a "class" keyword for a reason, and that's to steer you towards organising your code into classes which operate in certain ways. In both languages you can avoid using classes, sure, or abuse classes in various ways. But fundamentally they do have classes.

But what good are classes if you're not doing object-oriented programming? React classes are just stateful wrappers around a pure render function. It's not idiomatic and frankly dangerous to do anything you would with a regular ES6 class with a React.Component.

Can you clarify on that last point a bit? Not that I extend React.Component these days, but far as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended.

I guess, yes, there's different semantics between the constructor and componentDidMount, but it's UI library, this is common that "when a constructor is call there is no guarantee the component has actually mounted".

Sure, what I mean is you'd never use a React.Component like you would a class in Java or another OO language. You never instantiate it, pass instances of it around, or call any of its public methods. It serves just as a container for some functions and provides a binding for `this`. Dealing with `this` caused things like componentWillRecieveProps to be buggy so hooks allow you to use a function as the container and remove the need to reference `this`. The move from classes to functions was not a paradigm shift just a different implementation of the same approach.

Actually, you can pass instances of it around just fine, if you know how it works. It’s not any different than a view subclass on Android, or a widget in Qt.

Instantiating it does nothing useful, though. `React.Component` is basically an empty shell with a marker flag on it so that the React renderer recognizes it, and the `setState` method just delegates to the actual renderer implementation. There's no reason to ever instantiate it yourself.

But that's the point. All UI frameworks are like that.

You can't `new MyRecyclerView(...)`, you've got to `LayoutInflater.inflate(MyRecyclerView, parent)`, which isn't any different from `React.render(MyApp, parent)`.

You can definitely pass them around and call public methods on them using refs, that's what useImperativeHandle is mimicking.

Was the issue with `this` in componentWillRecieveProps not solved by using an arrow function? If so, that just sounds like normal JS binding woes.

> as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended.

Facebook recommend composition over inheritance, but you can totally extend React.Component and even get abstract classes involved. In my custom React renderer, all the components in the library are based off React.Component class inheritance.

https://github.com/shirakaba/react-nativescript

> steer you towards organizing your code into classes which operate in certain ways

But that’s the point. The way in which classes operate in JS is different from the way classes operate in OOP focused languages like C++, Java and C#. That’s because the language doesn’t have classes, but rather syntax to make it look like it does. On the surface your code will be organized in similar ways but the underlying behavior is different.

Reply on news.ycombinator.com