10 ms·
Were React hooks a mistake?
- avereveard 4y agoyes, anything that muddles the stack trace is
- CharlieDigital 4y agoThe best take I've been offered is that the problem with Hooks is that they are kind of a quasi object-oriented solution (more or less it is encapsulating state with a setter/getter) shoe-horned into a quasi-functional render pipeline that demands functional purity at scale (lest your performance falls off a cliff from over-rendering or you end up with odd side effects). That disconnect is why hooks just don't feel right.
- andix 4y agoIsn’t the best of both worlds what you want? I do a lot of FP and OOP, and both worlds are not perfect. You want to mix them in a way you get the best out of both worlds.
- CharlieDigital 4y agoEach has a different mental model and as Evan You said, the host language itself is not suited for a "pure" FP approach and you end up with a leaky abstraction. As the article states, function closures are how classes are actually implemented in JavaScript so rather than mash the two together, it would seem a more cohesive mental model to simply use a class. If you step back and look at the broader landscape of UI across desktop (Windows, Mac, Linux), devices (iOS, Android), and web: how many libraries and toolkits are FP and how many are OOP in their abstraction when it comes to managing components and object instances?
- Rapzid 4y ago> function closures are how classes are actually implemented in JavaScript Quite the opposite with V8.
- andix 4y agoIf you love OOP, then use Angular. It’s OOP all the way! But you will probably regret using it… There are also a lot of UI frameworks that are completely functional. Take your pick. (ReScript would be the most obvious choice for a react developer) But for a good reason the hybrid FP/OOP framework React on JS/TS is one of the most popular.
- CharlieDigital 4y agoEven Solid and Preact are OOP in nature since JS closures are how classes are represented in JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Classes are in fact "special functions", and just as you can define function expressions and function declarations, a class can be defined in two ways: a class expression or a class declaration. The difference is that React functional components are effectively "parroting" FP and half-in (stateless components) and half-out (hooks). Solid, Preact, Vue are all-out.
- andix 4y agoBy that logic F# is also not an functional language, because it gets compiled to CLR classes. For me those implementation details are not important. But sure, you’re right.
- CharlieDigital 4y agoF# is not a functional language. Even says so in the docs: https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ F# has full support for programming with objects in .NET, including classes, interfaces, access modifiers, abstract classes, and so on. For more complicated functional code, such as functions that must be context-aware, objects can easily encapsulate contextual information in ways that functions cannot. https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/classes https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... Classes represent the fundamental description of .NET object types; the class is the primary type concept that supports object-oriented programming in F#. https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsha... F# has full support for objects, which are useful when you need to blend data and functionality. The underlying CIL representation of a lambda expression is an object; the functional side of .NET (whether C# or F#) is syntactic sugar on top of an OOP runtime. (C#/.NET dev by day dabbling in F#)
- bayesian_horse 4y agoHooks are often side effects (but not always) and that sounds like "imperative" programming, but actually the side effect is what is inside the useEffect hook, not so much the hook itself. The component is still a pure function. It "returns" side effects without executing them, just not as the function return value but through a side channel. But that side channel is sort of a clutch to achieve a pure relation from input to output, just that the output is now a return value from the function plus the sideeffects, which may be executed or not.
- CharlieDigital 4y ago"Side effect" in my comment means an unintended side effect from an impure functional component (often a case of missing a useEffect, useMemo, or useCallback).
- bayesian_horse 4y ago"Side Effect" in functional programming usually means the function is affecting something other than the output. And calling a hooks really doesn't, they just output the description of such an effect on a side channel.
- CharlieDigital 4y ago> usually means the function is affecting something other than the output That's exactly the point. If you leave an errant function call in a functional component, it's going to affect something other than the output of that component.
- EGreg 4y agoIt was like an admission that their idea couldn’t handle many cases and they made a release valve. There are other approaches like Signals… or Angular… or our totally different approach: https://qbix.com/platform/guide/tools#designing https://qbix.com/platform/guide/tools#designing There is really nothing wrong with simply having components without unidirectional flow, with being able to simply pass options down to child components.
- urbandw311er 4y agoSlightly off-topic but I'm struggling to understand the choice of that weird looping font the web page uses for keywords in code.
- Xelynega 4y agoCursive?
- urbandw311er 4y agoYes, that's the one. Very hard to read quickly, and an odd choice for a use case that I'd think would require absolute clarity and rapid recognition.
- cityofdelusion 4y agoIf you know cursive, it usually reads fast and clear. I don't think it is widely taught anymore though, as it was mostly a footnote when I was in school many years ago. It is a strange choice for the article considering the rarity of cursive these days.
- rhacker 4y agoThe cursive throws me off and I am heavily distracted by it. teho (to each his own)
- Joker_vD 4y agoI'd argue, on the contrary, it's perfect for keywords: you recognized those mostly by shape anyway, so now they don't even look like actual names which is an upside for me.
- arrakeen 4y agoit's not cursive because the letters are not connected (unless my fontconfig setup is messed up). these are cursive letterforms completely divorced from their utility which makes them awkward and jarring
- jitl 4y agoAll of this tricky reasoning about what executed when - and what is closed over vs not - is challenging for most developers. The class version is the most straight forward by a wide margin compared to either React function components or Solid functions. I am happy writing hooks and figuring out the right way to express my effect conditions, but I read a lot of code that gets it wrong, and when I talk to devs they often don’t have as strong a mental model for lexical scope, lifetimes, and closures. Ultimately I think either function API is too subtle for the median developer I’ve worked with.
- phailhaus 4y agoYeah I absolutely love hooks, but it definitely has a learning curve. But damn, you can do nearly anything with it. One of my favorite projects involved using hooks to manage p2p connections using WebRTC, which would have been a nightmare to write without hooks. Haven't looked into signals yet, it's interesting that it almost looks identical. I wonder how it decides when to rerender.
- petilon 4y agoSo you're building business logic into your view components? This used to be simple in the old days when we used MVC.
- phailhaus 4y agoNo it wasn't, MVC was a mess because your views would trigger your controllers, which would propagate changes back down to your views in entirely unpredictable and inconsistent ways. With hooks you're still free to manage business logic elsewhere, it just means that you can trivially reuse them across your application without worrying about order-dependence. So I was able to write a hook that returned connection state, and then drove my views off of that reactively.
- petilon 4y agoI think you're thinking of MVVM, not MVC.
- urbandw311er 4y agoI think I am getting old and cynical. These days whenever I read a blog claiming some approach has recently "exploded in popularity" and implying it's the 'ultimate solution' to whatever problem space, I mentally start counting the days until its inevitable replacement with the next fad...
- politician 4y agoProgramming trends move 100x faster in webdev than in other areas for some reason.
- jjordan 4y agoThat definitely used to be the case, but it seems that webdev has matured to the point where you don't need to learn a new framework every 6 months. React turns 10(!) this year, and React hooks just turned 4.
- urbandw311er 4y agoI think that’s an entirely reasonable response - thanks for suppressing my inner cynic!
- throwaway5371 4y agoyes
- ihatepython 4y agoI would argue 'not exactly'. Technically, React was the mistake. Eliminating React would prevent React hooks from existing in the first place.
- H1Supreme 4y agoI copied this code into a current project and the alerts all had the correct counter.
- likeabbas 4y agoI am so happy I don't have to touch front end code for my career
- ranting-moth 4y agoReminds me of a story, The Emperor's New Clothes (H.C. Andersen, 1837). The emperor gets tricked into buying new extraordinary clothes. They are incredibly fancy, but invisible to anyone "who was unfit for his office, or who was unusually stupid". The emperor didn't see them, but of course he didn't want to admit that. The whole lot of townspeople didn't see them either, but likewise, no one wanted to admit that. In the end, the emperor goes to town, naked. Everyone praises his new clothes. Until finally a little boy utters: "But he hasn't got anything on!" and the truth unfolds. https://andersen.sdu.dk/vaerk/hersholt/TheEmperorsNewClothes_e.html https://andersen.sdu.dk/vaerk/hersholt/TheEmperorsNewClothes...
- nonethewiser 4y agoHow would the boy's comment reveal the truth? It should just be rationalized as he wasn't fit for office or unusually stupid. Likewise for the village people - even if they said something it has already been explained away by the initial premise the emperor accepted.
- ranting-moth 4y agoThat's an interesting question. The author has long passed away so he won't be able to explain his story. Perhaps a psychologist could chime in with some probable explanation?
- rozenmd 4y agoOnly if you weren't writing code for a bigco (imo) - hooks simplified a lot of enormous components to be almost readable
- notpachet 4y ago> enormous components Sounds like an X/Y problem to me.
- zodiakzz 4y agoCan you give any example where hooks helped readability without trading it for extremely high complexity behind the scenes? I maintain a large React codebase part-time. The client is a very good friend of mine and I was the one who chose to make my own life miserable by selecting React. Needless to say I won't touch/introduce anything "new and/or popular" for customer projects with a ten-foot pole for the rest of my career. I used both class-based (thank goodness?) and hooks based components but only coz React ecosystem forced me to, class-based were frozen and left in a sorry state - as if React's dictator-in-chief (forgot whoever they are/were, don't want to know - tried to engage once in writing the "beta" React docs but they were horribly toxic in response for no reason) is the only smart person(s) ever and all these OOP language designers are... No, dear Kim Jong(s), you were the ones abusing JS classes in strange counter productive ways and I easily found better OOP patterns for my class-based components. Then I met hooks - the definition of anti-productive. Not to say people don't have a right to write/reflect whatever madness in their code they want to but for me it's a tragedy their "work" became so popular. I don't mean to belittle people who actually have it but hooks is what comes to mind when I think of what PTSD must feel like. I no longer take up JS/TS SPA projects. For the mental strain - the pay feels peanuts compared to native mobile app development so why bother.
- mabbo 4y agoI miss using React Redux. I'm a back-end dev primarily and never had a good time writing front-end code. Redux just clicked for me. The model made perfect sense! Events from components get handled, and the state is changed. The state is then re-rendered. Beautiful. It feels like hooks replaced a lot of what redux was doing, yet I don't have the same sense of reasoning as I did with redux. But again, I'm mostly a back-end dev.
- pzduniak 4y agoI use Redux with hooks. It's fine and I prefer the hooks syntax to the `connect` stuff.
- andix 4y agoModern redux is okay, the first redux was just an abomination of boilerplate code, that gave frontend developers the feeling they are doing „clean architecture“ now too…
- halfmatthalfcat 4y ago@reduxjs/toolkit is absolved most, if not all, of the boilerplate. It's been a joy to use.
- andix 4y agoYeah, it got much better now. But since react query and swr I think most applications don’t need state management anymore. If you have complex state, it makes sense. But just to fetch/refetch some queries redux is overkill. Most redux (and also angular ngrx/ngxs) projects I’ve seen, are just over engineered. They solve an easy task in a very complicated way.
- halfmatthalfcat 4y agoI find using query/rtk/etc to be more trouble than they're worth tbh. It's more black-boxing then I'm comfortable with, personally. I want my side effects explicit. I've found a lot of success with redux/redux-observable which is super clean, at least for me.
- fourseventy 4y agoWay too much churn in React. People have products to build, they don't want to re-learn a new way to use React every year.
- illiarian 4y agoI pulled a class component into a greenfield project just last week. It worked without a hitch. You can still use React the way you used it 10 years ago.
- Hasu 4y agoReact Hooks came out 4 years ago. React doesn't change dramatically every year and the React devs are careful not to break the old APIs, so you can ignore hooks or other new features if you want. This complaint comes up in every thread about React and it makes no sense.
- penumbral 4y agoExcept in the real world opinionated leads and team members forced teams to adopt ONLY hooks going forward, or have to maintain two separate implementations - hook compatible or class component compatible code. So yes, this is a very sensible concern that transpired with hooks. Simply allowing reverse compatibility doesn't change the fact that hundreds of workplaces forced people to use a less ideal paradigm.
- Hasu 4y ago> Except in the real world opinionated leads and team members forced teams to adopt ONLY hooks going forward, or have to maintain two separate implementations - hook compatible or class component compatible code. That isn't React's fault. Your opinionated team members can enforce all kinds of nonsense. This is a general argument against ever introducing new features in any framework or language, and it's not valid. > So yes, this is a very sensible concern that transpired with hooks. Simply allowing reverse compatibility doesn't change the fact that hundreds of workplaces forced people to use a less ideal paradigm. "Less ideal paradigm" is an opinion. There are use cases where hooks make perfect sense and are superior to class components. And again, what your employer and teammates do doesn't implicate React or the React team! They could have enforced Hooks on all components, and dropped support for the old APIs. What should they have done differently? NOT released an optional feature that is loved by millions of their users, just so none of those users can interrupt your ideal workflow? How entitled can you be?
- andix 4y agoReact hooks are the best reactive state management for frontend I’ve ever used. They provide more or less the same functionality as Rxjs, but are 10 times easier to understand. Yes, they are not perfect, but they solve a very complex problem. It’s the easiest solution I’ve ever seen.
- MrStonedOne 4y ago[dead]
- jgoodhcg 4y agoI have not seen a better client state management than re-frame. https://github.com/day8/re-frame https://github.com/day8/re-frame Notably the author of re-frame has been weary of hooks. I think that’s for a good reason. The approach in re frame feels like the best way to manage state so far for a react based app. Everything that changes state flows through an event. State can only be observed through subscriptions. Side effects are isolated to their own type of event. Debugging and testing are so straight forward with these concepts. Redux got close but it has two problems in my mind. Like hooks, it encapsulates for no good reason. Put the state in one thing that you can observe holistically before and after pure events. It also has too much boiler plate.
- oaiey 4y agoA bit off-topic: How is any of the code samples intuitive for a beginner to use. I understand and love the reactive principle (and it immense benefit when it comes to sizeable UIs) and high-level react (never coded it) ... but still, the sheer complexity introduced for a simple counter by these 3 evolving snippet. This is not how I want my grandkids to code software (if the AI overlords let them).
- superdisk 4y agoAm I the only one who thought that class-based React components made perfect logical sense and "hooks" are way too magical and confusing? Plus I ran into this exact drawback (trying to access state from within callbacks) on a recent project. I feel like I'm taking crazy pills when I see hooks everywhere.
- phailhaus 4y agoClass based components are easy to pick up, but they don't scale. They're really hard to refactor, and make it hard to reuse behavior. If you have a simple app though, they'll do fine. Often with hooks, you'll have to think differently in order to figure out how to accomplish what you want to do more functionally. That up-front cost ends up paying back later because you'll rarely need to touch it, and it's dead-simple to reuse somewhere else. This pattern from the blog post of "fetching state from within a setTimeout" is rare, but your example of accessing state from within a callback should be manageable. Here's the thing: even though the example from the blog post is strange, the advantage of hooks is that you can pull that pattern out into a hook! So instead of `useState`, you'd call your hook that returns the reactive value, a setter, and a getter that uses the ref under the hood. Then you can use that getter in the `setTimeout`, and you never have to think about this problem again when you have to do this for any other piece of state!
- lpa22 4y ago“They don’t scale” They scale great. Decorators are incredibly underrated for code reuse.
- phailhaus 4y agoYou can't compose behaviors effectively with class based components, and the fact that you only have one of each lifecycle method means that they become an absolute mess as you scale with complexity. Each behavior gets split up across multiple lifecycle methods, mixed in with every other behavior. With hooks, you can encapsulate each behavior into a single hook function that handles its complete lifecycle, and then trivially use it anywhere else.
- deleted 4y ago[deleted]
- xwdv 4y agoThey were not a mistake, people just need to grok them better. You need to embrace functional purity.
- notpachet 4y agoBut hooks enable the creation of components that are often the antithesis of functional purity. Side-effects out the wazoo. It's like carbon credits for functional purity rather than the real thing. People just feel better being able to say that they're using a function component.
- rads 4y agoHooks encapsulate mutable state. It’s not much different than object-oriented programming with a different syntax.
- NDizzle 4y agoWell, I don't know about hooks being a mistake. What I do know is that the font choice in those code blocks was DEFINITELY a mistake.
- schwartzworld 4y agoSignals and hooks are solving different problems. React was designed to allow you to think functionally about UI. Your UI should be a pure function of your state. This has always been the goal. All your code runs on every render unless you specifically tell it not to. Signals are the opposite. A solidJS component runs once, and only the reactive bits ever update. You have to opt into reactivity instead of opting out of it. The post gives an example of an unintuitive use of hooks, but misses the point. Yes, it's a tricky use case, but the ability to write custom hooks means you need to solve this problem once per codebase at most. The author's "kludgy" solution just needs to be put in a `useTimeout` hook (https://usehooks-ts.com/react-hook/use-timeout https://usehooks-ts.com/react-hook/use-timeout). The kludge shouldn't live in the component. There are some weird cases when you rerender the whole world whenever state changes, but there are plenty of weird cases that it prevents. React's model encourages treating variables immutably and preferring pure functions for modeling your domain. This is hard, because it's not how most JS devs learn to write code before coming to React. But knowing that the whole world is going to rerender gives you tremendous certainty in other areas. Depending on how complex and reactive your UI is, maybe signals would work for you, but if most of what you see on the page is reactive, I'd probably prefer the React model.
- mpweiher 4y ago> Your UI should be a pure function of your state. Except this has always been BS, and IMHO this fundamental inconsistency at the heart of the model is why the wheel has to keep on turning. https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... (Read to the end...) https://github.com/reactjs/react-basic/pull/12 https://github.com/reactjs/react-basic/pull/12
- haspok 4y ago> "Except for games, UIs are actually very stable, more stable than the model. You have chrome, viewers, tools etc. What is a (somewhat) pure mapping from the model is the data that is displayed in the UI, but not the entire UI. So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability." I think this could be the key takeaway from the linked article. It hits the nail on the head, on the other hand though, pure functions are _really_ nice, so I believe in the future development of UI frameworks will congregate in that direction, but in a more fine-grained way than React et al.
- nathias 4y agoanything that isn't the garbage OOP with its infinite bloat is progress
- bayesian_horse 4y agoTo me React clicked because it was basically PHP or a template engine, just on the frontend and it rerenders when necessary. You can treat it mostly like that, even if it is more complicated. Where signals get into trouble (I think) is when the structure of the elements change a lot, and that's when I'd expect bugs in DOM manipulation or state handling to show up. You also need to remember to listen to these signals, otherwise you have something that updates fine under certain circumstances and not others.
- z3t4 4y agoI prefer this, what's it called? observable? function createButton() { var button = document.createElement("button"); function setClicks(clicks) { button.innerText = "This button has been clicked " + clicks + " times"; } DB_STATE.get("click", function(err, clicks) { if(err) alert(err.message); if(clicks == undefined) clicks = "?"; setClicks(clicks); }); DB_STATE.on("click", setClicks); but.addEventListener("click", function() { DB_STATE.do("click"); }); return button; }
- brap 4y agoI think hooks were a mistake. I think components should have been made pure functions, with state/effects being provided by higher order components (HOCs). For example: Counter = ({count, setCount}) => { // pure function here } StatefulCounter = withState(Counter, { count: { setCount: 0 } })
- notpachet 4y agoYou're basically describing Redux connected components.
- xzel 4y agoAs another child comment said this is how Redux with HoC worked a few years ago. It was very common. Imo working with that paradigm was miserable. You would have a mess of withXXXX type of connections. It was like using decorators or mixins with 0 ergonomics. Hooks are about a million times better.
- davnicwil 4y agoNot having heard much about signals my takeaway from this is that they allow you to write functional components assuming the function runs exactly once, thus sidestepping issues with closures etc on updates that cause further runs of the function. Is that right? If so it's pretty smart I think. I'm not really a fan of the 'magic' introduced that makes it work via direct DOM manipulation on updates. It seems suspiciously like that's yet another source of mental model confusion that articles will be written about a couple of years from now... but overall it does seem a lot simpler for most usecases.
- penumbral 4y agoReact hooks were a huge mistake because they (along with the huge push by Gaaeron to ditch redux at the same time) disrupted the more declarative styles in React that subjectively relax the mind. Boilerplate code is tedious, but gives the brain a rest from reasoning that many developers actually enjoy. You can really get in the zone wiring up a react/redux app and isolate yourself from re-render logic by focusing on individual stores, reducers, and action logic. The hooks people came in and said F all that, lets instead create an API that garbles up all the code in one spot, with imperatively nested functions required for more complex use-cases, oh and lets use CONTEXT for state management and just partition items up to deal with re-renders. They didn't do it on purpose, the react team is highly skilled, but they lacked the wisdom to understand how lower tier or mid-tier developers would use it. I knew plenty of devs that had 3-4 YOE and couldn't grok hooks for years.
- horsawlarway 4y agoI go back and forth on this - overall, I don't think hooks were a technical mistake (it's a fairly clean way to share code that is not cleanly shared in class components) but... I they accidentally knock a LOT of developers out of the pit of success. Overall - I think they accidentally made React apps a lot more unwieldy. My sweet spot for React was when it was class based components mixed with purely functional components. That combo led to all sorts of "happy accidents" in developer productivity. Logic that needed state tended to be clumped into a relatively small number of class based components, developers actively wanted to avoid adding state to new components because they had to write a lot more code to do it. So you end up with a structure that looks like several small trees in the code: A single class based component managing the state for several pure function components under it. Overall - this was a fairly happy spot to be. State is contained, performance is usually pretty predictable, pure mappings are encouraged. Hooks... well - they made state too easy again. Now adding state to a new component isn't a 20 line change (conversion to class). It's just dropping a new "useState()/useEffect()" call in near the top. Very easy. So easy you no longer really think about why that might not be such a great idea. Now you end up with state creeping through the entire component tree. Renders are hard to predict because any parent component might re-render at any point, you're neck deep into useMemo and useCallback to try to prevent all those extra renders from really killing performance. This is not such a happy place to be. Can those downsides be avoided? Of course. But developers no longer fall into the right path by default. You have to wrangle them there, and that's a huge downside.
- fabian2k 4y agoHaving a good way to compose stateful behaviour in React components is really useful. The alternative is a mess of higher-order components which quickly gets very annoying and tedious. Hooks provide that ability, and they make a lot of cases much easier to write. Hooks also have some behaviour that makes them harder to understand in certain situations. Closures are quite easy to get wrong, and handling callbacks is quite annoying because they're not stable by default. I think the timeout example is not ideal, it uses useEffect to handle an event, which is not the way this is supposed to be done and which does lead to various complications. But timeouts are the kind of thing that is much more difficult in hook-based React than it should be. But I don't think this is representative, it's a bit more like a worst case for React for things that should be simple but aren't. You don't write timers all day, you put this in a hook once and write other stuff.
- bayesian_horse 4y agoThere should be a meme for "useEffect is not an async framework".
- weevil 4y agoDuring the original hype over hooks, I vividly remember thinking: 'I wonder how long we'll wait before these too are reviled.' We're getting there.
- thrwy_918 4y agoOne of the promises of using hooks was that you wouldn't have to care about things being recreated every render. Gone were the days of complex update logic in lifecycle methods like `componentWillUpdate()`, `componentWillReceiveProps()`, `componentDidReceiveProps()` etc. Now you use clean, functional components everywhere, even if they needed local state. No kludge, just clean code. But most of the production functional React code I see is sprinkled so liberally with complex `useCallback()`, `useMemo()` and `useRef()` calls to prevent unnecessary updates that it seems just as bad as before. Worse, sometimes, because the hooks pattern can encourage more indirection. I still find myself thinking all the time about object references in state, cloning vs. mutating, dependency arrays with 5, 6, 7 distinct dependencies. Honestly, I don't know if it's any better than it used to be. At least the `componentDidReceiveProps()` logic tended to all be in one place.
- penumbral 4y agoI agree with this take! And class-scoped callbacks kept the render function so clean, I feel like hooks really muddled up the API with regards to render. It also created far-more proprietary-to-React logic.
- andix 4y agoMost of the usecallback or usememo you should try to remove. They are usually there to fix some other rendering issues (mostly performance). But I also don’t understand, why react renders all child components if the parent renders. As long as their props stay the same, they should just stay as they are.
- bluefirebrand 4y ago> But I also don’t understand, why react renders all child components if the parent renders. As long as their props stay the same, they should just stay as they are. It "renders" all child components if their parent renders in order to check if their props have changed or not. If the component has not actually changed, it does not actually re-draw it.
- awkward 4y agoIf react, and specifically react using functional components, is going to be a full featured web framework, hooks or something like them are necessary to integrate with the browser and the web of 2023. The 101 parts of functional programming are a very easy pitch. Stateless behavior, testable functions, no surprising side effects from way down the tree. When it gets to 201 stuff - boxing (like useRef) and dispatch (like useState) complexity creeps back in. That complexity is necessary, however, because that's the stuff people actually want to do. Hooks let react interact with browser audio and video, mapping tools, and other things that are reasons why people want to use web pages. They're complex, but there are limits to how simple a bridge between a functional programming framework and a mostly stateful host system can be.
- user3939382 4y agoIMHO best-case scenario with React is there's a lot of "you're holding it wrong" in which case we have to ask ourselves, is it that most programmers aren't skilled enough or that the tool is designed wrong? Both are possible but the latter is in general more likely. I also think there's an issue where react was made to solve Facebook's problems and we're not Facebook.
- frank_bb 4y ago[dead]
- fwlr 4y ago“Put another way: class components have a single instance per mounted component, but function components have multiple “instances” — one per render. Hooks just further entrench that constraint. It’s the source of all your problems with them” I see this a lot, it’s probably the misunderstanding that drives most of the dissatisfaction with hooks. Having a single instance that exists for the whole lifetime of the mounted component was a major advantage of class components, the major drawback being that you kept losing immutability. The big advantage of functional components is they give you all that immutability, their drawback is you no longer have a single instance that corresponds to the mounted component’s lifetime, because functions are just executed and then they’re gone (until the next time you execute them). The way to think about hooks is that React will create a internal virtual instance that does correspond to the lifetime of the mounted component, and it will let you hook into that virtual instance from the function (to store state, effects, refs, etc). The idea was that way, you can have both immutability and single-instance-per-lifetime benefits. Because React is managing all of these internal virtual instances itself, it can do some nice magic like letting you use a clean top-level “useState” function and it Just Works… because behind the scenes it is pairing up each call to that function with each internal virtual instance (using its order in the call stack, which means the magic fails if hooks are called conditionally, hence the rules of hooks). That’s fundamentally the concept that lets you work with hooks fearlessly. You no longer had to provision each of your class components with their own instance and make sure they were maintaining it properly, instead your function components could just clock in and clock out and React would take care of making sure they were handed the right instance to work with. If I had to pinpoint the exact mistake React made with Hooks, it was this: saying you could emulate componentDidMount with useEffect(fn, []). It completely obscures this idea of a virtual instance you’re hooking into. They should have been explicit about the virtual instance model and given developers “useDidMount(fn)” and “useWillUnmount(fn)” hooks, explaining that for each function component you write, React is managing an instance for it behind the scenes and React will make sure it runs the provided mount and unmount functions at the appropriate moments in that instance’s lifetime. One can imagine a hybrid option, a lightweight class definition (so you could set state in constructor, define DidMount, make refs, etc., in the natural way) that would then return a functional component. That would make the long-lived instance explicit, but I think the ergonomics would unfortunately suck: “render() { return function (props) { return <div/> } }” is hideous, for example.
- rk06 4y agomods, can we ban these React bashing threads which seem to pop up every other day? another recent thread[0] I get that react is full of problem and many people have to suffer because of it. But we are not even attempting to change status quo here. This thread merely serves as place to rant. and then go back to same problems. At this point, i have most of the opinions memorized and i am not even a React dev. PS: if people are really into React/vue/angular rants, then have a monthly thread for it. [0] https://news.ycombinator.com/item?id=35061672 https://news.ycombinator.com/item?id=35061672
- 5Qn8mNbc2FNCiVV 4y agoIf this was code I'd have to review I'd give the feedback that the wrong information is kept in state. After start the only thing the setTimeout should do is set the game to be finished and then show the final count to the user. If the code wouldn't have used an alert which definitely is a side effect of a function it gets apparent where the code went outside of the React loop. Not defending that but saying that alert and console.log conflict with React's always re-execute approach and for those cases, as you would have guessed, you can use useEffect and only listen to the finished state to execute your alert. Throwing a console.log/alert into the direct function body of a component just asks to be spammed by rerenders (assuming the average developer)