5 ms·

Yeah but how is that different from any other UI framework? onCreate/onStart/onResume and onComponentDidMount, onPause/onStop/onDestroy and onComponentWillUnmo

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

anon9001 7y ago
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes 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-presets https://babeljs.io/blog/2018/07/27/removing-babels-stage-pre...
- iainmerrick 7y ago
  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.
  - ng12 7y ago
    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.
    - mikewhy 7y ago
      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".
      - ng12 7y ago
        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.
        kuschku 7y ago
        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.
        acemarke 7y ago
        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.
efdee 7y ago
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 ;-)
- kuschku 7y ago
  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!!!"

anon9001 7y ago

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes 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-presets https://babeljs.io/blog/2018/07/27/removing-babels-stage-pre...

iainmerrick 7y ago
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.
- ng12 7y ago
  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.
  - mikewhy 7y ago
    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".
    - ng12 7y ago
      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.
      - kuschku 7y ago
        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.
        acemarke 7y ago
        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.

efdee 7y ago

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 ;-)

kuschku 7y ago
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!!!"