13 ms·

Hooks are the best thing to happen to React

• zeroq 5y ago
  Hooks. Brilliant new idea. It was a blast working with them in MediaWiki in 2005. JS community is adorable. They are like a little infant rushing to you with a snow on his hands "look pa, it's wet!". I'm excited to see what they are going to rediscover next.
  • stevebmark 5y ago
    Are you talking about event hooks, like https://m.mediawiki.org/wiki/Manual:Hooks https://m.mediawiki.org/wiki/Manual:Hooks ? If so, your comment is one for the record books of misunderstanding.
    • zeroq 5y ago
      How so? "Hooks are functions that let you “hook into” React state and lifecycle features from function components." and "[hook] adds the ability to perform side effects from a function component. It serves the same purpose as componentDidMount, componentDidUpdate, and componentWillUnmount in React classes". Quotes from React docs.
      • stevebmark 5y ago
        You have a common misconception of hooks that they are only lifecycle callbacks, I suggest https://epicreact.dev/myths-about-useeffect/ https://epicreact.dev/myths-about-useeffect/ to get a stronger mental model. They can mimic lifecycle callbacks but they're a superset of that ability. Also, I'm not sure why you chose Mediawiki as the thing that has lifecycle callbacks, the concept has probably been around as long as callbacks have been a thing.
• nathias 5y ago
  Hooks are a great start, I hope people embrance the functional paradigm more and we don't have another hype cycle of OOP for some reason ..
  • horsawlarway 5y ago
    See - I'm sort of on the opposite side of this coin. If you put a hook in your functional component, it's not functional anymore. The whole point of functional code is that I'm minimizing state, and writing code that's pure - It will always do the same thing given the same inputs. And that whole guarantee really gets thrown out the second you embed a hook in the function. Now, that said - I also prefer react with hooks. To me they compromised on the push for functional code in order to make working with side effects and state easier. Hooks feel a lot nicer than having to wrap a pure component in a HOC to get the same effect - but it lulls folks into complacency because they are actually dealing with side-effects, and now the boundary is a lot murkier, and comes with a completely different (and not particularly intuitive) set of rules around how to safely use hooks.
    • schwartzworld 5y ago
      You can and should still write mostly pure functional components. The difference for me is that I don't need a container component to manage state and side effects now. I can abstract those behaviors into hooks and test them in isolation.
    • More-nitors 5y ago
      worse, it's actually much more difficult to test states in hooks... it's a variable inside a function -- how am I supposed to test its state from outside (ie. test runner), without resorting to ugly hacks?
      • kushan2020 5y ago
        You test the hook itself. It is a function after all and using hook testing library, it is fairly easy to test. And if you want to test the component using it, you simply mock the hook and make sure the mocked hook returns all the value you want to test. What goes inside of the hook is outside your concern when testing the parent component.
• Stevvo 5y ago
  What I took away from the article is actually how similar the methods are. It's just different styles of writing code that does the same thing. If you use React often, you can build anything, really fast, using either paradigm. Yes, hooks are nice. Classes are still nice.
• deleted 5y ago
  [deleted]
• wruza 5y ago
  Is that a high-quality article? It feels like yet another clueless hype with arguments stretched to make a point. there’s no need to allocate space to a class instance, then call a render() function, you just call the function That module exports a class, not an instance (not that it was significant). React still allocates vdom nodes at mount, by using sort of new Component for function components and new Hello for class-based ones. It has to store useFoo()-states somewhere anyway. setName(response.data,name) That ‘name’ symbol was never defined. Or is it response.data.name? And the graph shows the same growth rate way before ‘hooks’ were released (2017), which makes “With hooks … has grown” a little non-sequitur. See also the same graph with react-hooks: https://insights.stackoverflow.com/trends?tags=jquery%2Cangularjs%2Cangular%2Creactjs%2Creact-hooks https://insights.stackoverflow.com/trends?tags=jquery%2Cangu...
  • true_religion 5y ago
    I don’t really understand the authors reasoning either. Classes in JavaScript are just sugar around functional closures. In fact, you can use hooks inside of React component subclasses with a little fiddling [1]. The fact that the official react doesn’t support it is basically a design decision. It’s not impossible, but they just want to draw a clear line in the sand about how they think React code should be written. 1. https://www.npmjs.com/package/react-universal-hooks https://www.npmjs.com/package/react-universal-hooks
    • EMM_386 5y ago
      > Classes in JavaScript are just sugar around functional closures. One of the key red flags I look for in articles like this are whenever the "overhead" of classes is mentioned, such as with "there’s no need to allocate space to a class instance", without any actual metrics showing what this "space overhead" or "performance penalty" amounts to. It seems like more of a misconception about how JavaScript works. There may be some overhead, but do we know what it actually is in a real world application? Or are we just going on assumptions about what we feel is "light" versus "heavy", often frequently with a biased opinion because we simply don't like OOP concepts?
