4 ms·

I use React (well, Preact) every day. I use it 2014-style. Class-based components, componentWillMount, render, callbacks, and that's about it. I love this wo

I use React (well, Preact) every day. I use it 2014-style. Class-based components, componentWillMount, render, callbacks, and that's about it. I love this workflow, and generally structure all my UIs this way regardless of platform - have a state struct and then fully render the UI as a function of the state. To me, that's the big hurrah for using React. But I have no clue why React is at version 18 and why it keeps getting new features. I'm perfectly happy making quite complicated UIs with the pattern I know well. Should I be following along? Does it matter?

no_wizard 5y ago
In this way react is choose your own adventure. There is no current signal that the way class components work will change and I don’t exactly expect that to happen any time soon if at all. Rather then new features are aimed at developers with more complex use cases and make heavy use of asynchronous data fetching in a way that lends itself to concurrency. If this isn’t you I’m sure at least the general performance improvements will be nice otherwise I don’t see why you can’t just keep doing what you’re doing
dstaley 5y ago
As someone who was initially resistant to hooks, I actually find that they're a more expressive API to how I was already thinking about my applications. There's footguns for sure, just like there are with class components, but I found that rewriting my class components with hooks instead actually made the code cleaner and easier to reason about. That being said, it's possible the benefit simply came from the rewrite, but even with newer components, I feel like hooks are a better API.
srpoder 5y ago
React hooks might be the best feature ever, once you understand it, it provides you a way to write highly reusable code.
enlyth 5y ago
I personally fell in love with hooks after initially disliking them, you should give it a try, maybe in a toy personal project, to see if you like it. It is great for separation of concerns. You basically stick to writing pure functional components focused only on how to render, and try to abstract reusable logic into hooks, and expose only what you need For example, you could make a useApi() hook and inside your component just do const { data, loading, error } = useApi('/endpoint'), so you can hide everything you don't need away from the rendering logic
- flowerlad 5y ago
  > pure functional components focused only on how to render, and try to abstract reusable logic into hooks Just FYI, once you add hooks, it is neither pure nor functional. https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
  - WorldMaker 5y ago
    They may not be pure, but they are still functional. The hooks follow similar laws to Monads. They aren't entirely monadic and it would have been nice if they were and used a more monadic combinator for bind [1], but they are a relatively pragmatic solution for a language without a strong type system to encode things like algebraic effects and monadic bindings in. [1] Mostly useless aside: using a .then()able based plumbing would have opened up the possibility of using the async/await combinator language. The names async/await would give the wrong impression especially prior to the actual concurrency changes to eventually ship in React 18, but would have potentially been a more monadic fit.
    - flowerlad 5y ago
      > The hooks follow similar laws to Monads. And monads are impure [1]. If all your functions are impure then you're not doing functional programming. [1] https://alvinalexander.com/scala/io-monad-doesnt-make-function-pure-obvious-impure/ https://alvinalexander.com/scala/io-monad-doesnt-make-functi...
      - WorldMaker 5y ago
        Yes, I stated that. Those functions are impure. Purity is a lovely goal, but purity also isn't a defining characteristic of functional programming, it's a modern pursuit. I've met enough classic LISP practitioners that lived their whole programming lives in the most impure of functional programming, that I would never want to tell them to their face that what they did didn't count as functional programming because of all the leaky impurity in LISP (due to pragmatic considerations of the time).
thatswrong0 5y ago
So you're saying you have no idea why they're making changes because you haven't been following along, despite using the library every day...? The communication about the "why" of new features has been extremely clear. E.g. for hooks: https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html
- tekstar 5y ago
  Your first sentence is correct. I'm quite happy using it the way I use it and don't hit any really sharp edges. Thanks for the link, I remember when Hooks came out but I didn't feel the need to adopt them, I'll take a look again.
