Hacker News Reader

Comment by kuschku | Hacker News Reader

Yeah but how is that different from any other UI framework?

onCreate/onStart/onResume and onComponentDidMount, onPause/onStop/onDestroy and onComponentWillUnmount are basically the same. Be it Android, Swing, or Qt, everywhere it's the same pattern.

React is the first framework which actually feels like UI development on the web, not anymore like JS spaghetti.

In fact, having internal state, externally given props, exposing events, and being declared through markup is exactly the same between React, Android or Qt.

The only thing React brought to the table was allowing you to basically just recreate the children every time something changed, and it'd diff automatically.

For us native devs this thread is hilarious, because it's just JS decs complaining over things we've always done

View on HN

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...

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.

I think lifecycle methods in general, no matter what the framework is, are a suboptimal way of doing things. React works quite differently and shoehorning it into a lifecycle thing was holding it back, or at least that's how I feel. YMMV.

At least it looks like we agree that React is a decent framework :-)

That said, for us devs who do both native and JS code, the condescending part is quite hilarious as well ;-)

I'm doing JS (vanilla and with React), Android and native (well Qt) myself.

It's just funny when pure JS devs go all "no you won't convince me to compile my code / use classes with lifecycles / etc, that's against the natural order!!!"

Reply on news.ycombinator.com