• porlune 5y ago
  Since switching to React functional components I haven't once felt a need to switch back to class based components. The hook ecosystem just feels right. I suppose it's a matter of opinion at this point, but I do really appreciate the hook feature of React.
  • rafaelturk 5y ago
    I share this vision. React functional components coding experience is amazing..
  • Scarblac 5y ago
    Same here, writing custom books is also a really clean way to make components less cluttered.
• ex3ndr 5y ago
  I really puzzled why no one switched to hooks + suspense. I started to use suspense when it was alpha - you don't need any support for this from react itself: just catch promise in error boundary and display placeholder. This makes everything is so easier: const data = useQuery('/api/user/:id', {id:1}); return (<span>{data.name}</span>); No error handling, not loaders, just one line.
  • spion 5y ago
    Because react no longer renders child components in the same stack as the parent after concurrent mode, I think?
  • kall 5y ago
    I started doing this when the third party apollo-react-hooks package came out with support for it years ago. It was wonderful. I have stopped based on hazy recommendations from the react team about what the future looks like, but I miss it. An underrated benefit is that you can depend on data in other hooks in the same component. If you have an error or loading bail-out it makes hooks calls after it conditional.
  • merrywhether 5y ago
    There’s a Suspense component that does that catch-and-placeholder functionality much more cleanly now. Suspense hasn’t really taken off yet because it’s not quite fully baked, and thus very few libraries are starting to take advantage of it yet. Once we get stale-while-waiting and server-side suspense, things are going to change rapidly.
• fabian2k 5y ago
  Hooks are more magic than I prefer, they behave in an unusual way compared to normal functions. But overall I like React more with Hooks compared to the previous state. One really important aspect here is that Hooks don't just replace class components, they also replace the need for higher order components in many cases. And they make it much easier to compose stateful behaviour in React components.
  • markplindsay 5y ago
    Using hooks to integrate 3rd party libraries is so much cleaner than using HOCs. The magic (and the learning curve, which I think is where much of the pushback on hooks comes from) is worth it.
  • munchbunny 5y ago
    The magic is usually what gets to me. Stuff like useState depending on the order it was called under the hood, meaning you have to use it a specific way. On the one hand, it really does clean some things up well, like for higher order components, but also I find the magic just leaks more than I’d like, and as a result I feel like the only way use the magic safely is to study all of the pitfalls. It’s like using C++ smart pointers but a bit less foot-shooty.
    • fabian2k 5y ago
      While this is kinda weird, I didn't find the dependence on the order of the hooks problematic. The most natural way to use hooks is also the correct one, at least for me. What is a bit tricky is useEffect, but I found that in many cases I either didn't actually need it, or I can use libraries for common tasks that hide the more complex parts. Using react query for data fetching simplified those parts considerably, and I never have to write a useEffect to fetch data from the server.
    • agumonkey 5y ago
      oh wow, if pure functions become hidden-order dependant again then the way is broken.
• otrahuevada 5y ago
  Hooks -React Fiber actually- really messed with my spatial awareness of components. When I started using React I got used to knowing at which point in the lifecycle some things would run, and hooks threw a wrench in that. Took me several months to actually get used to the way things work now, but lately I've found myself not even thinking about those things any more, which would mean the entire matter of lifecycle was removed from my problem space in such a tidy and neat way I find that amazing. I'd love to see some more transpiling magic around them though, most of the bundled hooks have clear correlations to plain JS and it would be pretty cool if the same dev stacks we use could let me write plainer JS and handle that wrinkle for me too.
  • kall 5y ago
    That‘s how I think of hooks. They don‘t let you express the lifecycle of things, only the data dependency graph. React moved the level of abstraction a second time, and I think they succeeded.
  • tuan 5y ago
    You still need to understand lifecycle of a component to understand how useEffect() works though...