jfengel 5y ago
I find the function-based components much more elegant than class-based components. The semantics of Javascript classes are confusing, and the new notation is very concise. (Especially with an IDE, such that "refactor this pile of tags into a function" is a one-click process.) The useState hooks are a tiny bit clearer than the setState semantics. The effect hooks are less clear, but all told, the new mechanisms for handle global state and side effects better without Redux. (Redux is neat, but after working with it for years, I just have to conclude that in most cases it's just too much mental overhead compared to a more idiomatically Javascript solution.) There's nothing wrong with continuing to use class-based components, but I think you'll find that everybody else is going to gradually deprecate it. The key facts about the work flow -- state to render function to surprisingly efficient DOM reconciliation -- remains the same.
flowerlad 5y ago
I am with you. React as originally designed made sense to me. You render the screen point-in-time and React takes care of updating the screen efficiently. This is all I need from React. Everything else is bloat.
- e12e 5y ago
  Wasn't react first designed in standard ml, without classes? Then classes were bolted on in the js rewrite - and hooks are closer to the original design? https://www.reactiflux.com/transcripts/jordan-walke https://www.reactiflux.com/transcripts/jordan-walke > So I continued to explore framework-izing these ideas, and I had implemented several iterations of what eventually became React, in a few languages - one of the first explorations began as a rough implementation of the reconciler and component model in Standard ML (CreateClass was a "module function"). This was really great because SML embraces immutability by default which is natural when building React style components. We naturally wanted to deploy UI to web browsers, and at the time, the compile-to-JS landscape was not as mature as it is now - I don't even think source maps existed yet. So it made sense to port that exploration to JavaScript (...) > One thing I noticed that when people were creating point to point bindings in their more traditional "MVC" app structure, it would almost always end up requiring "computable" bindings which invoke a function anytime a mutable cell had received a "change event". All these "computable bindings" ended up chaining together and small changes would end up causing large recomputation of the majority of the UI. I realized that functions already do transform inputs into outputs, and if we could just find a way to reinvoke those functions repeatedly, and quickly enough, that we could be much more expressive and concise, at not much more performance cost that the chain reaction that "computed bindings" would result in anyways.
joshxyz 5y ago
I think it's less about being pure or functional, but more about being "ergonomic". I abhored class-based components from day 1, but on hooks everything just clicked.
audit 5y ago
>".. I use it 2014-style ..." are you using any type system eg TypeScript or Flow ? I am asking because I do not remember them being used back then, so wondering if you had upgraded there. Also what do you use for 'whole app' state handling (rather than component level) ? Asking because React Context feature seems to be the right fit for the 'whole app' state handling, but it was not there back in 2014. I also like you picked up preact for smaller project.. just because the size is so small. But for lager things (eg over 20K lines of JS) I seem to be staying with React.

no_wizard 5y ago

In this way react is choose your own adventure. There is no current signal that the way class components work will change and I don’t exactly expect that to happen any time soon if at all. Rather then new features are aimed at developers with more complex use cases and make heavy use of asynchronous data fetching in a way that lends itself to concurrency. If this isn’t you I’m sure at least the general performance improvements will be nice otherwise I don’t see why you can’t just keep doing what you’re doing

dstaley 5y ago

As someone who was initially resistant to hooks, I actually find that they're a more expressive API to how I was already thinking about my applications. There's footguns for sure, just like there are with class components, but I found that rewriting my class components with hooks instead actually made the code cleaner and easier to reason about. That being said, it's possible the benefit simply came from the rewrite, but even with newer components, I feel like hooks are a better API.

srpoder 5y ago

React hooks might be the best feature ever, once you understand it, it provides you a way to write highly reusable code.

enlyth 5y ago

I personally fell in love with hooks after initially disliking them, you should give it a try, maybe in a toy personal project, to see if you like it. It is great for separation of concerns. You basically stick to writing pure functional components focused only on how to render, and try to abstract reusable logic into hooks, and expose only what you need For example, you could make a useApi() hook and inside your component just do const { data, loading, error } = useApi('/endpoint'), so you can hide everything you don't need away from the rendering logic

flowerlad 5y ago
> pure functional components focused only on how to render, and try to abstract reusable logic into hooks Just FYI, once you add hooks, it is neither pure nor functional. https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
- WorldMaker 5y ago
  They may not be pure, but they are still functional. The hooks follow similar laws to Monads. They aren't entirely monadic and it would have been nice if they were and used a more monadic combinator for bind [1], but they are a relatively pragmatic solution for a language without a strong type system to encode things like algebraic effects and monadic bindings in. [1] Mostly useless aside: using a .then()able based plumbing would have opened up the possibility of using the async/await combinator language. The names async/await would give the wrong impression especially prior to the actual concurrency changes to eventually ship in React 18, but would have potentially been a more monadic fit.
  - flowerlad 5y ago
    > The hooks follow similar laws to Monads. And monads are impure [1]. If all your functions are impure then you're not doing functional programming. [1] https://alvinalexander.com/scala/io-monad-doesnt-make-function-pure-obvious-impure/ https://alvinalexander.com/scala/io-monad-doesnt-make-functi...
    - WorldMaker 5y ago
      Yes, I stated that. Those functions are impure. Purity is a lovely goal, but purity also isn't a defining characteristic of functional programming, it's a modern pursuit. I've met enough classic LISP practitioners that lived their whole programming lives in the most impure of functional programming, that I would never want to tell them to their face that what they did didn't count as functional programming because of all the leaky impurity in LISP (due to pragmatic considerations of the time).

thatswrong0 5y ago

So you're saying you have no idea why they're making changes because you haven't been following along, despite using the library every day...? The communication about the "why" of new features has been extremely clear. E.g. for hooks: https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html

tekstar 5y ago
Your first sentence is correct. I'm quite happy using it the way I use it and don't hit any really sharp edges. Thanks for the link, I remember when Hooks came out but I didn't feel the need to adopt them, I'll take a look again.

jfengel 5y ago

I find the function-based components much more elegant than class-based components. The semantics of Javascript classes are confusing, and the new notation is very concise. (Especially with an IDE, such that "refactor this pile of tags into a function" is a one-click process.) The useState hooks are a tiny bit clearer than the setState semantics. The effect hooks are less clear, but all told, the new mechanisms for handle global state and side effects better without Redux. (Redux is neat, but after working with it for years, I just have to conclude that in most cases it's just too much mental overhead compared to a more idiomatically Javascript solution.) There's nothing wrong with continuing to use class-based components, but I think you'll find that everybody else is going to gradually deprecate it. The key facts about the work flow -- state to render function to surprisingly efficient DOM reconciliation -- remains the same.

flowerlad 5y ago

I am with you. React as originally designed made sense to me. You render the screen point-in-time and React takes care of updating the screen efficiently. This is all I need from React. Everything else is bloat.

e12e 5y ago
Wasn't react first designed in standard ml, without classes? Then classes were bolted on in the js rewrite - and hooks are closer to the original design? https://www.reactiflux.com/transcripts/jordan-walke https://www.reactiflux.com/transcripts/jordan-walke > So I continued to explore framework-izing these ideas, and I had implemented several iterations of what eventually became React, in a few languages - one of the first explorations began as a rough implementation of the reconciler and component model in Standard ML (CreateClass was a "module function"). This was really great because SML embraces immutability by default which is natural when building React style components. We naturally wanted to deploy UI to web browsers, and at the time, the compile-to-JS landscape was not as mature as it is now - I don't even think source maps existed yet. So it made sense to port that exploration to JavaScript (...) > One thing I noticed that when people were creating point to point bindings in their more traditional "MVC" app structure, it would almost always end up requiring "computable" bindings which invoke a function anytime a mutable cell had received a "change event". All these "computable bindings" ended up chaining together and small changes would end up causing large recomputation of the majority of the UI. I realized that functions already do transform inputs into outputs, and if we could just find a way to reinvoke those functions repeatedly, and quickly enough, that we could be much more expressive and concise, at not much more performance cost that the chain reaction that "computed bindings" would result in anyways.

joshxyz 5y ago

I think it's less about being pure or functional, but more about being "ergonomic". I abhored class-based components from day 1, but on hooks everything just clicked.

audit 5y ago

>".. I use it 2014-style ..." are you using any type system eg TypeScript or Flow ? I am asking because I do not remember them being used back then, so wondering if you had upgraded there. Also what do you use for 'whole app' state handling (rather than component level) ? Asking because React Context feature seems to be the right fit for the 'whole app' state handling, but it was not there back in 2014. I also like you picked up preact for smaller project.. just because the size is so small. But for lager things (eg over 20K lines of JS) I seem to be staying with React.