• bevacqua 5y ago
  And suspense is the worst thing to happen to React
  • scotty79 5y ago
    Why is that? It's a feature I was missing in react nearly from the strart and I was trying many times to mimic it with varying degree of success but all attempts were finicky.
    • bevacqua 5y ago
      it optimizes for not thinking about loading states, and the way it's normally used (hook fetches data, suspends) results in you having to go out of your way to add a loading state near the component that suspended, as you have to create an intermediate component and a loading component, splitting what should be a single concern into several, and it results in a lot of duplication that previously could be addressed by just having an `isLoading` prop not thinking about loading states hurts ux and perceived performance edit to clarify: i like hooks (though people abuse them) and believe react has generally always been best-in-class at thoughtful interface design. suspense breaks with that imo
      • tuan 5y ago
        >> add a loading state near the component that suspended, as you have to create an intermediate component and a loading component, splitting what should be a single concern into several I'm not following. Can you just wrap the component that suspends with <Suspense fallback={SharedLoadingUI} /> ? The SharedLoadingUI could help with duplication right ?
      • kall 5y ago
        Loading Boundary type things do have that issue, but the part where you can delay any update for the 70ms your very fast API response takes, while showing an inline loading indicator, is a real UX win.
• sandGorgon 5y ago
  interestingly, this concept has seeped into mobile app development. Swiftui was heavily inspired by React (https://twitter.com/jckarter/status/1135666944273571840 https://twitter.com/jckarter/status/1135666944273571840) Flutter and Jetpack Compose - also admittedly. React Native is a given. I think the biggest change that React has wrought is the paradigm of how UI can be composed...versus the javascript library itself
  • kushan2020 5y ago
    I could wrong but I remember that these peoples copied how you can decoratively write UI aka JSX. Did they also copy hooks ? Not that it is a bad thing to copy, just curious hope it looks.
    • sandGorgon 5y ago
      https://www.christopherbiscardi.com/swift-ui-state-property-wrapper-vs-react-use-state https://www.christopherbiscardi.com/swift-ui-state-property-... Generally, it seems like it. But I'm definitely not taking an authoritative stand here!
• andeee23 5y ago
  For hooks done right I recommend people look into SolidJs https://www.solidjs.com/ https://www.solidjs.com/. Very similar API to React but the reactivity system is nicer. There's no hooks rules like not putting them in if statements or inside other hooks. Very cool and I think this is the future. It also helps that the performance is crazy good and it doesn't re-render everything all of the time like React.
• deleted 5y ago
  [deleted]
• jrochkind1 5y ago
  > The code above collects user data by using the Axios API and prints it on the DOM. The useEffect and useState hooks make for more straightforward and concise code that is easy to understand and work on than the class components More concise? It seems about identical to me. More straightforward, easier to understand? I guess it's subjective? Defintiely not obvious to me, but I do come from an OO background. easier to learn for beginners, as the article next says? Does anyone have any even anecdotal information on that, if they themselves are a beginner or know some? It's really not obvious to me. I mean, these things are subjective (except for "concise" maybe), if lots of people are finding it more straightforward, easier to understand, easier to learn, then they are... but are they?
  • EMM_386 5y ago
    > More straightforward, easier to understand? I guess it's subjective? Defintiely not obvious to me, but I do come from an OO background. I had the exact same reaction to this code block. Using componentDidMount() made it clear what it was doing. Reading the functional version I have no idea how useEffect() equates to componentDidMount(). I am also from an OO background and am currently working on a very large Angular 12 project on the front-end with a C# back-end. I am really enjoying working with Angular ... I can quickly see at a glance what is going on and everything is structured and well organized. React often seems to be targeting developers coming from the "other direction", with a JS background first. I also don't understand "hooks have made React easier to learn for beginners". My mind glazes over sometimes reading these various examples and I've been in the industry for decades. To each their own I suppose.
    • angelzen 5y ago
      Not sure this has much to do with OO vs Functional Hooks, more like reading the docs? OO lifecycle: constructor, render, componendDidMount, render, (render, componentDidUpdate, render)* FH lifecycle: (renderFn, useEffectFn | (useLayoutEffectFn, renderFn))+ For more in-depth musing over the exact behavior, see, for example: https://reacttraining.com/blog/useEffect-is-not-the-new-componentDidMount https://reacttraining.com/blog/useEffect-is-not-the-new-comp...
    • 5y ago
• akdor1154 5y ago
  > The graph above shows the increase in the percentage of Stack Overflow questions about React over the years vs. other popular JavaScript frameworks, sure, looks successful. > With hooks, it’s now simpler to learn React; because of this, its use in the tech world today has grown: (graph) - proving that its general usage has increased since the introduction of hooks. wait what? You may as well say that React googling has caused Covid deaths. You could just as easily (mis)interpret the statistic to claim hooks have made it harder - "as per the graph, now they need to ask on Stack Overflow for things that were previously obvious". Pseudo-statistical garbage.
  • BobbyJo 5y ago
    > sure, looks successful > Pseudo-statistical garbage Seems like the author is just making a relatively benign, and half-hearted, conclusion (that React has gotten more popular) based on the data available. When I hear more people talk about something, that generally leads me to believe more people care about that thing. Does it have a P value that a journal would accept? No. But this is an opinion piece about a cool tool the author likes, not a paper on a new drug. You're going a little off the rails.
    • capableweb 5y ago
      The conclusion the author makes ("With hooks, it’s now simpler to learn React; because of this, its use in the tech world today has grown") is pretty garbage though, could be any reason popularity of the search term has increased. That it's because it's easier to learn feels pretty far down the list of possible reasons. The rate of the increase for React in that graph is pretty constant, and I see nothing that gives the impression that the introduction of Hooks (February 06, 2019) accelerated the increase. But yeah, harsh words by akdor1154 maybe but I agree with the sentiment in general.
      • BobbyJo 5y ago
        That's fair. I'm probably biased because I was introduced to react with redux and absolutely hated it. I dove into hooks the moment I had a chance and found it way easier, so I am exactly the anecdote the author thinks is the majority :P
• FractalHQ 5y ago
  Svelte makes React hooks feel like boilerplate.
• cyberpsybin 5y ago
  If you go by hacker news crowd, everyone despises React and SPAs are worst thing ever happened to web. In reality it exactly opposite. Most people use React, are satisfied and SPAs perform way better than your usual website that refreshes on every click.
  • fuzzy2 5y ago
    SPAs are fine. Server-side rendering is fine, too. What's not fine is using SPAs for static pages or server-side rendering for highly interactive web applications. Unfortunately, SPAs are often used where a classic SSR page would suffice, all in the name of "performance optimizations" and whatnot. Meanwhile, UX suffers because often edge cases like slow/spotty connections, device sleep or even just accessibility or not considered at all.
  • ptx 5y ago
    Refreshing on every click is super fast if you're not loading megabytes of JS. Maybe everyone on HN despises SPAs because we've all seen how fast, light and reliable HN itself is compared to e.g. Twitter where clicking anything usually brings my computer to a crawl and half the time shows a loading error.
• beebeepka 5y ago
  A bit off topic: do React jobs pay better in your area? Here in Bulgaria these jobs pay about 30% more than identical Vue positions. It's very unfortunate for people like me
  • __jem 5y ago
    Very superficial, but IME React developers tend to be more full stack, more likely to use TypeScript, be aware of tooling, etc., which I think suggests a higher level of “competency” (although not necessarily quality or complexity of code produced).
  • kushan2020 5y ago
    Ya React devs produce 30% more code than Vue devs. I’m just joking, but it very unfortunate for companies to pay more for a given flavour of UI library.
  • delta1 5y ago
    Maybe don’t identify as an X developer, and get the better paying job?
    • oblak 5y ago
      But then I'll have to use React
• Aeolun 5y ago
  I’m getting really tired of these distictions people make, saying either class components or hooks are better. Class components were fine. Hooks are also fine. They both give you plenty of rope to hang yourself with. And if a component in either form is hard to understand it’s probably just too f big. What bother me most is those people that have no clue how hooks work, but claim their “functional” components are now faster, because they’ve read that functional is good somewhere.
  • beaconstudios 5y ago
    The benefit hooks bring is that as well as already being able to separate out components, you can now separate out React functionality into reusable pieces in a clean way.
    • imbnwa 5y ago
      I'm still not sure why ostensibly little effort was put into figuring out mixins[0] [0]http://raganwald.com/2016/07/20/prefer-composition-to-inheritance.html http://raganwald.com/2016/07/20/prefer-composition-to-inheri...
      • beaconstudios 5y ago
        It's not about making something possible; it hasn't introduced any new capabilities. It's about improved semantics. Everything that is possible with programming has been possible since we were poking hex codes directly into memory. All language improvements have been about semantics, or fixing performance degradations brought about by new programming paradigms. [edit] I do agree that mixins could've been good too.
  • orcdork 5y ago
    For me (and I suspect a few other people working with react, but certainly not everyone), the main issue with hooks is exactly that class components were fine, and hooks are fine, and we did not need nor want more "fine". Hooks feel more like something added to fill in space and another example of the ecosystem bloating itself just for show.
• ricardobeat 5y ago
  “hooks make for more straightforward and concise code”, “easier to learn” Proceeds to pass an empty array for no apparent reason* to a function in the first example. The later explanation completely ignores mutability and what it means for the type of value you can use as a dependency. Hooks are nice for small components, but overall haven’t improved DX over classes much, and introduced a ton of new concerns. Yes, it makes composition easier. It also makes it harder to reason about component lifecycle when state changes are distributed among a dozen little functions with slightly different update semantics. * I am familiar with how hooks work, am highlighting the implicit complexity
  • junon 5y ago
    Check out Surplus. It was "hooks" before the react team decided to implement a half-assed version of clocks. I use surplus everywhere I'm allowed to, and it rarely bites me. It also allows me to develop pretty robust frontends quite quickly. The learning curve is a bit high, admittedly, but I think that's fine.
  • kushan2020 5y ago
    > Hooks are nice for small components, but overall haven’t improved DX over classes much, and introduced a ton of new concerns. Composition itself is a huge DX improvement. > It also makes it harder to reason about component lifecycle. I would argue that it is the same if not better than class based components. One of the amazing things about hooks is that you can ignore all of the hook updates and just treat the values returned by them static to see how the rendering will happen at a particular instance.
    • bryanrasmussen 5y ago
      For simple states hooks are the same if not better, I would say almost probably better. For complicated states where you need 4+ hooks - well in that case most of the time refactoring is needed but there are cases where it should not be refactored and I have a certainty something could be done much easier with the old class based way of doing it, but then I would have to deal with people in PR who say we must use hooks for everything.
• hliyan 5y ago
  The current enthusiasm around React seems somewhat reminiscent of jQuery about 15 years back. It was the first library to solve a problem that plagued the entire industry. It was widely adopted and considered almost a "standard", to the point where you will now find an entire graveyard of Stackoverflow questions about DOM manipulation where the answer is "just use jQuery". My gut feeling is that the same will happen to React in the next 5 years, possibly as a result of more native support for web components and front-end state management. I was writing Visual C++ front-ends around the time jQuery first appeared. Front-end state management should not be this complicated.
  • porlune 5y ago
    I agree, jQuery has been quite the workhorse, so much so that Angular 1 had a built in subset of jQuery called jqLite
  • lsalvatore 5y ago
    I wrote jQuery in production for 5 years and then switched to React for 6 years in production at a half dozen companies. In my opinion, nothing can be improved further. I love writing React, it solves every problem you can think of and scales for large codebases. Prior to React, we were using Backbone, Handlebars and jQuery. It was horrible. Logic was put into Handlebars templates, Backbone models created an unnecessary abstraction, we had to setup our own event handlers for every model -> view change. It just didn't work. JSX solved all these problems. Frontend-state management with React is not complicated. There is a current trend to trash React because of its perceived complexity. Take it from an experienced React developer- it's easy and fun. Hooks are a short syntactic sugar over its lifecycle methods. Once you learn hooks, there isn't much more to learn. I'm not sure where you are in your career now, but I recommend that you give React another chance, and avoid jumping on the bandwagon to hate on React. It's solved so many problems for me and allowed me to actually enjoy my job as a software developer.
• kushan2020 5y ago
  I was debugging my apps monstrous memory leak. It took me quite a while to figure out that ‘useMemo’ was sneakily responsible for it. Currently the way this hook works is that it will hold references to all the objects that go through it. In most cases these objects are pretty small and trivially contribute to a leak, but in my case I was saving a giant class instance which was causing significant memory usage. Just wanted to share this on how the simple looking hooks can hide some really hard to find bugs.
  • jitl 5y ago
    Do you mean that it holds references to all versions of the memo’s dependency array AND all versions of the memo return value, or just that it holds the last version?
    • kushan2020 5y ago
      It holds all of the references to the dependencies strongly, which makes sense since it is a memorization helper function. It saves all the dependencies to avoid recomputing if the same dependency shows up any time in future. But in my case I was using an old school library where you call destroy and set reference to the instance as null, and putting that as a dependency in usMemo was a bad idea.
• BiteCode_dev 5y ago
  I hates the idea of hooks. After trying them, there are things are like about them, and I use them. But it's not "the best things to happen to react". It added plenty of complexity to the system. Hooks have been embraced by the community in a way that now many features only exist as hooks, which makes ones life difficult as soon as you don't want to use a functional component. An no, not everything should be a functional component. In fact, some things are really hard to do with hooks. I dare you to craft a simple reusable _and correct_ useInterval() hook without stealing the solution online. Go on, I'll wait.
  • jitl 5y ago
    I think your exercise framing is silly but I’ll bite since I’m a programming addict. Writing on my phone so forgive any typos. function useInterval(cb, ms, deps) { useEffect(() => { const id = setInterval(cb, ms) return () => cancelInterval(id) }, [ms, …deps]) } I think this is much nicer than having interval maintenance and prop diffing is didMount, didUpdate, and willUnmount. Certainly it’s easier to get the hooks right (for me) and all the logic ends up in contiguous lines of code. It’s a higher level interface so it takes a bit more practice to apply - feels like Ocaml more than Java.
    • stevebmark 5y ago
      I think the original comment is fair, and comparing your attempt to working solutions online will reveal the complexity of bugs that can arise from hooks.
      • jitl 5y ago
        I see - the issue with my solution is that the interval will reset whenever the deps array changes, starting over the delay? The implicit "state" of the time left before the next tick is destroyed when the effect re-runs - instead this should persist. Dan Abramov has a good post that explains the issue here well: https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r...
• trias 5y ago
  To me React hooks look like they want to be a different programming language while still using js-syntax. It would be great if "useState", "useMemo" and the like would be first class citizens in a PL. Hooks as they are have some non-obvious rules which can make them hard to understand / learn. Also debugging is not great (but that's true for react in general, imo)
  • wruza 5y ago
    You should check out Redux if React seems alien in its own language. This entire stack pretends to be something non-imperative javascript, but at the end of the day just offloads all the burden of writing few layers of abstractions by hand on developers.
• ibejoeb 5y ago
  const loadingTuple = React.useState(true) const loading = loadingTuple[0] const setLoading = loadingTuple[1] I've never seen this construct once in the wild. Makes one wonder if the author actually uses React.
  • satvikpendem 5y ago
    Maybe they're using ES5 rather than ES6+?
    • imcotton 5y ago
      I once saw someone writing ES5 barehanded, like savages.
• thrower123 5y ago
  I haven't done a great deal of React, but having inherited a codebase with both class components and hooks sprinkled through, the class components are better organized if the component actually does anything useful. Hooks seem to be fine for dumb little UI bits that you'd use directives for in AngularJS.
• ptx 5y ago
  I'm only vaguely familiar with React, but the class-based components and their methods make perfect sense to me after seeing the diagram and example in the article, whereas I have no idea how the "more straightforward" and "easy to understand" hooks-based example is supposed to work. Also, that loading boolean seems unusually variable for a constant.
  • portlander52232 5y ago
    They basically invented a new programming paradigm. You’re not familiar with it so it doesn’t make sense. But it actually more closely matches what’s really going on, so it’s more straightforward to someone familiar with how React works. The class-based API did not closely match how React actually works and so led to various common bugs which don’t occur anymore with the hooks API. You do have to learn the paradigm, but having done that you understand a lot more what you’re doing. This would probably be clearer if it were just a new programming language instead of being shoehorned into Javascript—then it wouldn’t seem so weird to be learning a new paradigm.
    • imbnwa 5y ago
      > But it actually more closely matches what’s really going on, so it’s more straightforward to someone familiar with how React works. The class-based API did not closely match how React actually works and so led to various common bugs which don’t occur anymore with the hooks API. I see this said a lot, so what's really going on that the class API obfuscates?
      • portlander52232 5y ago
        It isn’t perfect but this is probably the best explanation that I know of https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/
  • dragonwriter 5y ago
    > Also, that loading boolean seems unusually variable for a constant. Like any other constant, it never changes during the lifetime of its scope (a single function invocation) but can be different during different invocations. (The initialization by the useState function, though, is somewhat magical, involving external knowledge of whether this invocation is rendering a new instance or rerendering an existing one.)
• stevebmark 5y ago
  The main takeaway from this article is how to improve the marketing of your own content. This is a fluff piece that is mostly copypasta from React documentation. How did it frontpage? The title, and maybe some klout from the domain name. Clickbait gets you pretty far. Either way, I hope you’ll join me in flagging it.